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