При закрытии месяца в программе «1С:Бухгалтерия 3.0» пользователи и разработчики иногда сталкиваются с аномальным поведением системы: расходы будущих периодов (РБП) списываются в двойном размере по бухгалтерскому учету (хозрасчетному регистру), в то время как специализированные регистры накопления могут показывать корректные суммы. Ситуация осложняется тем, что современные конфигурации на базе БСП (Библиотеки стандартных подсистем) выполняют большинство процедур закрытия месяца в фоновом режиме. Разберем подробно, как диагностировать эту проблему, настроить отладчик для работы с серверными сеансами и найти истинную причину «задвоения» записей.
Прежде чем приступать к отладке, проанализируем, как работает механизм списания. В «1С:Бухгалтерии 8» расчет списания РБП выполняется документом РегламентнаяОперация с видом операции «Списание расходов будущих периодов». Алгоритм системы опирается на два основных источника данных:
Если данные в регистре накопления и на счете бухгалтерского учета расходятся (например, из-за ручных операций по счету 97 без корректировки регистра), система может сформировать некорректные проводки. Однако, если проводки именно «дублируются» (то есть создаются две идентичные записи), проблему следует искать в программном коде или настройках конфигурации.
Одной из главных сложностей для разработчика является то, что документ РегламентнаяОперация запускает расчет через длительную операцию. Рассмотрим типичный код вызова, который можно встретить в конфигурации:
Результат = ДлительныеОперации.ЗапуститьВыполнениеВФоне(
УникальныйИдентификатор,
"Документы.РегламентнаяОперация.ЗапуститьВыполнениеИзФормы",
СтруктураПараметров,
НаименованиеЗадания);
АдресХранилища = Результат.АдресХранилища;
ИдентификаторЗадания = Результат.ИдентификаторЗадания;
Для того чтобы «поймать» выполнение кода внутри процедуры ЗапуститьВыполнениеИзФормы, которая исполняется в отдельном сеансе на сервере, выполним следующие шаги:
-debug. Без этого ключа отладка на сервере невозможна в принципе.После этого запустим закрытие месяца или перепроведение регламентной операции. Конфигуратор должен «остановиться» на выбранной строке кода, даже если она выполняется в контексте фонового процесса.
Рассмотрим ситуацию, когда отладка настроена, и мы анализируем процесс формирования движений. Если в консоли запросов данные выглядят корректно, а в результате записи документа появляются дубли, выясним основные причины такого поведения.
Анализ подписок на события
Наиболее вероятной причиной «мистического» появления лишних записей являются Подписки на события. В современных конфигурациях разработчики часто добавляют собственные механизмы для дополнительного контроля или трансляции данных. Проанализируем подписки для объекта ДокументОбъект.РегламентнаяОперация или РегистрБухгалтерииНаборЗаписей.Хозрасчетный.
Посмотрим на пример логической ошибки в подписке ПередЗаписью или ПриЗаписи:
Процедура ПриЗаписиРегламентнойОперации(Источник, Отказ) Экспорт
// Если здесь программно вызывается запись движений без очистки старых
// или повторно запускается алгоритм расчета, это приведет к дублированию
Источник.Движения.Хозрасчетный.Записать();
КонецПроцедуры
Если какая-то «рукожопная» подписка (как выразился автор темы) вмешивается в процесс записи набора записей регистра бухгалтерии, она может повторно добавлять записи в коллекцию Движения. Рассмотрим ситуацию, когда подписка срабатывает дважды или не проверяет наличие уже сформированных движений.
Если отладка кодом затруднена, проанализируем состояние данных до и после выполнения операции с помощью консоли запросов. Нам необходимо сравнить данные в следующих таблицах:
РегистрНакопления.РасходыБудущихПериодовРегистрБухгалтерии.Хозрасчетный.Остатки (по счету 97)РегистрБухгалтерии.Хозрасчетный.ДвижениясСубконто (фильтр по регистратору — нашему документу)Выясним, на каком этапе происходит удвоение. Если в таблице Движения после выполнения метода Записать() строк в два раза больше, чем было в коллекции Движения в памяти перед записью, значит, работают механизмы платформы или подписки на уровне БД.
Проанализируем другие возможные факторы, которые могут выглядеть как двойная запись:
Способ отражения в расходах. Если в табличной части способа указаны две одинаковые статьи затрат с распределением (например, 50% на одну статью и 50% на ту же самую), система создаст две проводки. Для пользователя это может выглядеть как дублирование общей суммы.РасходыБудущихПериодов на наличие дублей через стандартный поиск или обработку «Поиск и удаление дублей».Ручная корректировка, система перестает автоматически обновлять движения при перепроведении. Если при этом программно вызываются какие-то обработчики, они могут наслаиваться на уже существующие ручные записи.Подведем итог нашего исследования. Для устранения двойных записей при списании РБП рекомендуем действовать по алгоритму:
-debug на сервере).РегламентнаяОперация и регистра бухгалтерии Хозрасчетный.Расходы будущих периодов соответствуют бухгалтерским остаткам на счете 97.Как показывает практика, в 90% случаев проблема кроется либо в некорректных доработках (подписки), либо в «мусорных» данных в справочниках и регистрах сведений. Использование инструментов отладки фоновых заданий позволяет быстро локализовать участок кода, ответственный за лишние движения, и исправить ошибку.