При подготовке и сдаче регламентированной отчетности по НДС бухгалтеры часто сталкиваются с непредвиденным поведением программы. Типичный пример такой ситуации — ложная проверка контрольных соотношений в Разделе 2 декларации по НДС, когда организация не является налоговым агентом. Программа 1С:Бухгалтерия предприятия 3.0 (в частности, на релизе 3.0.70.33) может принудительно и ошибочно заполнять поле ОКТМО в Разделе 2, блокировать эту ячейку для редактирования и выдавать критическую ошибку при проверке контрольных соотношений: "Значение КБК в стр.040 Раздела 2 должно соответствовать списку допустимых значений".
В этой статье мы подробно разберем, почему возникает данная техническая проблема, проанализируем внутренние механизмы работы проверки регламентированных отчетов и рассмотрим по шагам несколько надежных способов исправления этой ошибки.
Для того чтобы правильно решить проблему, нам необходимо понять физику процесса. В период сдачи отчетности за 1 квартал 2019 года Федеральная налоговая служба обновила перечень контрольных соотношений (КС) для декларации по НДС. В ответ на это разработчики фирмы 1С оперативно выпустили внешнюю форму отчета с внедренной проверкой нового соотношения КС 1.53б. Это соотношение жестко сверяет КБК в строке 040 Раздела 2 со списком законодательно утвержденных кодов бюджетной классификации.
Однако в коде внешней формы декларации была допущена программная неточность. Алгоритм автозаполнения подтягивал ОКТМО организации в Раздел 2, даже если признак ведения деятельности в качестве налогового агента не был установлен в настройках учета. Программа видела заполненную ячейку ОКТМО и ошибочно трактовала это как начало заполнения Раздела 2. В результате модуль проверки запускал проверку КС 1.53б и требовал указать КБК. Попытка заполнить КБК вручную приводила к следующей ошибке выгрузки: "Укажите код операции налогового агента на странице 1 раздела 2". Таким образом, пользователь попадал в замкнутый круг программных проверок.
Давайте подробно рассмотрим три практических способа решения этой проблемы.
Если на вашем предприятии была подключена внешняя форма регламентированного отчета НДС, самым простым и быстрым решением будет временный отказ от нее и возврат к использованию стандартной встроенной формы отчета. Встроенная в релиз 3.0.70.33 форма декларации не содержит ошибочного алгоритма автозаполнения ОКТМО.
Выполним этот процесс по шагам:
Проанализируем техническую сторону выгрузки отчета в формате XML. Многие бухгалтеры опасаются отправлять декларацию, если встроенная проверка 1С показывает красные предупреждения. Однако в данном случае важно понимать разницу между логической проверкой интерфейса и реальным содержимым файла выгрузки.
Механизм выгрузки регламентированного отчета работает по строгим правилам формата ФНС. Если у организации в информационной базе нет проведенных операций налогового агента по НДС, то при выгрузке модуль формирования электронного документа видит, что значимые показатели Раздела 2 отсутствуют. Программа просто исключает Раздел 2 из выгружаемого XML-файла.
Вы можете легко убедиться в этом самостоятельно:
.xml через любой текстовый редактор (например, Блокнот) или встроенный просмотрщик 1С.
<?xml version="1.0" encoding="windows-1251"?>
<Файл ИдФайл="Имя_Файла" ВерсПрог="1С:Бухгалтерия 3.0" ВерсФорм="5.06">
<Документ КНД="1151001">
<НалПлат>...</НалПлат>
<Деchoices>
<!-- Раздел 1 -->
<КодНО>...</КодНО>
<!-- Раздел 3 -->
<РасчетНДС>...</РасчетНДС>
</Деchoices>
</Документ>
</Файл>
Как мы видим, пустой Раздел 2 не попадает в файл. Соответственно, приемный шлюз ФНС примет данный файл без каких-либо ошибок, так как на стороне налоговой инспекции проверяется именно XML-структура. Таким образом, отчет можно отправлять даже при наличии этого предупреждения в программе.
Фирма 1С оперативно реагирует на подобные массовые проблемы и выпускает исправления. Чтобы устранить ошибку окончательно, необходимо обновить внешнюю форму декларации или саму конфигурацию.
Для загрузки исправленной формы выполним следующие действия:
Также помните, что при первой отправке декларации на печать или выгрузку программа может предложить обновить или подключить внешний бинарный модуль печати. Рекомендуется дать согласие на это действие, так как это обновляет внутренние компоненты парсинга форм отчетности.
Разберем еще одну частую проблему, о которой упоминают пользователи при заполнении этой декларации. Речь идет о ситуации, когда итоговая сумма налога в строке 010 Раздела 3 незначительно (обычно на несколько рублей) отличается от суммы, которая отображается при расшифровке этой строки.
Выясним причину этого явления. Согласно действующему порядку заполнения декларации НДС, сумма налога в графе 5 строки 010 Раздела 3 рассчитывается строго математическим путем: налоговая база (графа 3) умножается на ставку налога (например, 20%) и делится на 100, после чего округляется до целых рублей. В то же время, расшифровка строки 010 и Книга продаж собирают реальные суммы НДС с копейками по каждому конкретному документу реализации, и только потом округляют финальный итог.
Из-за накопившейся погрешности округления копеек по каждому счету-фактуре возникает разница. Важно знать: ФНС допускает подобные расхождения из-за математического округления. Настоятельно рекомендуем вам не править эти суммы вручную в Разделе 3, пытаясь подогнать их под копейки Книги продаж. Ручное вмешательство нарушит контрольные соотношения внутри самой декларации и гарантированно вызовет требование о представлении пояснений от налогового органа.