Есть два основных направления отслеживания истории изменения какого-либо объекта.
1. Историчность данных
В этом случае мы принимаем за основу, что нам интересно знать состояние объекта на любую заданную дату: год назад, месяц назад, вчера, сегодня. И знание такой информации важно для осуществления бизнес-операций.
Реализуется такое в БД посредством включения даты в ключ таблицы (BEGDA/ENDDA) и написания многих строк на ABAP, разруливания этого добра на экранах.
При этом предполагается, что пользователь может управлять диапазонами актуальности данных.
Модуль Управление кадрами HCM практически полностью использует этот подход, там всё зависит от даты (имя, должность, организационное присвоение, наименования, мероприятия, отсутствия, документы, счета).
2. Журналирование изменений
В этом случае мы принимаем за основу, что нас интересует только текущее состояние объекта, но мы хотим “на всякий случай” иметь историю изменения.
Эта история нужна в первую очередь для контроля за действиями пользователя пост-фактум. Как правило, её используют только в качестве улик, при разборе проблем. Информация о предыдущем состоянии объекта не может использоваться в бизнес-операциях, хотя я встречал в жизни и такие Z-кейсы.
При этом предполагается, что пользователь не может управлять журналированием – оно производится незаметно и всегда. При желании пользователь может посмотреть на историю, выбрав соответствующий пункт меню.
Самый базовый подход предполагает использование четырёх дополнительных полей: ERNAM (кто создал), ERDAT (когда создал), AENAM (кто изменил), AEDAT (когда изменил). Дело совсем нехитрое. Однако нас может и должен заинтересовать характер вносимых изменений, то есть список всех изменений, включая старые и новые значения полей:
Пользователь IVAN 13 декабря 2012 года в 14:15 GMT в объекте ANLA (ключ 001234567890) в таблице ANLA поменял поле TXT50 (Наименование основного средства) со значения «Мой компьютер» на «Просто компьютер».
Именно такой подход используется практически во всех основных данных ERP (ОС, Счёт, Дебитор, Кредитор), поэтому есть некоторый стандартный механизм в SAP, который используется везде, где это необходимо.
И именно о нём пойдёт речь под катом.