Почему не проводится сводный счет-фактура с кодом вида операции 27 в 1С:Бухгалтерии?

При интеграции баз 1С:ERP Управление предприятием и 1С:Бухгалтерия предприятия (БП 3.0) нередко возникает ошибка проведения входящих счетов-фактур с кодом вида операции (КВО) 27 («Сводный комиссионный счет-фактура»). Документ, успешно проведенный в исходной конфигурации ERP, отказывается проводиться в бухгалтерии, вызывая ошибку записи в регистр сведений Журнал учета счетов-фактур. Разберем механизм возникновения этой ошибки и способы ее устранения.

Анализ проблемы и архитектура регистра

Проанализируем техническую сторону вопроса. В соответствии с Постановлением Правительства РФ № 1137 код 27 применяется комитентами (принципалами) при регистрации сводных счетов-фактур, полученных от агентов или комиссионеров, приобретавших товары или услуги у нескольких фактических продавцов. Каждая позиция по конечному поставщику должна фиксироваться в журнале учета счетов-фактур обособленно со своими реквизитами.

В конфигурации 1С:Бухгалтерия ключевыми измерениями регистра сведений ЖурналУчетаСчетовФактур являются Организация, СчетФактура и ИндексСтроки. Для уникальности каждой строки набора записей измерение ИндексСтроки должно содержать уникальный числовой идентификатор (0, 1, 2 и так далее).

В ERP при проведении сводного счета-фактуры формируется N+1 записей с инкрементом индекса. Однако при загрузке документа в БП типовой запрос проведения формирует для всех строк жестко фиксированное значение:

0 КАК ИндексСтроки

В результате СУБД пытается записать в регистр несколько строк с абсолютно одинаковым набором измерений, что приводит к системной ошибке нарушения уникальности ключа записи регистра сведений. Выясним, почему типовой алгоритм 1С подставляет ноль вместо динамического индекса.

Причина: несоответствие вида договора контрагента

Алгоритм проведения документа СчетФактураПолученный в 1С:Бухгалтерии динамически выбирает ветку запроса в зависимости от реквизита ВидДоговора в карточке договора с контрагентом:

1. Если выбран договор с видом «С поставщиком», система расценивает операцию как прямую покупку у единственного контрагента. Запрос жестко присваивает выражению значение 0 КАК ИндексСтроки. При наличии нескольких строк в табличной части продавцов происходит коллизия ключей.
2. Если выбран договор с видом «С комиссионером (агентом) на закупку», активируется специализированная ветка проведения, где индекс рассчитывается с учетом строк продавцов:

ТабличнаяЧасть.НомерСтроки - 1 КАК ИндексСтроки

Чаще всего при синхронизации через универсальный формат обмена (EnterpriseData) договор комиссионера автоматически создается или сопоставляется со стандартным видом «С поставщиком». В результате документ загружается с неверным контекстом договора, из-за чего падает при проведении.

Решение 1. Изменение вида договора через групповую обработку

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

1. Откроем раздел Администрирование → Обслуживание → Корректировка данных → Групповое изменение реквизитов.
2. Выберем объект Договоры контрагентов.
3. По кнопке «Добавить условие отбора» найдем конкретный проблемный договор комиссионера.
4. В нижнем правом углу в Дополнительных параметрах включим флажок «Разработчикам: Показывать служебные реквизиты» и отключим оптимизацию записи при необходимости.
5. Найдем реквизит Вид договора и установим значение С комиссионером (агентом) на закупку.
6. Нажмем Изменить реквизиты, после чего вернемся в документ Счет-фактура полученный и проведем его.

Решение 2. Создание нового комиссионного договора и перепривязка

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

1. Создадим в 1С:Бухгалтерии новый договор контрагента, выбрав правильный вид: «С комиссионером (агентом) на закупку».
2. Откроем входящий счет-фактуру (и связанный с ним документ основания, если передан) и укажем созданный договор.
3. В настройках сопоставления данных интеграции ERP — БП свяжем соответствующий договор из ERP с новым договором в БП, чтобы последующие обмены не затирали значение.
4. Проведем документ. Набор записей регистра ЖурналУчетаСчетовФактур сформируется корректно без дублирования измерений.

Решение 3. Корректировка алгоритма через расширение конфигурации

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

Перехватим процедуру формирования движений документа СчетФактураПолученный с помощью аннотации &Вместо или &После в модуле объекта (или специализированном общем модуле проведения). В тексте запроса формирования движений по регистру сведений ЖурналУчетаСчетовФактур заменим константный ноль на вычисление номера строки:

// В части запроса, собирающей данные по продавцам сводного счета-фактуры:
ВЫБОР
    КОГДА ТаблицаПродавцов.НомерСтроки ЕСТЬ NULL ТОГДА 0
    ИНАЧЕ ТаблицаПродавцов.НомерСтроки - 1
КОНЕЦ КАК ИндексСтроки

Такой подход гарантирует создание уникальных записей по каждому продавцу в регистре независимо от того, какой вид договора был ошибочно указан при переносе данных.