Прямая интеграция Честный знак (мясная продукция) в 1С: БП 3.0: наработки, живущие на практике

СЕРВЕРНАЯ версия! НЕ считается окончательным рабочим расширением! Наработки по прямой интеграции Честного знака (trueAPI, API СУЗ 3.0) в БП 3.0, успешно используемые на потоке. Реализована автоматика до ввода в оборот, то есть успешная автоматическая отправка отчетов о нанесении без участия пользователей, получение кодов маркировки по регламенту на основании порогов пополнения в карточке номенклатуры - открытие заказов, забор кодов, закрытие заказов, проверки на потерянные блоки заказов при потерях соединения и прочая логика. Расчет на возможность скачивания больших объемов согласно документации API: 10 GTIN по 150000 в одном заказе. Печать КМ из товарной накладной по факту количества штук и динамическое взвешивание там же.

Можно применять под любую категорию Честного знака, просто я ленивый такой засунул в код размерности мясной продукции и не вынес в настройки.

ВАЖНО! Потребует КриптоПро на сервере 1С и CADES-plugin там же для прямой работы с УКЭП. По сути подписание происходит вне 1С.

В Регистре АС_НастройкиИнтеграции (скриншот, выведен в пользовательском меню, сделал для отладки) прописываются настройки вашего ЛК Честного знака и отпечаток ЭП. Токены СУЗ и API будут прописываться при регламентных обновлениях каждые 8 часов (или чаще, уже и сам не помню).

В карточках номенклатуры достаточно заполнить GTIN из Национального каталога и пороги автопополнения КМ. GTIN должен быть в статусе "опубликован". 

Автоматическая отправка отчетов о нанесении возможна только в том случае, если будет наполняться и сопоставляться регистр АС_ДанныеРТУМеркурий - в моем случае это обработка частной фирмы, через которую работают ветеринары, я запросил доработку для возврата значений даты производства и срока годности в свой регистр при оформлении накладных в Меркурии. Этого уже достаточно, чтобы спокойно отправлять отчеты о нанесении с валидными датами, так как отчет требует набор КМ в теле запроса плюс две этих даты - объединить можно до 30000 КМ, которые имеют одинаковые даты производства И срока годности. У меня реализовано дробление регистра отправки КМ (АС_КМ_Нанесенные) на триады документ-дата1-дата2, далее идет отправка, пишется полученный reportid, затем опрашивается его статус. При успехе КМ переносятся из Нанесенных в следующий регистр для ввода в оборот. Который я почти ввёл, но... не ввёл ещё. До 1 сентября надо ввести - там уже его все затребуют в рознице. 

Под капотом дофига логики, которую я мало того что тут не опишу, так я и половины уже не вспомню сам - делал это в одиночку + Gemini натаскивал на свой код, иначе бы только писанина отняла вдвое больше времени. Gemini любит облажаться, выдать за действительное ложные решения, когда не знает ответа, поэтому много проверок, много отладки, много тестирований. Пользовательскую логику как мог тестировал сам, изначально всё было в разы неудобнее. 

Расширение писалось на серверной платформе, как поведет себя в файловом варианте понятия не имею - все оптимизации наподобие запроса полутора миллиона кодов я делал исходя из серверной архитектуры.

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

Причиной разобраться в этой всей фигне самостоятельно стал факт крайне неудобного и времязатратного механизма весовой печати у предлагаемых решений маркировки на рынке, которые вообще не подходили под реалии моего работодателя. Плюс небольшие объемы и необходимость напечатать здесь и сейчас непосредственно перед отгрузкой или в процессе подготовки к отгрузке незадолго до. Собственно, результат. Совсем не окончательный, требуется доделывать и доделывать, используются только основные методы API (ну, чуть больше, чем основные), но "IT'S ALIVE!!! \o/"
Можно адаптировать под себя. Даже нужно! Как пример - мне достались весы CAS, интерфейс USB. Драйвера 1С нет. Кстати в БП3.0 нет механизма работы с весами, но я его внёс и перенес нужные модули работы с весами, выдернув из УНФ (протестирован штатный механизм адаптации из УНФ на весах Mertech). С CAS пришлось творить чудеса, прописывая переменную среды VES_PORT, которая содержит в себе COM1...3, на каком весы повисли. Далее идет опрос виртуального COM-порта весов, которые взведены в непрерывную передачу. Только эти данные считываются через COMОбъект("MSXML2.XMLHTTP"). 

Для корректной работы в целом автоматических заказов и отчетов должна быть УКЭП, под которой мы ходим в ЛК Честного знака. Эту УКЭП нужно поселить в хранилище пользователя, под которым крутится служба агента 1С, либо можно переписать параметры на хранилище локальной машины вместо пользователя. 

Спасибо за чтение :) 

UPD: Добавлен опрос производственного ВСД через ВЕТИС.API через транспортный ВСД.
Необходимость - есть транспортные ВСД, нет производственных для автоматического ввода в оборот.
Выбираем данные транспортного документа через <merc:getVetDocumentByUuidRequest>, затем запрашиваем список производственных ВСД за нужный день через <merc:getVetDocumentListRequest>.
Тело ответа сохраняется для последующего чтения XML других наших ВСД за этот день. На help.vetrf.ru пока что "Фильтр по связанным документам. Будет реализован в следующих версиях.", поэтому фильтруем по ключевым параметрам узлов, получая производственный ВСД на выходе. 
Сделал разбивку ввода в оборот: было - весь документ в одном теле, стало - отдельные вводы в оборот по номенклатурам. Причина: ввод в оборот отклоняется полностью, если хоть одна запись не проходит. В моем случае обычно по номенклатуре при сравнении с Меркурием были устаревшие данные - GTIN в Меркурии не успели назначить, к примеру. Отсюда возникал отказ по подобному производственному ВСД, а вслед за ним и вся остальная невинная пачка другого товара.