В процессе разработки и сопровождения конфигураций на платформе 1С:Предприятие 8 часто возникает вопрос: обязан ли Период записи в регистре накопления (или сведений) в точности соответствовать дате документа, который является регистратором этой записи? Рассмотрим эту ситуацию подробно, разберем механизмы платформы и выясним, почему в некоторых случаях дата документа может «подтягиваться» к периоду движений.
С точки зрения платформы «1С», Дата документа и Период записи в регистре — это два разных поля в базе данных. Прямой жесткой связи, накладываемой на уровне СУБД, между ними нет. Это означает, что программно мы можем записать в регистр любую дату в поле Период, независимо от того, каким числом датирован сам документ-регистратор.
Проанализируем стандартный механизм формирования движений. Обычно в процедуре ОбработкаПроведения мы заполняем набор записей регистра. Если мы явно не указываем период для каждой строки, платформа может подставить дату документа, но разработчик имеет полное право переопределить это значение:
Движение = Движения.Хозрасчетный.Добавить();
Движение.Регистратор = ЭтотОбъект.Ссылка;
// Период может быть любым, не обязательно равным ЭтотОбъект.Дата
Движение.Период = КонецМесяца(ЭтотОбъект.Дата);
Движение.СчетДт = ПланСчетов.Хозрасчетный.ОС;
// ... заполнение остальных полей
Если вы заметили, что при проведении документа его дата внезапно меняется и становится равной периоду движений в регистре, важно понимать: сама платформа так не делает. Это поведение прописано в коде конкретной конфигурации. Разберем основные причины, почему это происходит:
ПередЗаписью или ОбработкаПроведения может присутствовать строка вида ЭтотОбъект.Дата = Движение.Период;. Часто это делается для того, чтобы документ не «висел» в будущем относительно своих реальных движений, что может быть критично для управленческой логики.ПриЗаписи набора записей регистра. При срабатывании она находит регистратор и корректирует его дату.Рассмотрим ситуации, когда несовпадение периода регистра и даты документа является не ошибкой, а необходимостью:
Выясним, как такое поведение отражается на получении данных из системы. Это критически важный момент для разработчика. Все виртуальные таблицы регистров накопления (Остатки, Обороты, ОстаткиИОбороты) работают исключительно по полю Период.
Проанализируем ситуацию: дата документа — 10.05.2023, а период движения в регистре — 12.05.2023.
МоментВремени документа (10.05.2023), мы не увидим эти движения, так как они находятся «в будущем» относительно этой точки.Регистратор.Дата в запросах к виртуальным таблицам является справочным и никак не влияет на то, попадет ли запись в расчет итогов на определенную дату. Решающее значение имеет только Период.Рекомендация: При получении остатков в коде проведения такого «сложного» документа всегда используйте объект Граница, если вам нужно включить или исключить конкретные движения, либо четко задавайте момент времени, понимая специфику ваших периодов.
Посмотрим на ограничения оперативного режима. Если у документа в метаданных включено «Использовать режим проведения: Оперативный», платформа ожидает, что движения будут делаться «сейчас». Попытка программно записать в регистр период из далекого прошлого при оперативном проведении может привести к конфликтам блокировок или логическим коллизиям в механизме контроля остатков. Контроль остатков в оперативном режиме всегда выполняется на текущий момент времени сеанса, независимо от того, какой период вы указали в наборе записей.
Проанализируем ситуацию с последовательностями. Положение документа в последовательности обычно определяется его датой и временем. Если документ делает движения «в прошлое» (период меньше даты документа), платформа не переместит его в начало последовательности автоматически. Это создает серьезный риск: итоги на раннюю дату изменятся, а документы, стоящие в последовательности после этой даты, но перед нашим документом-регистратором, останутся «не в курсе» изменений. Это классическая причина нарушения правильности партионного учета или расчета себестоимости.
Вывод: Разделение даты документа и периода регистра — это мощный инструмент, позволяющий отражать сложные хозяйственные операции. Однако использовать его нужно с осторожностью, понимая, как это повлияет на запросы остатков, последовательности и отчетность предприятия.