Вариант прототипа новой методики учета периодических возвратных регистров сведений для будущей редакции ЗУП

О чем статья

В конфигурациях 1С: ЗУП одна из ключевых проблем – эффективная реализация архитектуры периодических возвратных регистров сведений таких как «Кадровая история сотрудников», «Плановые начисления», «Состояния сотрудников» и т.д.

В ЗУП 2.5 программисту вручную приходилось реализовывать все особенности учета этих регистров. В ЗУП 3 ситуацию улучшили специализированным программным интерфейсом и механизмом представлений, которые стандартизируют и реализовывают все особенности учета этих регистров. Но данная архитектура стала своего рода шифровальная машина «Энигма» для избранных, повышая порог вхождения в разработку конфигурации ЗУП.

Данная статья предлагает вариант дальнейшей эволюции реализации архитектуры периодических возвратных регистров сведений. Возможно, новая методика пригодится при проектировании ЗУП 4 :)

Основные проблемы в учете периодических данных:

1. Учет возвратных событий.
   На примере регистра «Кадровая история сотрудников»: сотрудник с 01 января занимал должность «Программист». С 15 января по 25 января его временно перевели на должность «Старший программист», пока его коллега был в отпуске. Проблема получения информации об актуальной должности на 10, 20 и на 31 января и проблема получения интервалов действия должностей с 01 по 31 января.

2. Вытеснение приоритетными интервалами, пересекающих интервалы других регистраторов.
   На примере регистра «Состояния сотрудников»: сотрудник с 01 января в состоянии «Работает». С 15 января по 25 января он берет отпуск и находится в состоянии «Отпуск». Однако 20 января он заболел и болел до 30 января, то есть находился в состоянии «Больничный». Проблема получения информации об актуальном состоянии на 10, 17, 23, 27 и 31 января и проблема получения интервалов действия состояний с 01 по 31 января.

Преимущества новой методики.

Преимущества данной методики по сравнению с текущей в ЗУП 3:

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

2. Отсутствие сложного перегруженного программного интерфейса. Вся работа сводится к простым запросам

3. Отсутствие механизма представлений в СКД. Отчеты на СКД разрабатывать и отлаживать проще.

4. Простота, прозрачность и читаемость данных в регистрах для пользователей, аналитиков и разработчиков

5. Легко внедрить новый нетиповой интервальный регистр.

6. По сути, вся учетная работа ведется с обычным периодическим регистром сведений без возвратных событий и без вытеснения, как например с РС «ФИО физических лиц». При этом проблема возвратных событий и вытеснений конкурентных интервалов решена.

7. Гибкая система настройки приоритетов интервалов разных типов регистраторов

Концепция.

Основные принципы и особенности методики:

1. Данная методика работает при любых комбинациях возвратных событий и конкурирующих интервалов разных типов регистраторов с разными приоритетами

2. Учет периодических данных строится на двух регистрах:

а) Системный регистр. Непериодический. Подчинен регистратору.

Имеет имя <УчетноеИмя>Регистрация. (Пример «ПлановыеНачисленияРегистрация»)

Имеет следующую структуру:

Измерения:

ДатаНачала

ДатаОкончания

РегистраторИзмерение

<УчетноеИзмерение1….N>

Ресурсы:

ПустойИнтервал

<УчетныйРесурс1….N>

б) Учетный регистр. Периодический (в пределах дня). Независимый.

Имеет имя <УчетноеИмя>. (Пример «ПлановыеНачисления»)

Имеет следующую структуру:

Измерения:

<УчетноеИзмерение1….N>

Ресурсы:

ПустойИнтервал

<УчетныйРесурс1….N>

3. В системном регистре ДатаНачала и ДатаОкончания имеют тип Дата без времени. То есть никаких секунд. Периодичность интервалов – в пределах дня

4. В системном регистре ДатаОкончания – всегда заполнена. Если событие не имеет завершения, то ДатаОкончания = 31.12.3999. Таким образом всегда ДатаНачала <= ДатаОкончания. Никаких проверок на незаполненность ДатаОкончания. Все интервалы правильные с точки зрения логики и имеют всегда границы с обеих сторон.

5. В системном регистре ДатаОкончания – это последний день действия интервала. Пример интервал Надбавки в регистре 02.06.2024 – 08.06.2024, значит 08.06.2024 – это последний день действия надбавки

6. В учетном регистре хранятся сведения о датах начала смены состояния данных, с учетом возвратных событий и вытеснений

7. Приоритеты конкурирующих интервалов определяются по типу регистратора в специальном регистре «ПриоритетыРегистраторов». Приоритет двух интервалов регистраторов, имеющих один тип, определяется датой регистратора – чем позже, тем приоритет выше.

8. При проведении, перепроведении и отмене проведения регистратор делает запись в системный регистр. При этом системный регистр при записи своего интервала делает перерасчет дат начала смены состояния данных в учетном регистре в пределах своего интервала (точнее с ДатаНачала-1день по ДатаОкончания+1день). За пределами своего интервала делать перерасчет нет необходимости. Перерасчет делается с учетом всех конкурирующих интервалов согласно приоритету их регистраторов-владельцев

9. 

10. Прилагается конфигурация-пример, в которой воспроизведена данная методика. Тестирование проводилось на платформе 1С 8.3.27.1719. Рассмотрен случай с плановыми начислениями, чтобы учесть ситуацию с несколькими учетными измерениями (Сотрудник+Начисление). Перерасчет учетного регистра можно найти в модуле набора записей ПлановыеНачисленияРегистрация

11. В конфигурации-примере также разработаны элементарные отчеты чтобы показать получение данных из учетного регистра в двух распространенных режимах: а) получение данных на заданную дату; б) получение данных за указанный период.