В процессе работы с маркированной продукцией, особенно в табачной отрасли, технические специалисты часто сталкиваются с проблемой "исчезновения" марок. Поставщик утверждает, что отправил все коды (пачки и блоки), а в программе 1С (например, в конфигурации Рарус: ТКПТ или Управление торговлей) отображаются только коды верхнего уровня агрегации. Разберемся детально, как устроено хранение электронных документов в 1С, на каком этапе могут теряться данные и как проверить содержимое исходного XML-файла.
Для начала проанализируем, где именно система 1С сохраняет данные, полученные от оператора ЭДО. В современных конфигурациях, построенных на Библиотеке стандартных подсистем (БСП), электронные документы не хранятся в виде обычных текстовых полей. Рассмотрим основные места хранения:
ХранилищеЗначения.Важно понимать: документ попадает в базу 1С с сервера оператора ЭДО в том виде, в котором его сформировал отправитель. Операторы (такие как Калуга Астрал, Тензор или Контур) обычно не модифицируют тело XML-файла, так как это нарушит электронную подпись документа. Если марки "обрезаны", это либо произошло на стороне поставщика при формировании файла, либо это особенность визуализации данных в самой 1С.
Разберем ситуацию с точки зрения методологии "Честного знака" (ГИС МТ). Для табачной продукции действует правило агрегации. Проанализируем основные причины отсутствия детальных кодов в документе:
1. Агрегированный формат передачи. Согласно приказу ФНС №820, в электронном УПД в блоке НомУпак достаточно указать только код транспортной упаковки (блока или короба). Система маркировки автоматически "знает", какие пачки привязаны к этому блоку, если поставщик выполнил агрегацию в ГИС МТ. Поэтому в самом XML-файле физически может не быть кодов 11 видов сигарет, если они упакованы в блоки.
2. Особенности парсера 1С. При загрузке XML программа считывает теги <НомУпак>. Если конфигурация (например, Рарус: ТКПТ) настроена на работу с ИС МП, она должна отправить запрос к API "Честного знака" (True API), чтобы получить состав агрегата. Если этот запрос не прошел или в системе маркировки связь "блок-пачка" отсутствует, 1С покажет только то, что есть в файле.
3. Проблемы на стороне поставщика. Если поставщик некорректно выполнил агрегацию (например, засунул разные виды продукции под один код блока), то при получении состава блока через API вы увидите именно эту некорректную информацию.
Чтобы выяснить, на каком этапе пропадают данные, необходимо проанализировать исходный файл. Рассмотрим пошагово, как это сделать:
НомУпак.Если в файле из ЛК оператора кодов пачек нет, значит, поставщик их не передавал. Если же в файле коды есть, а в 1С они не отображаются — проблема в обработке загрузки данных в вашей конфигурации.
Если вам необходимо программно проверить содержимое прикрепленного файла в регистре 1С, используйте следующий подход для извлечения двоичных данных:
// Пример получения двоичных данных из хранилища
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПрикрепленныеФайлы.ДанныеФайла КАК Данные
|ИЗ
| РегистрСведений.ПрикрепленныеФайлы КАК ПрикрепленныеФайлы
|ГДЕ
| ПрикрепленныеФайлы.ВладелецФайла = &Владелец";
Запрос.УстановитьПараметр("Владелец", СсылкаНаЭлектронныйДокумент);
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Если Выборка.Следующий() Тогда
ДвоичныеДанные = Выборка.Данные.Получить();
// Если данные сжаты в ZIP (часто для ЭДО), их нужно распаковать
// Далее сохраняем во временный файл для анализа
ИмяФайла = ПолучитьИмяВременногоФайла("xml");
ДвоичныеДанные.Записать(ИмяФайла);
КонецЕсли;
Обратите внимание, что в современных версиях БСП для получения файлов лучше использовать программный интерфейс модуля РаботаСФайлами. Это гарантирует правильное извлечение данных вне зависимости от того, хранятся они в базе или в томах на диске.
В решениях от Рарус механизмы работы с маркировкой могут иметь дополнительные настройки. Проанализируем, на что обратить внимание:
Совет: Если вы обнаружили расхождения, попросите поставщика выгрузить XML напрямую из его 1С (через сохранение документа в файл) и сравните его с тем, что пришло по каналам ЭДО. Это поможет локализовать проблему: либо это ошибка формирования УПД в Управлении Торговлей поставщика, либо это "обрезание" данных при передаче через хаб оператора (что случается крайне редко, но возможно при использовании специфических провайдеров).
Выясним причину "пропажи" марок окончательно: чаще всего это не ошибка программы, а стандартная работа механизма агрегации. Чтобы убедиться в корректности поставки, следуйте этому алгоритму:
1. Сверьте количество блоков в XML и физически на складе.
2. Сделайте запрос в ГИС МТ по коду одного из блоков, чтобы увидеть, какие пачки за ним числятся.
3. Если состав блока в ГИС МТ не соответствует реальности, необходимо оформлять акт расхождений, так как юридически к вам перешли только те коды, которые указаны в системе маркировки, независимо от того, что написано в бумажной накладной.
Для глубокого изучения вопроса рекомендуется ознакомиться с документацией True API от ЦРПТ, где описаны методы /cism/info для получения детальной информации о кодах и их иерархии.