При работе с электронным документооборотом (ЭДО) в системе 1С пользователи иногда сталкиваются с аномалиями: данные в печатной форме или визуализаторе ЭД не соответствуют данным в учетной системе или различаются внутри одного документа. Одной из таких проблем является некорректное заполнение реквизита СоглашениеНомер, когда значение в шапке электронного документа отличается от значения в табличной части на одну или несколько цифр. Проанализируем, почему это происходит, и разберем алгоритм поиска ошибки в программном коде.
Первое, что нам необходимо выяснить — является ли данный реквизит стандартным для формата ФНС. Рассмотрим структуру типового электронного счета-фактуры (согласно приказам №820 или №189). В официальном формате обязательного поля с идентификатором СоглашениеНомер не существует. Это означает, что мы имеем дело с кастомной реализацией.
Проанализируем типичные причины появления таких полей:
ИнфПолФХЖ1 или аналогичные).Поскольку реквизит не является типовым, стандартные механизмы отладки 1С могут не сразу показать место ошибки. Разберем ситуацию подробнее.
Ситуация, когда номер в шапке отличается от номера в строках табличной части, чаще всего указывает на разные источники данных. Рассмотрим, как это реализовано программно:
Различие источников в коде: В шапку электронного документа номер может подтягиваться напрямую из основного реквизита ДоговорКонтрагента. В то же время в табличную часть данные могут попадать из связанных документов-оснований, таких как ЗаказПокупателя. Если в процессе подготовки реализации один из заказов был изменен или перевыбран, а данные в шапке остались прежними, возникает конфликт версий.
Программная ошибка в цикле формирования XML: Рассмотрим пример кода, который часто встречается в доработках формирования ЭД. Ошибка может крыться в обращении к индексу строки или некорректном кэшировании:
Для Каждого СтрокаТЧ Из ДокументОбъект.Товары Цикл
// Ошибка может быть здесь: берется номер из связанного объекта,
// который был неверно итерирован или выбран
ДанныеСтр = ПолучитьДанныеСоглашения(СтрокаТЧ.ЗаказПокупателя);
ЗаписатьТекстовыйУзел(УзелТабличнаяЧасть, "СоглашениеНомер", ДанныеСтр.Номер);
КонецЦикла;
Если номер "убегает" на единицу, проанализируем, не используется ли в системе автогенерация номеров при создании документов через внешние обработки.
В старых конфигурациях (например, 1С:УПП) или сильно кастомизированных системах поиск модуля, отвечающего за ЭДО, может быть затруднен. Если стандартный модуль ЭлектронныеДокументыЭДО отсутствует, выполним следующие шаги:
Это самый эффективный метод. Нажмем Ctrl+Shift+F и введем строку "СоглашениеНомер". Обязательно используем кавычки, так как мы ищем строковую константу, которая записывается в XML-тег. Проанализируем результаты:
ЭлектронныеДокументыПереопределяемый или БЭД_ВыгрузкаДанных, значит, логика зашита в механизм формирования транспортного контейнера.РеализацияТоваровУслуг, СчетФактураВыданный), проверьте процедуры Печать или специализированные экспортные функции.Часто функционал заполнения специфических полей выносится во внешние обработки. Проверим справочник "Дополнительные отчеты и обработки". Также выясним, не используется ли механизм Подписки на события. Для этого в конфигураторе найдем узел "Подписки на события" и просмотрим те, что привязаны к источнику ДокументОбъект.РеализацияТоваровУслуг или ДокументОбъект.СчетФактураВыданный на событие ПередЗаписью или ПриУстановкеНовогоНомера.
Если в системе используется нетиповой механизм заполнения, такой как "Копирование заказов", проанализируем его программный код. Часто такие инструменты "умного" копирования пытаются автоматически инкрементировать (увеличивать на единицу) номера договоров или соглашений при создании новых цепочек документов. Это и может быть причиной того, почему в табличную часть попадает номер, отличающийся от основного документа.
Чтобы окончательно локализовать ошибку, выполним следующие действия:
XML, Выгрузка или Сведения.ЭтотОбъект и в структурах, которые готовятся к отправке.Важный совет: Если вы обнаружили, что данные подтягиваются из Заказа покупателя, проверьте, нет ли в этом заказе скрытых реквизитов или дополнительных сведений, которые могут содержать "старый" или ошибочный номер соглашения. Исправление может заключаться не в изменении кода, а в очистке некорректных данных в документах-основаниях.
Таким образом, мы выяснили, что проблема расхождения номеров соглашений в ЭДО — это следствие кастомной доработки под требования контрагентов. Используя глобальный поиск по строке тега и отладку модулей выгрузки, можно оперативно найти и исправить логическую ошибку в заполнении табличной части электронного документа.