← На главную

При обновлении Универсального транспортного модуля (УТМ) до актуальных версий формат входящих накладных автоматически переключается на вторую версию (v2). Пользователи конфигурации 1С:Розница 1.0 при этом сталкиваются с ситуацией, когда входящие документы видны в веб-интерфейсе УТМ, но при выполнении обмена программа сообщает: «Загружено документов 0». Разберем причины такого поведения платформы и пошагово выясним, как адаптировать типовую конфигурацию под обновленный формат обмена.

Причина возникновения ошибки «Загружено документов 0»

Проанализируем механизм обработки входящих сообщений в «1С:Розница 1.0». Типовой алгоритм разбора XML-файлов из УТМ жестко привязан к пространствам имен (namespaces) первой версии документов: http://fsrar.ru/WEGAIS/TTNSingle и корневому тегу ns:WayBill.

Когда транспортный модуль передает накладную формата v2 (схемы TTNSingle_v2 и тег ns:WayBill_v2), встроенный парсер не находит совпадений ни с одним зарегистрированным в метаданных типом XDTO. В результате обработчик просто игнорирует неизвестный XML-документ без генерации критического исключения и завершает сеанс загрузки с нулевым результатом.

Варианты решения проблемы

Существует три основных подхода к восстановлению обмена с ЕГАИС:

1. Переход на типовую конфигурацию «1С:Розница 2.x» — штатный путь, рекомендованный разработчиками, однако требующий полного переобучения кассиров и адаптации кастомизированного РМК на обычных формах под управляемый интерфейс.
2. Использование промежуточного шлюза или внешней обработки — приемка документов происходит во внешней обработке (или отдельной вспомогательной базе), после чего создаются типовые документы ПоступлениеТоваров.
3. Самостоятельная доработка «1С:Розница 1.0» — перенос схем обмена и логики парсинга из конфигураций-доноров на обычных формах (например, из 1С:Управление торговлей 10.3 начиная с релиза 10.3.42.1).

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

Пошаговый план доработки конфигурации

Разберем по шагам, какие изменения необходимо внести в дерево метаданных конфигуратора.

1. Обновление и добавление пакетов XDTO.

   В ветке ПакетыXDTO необходимо актуализировать базовые схемы и добавить новые:

   1. Обновим базовые пакеты EGCommon и EGCommonEnum.
   2. Добавим пакеты второй версии: TTNSingle_v2, WayBill_v2, ClientRef_v2, ProductRef_v2, WayBillAct_v2.

   Все схемы можно экспортировать в виде файлов .xsd из конфигурации «1С:Управление торговлей 10.3» (релиз 10.3.42.1 или выше) и загрузить в «Розницу 1.0».

2. Доработка реквизитного состава справочников и документов.

   Формат v2 вводит новые обязательные поля для алкогольной продукции и классификаторов. Проверим и добавим следующие реквизиты:

   1. В справочники классификаторов ЕГАИС: реквизит ФорматОбмена (для разделения обработки версий v1 и v2).
   2. В табличные части документов и справочник номенклатуры/алкогольной продукции: емкость тары (Capacity), объемная доля спирта (AlcPercent), а также тип продукции UnitType со значениями Packed (фасованная) / Unpacked (нефасованная).
   3. В структуру хранения справок к ТТН: формат v2 заменяет связку справок «А» и «Б» на единую структуру с ключевым идентификатором InformF2RegId (справка 2).
3. Перенос логики из общих модулей интеграции с ЕГАИС.

   Необходимо обновить код в общих модулях, отвечающих за разбор входящих XML-пакетов и генерацию исходящих сообщений. Переносим функции парсинга из модуля ИнтеграцияЕГАИС (или аналогичного) конфигурации УТ 10.3. При этом важно скорректировать условия выбора схемы при формировании объектов XDTO.

4. Адаптация формирования актов подтверждения и расхождений.

   Обратите внимание: если накладная пришла в формате v2, ответный акт (подтверждение, отказ, акт расхождений) обязательно должен быть сформирован по схеме WayBillAct_v2. Отправка акта первой версии на накладную v2 приведет к ошибке формата на стороне ЕГАИС.

Рекомендации по отладке и безопасности данных

При тестировании алгоритмов загрузки важно учитывать поведение УТМ относительно очереди входящих сообщений:

В типовых модулях после считывания XML-документа отправляется HTTP-команда DELETE по адресу сообщения в УТМ. Если на этапе отладки в коде разбора возникнет непредвиденная ошибка, документ уже будет удален из буфера УТМ, и его придется запрашивать повторно через запрос переотправки (QueryResendDoc).

На время разработки и отладки закомментируем вызов процедуры удаления сообщений из транспортного модуля. Возвращать команду DELETE следует только после того, как убедимся, что накладные формата v2 корректно десериализуются в объекты информационной базы.