Нужен файлик примера УПД через ЭДО с табаком для розницы : Маркировка

Держи тогда ещё одну задачку)

Отправили 50 штук и 60 штук одинаковых сигарет, но с разным МРЦ.
В теге перечислены идентичные блоки, в кол-ве 11 штук, 5 для одного мрц и 6 для другого. Комментировать отказались.

Миниатюры

 

А с какой целью парсите УПД? Записываете КМ в учетную систему?

У нас типовая 1С создавала дерево упаковок накладной на 30кк примерно полтора часа. Мы решили отказаться от функционала, который навязывает нам 1С.

Создали ещё одну ТЧ для документов поступления-реализации и записываем туда "факт" в строчном формате.

По сути, комплектовщики "собирают" все сиги на ТСД, которые разгрузили по накладным. Затем данные выгружаются в 1С в ТЧ, на скриншоте. Для документов создал два реквизита - проверено и расхождения. После заполнения ТЧ оператор, с помощью обработки, проверяет "факт" с данными из УПД. Если всё окей - проверяем данные в ЦРПТ. Если всё окей - ставим булево "проверено". Если на каком-то из этапов есть проблемы - ставим галку "расхождение" и запрещаем оборот(проведение), до устранения расхождений.

Экономим ресурс базы и сервера :)

Такая же история при отгрузке, только без проверки УПД. Лично на мой взгляд - нецелесообразно, но будет полезно использовать это в переговорах с торговой точкой, которые всё ещё боятся принимать товар без собственной проверки - которую не могут реализовать.

Миниатюры

 

А что за конфигурация? Любопытство проснулось)) Я думал 1С уже ничего не поддерживает на обычных формах, кроме БП 2.0 в части рег учета.

Не... Не вижу смысла хранить КМ в УС, дублирование учета... Достаточно того, что в ЛК ЧЗ все есть. Если когда-то, в будущем и будут расхождения(а они обязательно будут!), то все равно хрен им чего докажешь... Пусть будет учет на их стороне, и ладно, будем на него ориентироваться.
А парсю - для того, что-бы при приемке, ПРИ ЖЕЛАНИИ, можно было проверить соответствие КМ принимаемых блоков сканированием... Ну, и второе - что-бы путем разагрегации КМ блока вытащить ШК пачки(интересует только ЕАН) для учетной системы. Ну, и опять-же, после запроса разагрегации, ПРИ ЖЕЛАНИИ, можно марки пачек сканированием проверить, так, как они там полностью в списке хранятся до закрытия формы(естественно, в том виде как прилетели - т.е. без криптохвостов).

PS По времени - разагрегация делается мгновенно - особенно если запрос не первый в час(при первом запросе происходит получение токена, а это несколько секунд. Дальше, токен сохраняется в файл(+ время его получения) и при следущем запросе, проверяется время его получения. Если еще не "протух", используется он, если час прошел - то запрашивается новый)...

Это уже проходил с ЕГАИС. У меня помарочный учет на отдельном регистре ведется, и марки в отдельном справочнике хранятся... За все время, так никому и не понадобился...

Еще раз - все, что я выше написал - касается розничных магазинчиков, где выбытие КМ идет через кассы, конечным "курильщикам". Для опта - ИМХО такой подход не подойдет.

1С:Предприятие 8.3 (8.3.12.1714) (10.3.8.9)

Она ничего и не поддерживала, пока я не перенёс подсистему маркировки с демо-версии. Функционал подписи бобра, для авторизации в ЦРПТ, подсмотрел в документациях библиотеки крипто-про.

Основная проблема была с зависимостями общих модулей и новых объектов конфигурации (справочник ШКУ, перечисления). Всё что ломалось - //комментировалось, всё что было необходимо для корректной синергии модулей - допиливалось. Например почти все модули подсистемы ИСМП(МОТП) перед каждым обращением к API проверяют токен авторизации. Данный функционал заменили на заглушки или вызовы своих функций подписи ключа.

На самом деле, самое сложно - заменить все вызовы функций СтрРазделить, СтрНайти, СтрШаблон на их аналоги, поскольку их поддержка началась с 8.3.16 (по-моему), а конфигурация запущена в режиме совместимости с 8.3.12.

Но ведь если не докажите, то не смениться собственник в ЦРПТ, а стало быть - при реализации товара, который вам не принадлежит, к кассиру могут появится вопросы.
Мне хочется верить, что ЦРПТ будет блокировать УПД в случае, если перечисленные в ней КМ - не принадлежат продавцу, но тот дурдом, свидетелем которого мы все стали за предыдущий месяц - готовит меня к худшему

Кстати, ГИСМТ обновили API получения содержимого агрегата. APIV2 стал возвращать какие-то идиотские ошибки -

При отправке запроса private-office-api/private/v2/cis/aggregated?cis=%2801%2904606203097074%2821%29WYROFm%3B возникла ошибка.
Текст ошибки: Код состояния : HT*P 500..

В оригинале " 010460620309707421WYROFm; "

А точка с запятой (0x3B) в конце кода нужна?

Да, это часть КМ.