При ведении электронного документооборота (ЭДО) через систему «Контур.Диадок» пользователи часто сталкиваются с ситуацией, когда отправленный документ возвращается со статусом «Отказано в подписи — неправильное количество товара». Данная проблема наиболее характерна для УПД (универсальных передаточных документов) с функцией счета-фактуры и первичного документа, в которых оформляется реализация исключительно нематериальных ценностей — услуг или работ.
В печатной форме (например, в формате PDF) на месте количества и единицы измерения для услуг вполне законно отображаются прочерки. Однако автоматический верификатор на стороне контрагента считывает именно структуру XML-файла и блокирует подписание документа. Проанализируем, почему возникает этот сбой, как должна выглядеть правильная XML-схема в соответствии с требованиями ФНС и как настроить программу 1С, чтобы обойти жесткие требования верификатора получателя.
Формат электронного УПД строго регламентирован регулирующими органами. На текущий момент актуальным является формат, утвержденный Приказом ФНС России № ЕД-7-26/970@ (версия формата 5.03). Согласно этому формату, заполнение полей количества и единицы измерения зависит от того, передается ли код по ОКЕИ (Общероссийскому классификатору единиц измерения):
КолТов (Количество товара) и ЦенаТов (Цена за единицу). Это эквивалентно прочеркам в бумажном документе. На уровне схемы ФНС такой файл является абсолютно валидным.ОКЕИ_Тов (например, со значением «796» для штук или кодом другой единицы измерения), теги КолТов и ЦенаТов автоматически переходят в разряд строго обязательных. При этом их значения должны быть строго больше нуля.Рассмотрим структуру XML-строки УПД, которая полностью соответствует требованиям ФНС для услуги без единицы измерения:
<СведТов НалСт="20%" СтТовБезНДС="10000.00" СтТовУчНал="12000.00" НаимТов="Предоставление консультационных услуг" НомСтр="1">
<Акциз>
<БезАкциз>без акциза</БезАкциз>
</Акциз>
<СумНал>
<СумНал>2000.00</СумНал>
</СумНал>
<ДопСведТов КодТов="УСЛ-001" ПрТовРаб="3"/>
</СведТов>
Обратим внимание на тег ПрТовРаб="3" — это признак того, что передается именно услуга. По спецификации ФНС отсутствие тега КолТов здесь абсолютно корректно. Оператор ЭДО («Контур.Диадок») без проблем пропускает такой файл, так как он валиден на уровне формата.
Тогда почему клиент возвращает отказ? Дело в том, что крупные компании (особенно холдинги и предприятия с миллиардными оборотами) автоматизируют обработку входящих документов. Их внутренние роботы-верификаторы (встроенные в SAP, Oracle, ERP-системы или самописные модули 1С) настроены по жестким правилам. Верификатор ищет сопоставление (мэтчинг) полей УПД со своим внутренним «Заказом на закупку» (Purchase Order). Если в их системе заказ оформлен как «1 услуга по цене X», а к ним приходит XML без тега КолТов, автоматика выдает ошибку: «Неправильное количество товара». Программа просто не умеет обрабатывать пустые значения там, где ожидает увидеть число.
---
Если контрагент — крупная корпорация, которая не планирует оперативно переписывать алгоритмы своих роботов ради одного поставщика, самым простым и бесконфликтным решением будет адаптация заполнения документа на вашей стороне в 1С.
Для этого выполним следующие действия по шагам:
При такой настройке XML-схема сформирует обязательные теги ОКЕИ_Тов, КолТов и ЦенаТов, сохранив при этом признак услуги ПрТовРаб="3". Верификатор клиента увидит ожидаемую единицу в поле количества, и документ будет успешно подписан в автоматическом режиме.
---
Рассмотрим ситуацию, когда бухгалтерия категорически против указания количества «1» в документах реализации услуг из-за требований внутренней учетной политики. В этом случае нам потребуется вмешаться в процесс формирования XML-файла в модуле ЭДО в 1С.
В типовых конфигурациях 1С, использующих Библиотеку электронных документов (БЭД), за формирование XML-структуры УПД отвечает общий модуль ВыгрузкаДокументовЭДОПереопределяемый или специализированные модули интеграции «Диадок». Проанализируем алгоритм заполнения тегов строки таблицы.
Для того чтобы принудительно исключить отправку кодов ОКЕИ при незаполненном количестве (или, наоборот, добавить дефолтное значение «1» «на лету» только для отправки в ЭДО без изменения данных в базе 1С), мы можем воспользоваться механизмом переопределения параметров выгрузки. Найдем процедуру формирования сведений о товарах и добавим условие:
// Пример модификации заполнения структуры выгрузки в ЭДО
Если СвойстваНоменклатуры.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Услуга Тогда
// Если у услуги не должно быть количественных показателей,
// принудительно очищаем параметры единиц измерения для ЭДО
СтруктураДанныхСтроки.Вставить("ОКЕИ", "");
СтруктураДанныхСтроки.Вставить("Количество", Неопределено);
СтруктураДанныхСтроки.Вставить("Цена", Неопределено);
Иначе
// Стандартное заполнение для товаров и работ
КонецЕсли;
Если же верификатор клиента, наоборот, требует наличия количества даже для услуг без ОКЕИ, мы можем программно подставить единицу и код ОКЕИ «796» исключительно в структуру файла выгрузки, оставив учетный документ в вашей информационной базе неизменным (с прочерками):
// Подстановка условных единиц для верификатора контрагента
Если СвойстваНоменклатуры.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Услуга
И Не ЗначениеЗаполнено(СтруктураДанныхСтроки.Количество) Тогда
СтруктураДанныхСтроки.Вставить("ОКЕИ", "796"); // Код ОКЕИ для 'шт'
СтруктураДанныхСтроки.Вставить("Количество", 1);
СтруктураДанныхСтроки.Вставить("Цена", СтруктураДанныхСтроки.Сумма);
КонецЕсли;
Использование этого кода позволяет обойти ограничения на стороне получателя без внесения изменений в первичные документы бухгалтерского учета.
---
Если вы являетесь ключевым подрядчиком или объем документов достаточно велик, имеет смысл решить проблему на стороне получателя. Для этого необходимо инициировать обращение в техническую поддержку клиента.
Предоставим им следующие аргументы:
ПрТовРаб="3", однозначно определяющий номенклатуру как «Услуга».КолТов и ЦенаТов является легитимным, если не указан код ОКЕИ.Как показывает практика, крупные компании в курсе этой проблемы и при аргументированном обращении могут внести ИНН вашей организации в список исключений своего верификатора либо скорректировать правила обработки для признака услуги ПрТовРаб="3".