Почему в электронном счете-фактуре номер соглашения в шапке и табличной части не совпадает?

Программист 1С v8.3 (Обычные формы) Управленческий учет Торговля и дистрибуция
← На главную

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

Природа реквизита СоглашениеНомер и его происхождение

Первое, что нам необходимо выяснить — является ли данный реквизит стандартным для формата ФНС. Рассмотрим структуру типового электронного счета-фактуры (согласно приказам №820 или №189). В официальном формате обязательного поля с идентификатором СоглашениеНомер не существует. Это означает, что мы имеем дело с кастомной реализацией.

Проанализируем типичные причины появления таких полей:

  1. Требования торговых сетей (Ритейл): Крупные контрагенты (например, X5 Group, Магнит, Леруа Мерлен) часто используют дополнительные информационные поля для автоматизации своей приемки. Они требуют передавать номер заказа или соглашения в специфических тегах XML-файла.
  2. Доработки конфигурации: Программисты внедряют расширения или изменяют типовые модули, чтобы принудительно вставлять эти данные в блок дополнительных сведений (ИнфПолФХЖ1 или аналогичные).

Поскольку реквизит не является типовым, стандартные механизмы отладки 1С могут не сразу показать место ошибки. Разберем ситуацию подробнее.

Выясняем причины расхождений в данных

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

Различие источников в коде: В шапку электронного документа номер может подтягиваться напрямую из основного реквизита ДоговорКонтрагента. В то же время в табличную часть данные могут попадать из связанных документов-оснований, таких как ЗаказПокупателя. Если в процессе подготовки реализации один из заказов был изменен или перевыбран, а данные в шапке остались прежними, возникает конфликт версий.

Программная ошибка в цикле формирования XML: Рассмотрим пример кода, который часто встречается в доработках формирования ЭД. Ошибка может крыться в обращении к индексу строки или некорректном кэшировании:


Для Каждого СтрокаТЧ Из ДокументОбъект.Товары Цикл
    // Ошибка может быть здесь: берется номер из связанного объекта, 
    // который был неверно итерирован или выбран
    ДанныеСтр = ПолучитьДанныеСоглашения(СтрокаТЧ.ЗаказПокупателя);
    ЗаписатьТекстовыйУзел(УзелТабличнаяЧасть, "СоглашениеНомер", ДанныеСтр.Номер);
КонецЦикла;

Если номер "убегает" на единицу, проанализируем, не используется ли в системе автогенерация номеров при создании документов через внешние обработки.

Поиск места формирования электронного документа

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

Глобальный поиск по конфигурации

Это самый эффективный метод. Нажмем Ctrl+Shift+F и введем строку "СоглашениеНомер". Обязательно используем кавычки, так как мы ищем строковую константу, которая записывается в XML-тег. Проанализируем результаты:

Анализ внешних обработок и подписок

Часто функционал заполнения специфических полей выносится во внешние обработки. Проверим справочник "Дополнительные отчеты и обработки". Также выясним, не используется ли механизм Подписки на события. Для этого в конфигураторе найдем узел "Подписки на события" и просмотрим те, что привязаны к источнику ДокументОбъект.РеализацияТоваровУслуг или ДокументОбъект.СчетФактураВыданный на событие ПередЗаписью или ПриУстановкеНовогоНомера.

Связь с обработкой Копирование заказов

Если в системе используется нетиповой механизм заполнения, такой как "Копирование заказов", проанализируем его программный код. Часто такие инструменты "умного" копирования пытаются автоматически инкрементировать (увеличивать на единицу) номера договоров или соглашений при создании новых цепочек документов. Это и может быть причиной того, почему в табличную часть попадает номер, отличающийся от основного документа.

Методика диагностики и исправления

Чтобы окончательно локализовать ошибку, выполним следующие действия:

  1. Замер производительности: Запустим замер производительности в конфигураторе непосредственно перед нажатием кнопки "Сформировать" в интерфейсе ЭДО. После формирования документа остановим замер и отсортируем список процедур по времени выполнения. Ищем функции, в названии которых есть XML, Выгрузка или Сведения.
  2. Точка останова: Установим точку останова в найденном модуле формирования структуры данных. Проанализируем значения переменных в момент обхода строк табличной части. Сравним значение в объекте ЭтотОбъект и в структурах, которые готовятся к отправке.
  3. Проверка кэша: Убедимся, что при формировании каждой строки табличной части данные считываются заново, а не используются значения от предыдущей итерации цикла.

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

Таким образом, мы выяснили, что проблема расхождения номеров соглашений в ЭДО — это следствие кастомной доработки под требования контрагентов. Используя глобальный поиск по строке тега и отладку модулей выгрузки, можно оперативно найти и исправить логическую ошибку в заполнении табличной части электронного документа.

← На главную