При работе в устаревших, но все еще актуальных конфигурациях на платформе 1С 7.7 (например, «Бухгалтерский учет»), пользователи часто сталкиваются с проблемой некорректного заполнения регламентированных отчетов после законодательных изменений. Одной из самых распространенных ошибок является ситуация, когда информация из счета-фактуры на аванс (код вида операции 02) со ставкой 20% попадает в графу для 18% (графа 17а) в Книге продаж, хотя математически сумма налога рассчитана верно. Разберем детально, почему это происходит и как программно устранить этот дефект.
Для начала проанализируем ситуацию. Основная причина кроется не в пользовательских данных, а в жестких алгоритмах распределения сумм по колонкам внутри самого отчета Книга продаж. В 1С 7.7 ставка налога — это не просто число, а зачастую ссылка на элемент справочника НалогиИОтчисления. При формировании отчета система сравнивает ставку в документе с предопределенными значениями или константами.
Выделим основные факторы, влияющие на ошибку:
ВидОперации со значением «аванс» заставляет отчет искать ставку не в табличной части (которой у авансового счета-фактуры может не быть), а рассчитывать её исходя из суммы документа или брать из шапки.глНДС20, которые инициализируются при запуске. Если в справочнике налогов создано несколько ставок с похожими названиями, система может выбрать не ту, и условие сравнения в отчете выдаст Ложь.Рассмотрим подробнее, как работает механизм определения колонки. Программа перебирает условия: если ставка равна 20%, то пишем в одну колонку, иначе если 18% — в другую. Если ставка 20% не распознана программой как «своя», она по остаточному принципу может попасть в ближайшую подходящую колонку (в данном случае 18%).
Прежде чем переходить к правке кода, выполним проверку нормативно-справочной информации. Посмотрим на настройки, которые могут косвенно влиять на отчет:
Во-первых, откроем справочник «Налоги и отчисления». Убедимся, что для новой ставки 20% корректно указан вид налога (НДС) и дата начала действия. Если ставок с названием «20%» несколько, это первый признак того, что отчет может путаться.
Во-вторых, проанализируем учетную политику и регистр сведений (если он используется в вашей конфигурации), где фиксируется дата перехода на новую ставку НДС. Если дата формирования Книги продаж или дата документа попадает в «переходный» период, алгоритм может отрабатывать по старой схеме.
Если настройки справочников в порядке, значит, проблема зашита непосредственно в алгоритм формирования печатной формы. Нам потребуется внести изменения в модуль внешнего отчета (обычно это файл kng_prd.ert в каталоге ExtForms) или встроенного отчета конфигурации.
Найдем в модуле процедуру, отвечающую за заполнение переменных Сумма20, НДС20, Сумма18 и НДС18. Обычно это цикл по документам в процедуре Сформировать(). Выясним причину, по которой условие проверки ставки игнорирует значение 20%.
Рассмотрим пример корректировки кода. Часто проблема заключается в том, что программа ожидает числовое значение, а получает объект, или наоборот. Практика показывает, что надежнее всего добавить проверку на оба возможных варианта идентификации ставки.
Найдем фрагмент кода, похожий на этот:
Если Ставка = 20 Тогда
// Код распределения в колонку 20%
ИначеЕсли Ставка = 18 Тогда
// Код распределения в колонку 18%
КонецЕсли;
И заменим его на более «гибкое» условие, которое позволит системе корректно обрабатывать значения в переходный период или при программных неточностях. Воспользуемся советом опытных разработчиков и расширим область срабатывания условия:
// Модифицированный код для корректного определения колонки 20%
Если (Ставка = 20) Или (Ставка = глНДС20) Тогда
// Суммы гарантированно попадают в колонку 17 Книги продаж
Сумма20 = Сумма20 + СуммаДок;
НДС20 = НДС20 + СуммаНДС;
ИначеЕсли (Ставка = 18) Или (Ставка = глНДС18) Тогда
// Суммы попадают в колонку 17а (18%)
Сумма18 = Сумма18 + СуммаДок;
НДС18 = НДС18 + СуммаНДС;
КонецЕсли;
Важный нюанс: Обратите внимание на идентификатор глНДС20. Это глобальная переменная, которая должна быть определена в глобальном модуле. Если она не определена, проверку следует делать по числовому значению или по идентификатору ставки в справочнике.
Почему же обычные реализации могут попадать правильно, а авансы — нет? Разберем по шагам логику документа «Счет-фактура выданный» с видом операции «Аванс». В таких документах часто отсутствует табличная часть с товарами, где явно указана ставка НДС. Программа вычисляет ставку «на лету» как 20/120.
В коде отчета Книга продаж для авансов часто выделен отдельный блок Если ВидОперации = Перечисление.ВидыОперацийСЧФ.Аванс. Проверьте, чтобы внутри этого блока расчетная ставка также сравнивалась с актуальным значением 20%. Если там жестко прописано сравнение с 18%, то никакие изменения в самом документе не помогут — нужно править именно формулу в отчете.
Также стоит помнить, что ручное изменение поля «КВО» в документе (например, с 02 на 01) не меняет внутреннюю логику обработки документа программой, так как 1С 7.7 ориентируется на реквизит ВидОперации. Поэтому, даже если вы напишете в КВО любое другое число, логика распределения сумм останется «авансовой», пока не будет изменен программный код отчета.
Мы выяснили, что «хрень» в Книге продаж 1С 7.7 при использовании ставки 20% для авансов — это следствие несоответствия программного кода отчета и актуальных справочных данных. Для исправления ситуации необходимо:
КнигаПродаж, расширив условия проверки ставки НДС, как показано в примере выше.Такой комплексный подход позволит корректно формировать налоговую отчетность и избежать претензий со стороны бухгалтерии и налоговых органов.