Коды маркировки из Диадока в 1С:ERP: как склады без сканеров принимают маркированный товар по УПД

Коды маркировки попадают из Диадока в 1С:ERP только вместе с документом приобретения, а его бухгалтерия создаёт уже после того, как склад принял товар. Крупная строительная компания упёрлась в это, когда начала закупать маркированную электронику: сканеров на объектах нет, и кладовщик принимает коробки, не видя кодов. Так легко принять маркируемый товар без маркировки. Мы сделали расширение, которое само забирает УПД с кодами из Диадока по API, и кладовщик создаёт приходный ордер уже с кодами. Остатки кодов ведутся в 1С вместе с номерами ГТД и подбираются в отгрузку.

Клиент — крупная строительная компания: несколько тысяч сотрудников, десятки объектов, несколько юрлиц на 1С:ERP редакции 2.5. Чтобы строительство шло по плану и графику, на объектах всегда должно быть в нужном количестве оборудование и материалы. Приёмка, хранение материалов и оборудования происходят непосредственно на объекте. Поэтому каждый объект — это своеобразный удалённый склад.

Приёмка ресурсов на объектах была устроена так: товар приезжает в соответствии с заказом, который делали поставщику. На объекте подписывают УПД, сканируют его и отправляют скан в бухгалтерию. На основании УПД бухгалтерия создаёт «Приобретение товаров и услуг» и подписывает УПД в Диадоке. Такая схема работы была устоявшейся и всех устраивала. До тех пор, пока на некоторые товарно-материальные ценности (ТМЦ) не ввели маркировку.

Приём маркированных товаров сломал прежнюю схему работы. Дело в том, что коды маркировки на оборудование и материалы приходят от поставщиков по ЭДО в Диадоке и появляются в 1С, только когда создают документ приобретения. По внутренним регламентам приобретение может создаваться только бухгалтерией и после фактической приёмки товара. Так и работало в старой схеме.

По новой схеме наоборот: чтобы получить коды маркировки, нужно сначала оформить приобретение ТМЦ в 1С, а потом фактически принять товар. Получается, что на объекте не могут принять поставку, потому что не видят кодов маркировки в программе, а коды бухгалтерия не может загрузить в ERP по бизнес-процессу, потому что поставка ещё не принята. Замкнутый круг.

В итоге:

• Кладовщик принимает товар вслепую. Он не видит кодов в 1С и не может проверить, соответствует ли товар и коды маркировки из поставки товару, который указан в электронных документах. Многие поставщики сами не знают, что их товар маркируется, и маркируемое можно принять без маркировки.
• Сканеров нет и не будет. Поставить сканер на каждую стройплощадку нереально. Принимать можно только по данным из Диадока.
• Брать коды из XML — не подходит. Открывать XML-файл УПД, искать в нём коды и переносить их руками — не вариант. Это трудозатратно, требует технических навыков и понимания структуры документа. Легко ошибиться, если позиций много.

Заказчик сформулировал задачу: коды из Диадока должны оказаться в 1С раньше приобретения, на этапе приёмки, и дальше жить в учёте до отгрузки.

То есть сначала на основании документов ЭДО коды создаются в 1С, происходит приёмка товара, сверка кодов. Если всё в порядке, создаётся приобретение. Если есть замечания, сотрудники отправляют их поставщику, а поставщик исправляет УПД и отправляет заново скорректированный.

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

Обработка загрузки УПД работает по расписанию фоновым заданием, но при необходимости пользователь может загрузить данные вручную. Она берёт из Диадока входящие УПД за последние несколько дней (глубина задаётся в настройке), извлекает из них XML и разбирает: поставщик с ИНН и КПП, товары, коды маркировки, номера ГТД, страна происхождения, сумма. Документ, который уже загружен, повторно не создаётся.

Чтобы загрузить данные УПД, достаточно нажать одну кнопку — «Загрузить УПД с портала Диадок». Подгружаются все УПД за период. Документы, в которых есть маркируемая продукция, отмечены флажком «Есть марки».

При загрузке УПД отсекается всё лишнее:

• пропускаются УПД с отгрузкой конечному потребителю: коды в них не переходят к новому владельцу, а выбывают из оборота;
• аннулированные документы не загружаются.

Для чтения УПД сертификат электронной подписи не нужен: хватает учётной записи Диадока, подпись нужна только для подписания. Настройки подключения (ключи доступа, ящик организации, глубина загрузки) хранятся в 1С и заводятся на любое число организаций, в коде ничего не зашито. Начинали с одной организации, но настройки сразу сделали на несколько, чтобы потом не переделывать.

Загруженный УПД превращается в отдельный документ «Марки из УПД». Этот документ нужен для хранения информации из считанного УПД, а также создания связи между этой информацией и документом «Заказ поставщику», на основании которого осуществляется поставка.

Документы «Марки из УПД» загружаются сами, а сопоставление и привязку к заказу проверяет человек. Это обязательное условие: контроль разнесения данных в 1С остаётся за сотрудником. От сотрудника требуется заполнить недостающие поля и сопоставить номенклатуру.

Выбор нужного поставщика, чьи товары загрузились в документ, происходит по реквизитам, автоматически при нажатии на кнопку «Найти поставщика и контрагента»: сначала по ИНН и КПП, потом по наименованию.

Заказ поставщику, на основании которого происходит поставка товара, подбирается автоматически по совпадению состава и числа строк. Если по каким-то причинам заказ поставщику не будет найден, можно выбрать заказ и вручную, с отбором по поставщику, контрагенту и сумме.

Сопоставление товара происходит по GTIN: он выделяется из кода маркировки и сверяется со штрихкодами номенклатуры. Не нашёлся — сотрудник может выполнить поиск командой «Найти номенклатуру» или выбрать из товаров заказа. Сопоставление можно сохранить: GTIN запишется в карточку, и в следующей поставке товар определится сам.

Когда товар приезжает на склад и происходит приёмка, сотрудник создаёт «Приходный ордер на товары».

В рабочем месте приёмки товаров рядом с типовой кнопкой создания ордера появилась ещё одна — «Создать ордер по УПД». Кладовщик видит документы из Диадока, привязанные к этому заказу, выбирает нужный, и открывается типовой приходный ордер, уже заполненный товарами и кодами маркировки.

Теперь кладовщик знает, сколько товара указал поставщик и какие коды отправил. Он видит коды у себя в программе, может распечатать и сравнить с кодами, нанесёнными на упаковку товаров.

Для остатков мы сделали отдельную таблицу учёта: какие коды есть у организации сейчас и с каким номером ГТД. Запрашивать остатки у «Честного знака» в реальном времени не стали из-за нестабильности его API.

• Приход — из документа «Марки из УПД» и из отчёта о нанесении кодов. Второй источник добавили по ходу опытной эксплуатации: часть товара компания ввозит сама и сама выпускает на него коды, и такие коды в остатки поначалу не попадали.
• Расход — реализацией и внутренним потреблением.

В реализации и внутреннем потреблении коды подбирает кнопка «Заполнить по остаткам» в типовой форме подбора марок: она берёт их из остатков по поставщику в пределах количества. В реализации кнопка «Заполнить номер(а) ГТД» ставит те номера ГТД, с которыми подобранные марки лежат на остатке.

Главная сложность проекта была не в 1С, а в связи с Диадоком. У Контура для 1С два готовых варианта, и оба не годились:

• Модуль Диадока для 1С. Техподдержка Контура ответила, что нужной функциональности в нём нет.
• COM-компонента. Контур прекратил её развитие и поддержку с 1 сентября 2026 года и сам рекомендует переходить на HTTP API. Когда мы начинали проект, до этой даты оставалось несколько месяцев: построить интеграцию на компоненте значило вскоре переделывать её за деньги клиента.

Остался HTTP API. Он сложнее, и начинается сложность с авторизации.

Бесплатно по API Контур не консультирует и отправляет за примерами на свой GitHub. Переписка с техподдержкой заняла бы недели с тем же итогом «делайте сами». Полностью без человека авторизация невозможна: это ограничение Контура, первый вход по ссылке делает пользователь. Мы искали обход, в том числе пробовали переиспользовать доступ штатной обработки Диадока, и в итоге остановились на схеме «первый вход человеком, дальше 1С продлевает доступ сама».

По ходу опытной эксплуатации всплыли ещё две вещи:

• один товар приходил в УПД двумя строками: с ГТД и кодами и с ГТД без кодов;
• по одному номеру УПД Диадок отдавал несколько документов: поставщик отправлял его повторно, а прежние версии аннулировал.

• Коды маркировки есть в 1С на этапе приёмки, до приобретения. Кладовщик видит их в приходном ордере без сканера и без доступа в Диадок. Если на маркируемый товар коды не пришли, это видно при приёмке, а не когда бухгалтерия оформляет приобретение.
• Остатки кодов маркировки ведутся в 1С по поставщикам и номерам ГТД. В реализацию и внутреннее потребление коды и ГТД подбираются из остатков, а не вручную.
• Решение работает в шести юрлицах. Новую организацию подключают настройкой в 1С, без программиста, но со своей лицензией API.
• Интеграция построена на HTTP API, который Контур рекомендует как основной путь, а не на компоненте, поддержку которой прекратили.

• Вы принимаете маркированный товар на складах, где нет сканеров, а коды приходят только в УПД в Диадоке.
• Приобретение у вас создаёт бухгалтерия после приёмки, а коды маркировки нужны складу раньше.
• В отгрузке нужно подбирать коды и номера ГТД из того, что реально лежит на остатке.

Коды маркировки лежат в Диадоке, а склад принимает товар, не видя их? Напишите — посмотрим, как у вас устроена приёмка, и скажем, что можно сделать.