Если есть какая-то api От него то можно или как вариант написать софтинку и через сокеты с браузером обмениватьс и отсылать данные на ком или юсб

сомневаюсь,что они дают доступ к нему

ну эта дичь стоит у клиента в локальной сети) а у меня облачное приложение с N клиентами

пусть принтер чеков покупают)

сталкивался, с помощью JS формировал чек и отправлял на печать

делаю patch запрос на обновление данных в 1С через их API, возможность на запись открыта, ответ приходит 200 но данные не меняеются, может кто-то заметит ошибку?

не сохранилось кода никакого?)

https://printjs.crabbly.com/#documentation Вот либа, которую юзал
на вью создал компонент, куда передавал item и формировал чек

спасибо

у нас чеки кассовый аппарат сам печатает, но есть ещё принтер этикеток Zebra, к нему из облака по ключу открывается SSH-туннель, и в порт кидается текст на ZPL.
жесть, но другого решения я не нашёл =)

и в такой реализации ты не можешь управлять какой принтер выбирать на печать, и какой размер бумаги используется
все это надо будет пользователям самим выбирать

Ребят, а как можно подгрузить eager loading-ом сложные отношения. Проще на примере.
Есть комплект документов (DocumentSet)
у него есть отчет (Report, DocumentSet hasOne Report)
у отчета есть события (Report hasMany Events)
у события есть люди (Events belongsToMany Person)

И нужно чтобы у комплекта документов возвращались люди. Причем так как между event и person есть pivot таблица, там еще и по ней по флажку нужно фильтровать

И это все вернуть в списке комплектов документов, то есть между комплектом и людьми опосредованная связь

Ну вложенные отношения просто через точку model->with('relation.nestedRelation.nestedRelation')

ну это да
но смотри
documentSet.report.events.persons
Он мне загрузит и отчет, и иветы и людей, причем всех людей

Ну и получается что условно для 10 записей 100500 кбайт возвращается, ибо много всего подгрузилось)

А вот условия, это надо колбеки использовать

хотелось бы как получить это в виде documentSet.persons как бы

Аа

причем я получу всех персон всех мероприятий, они могут повторяься, а мне уникальные нужны)

предпочитаю позволять ОРМу только простые запросы.
для таких сложных — делай сам огромный SQL-запрос (на несколько экранов), который тебе в списке комплектов вернёт уже все потроха  собранные в JSON

ну как вариант