При этом не забываем, что фактические операции обычно вводятся в ERP с отставанием как минимум несколько минут, а то и в день.

SPL
Пример 2 (посложнее)
Рассмотрим более сложный пример из другой сферы: управление платежами. Здесь точно так же используется три документа:

• заявка на оплату (поданная руководству компании одним из подразделений);
  
• платежное поручение (поданный компанией в банк «заказ» списать денежные средства с расчетного счета);
  
• банковская выписка (отчетный документ от банка о фактически проведенном платеже).

Но информация об одном и том же платеже в компании проходит семь этапов, на каждом из которых отдельные реквизиты платежа могут уточняться и изменяться.

Табл. 1
Вообще, в бизнесе различаться на разных этапах могут любые данные — даты платежей; банковские счета; статьи; суммы; ставки НДС; номера договоров и т.д.

В каких еще сферах может встречаться эта задача?
Возможно, во всех. Как минимум:

• в производстве (где используется заказ на производство, план производства);
  
• в транспортной логистике (заказ на транспортировку);
  
• в управлении складом (расходные ордеры).

Как происходит сейчас
Обычно в ERP-системах логика ввода и хранения данных, отчетов и расчетов привязывается не к сквозному объекту учета («платеж» или «закупка»), а к отдельным документам. В результате складываются различные проблемные ситуации.
1) Отчеты и аналитика только по фактическим документам.
Утвержденные заявки и даже заказы при этом не учитываются, хотя, как мы уже рассмотрели выше, для бизнеса это необходимо.
2) Отдельные отчеты и аналитика по плановым документам (заказам, заявкам, потребностям).
В таких отчетах часто используется, в том числе, информация из тех плановых документов, которые уже исполнены. Однако, это неправильно: всю информацию из исполненной заявки, насколько это возможно, нужно замещать информацией из созданного по ней фактического документа, во всех управленческих отчетах.
3) Со временем, по мере возникновения потребности, фактические отчеты и расчеты иногда дорабатывают так, чтобы в них «попадали» еще и плановые документы. Но в них обычно не прописывают условие для плавной актуализации данных, например: [Если в выписке заполнена дата платежа — использовать её; если нет — использовать ожидаемую дату по заявке]. А значит, если в выписке пропущены какие-то отдельные поля — они не заместятся заявочными.
4) И наоборот, для решения проблемы №2 в плановые отчеты иногда искусственно добавляется уточняющая информация из фактических документов. Но эти доработки также выполняются достаточно индивидуально, без решения задачи в общем виде.
5) Информацию, полученную на этапе «звонок из банка», вписать элементарно некуда.
Для этого этапа нужно либо создавать отдельный документ, хотя с точки зрения логики бизнеса это не обосновано, либо позволять изменять уже зафиксированный документ (например, платежное поручение или даже заявку на оплату), что также неправильно: каждый документ должен хранить те данные, которые были актуальны на момент его фиксации.
Как итог, описанная задача иногда решается, но на основе заранее ограниченных вводных данных в каждом конкретном случае. В данной статье я предлагаю обсудить ее решение в общем виде.
Логика решения
Паттерн 1: все о платеже — в одну строку
Самый простой вариант решения — создать объект «платеж», всю информацию о котором записывать в строку: всё новые данные о нем просто дописываются всё правее и правее во всё новые столбцы.

Рис. 3. Продольная информация о платеже
В этом случае отчеты должны будут использовать по каждому сквозному реквизиту (дата платежа; банковский счет) сведения, которые находятся правее других. А если информации там не будет хватать — проверять все левее и левее.

Плюсы этого паттерна:

• Такая таблица максимально приближена к логике бизнеса, и по ней легко проверять данные
  
• В отчетах можно легко фильтровать нужные версии (этапы) данных о платеже, принимая/убирая из внимания те или иные столбцы
  
• При такой конструкции dramatically проще анализировать расхождения между разными документами по одному платежу (поскольку сравнивать колонки одной таблицы в реляционных ERP очень несложно даже с помощью пользовательских конструкторов отчетов). Тогда как при другой архитектуре это может быть непросто

Минусы:

• Такой подход хорош только когда число этапов (версий данных об операции) заранее известно. Но если этапов много и они могут периодически добавляться, в систему придется добавлять много столбцов, и каждый раз делать это программно. А в базах данных (SQL), как мы знаем, столбцы обходятся дороже строк

Обратите внимание, что я не показал в примере разные столбцы для разных этапов согласования документа заявки. Дело в том, что этапов в маршрутах согласования в компании может быть очень много, и их количество может постоянно изменяться пользовательскими настройками. Создавать на каждый этап согласования одного документа отдельные столбцы и поддерживать их — это чересчур.

• В этом варианте система сама по себе не будет «знать», что «Дата платежа» из заявки и «Дата платежа» из выписки — с точки зрения бизнеса один и тот же реквизит платежа. Таким образом, каждый раз при добавлении каждого столбца в таблицу, код каждого отчета и расчета скорее всего придется дописывать, добавляя в него чтение и интерпретацию этого столбца.

Паттерн 2: каждый новый этап данных — новой строкой
В более универсальном виде можно сделать так: записывать каждый новый этап (версию) данных не в столбцы, а в строки. При этом id у каждого платежа будет одним и тем же по всем строкам (см. нижняя таблица на рисунке).
А на основе этой таблицы будет постоянно обновляться срез, который содержит только одну — самую актуальную — версию данных по каждому реквизиту (см. верхняя таблица).

Рис. 4. Построчная информация о платежах
По этой схеме лучше всего видно, что задача в общем виде становится очень похожей на те задачи, которые решаются при построении хранилищ данных (DWH). При этом таблицу версий можно рассматривать по смыслу близкой к таблице-сателлиту в методологии Data Vault.

Плюс такой логики:

• У каждого платежа есть единая структура реквизитов. Система будет знать, что дата — это дата, а банковский счет — это банковский счет
  
• При этом для каждого платежа можно создавать сколько угодно новых этапов (в том числе, новых документов) — причем делать это значительно проще, чем в другой бизнес-архитектуре. Несложно сделать так, чтобы новые этапы создавались в пользовательском режиме

А вот дальнейшие плюсы и минусы будут зависеть от выбранного варианта реализации.

ВАРИАНТ РЕАЛИЗАЦИИ 2.1: ОБЕ ТАБЛИЦЫ ПОСТОЯННО СУЩЕСТВУЮТ В СИСТЕМЕ
Плюсы

• Максимальная скорость формирования отчетов

Минусы

• В отчетах нельзя будет задавать фильтры по версиям данных.