При работе в 1С:Бухгалтерия 3.0, особенно после загрузки данных из внешних систем через Универсальный обмен данными XML, пользователи часто сталкиваются с загадочной ошибкой: программа сообщает, что в регистре бухгалтерии не заполнен счет дебета в строке, номер которой значительно превышает количество строк в самом документе. Например, в вашем Отчете о розничных продажах всего 61 позиция, а система ругается на строку №123.
В рамках данной статьи мы подробно разберем, почему возникает такой диссонанс, как устроена логика формирования проводок в рознице и что именно нужно проверить в настройках эквайринга, чтобы документ проводился без ошибок.
Давайте проанализируем, почему номер строки в сообщении об ошибке не совпадает с номером строки в табличной части документа. Это одна из самых распространенных ловушек для начинающих специалистов и бухгалтеров. Когда система выдает сообщение: "ЗАПИСЬ не верна - не заполнен счет дебета (регистр бухгалтерии (журнал проводок)... номер строки 123", она обращается не к вашему списку товаров, а к набору записей регистра бухгалтерии (Хозрасчетный).
Рассмотрим структуру формирования проводок. Один товарный элемент в Отчете о розничных продажах может генерировать сразу несколько проводок:
Если в документе 61 строка с товарами, то только по реализации может быть сформировано более 120 проводок. Кроме того, если в документе заполнена вкладка "Безналичные оплаты", к этому списку добавляются проводки по эквайрингу (например, Дебет 57.03 — Кредит 62.Р). Таким образом, строка 123 в регистре — это вполне реальная запись, возникшая в процессе трансляции данных документа в бухгалтерский учет.
Проанализируем ситуацию, описанную в теме. Пользователь обнаружил, что ошибка исчезает, если на вкладке "Безналичные оплаты" указать конкретный эквайринговый терминал. Почему это критично для системы?
В 1С:Бухгалтерия 3.0 аналитика по счету 57.03 (Продажи по платежным картам) строится в жесткой иерархии объектов. Программа должна четко понимать, на каком субконто «зависнет» задолженность банка-эквайера. Если вы выбрали Вид оплаты, но не указали Терминал, алгоритм проведения сталкивается с неопределенностью:
Договор и какой Банк подставить в проводку.СчетДт в наборе записей остается пустым, что и вызывает блокировку проведения документа.Рассмотрим по шагам, как исправить эту ошибку в Отчете о розничных продажах:
Эквайринговые терминалы.Уникальный Идентификатор (GUID) терминала. Часто бывает так, что текстовое представление терминала в документе есть, но сама ссылка на объект в базе данных пуста или битая.Посмотрим на пример из практики: если вы не знаете, какая именно строка вызывает сбой, воспользуйтесь методом последовательного исключения, который упоминался в обсуждении. Если оставить в документе 10 строк и программа начнет ругаться на строку 21 регистра, это явный признак того, что проблема не в конкретном товаре, а в общих итогах или в таблице оплат.
Также рекомендуется проверить Счета учета номенклатуры. Если вы загрузили новый товар, для которого не настроен регистр сведений СчетаУчетаНоменклатуры, система не сможет определить счет кредита для выручки или счет дебета для себестоимости. Проверить это можно, нажав в документе кнопку Дт/Кт (если документ хотя бы раз провелся с ручной корректировкой) или через проверку заполнения реквизитов.
Проанализируем техническую сторону вопроса. При использовании обработки Универсальный обмен данными XML объекты создаются программно, минуя некоторые проверки форм. Чтобы избежать подобных ситуаций в будущем, проверьте ваш алгоритм выгрузки на предмет заполнения следующих реквизитов:
// Пример заполнения структуры безналичной оплаты при программном создании
СтрокаОплаты = ДокументОбъект.Оплата.Добавить();
СтрокаОплаты.ВидОплаты = Справочники.ВидыОплатЧековККМ.НайтиПоНаименованию("Карта");
СтрокаОплаты.Сумма = 1000;
// Критически важный момент для БП 3.0:
СтрокаОплаты.ЭквайринговыйТерминал = Справочники.ЭквайринговыеТерминалы.НайтиПоКоду("00001");
Если терминал не будет заполнен программно, то при интерактивном открытии документа пользователем поле может подсвечиваться красным, но при попытке группового проведения документов программа просто выдаст ошибку о незаполненном счете.
Подводя итог, отметим ключевые точки контроля для документа Отчет о розничных продажах в конфигурации 1С:Бухгалтерия 3.0:
Эквайринговый терминал является ключевым для определения счета 57.03 и его субконто.Таким образом, решив проблему с заполнением терминала, вы обеспечиваете системе возможность однозначно определить Счет Дебета для регистрации задолженности банка по операциям эквайринга, что устраняет ошибку в 123-й (и любой другой) строке регистра бухгалтерии.