Учетная история Справочных сущностей
В статье рассказывается о проблеме обновления данных в учётных системах и полезности учёта состояний справочных сущностей.
Амбула
Представим, что у вас есть MVP и вы сделали справочник сотрудников для бухгалтера, самым тривиальным образом, и запустили в эксплуатацию.
Явление бухгалтера первое
К вам приходит бухгалтер и говорит, что сотрудница Иванова поменяла фамилию на Петрова.
Вы: заходите в справочник и меняете фамилию сотрудницы.
Явление бухгалтера второе
Приходит бухгалтер и говорит, что в отчете за прошлый квартал Петрова отображается неправильно, поскольку тогда она была еще Иванова.
Вы: понимаете, что исправить этот дефект можно с помощью учётного версионирования строк с указанием даты ввода в учёт нового значения и дорабатываете.
Явление бухгалтера третье
Еще через 3 месяца бухгалтер приходит опять и говорит, что у этой же сотрудницы ошибка в отчестве.
Вы: заходите в справочник, исправляете ошибку, и в результате порождается новая версия записи с правильным отчеством.
Явление бухгалтера четвертое
Бухгалтер звонит и жалуется, что в отчетах за предыдущие кварталы отчество сотрудницы выводится неправильно.
Тут приходит понимание, что в справочнике нужно сделать кнопку "Сохранить" для update`а немного сложнее. При нажатии кнопки необходимо спросить у пользователя, а что, собственно, он хочет сделать, исправить ошибку или актуализировать значение?
- если нужно Исправить ошибку ...
» Это Коррекционное изменение.
» В этом случае версия записи порождаться не будет, но исправление должно быть сделано в актуальной и исторических версиях. - если нужно Актуализировать значение ...
» Это Эволюционное изменение.
» В этом случае нужно потребовать дату ввода в учёт нового значения. Будет порождена новая версия записи.
Важный нюанс
AT – дата окончания учётного состояния
Для самостоятельной сущности (на которую могут быть ссылки) допускается удаление (если она ошибочно создана), но не допускается ограничение AT в актуальной записи. Дело в том, что технически актуальность сущности должна быть непрерывна и покрывать диапазон 2000 – 3000 гг. Это нужно для того, чтобы ретроспективные запросы не разрушались в ситуации, когда ссылка на сущность есть, а актуальности в исторической точке нет (а такое случается). Тогда управлять видимостью сущности в UI надо с помощью отдельного признака (т.е. учетные состояния – отдельно, видимость в UI – отдельно).
Для подчиненной сущности (на которую не может быть ссылок, например: предметный состав), допускается удаление (если она ошибочно создана), а также допускается ограничение AT в актуальной записи. Здесь уже не нужен дополнительный признак для UI (используется AT).
Общие тезисы
Учётная история нужна только для нормативного базиса (справочники).
Так как некоторые кейсы могут быть достаточно запутанными, то необходим интерфейс для управления учетной историей (иногда нужно исправить даты или отменить изменение).
Аудит действий пользователя никак не связан с учетной историей, поэтому моделируйте его отдельно.