В процессе работы с электронным документооборотом (ЭДО) в программе 1С пользователи часто сталкиваются со специфической ошибкой при попытке выгрузить документ реализации, содержащий строки с отрицательным количеством или суммой. Система выдает сообщение следующего содержания: "Ошибка заполнения XDTO. Ошибка установки значения свойства 'СтТовУчНал'. Значение не соответствует простому типу...". В данной статье мы подробно разберем, почему возникает эта ситуация, проанализируем технические требования законодательства и найдем правильные способы отражения таких операций в учете.
Для начала разберем, что именно означает это системное сообщение. При выгрузке электронного документа программа осуществляет формирование файла типа XML для формализованных документов. Структура этого файла жестко регламентирована ФНС и описывается так называемой XSD-схемой. Посмотрим на технические требования к атрибуту СтТовУчНал (Стоимость товаров с налогом — всего).
Согласно формату УПД, утвержденному Приказом ФНС России, данный показатель имеет тип N(19.2) и сопровождается жестким условием: СтТовУчНал >= 0. Это означает, что на уровне самой структуры файла запрещено передавать отрицательные числа. Когда 1С пытается записать «минус» в это поле, механизм XDTO (XML Data Transformation Objects) блокирует операцию.
Рассмотрим ситуацию с точки зрения методологии бухгалтерского и налогового учета. ФНС в своих письмах однозначно указывает на то, что реализация — это факт хозяйственной жизни, отражающий отгрузку товаров. Факт отгрузки по определению не может быть отрицательным. Если вы используете сторонние сервисы, такие как выгрузка УПД в XML для Diadoc, система также будет требовать соответствия документа легальным XSD-схемам.
Если контрагент требует отразить возврат товара или уменьшение стоимости в том же самом документе «одним файлом», он фактически просит нарушить требования к формату первичного документа. Для отражения изменений существуют специализированные типы документов.
Если нам необходимо отразить уменьшение количества отгруженного ранее товара, наиболее правильным и легитимным способом является использование Универсального корректировочного документа (УКД). Проанализируем, как это работает:
Рассмотрим пример логики проверки заполнения свойств, которая срабатывает при выгрузке:
// Пример упрощенной логики проверки перед выгрузкой в XDTO
Если СтрокаДокумента.СуммаСНДС < 0 Тогда
Сообщить("Выгрузка отрицательных сумм в формате УПД невозможна.
Используйте корректировочный документ.");
Отказ = Истина;
КонецЕсли;
Если речь идет не об исправлении ошибки в текущей отгрузке, а о фактическом возврате товара, который был принят контрагентом ранее, мы должны использовать стандартную схему:
Это разделение позволяет избежать технических ошибок и полностью соответствует правилам ведения книги продаж и книги покупок.
Часто клиенты сталкиваются с утверждением контрагентов, что другие поставщики присылают файлы с минусами. Разберем, почему это вводит в заблуждение:
Чтобы избежать ошибки СтТовУчНал, мы рекомендуем придерживаться следующего алгоритма действий:
Таким образом, техническая ошибка XDTO — это не «баг» программы, а защитный механизм, который предотвращает отправку заведомо неверного документа. Решение задачи лежит в плоскости правильного методологического оформления первичных документов.