При разработке на платформе 1С часто возникает задача хранить историю изменений каких-либо данных, привязанных к документам. Для этого идеально подходит периодический регистр сведений, подчиненный регистратору. Однако при его настройке появляются два ключевых вопроса: накладывает ли подчинение регистратору ограничения на выбор периодичности и как в этом случае будет работать виртуальная таблица СрезПоследних, в частности, вернет ли она сам документ-регистратор?
Давайте подробно разберем эти моменты, чтобы в дальнейшем не возникало путаницы, и проанализируем, как разные настройки влияют на поведение системы.
Первый вопрос касается того, можно ли для подчиненного регистра использовать любую периодичность (например, "В пределах секунды", "В пределах дня") или есть какие-то строгие ограничения. Короткий ответ: можно использовать любую периодичность. Подчинение регистратору напрямую не блокирует выбор периодичности.
Однако ключевое различие кроется в том, как формируется уникальный ключ записи регистра при разных настройках периодичности. Именно это определяет, как система будет себя вести при попытке записи данных из разных документов в один и тот же момент времени.
Рассмотрим два основных сценария:
В этом режиме ключ уникальности записи формируется из комбинации Период + Набор измерений. Поле Регистратор в состав ключа уникальности не входит.
Что это означает на практике? Если два разных документа (например, два "Приема на работу") попытаются записать в регистр сведения для одного и того же сотрудника (одно и то же измерение) с точностью до одной секунды, то второй документ не проведется. Система выдаст ошибку о нарушении уникальности записи, так как в регистре уже существует запись с таким же периодом и набором измерений.
Такой режим подходит, когда изменение состояния объекта (например, назначение цены на товар) должно быть уникальным в пределах выбранного временного интервала, и неважно, какой именно документ это сделал.
Этот режим периодичности доступен как раз для регистров, подчиненных регистратору. Здесь ключ уникальности формируется совершенно иначе: Регистратор + Номер строки документа. Платформа для определения "позиции" использует внутренний уникальный идентификатор, связанный с документом и его строкой на оси времени.
Что это означает на практике? Два (и более) разных документа могут совершенно спокойно делать записи с абсолютно одинаковыми измерениями в один и тот же момент времени. Конфликта уникальности не возникнет, потому что у каждой записи будет свой уникальный регистратор в составе ключа. Каждая запись будет уникальна за счет своей привязки к конкретному документу.
Этот режим является предпочтительным, когда нужно отслеживать историю изменений, вносимых именно документами, и допускается, что несколько документов могут влиять на одни и те же данные в один момент времени.
Второй вопрос: как поведет себя запрос к виртуальной таблице СрезПоследних и вернет ли он поле Регистратор? Ответ однозначный: да, вернет.
Для регистра сведений, подчиненного регистратору, поле Регистратор является стандартным реквизитом и всегда доступно для выбора в запросах, в том числе и к виртуальным таблицам. Это одно из его ключевых отличий от независимых регистров.
Однако логика определения "последней" записи немного отличается в зависимости от периодичности:
МоментВремени, который включает в себя не только дату, но и ссылку на сам документ. Это гарантирует стабильный и предсказуемый порядок документов и, соответственно, правильное определение последнего значения.Чтобы картина была полной, рассмотрим еще несколько важных аспектов, которые часто вызывают вопросы.
В обсуждениях иногда встречается ошибочное мнение, что Регистратор является ресурсом регистра. Это не так. Регистратор — это стандартный реквизит, который платформа добавляет автоматически при установке режима записи "Подчинение регистратору". На уровне базы данных это отдельная колонка, хранящая ссылку на документ.
Важным следствием этого является автоматическое поддержание ссылочной целостности. Если вы удалите документ-регистратор, платформа автоматически удалит все связанные с ним записи из подчиненного регистра сведений. Это очень удобно и избавляет от необходимости писать дополнительный код для очистки "хвостов".
В теме возникла путаница между понятиями "Режим записи" и "Периодичность". Давайте их разграничим:
Это накладывает важное ограничение: записывать данные в такой регистр можно только через набор записей, связанный с конкретным документом-регистратором. Например, в модуле объекта документа, установив свойство Записывать в Истина для нужного набора движений, или программно, через метод СоздатьНаборЗаписей() с установленным отбором по регистратору.
Вы не сможете создать запись в таком регистре с помощью менеджера записи (РегистрыСведений.МойРегистр.СоздатьМенеджерЗаписи()) и записать ее без привязки к документу.
Еще одна полезная особенность подчиненных регистров — автоматическое добавление стандартного реквизита Активность (тип Булево). Он играет ключевую роль в механизме проведения и отмены проведения документов.
Активность = Истина.Активность = Ложь).Виртуальные таблицы, включая СрезПоследних, по умолчанию работают только с активными записями. Таким образом, когда вы отменяете проведение документа, срез автоматически начинает "видеть" предыдущее состояние данных, записанное предыдущим активным документом. Это элегантный и производительный механизм, позволяющий легко "откатывать" изменения.
Подведем итог. Подчинение регистра сведений регистратору — мощный механизм, но его нужно использовать осознанно. Выбор периодичности напрямую влияет на логику работы системы и должен диктоваться бизнес-задачей. А виртуальная таблица СрезПоследних прекрасно справляется со своей задачей в любом из режимов, корректно возвращая как сами данные, так и ссылку на документ, который их установил.