В процессе администрирования современных конфигураций на платформе 1С:Предприятие 8.3 (таких как «Управление торговлей 11», «Комплексная автоматизация 2» или «ERP Управление предприятием») специалисты часто сталкиваются с неожиданным поведением системы при расчете себестоимости. Одной из наиболее распространенных проблем является сбой регламентного задания, выполняющего ежедневный предварительный расчет себестоимости, с ошибкой блокировки из-за установленной даты запрета изменений.
В этой статье мы подробно проанализируем, почему возникает данная коллизия, разберем особенности взаимодействия механизмов платформы 1С, Библиотеки стандартных подсистем (БСП) и регистров учета себестоимости, а также рассмотрим три практических способа полного решения этой проблемы.
Для начала проанализируем внутреннюю механику работы системы. На первый взгляд ситуация выглядит парадоксально: регламентное задание должно рассчитывать себестоимость за текущий (открытый) месяц, однако система выдает ошибку, сообщая, что для пользователя установлен запрет редактирования вчерашним днем. Почему это происходит?
Здесь работают два скрытых механизма платформы и конфигурации:
Имя пользователя оставлено пустым, такое задание выполняется на сервере в специальном системном сеансе. При проверке прав и дат запрета изменений механизмы БСП пытаются сопоставить этот фоновый процесс с реальным пользователем. В зависимости от релиза конфигурации, система может использовать настройки первого найденного пользователя с полными правами (часто им оказывается учетная запись «Администратор») либо применять общие («дефолтные») настройки даты запрета для всей информационной базы.РегистрСведений.ЗаданияКРасчетуСебестоимости (или РегистрСведений.ЗаданияКЗакрытиюМесяца). Главным измерением этого регистра является Месяц. При этом в качестве значения всегда записывается дата начала текущего месяца (например, 01.06.2026 для июня).Если в системе установлена относительная дата запрета изменений «Предыдущий день» (то есть вчерашнее число), то при попытке регламентного задания записать данные на дату 01.06.2026 (которая хронологически раньше вчерашнего дня) срабатывает стандартный механизм контроля БСП. Система считает, что процесс пытается изменить документы в закрытом периоде, и аварийно завершает транзакцию с ошибкой.
Самым надежным и методически верным решением является разделение интерактивной работы администраторов и выполнения автоматических фоновых процессов. Рассмотрим пошагово, как это настроить:
Робот_Регламент или Service_Background.Полные права (или специализированный набор ролей для закрытия месяца, если это предусмотрено вашей политикой безопасности). На вкладке «Администрирование» снимем флаг «Показывать в списке выбора», чтобы обычные пользователи не видели эту учетную запись при авторизации.Робот_Регламент. Сохраним настройки.Робот_Регламент. В колонке «Дата запрета» укажем способ «Не применять» или установим пустую дату (01.01.0001).При такой схеме фоновое задание всегда будет стартовать под выделенной учетной записью, для которой полностью отключены проверки дат изменения, и расчет будет проходить успешно без ослабления контроля над действиями реальных пользователей-администраторов.
Если по каким-то причинам вы не хотите создавать дополнительных пользователей, необходимо скорректировать логику самой даты запрета. Использование общей настройки «Предыдущий день» для всей базы сразу — частая ошибка администрирования, парализующая регламентные операции.
Разберем, как правильно разделить контуры оперативного и финансового учета:
При такой настройке регламентный расчет себестоимости, выполняющийся в текущем месяце, сможет беспрепятственно записывать данные в регистры на дату 01.06.2026, так как весь текущий месяц открыт для регламентных операций, в то время как первичные документы вчерашнего дня для обычных пользователей останутся заблокированными.
Иногда регламентный расчет себестоимости аварийно завершается из-за того, что система пытается рассчитать не только текущий месяц, но и обращается к прошлым закрытым периодам. Это происходит, если в системе остались необработанные или некорректно сформированные «задания» из-за перепроведения старых документов.
Проанализируем состояние базы данных и устраним эту проблему:
Задания к расчету себестоимости.Месяц указаны периоды за прошлые кварталы или годы, это означает, что система при каждом автоматическом расчете пытается актуализировать себестоимость прошлых лет и упирается в дату запрета изменений.Для программной очистки устаревших записей можно воспользоваться несложной обработкой со следующим кодом:
ГраницаОчистки = НачалоМесяца(ТекущаяДата()); // Оставляем только текущий месяц
НаборЗаписей = РегистрыСведений.ЗаданияКРасчетуСебестоимости.СоздатьНаборЗаписей();
// Выполняем выборку старых записей и их удаление
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| Задания.Организация КАК Организация,
| Задания.Месяц КАК Месяц
|ИЗ
| РегистрСведений.ЗаданияКРасчетуСебестоимости КАК Задания
|ГДЕ
| Задания.Месяц < &ГраницаОчистки";
Запрос.УстановитьПараметр("ГраницаОчистки", ГраницаОчистки);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
Набор = РегистрыСведений.ЗаданияКРасчетуСебестоимости.СоздатьНаборЗаписей();
Набор.Отбор.Организация.Установить(Выборка.Organizaciya);
Набор.Отбор.Месяц.Установить(Выборка.Mesyac);
Набор.Записать(); // Запись пустого набора удаляет движения по данному отбору
КонецЦикла;
КонецЕсли;
Очистка устаревших записей регистра не только решит проблему с датой запрета изменений, но и существенно ускорит ежедневное выполнение регламентных заданий, так как серверу 1С больше не придется тратить ресурсы на анализ неактуальных исторических данных.