Как скорректировать движения регистра накопления в закрытом периоде в 1С?

← На главную

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

Анализ проблемы и почему не подходят "простые" решения

Первое, что приходит на ум разработчику — это программно очистить параметр сеанса ГраницыЗапретаИзмененияДанных непосредственно перед проведением документа (например, табеля) в обработчике ОбработкаПроведения, а затем вернуть его обратно. Разберем, почему это плохой подход:

Если в процессе проведения возникнет исключительная ситуация или ошибка, код восстановления параметра сеанса может не выполниться. В итоге «Дата запрета» для текущего сеанса останется пустой или искаженной, что даст пользователю возможность случайно отредактировать другие документы в закрытом периоде.
Добавление условий вида Если ТипЗнч(ЭтотОбъект) = Тип(ДокументОбъект.ТабельУчетаРабочегоВремени) прямо в модуль документа усложняет поддержку и не решает проблему глобально, так как проверка периода обычно происходит не в самом документе, а в подписках на события.

Оптимальное программное решение: использование режима загрузки

Самый безопасный и "чистый" способ программно записать данные задним числом, не трогая глобальные переменные и границы запрета — это использование свойства ОбменДанными.Загрузка. Рассмотрим подробнее, как работает этот механизм.

Контроль даты запрета редактирования в УПП и аналогичных конфигурациях реализован через механизм "Подписки на события" (например, подписка ПередЗаписьюРегистраНакопления). Установка свойства ОбменДанными.Загрузка = Истина перед выполнением метода записи дает платформе прямую команду проигнорировать выполнение любых обработчиков событий (как в модуле набора записей, так и в подписках). Следовательно, программный код 1С, проверяющий закрытый период, просто не будет вызван.

Посмотрим на пример того, как это можно реализовать с помощью внешней обработки или при программной корректировке набора записей:


НаборЗаписей = РегистрыНакопления.РабочееВремяСотрудниковОрганизаций.СоздатьНаборЗаписей();
// Устанавливаем отбор по регистратору (документу, движения которого корректируем)
НаборЗаписей.Отбор.Регистратор.Установить(СсылкаНаДокумент);
НаборЗаписей.Прочитать();

// ... здесь выполняем нужную модификацию записей набора ...
Для Каждого Запись Из НаборЗаписей Цикл
    // Корректируем реквизиты или ресурсы
    Запись.Дни = Запись.Дни - 5;
КонецЦикла;

// Включаем режим загрузки для обхода проверок
НаборЗаписей.ОбменДанными.Загрузка = Истина;

// Записываем измененный набор
НаборЗаписей.Записать();

Этот подход гарантирует, что система не выдаст ошибку о нарушении прав доступа или закрытом периоде, при этом риск глобального сбоя настроек прав минимален.

Архитектурно правильный обход проверок с помощью ролей

Если вам необходимо, чтобы корректировка табеля в закрытом периоде стала регулярной практикой для определенных пользователей, логичнее вносить изменения не в модуль самого «Табеля», а в общий модуль, который вызывается из Подписки на события. Разберем алгоритм действий:

Добавьте в конфигурацию новую Роль (например, РазрешитьКорректировкуТабеляВЗакрытомПериоде).
В общем модуле, где проверяется дата запрета изменения данных (обычно это модули вроде НастройкаПравДоступа или ПолныеПрава), найдите процедуру проверки.
Добавьте условие: если корректируется целевой регистр и у пользователя (или сеанса) есть наша новая роль, то проверку даты запрета следует пропустить.

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

Использование штатного документа «Корректировка записей регистров»

Не стоит забывать про штатный инструмент платформы — документ КорректировкаЗаписейРегистров. Он изначально спроектирован для ручного или программного изменения движений по любым регистрам без необходимости перепроведения исходного документа-регистратора. Вы можете использовать его как контейнер для внесения точечных изменений. Программно сформировав такой документ и заполнив его движения нужными записями (в том числе сторнирующими), вы добьетесь прозрачности учета — всегда будет видно, каким документом была внесена правка.

Риски изменения структуры регистра (Добавление измерения "ПериодРегистрации")

В современных решениях (например, ЗУП 3.1 или ERP) в расчетных регистрах часто присутствует измерение ПериодРегистрации, по которому и происходит контроль периодов. На форуме предложен вариант добавить такое же измерение в старую УПП, переопределить сравнение в общем модуле и заполнять его датой текущего документа.

Выясним причину, почему это плохая идея. Добавление нового измерения в базовый расчетный регистр в условиях старой конфигурации несет критические риски. Система содержит огромное количество жестко "зашитых" запросов к виртуальным таблицам оборотов (например, РегистрНакопления.РабочееВремяСотрудниковОрганизаций.Обороты). Изменение структуры измерений оборотного регистра неизбежно нарушит корректную работу типовых запросов расчета зарплаты, формирования себестоимости и отчетов, так как кардинально изменится порядок группировки данных по умолчанию платформой. Отладка всех "поехавших" отчетов займет колоссальное количество времени.

Влияние сторнирования на отчетность текущим периодом

Еще один важный вопрос: что будет, если реализовать корректирующий табель текущим (открытым) месяцем, сделав запись с минусом (например, -5 дней) за прошлый период? Повлияет ли это на отчеты?

Проанализируем эту ситуацию. Сторнирование записей оборотного регистра РабочееВремяСотрудниковОрганизаций текущим (открытым) периодом за прошлый (закрытый) период приведет к серьезным искажениям в кадровых отчетах, в первую очередь в унифицированной форме Т-13.

Отчеты по рабочему времени в УПП и ЗУП 2.5 жестко привязаны к стандартному реквизиту Период самой записи регистра. Если сделать корректирующую запись (минус 5 дней) датой текущего открытого месяца (например, октябрем за январь), эти отработанные дни уменьшатся в текущем месяце. В результате за октябрь у сотрудника отобразится нехватка дней, а в отчете за прошлый январь ошибка так и останется, потому что система будет смотреть на записи с Период = Январь.

Как правильно сделать сторно? В системах на базе УПП и ЗУП 2.5 для корректного отражения используется типовой механизм документов-исправлений (по кнопке «Исправить» внизу документа). Он формирует сторно-записи именно за прошлый расчетный период (период регистрации сторно-записей будет равен прошлому месяцу). И именно поэтому вам в любом случае придется научить систему или обходить закрытый период (как мы описали выше через ОбменДанными.Загрузка), или административно "приоткрывать" период для ответственного расчетчика на время внесения исправления.

Краткие выводы

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

Избегайте прямого изменения структуры старых расчетных регистров (не добавляйте новые измерения), чтобы не сломать виртуальные таблицы.
Для программной корректировки наборов записей используйте свойство ОбменДанными.Загрузка = Истина. Это пропустит подписки на события и не потребует манипуляций с переменными сеанса.
Для прозрачного учета в пользовательском режиме используйте типовой документ КорректировкаЗаписейРегистров или штатный механизм "Исправить" в исходном документе, предварительно разрешив эту операцию на уровне ролей.
Сторнирующие записи по рабочему времени должны формироваться датой того периода, к которому они относятся, иначе кадровые отчеты (Т-13) будут искажены.