Как предотвратить сторнирование проводок нетипового документа при закрытии счетов 25 и 26 в 1С:БИТ-Строительство?

Программист 1С v8.3 (Управляемые формы) Бухгалтерский учет Промышленность, строительство и АПК
← На главную

При разработке собственных механизмов распределения затрат в конфигурациях на базе 1С:Бухгалтерия 3.0 (таких как БИТ-Строительство) программисты часто сталкиваются с неприятной особенностью: типовой документ РегламентнаяОперация при выполнении процедуры «Закрытие счетов 20, 23, 25, 26» автоматически сторнирует все проводки, созданные нетиповыми документами. В этой статье мы подробно разберем, почему это происходит, как работает механизм «белых списков» в запросах 1С и какими способами можно заставить систему учитывать ваше кастомное распределение.

Выясняем причину: почему типовое закрытие «не видит» ваш документ?

Проанализируем ситуацию. Когда мы создаем ручную операцию через документ ОперацияБух, система ее не трогает. Но как только мы создаем аналогичные проводки собственным документом, при закрытии месяца программа формирует сторнирующие записи (отрицательные суммы), фактически аннулируя наш результат. Это происходит потому, что алгоритмы закрытия месяца в 1С построены не только на анализе бухгалтерских остатков, но и на жесткой логике соответствия данных в различных регистрах.

Разберем основные причины такого поведения:

  1. Жесткая фильтрация по типам документов. В коде типовых общих модулей (например, при формировании временных таблиц затрат) часто встречаются запросы, где прописаны исключения только для определенных типов объектов. Система «доверяет» документу ОперацияБух, полагая, что это осознанная корректировка пользователя. Ваш новый документ для системы является «шумом», который мешает расчету себестоимости по типовому алгоритму.
  2. Разрыв между регистрами и проводками. Типовое закрытие месяца ориентируется на данные регистров накопления (например, Затраты, ЗатратыНаПроизводство). Если ваш документ делает только проводки по хозрасчетному регистру, но не делает движений по соответствующим регистрам накопления, система видит «зависшие» затраты в регистрах и пытается привести бухгалтерский учет в соответствие с ними.
  3. Проверка равенства БУ = НУ + ПР + ВР. Если вы пытаетесь отключить корректировку только для бухгалтерского учета, система, следуя правилам налогового учета, может перенести разницу в налоговый учет или временные разницы, чтобы итоговое балансовое уравнение сошлось.

Решение 1: Использование реквизита «Не корректировать стоимость автоматически»

Рассмотрим самый простой способ, который заложен в архитектуру БП 3.0. В регистре бухгалтерии Хозрасчетный существует специальный реквизит НеКорректироватьСтоимостьАвтоматически. Если установить его в значение Истина для ваших движений, это даст сигнал системе, что данные строки не должны подлежать автоматической корректировке регламентными операциями.

Проанализируем пример кода, который необходимо добавить в модуль проведения вашего документа:


Для Каждого Движение Из Движения.Хозрасчетный Цикл
    // Устанавливаем флаг, чтобы закрытие месяца не сторнировало проводку
    Движение.НеКорректироватьСтоимостьАвтоматически = Истина;
КонецЦикла;

Важное примечание: Как показывает практика, установка этого флага в Истина может решить проблему сторнирования в БУ, но спровоцировать появление странных проводок в налоговом учете (НУ) и по временным разницам (ВР). Если система видит, что затраты не распределены по ее регистрам, она попытается «выровнять» ситуацию через НУ, что приведет к нулевому БУ и ненулевым суммам в других видах учета.

Решение 2: Эмуляция ручной операции (Создание документа «ОперацияБух»)

Если вы не хотите глубоко внедряться в логику типовых запросов закрытия месяца, которые часто содержат «адские» временные таблицы, рассмотрим обходной путь. Поскольку система игнорирует (не сторнирует) движения документа ОперацияБух, мы можем сделать так, чтобы наш нетиповой документ сам создавал этот документ программно.

Разберем алгоритм этого метода:

  1. Ваш документ не делает движений напрямую.
  2. При проведении вашего документа программно создается (или обновляется) документ ОперацияБух.
  3. В ОперацияБух записываются нужные проводки Дт 20.1 Кт 25.
  4. В качестве содержания операции указывается ссылка на ваш первичный документ.

Этот метод гарантирует, что типовое закрытие месяца «пропустит» эти проводки, так как ОперацияБух входит в программный «белый список» исключений.

Решение 3: Доработка типовых запросов и определяемых типов

Если вы готовы к серьезной модификации конфигурации, проанализируем, где именно в коде происходит отсечка документов. Нам необходимо выполнить следующие шаги:

1. Определяемые типы. Проверьте, включен ли ваш новый документ в определяемые типы, связанные с финансовыми операциями и закрытием периода (например, ОрганизацияОснование или специфические типы в БИТ-Строительство).

2. Поиск в модулях закрытия. Необходимо найти в общем модуле (обычно это модули, связанные с расчетом себестоимости и закрытием счетов 20, 25, 26) текст запроса, который собирает данные об оборотах за месяц. Скорее всего, там вы обнаружите условие:


ГДЕ
    НЕ ХозрасчетныйОбороты.Регистратор ССЫЛКА Документ.ОперацияБух

Чтобы система начала доверять вашему документу так же, как и ручной операции, вам придется добавить тип вашего документа в это исключение. Однако помните, что это потребует постоянного контроля при обновлении конфигурации.

Резюме и рекомендации

Мы выяснили, что причина сторнирования кроется в защитных механизмах типового решения, которые пытаются обеспечить целостность данных между регистрами и бухгалтерскими счетами.

Для корректной работы вашего алгоритма распределения рекомендуем придерживаться следующей стратегии:

← На главную