Рассмотрим ситуацию, с которой столкнулись многие пользователи программы 1С:Бухгалтерия 3.0 после планового обновления. До обновления в отчете «Анализ учета по налогу на прибыль» в расшифровках фигурировали привычные аббревиатуры корректировок: ПНО, ПНА, ОНО, ОНА, и сам анализ формировался без ошибок. Однако после перехода на новый релиз пользователи заметили две проблемы: во-первых, вместо ПНО и ПНА появились новые термины — ПНР и ПНД; во-вторых, в отчете стала появляться ошибка, при которой блок обводится красной рамкой и выводится сообщение о том, что не выполняется условие БУ=НУ+ВР+ПР. При этом, если проверить суммы (например, БУ=176330, НУ=176000, ВР=330, ПР=0), математически формула сходится идеально.
Проанализируем эту ситуацию, выясним причины произошедшего и разберем по шагам, как вернуть корректное отображение данных в отчете.
Для начала разберем, почему в программе изменились привычные аббревиатуры. Многим бухгалтерам показалось, что это сбой программы, однако это не так.
Появление в расшифровке отчета новых аббревиатур связано с масштабными изменениями в законодательстве Российской Федерации. С 2020 года вступила в силу новая редакция стандарта ПБУ 18/02 «Учет расчетов по налогу на прибыль организаций» (утверждена приказом Минфина № 236н). Согласно этим поправкам, старые термины были официально переименованы:
Разработчики 1С просто привели интерфейс и печатные формы отчетов конфигурации 1С:Бухгалтерия в полное соответствие с актуальными требованиями законодательства. Таким образом, наличие ПНР и ПНД вместо ПНО и ПНА — это не ошибка, а правильное, современное поведение программы.
Посмотрим на вторую, более критичную часть проблемы — красную рамку и сообщение о невыполнении базового контрольного правила БУ=НУ+ВР+ПР, несмотря на то, что цифры фактически сходятся.
Эта ошибка в релизах линейки 3.0.75 возникла из-за перехода 1С на новые алгоритмы работы с налогом на прибыль. В 2020 году разработчики сделали приоритетным новый «балансовый метод» учета разниц. Алгоритмы отчета «Анализ учета по налогу на прибыль» были масштабно переписаны под эту новую методику.
Однако многие организации в своей учетной политике оставили старый вариант — «затратный метод (метод отсрочки)». При попытке сформировать новый, переписанный отчет по данным, рассчитанным старым затратным методом, в первых переходных релизах конфигурации дал сбой механизм визуальной проверки. Программа некорректно сопоставляла показатели для контроля по старой учетной политике, из-за чего блок отчета ошибочно обводился красным цветом, сигнализируя о несуществующей проблеме.
Проанализируем влияние этой ошибки на сам учет. Выясним главное: проблема носила исключительно интерфейсный характер (то есть это была ошибка визуализации самого отчета).
Фактические расчеты сумм, формирование проводок закрытия месяца и сбор данных для регламентированной декларации по налогу на прибыль формировались в программе абсолютно верно. Система правильно считала налоги, но сам отчет-анализатор некорректно собирал показатели на экран. Именно поэтому пользователям не нужно было отменять закрытие месяца, перепроводить документы или пытаться исправить проводки вручную операциями, введенными вручную.
Так как проблема кроется в программном коде самого отчета конфигурации, единственным и самым правильным решением является обновление базы данных до релиза, в котором разработчики устранили этот баг.
Разберем по шагам, что нужно сделать:
После установки указанного (или более нового) обновления ошибка в формулах исчезнет, красная рамка больше не будет вас беспокоить, а новые аббревиатуры ПНР и ПНД останутся на своих местах, так как они полностью соответствуют текущему законодательству.