Cash Management в EDWH: гранулярность, история и сверка
Как проектировать передачу прогнозных и фактических денежных потоков: сохранять идентичность источника, версии прогноза, валюту и статусы, не предполагая CDC или универсальный SAP API.
4 мин чтения·База знаний
Ревизия 2Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-S4-ONPREMдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Cash Management в EDWH: гранулярность, история и сверка#
One Exposure from Operations - оперативная модель потоков для Cash Management; EDWH решает другую задачу: воспроизводимо хранит историю, версии и контрольные результаты. Передача только итогового остатка теряет происхождение суммы, а перезапись предыдущего прогноза фактом не позволяет восстановить, что было известно на дату расчёта.
Сначала подтвердите интерфейс и уровень детализации#
Документация SAP описывает источники One Exposure, типы и certainty уровни денежных потоков, отдельные интеграции учётных документов и выписок. Это не задаёт универсальный API, ключ строки или CDC-механизм для всех выпусков. Выберите документированный для вашей редакции интерфейс, проверьте его ключи, семантику удаления/сторно, доступные поля, границы извлечения и права. Не считайте внутреннюю таблицу или техническое поле стабильным контрактом без опубликованной гарантии.
Для исходной строки определите её фактический уровень детализации в выбранном интерфейсе. В проекте EDWH зафиксируйте согласованную идентичность как минимум через оригинальную систему, приложение-источник, ключ исходного документа/события и ключ строки. Состав полей, их обязательность и уникальность нужно подтвердить в системе, а не вывести из названия One Exposure.
В аналитическом событии или срезе оставляйте рядом с суммой контекст, который объясняет её: компания, банковский счёт/идентификатор, валюта суммы, дата потока и дата извлечения, flow type, certainty level, liquidity item, planning level/group, приложение-источник, original system, ссылка на документ и статус. Точное представление зависит от контракта источника.
Не смешивайте две оси времени:
бизнес-время потока: дата документа, платежа, валютирования или выписки;
время наблюдения: когда конкретная версия записи была получена и зафиксирована в EDWH.
Суммы храните вместе с исходной валютой. Если нужна валюта отчёта, сохраняйте курс, источник курса, дату/время действия и правило пересчёта отдельно. Прогноз и факт разделяйте по состоянию/классификации, а не по догадке на основании даты или знака.
Официальная документация описывает real-time интеграцию центральных приложений в One Exposure и отдельно - массовую начальную загрузку существующих данных. Это не означает, что downstream-интерфейс обязан поставлять CDC, tombstone или последовательный номер версии. Выясните документированную стратегию извлечения: watermark, диапазон повторного чтения, полный снимок, delta-объект или сообщение об удалении.
В EDWH используйте идемпотентное применение по подтверждённому ключу и версии источника. Поздно доставленная старая версия не должна молча затереть более новую. Исправление или сторно сохраняйте как изменение состояния либо связанное корректирующее событие; не изменяйте факт исходного поступления без аудита.
Для истории прогноза сохраняйте отдельные неизменяемые vintages. Например, снимок на момент T1 может содержать ожидаемые 100 EUR; на T2 поступила фактическая часть 40 EUR, и актуальный остаток прогноза стал 60 EUR; на T3 пришли остальные 60 EUR. Для оперативного остатка прогноз уменьшается по мере подтверждения, но EDWH сохраняет все три состояния, если нужно анализировать точность прогноза и поздние изменения. Это рекомендованная модель хранилища, не утверждение о встроенной функции SAP.
Для каждой загрузки сохраняйте batch ID, время начала/окончания, watermark, редакцию источника, прочитанные/принятые/отклонённые строки и причины отказа. Карантин и повторная обработка не должны незаметно терять исходный ключ.
Сверяйте по одинаковому срезу и отдельно по компании, счёту, валюте, дате/горизонту, certainty и flow type:
Количество и сумму строк в источнике и landing-слое.
Дубли идентичности, пропуски ключей, неизвестные валюты/типы и поздние версии.
Итоги после применения относительно принятых строк, с отдельным объяснением сторно, удаления и карантина.
Прогноз и фактические движения отдельно; внутренние переводы и повторные пути импорта не должны удваивать внешние поступления/выплаты.
Повторный запуск одного batch ID даёт тот же результат и не создаёт новых событий.
Сравнение итога без сопоставления состава строк может скрыть компенсирующие пропуски и дубли. Различия по периоду или валюте не исправляйте технической корректировкой, пока не объяснены источник и временная семантика.
Материал частично покрывает CASH-24. Источники относятся к SAP S/4HANA On-Premise 2025 FPS01/FPS02 и зарегистрированы как metadata_only. Интерфейс, ключи, CDC, объём данных, конфигурация и SAP runtime не проверялись; статья задаёт аналитическую модель передачи, а не реализацию интеграции в конкретной системе.
Cash Management in EDWH: Grain, History, and Reconciliation#
One Exposure from Operations is the operational flow model for Cash Management; an EDWH has a different role: it stores history, versions, and control results reproducibly. Transferring only a closing balance loses the amount's lineage, while overwriting an earlier forecast with actuals prevents reconstruction of what was known at forecast time.
SAP documentation describes One Exposure sources, cash-flow types and certainty levels, and separate accounting-document and bank-statement integrations. It does not define a universal API, row key, or CDC mechanism for every release. Select an interface documented for the target edition and check its keys, deletion/reversal semantics, available fields, extraction boundaries, and permissions. Do not assume an internal table or technical field is a stable contract without a published guarantee.
Determine the actual grain of the selected interface. In the EDWH design, preserve identity with at least the original system, source application, originating document/event key, and line key. Confirm the exact fields, requiredness, and uniqueness in the system instead of inferring them from the One Exposure name.
In the analytical event or snapshot, keep context next to the amount so it can be interpreted: company, bank account/ID, amount currency, flow date and extraction date, flow type, certainty level, liquidity item, planning level/group, source application, original system, document reference, and status. The exact representation depends on the source contract.
Keep two time axes separate:
Flow business time: document date, payment date, value date, or statement date.
Observation time: when a particular record version was received and committed to the EDWH.
Store amounts with their source currency. If a reporting currency is needed, retain the rate, source, effective date/time, and conversion rule separately. Separate forecasts from actual movements by state/classification, not by guesswork based on date or sign.
Official documentation describes real-time integration of central applications into One Exposure and separately describes bulk initial loading of existing data. This does not imply that a downstream interface must provide CDC, tombstones, or a sequential version. Identify the documented extraction strategy: watermark, replay window, full snapshot, delta object, or deletion message.
Apply rows idempotently using a confirmed key and source version. An older version delivered late must not silently overwrite a newer one. Preserve a correction or reversal as a state change or linked correcting event; do not alter the original arrival without an audit trail.
For forecast history, retain separate immutable vintages. For example, a snapshot at T1 may contain an expected 100 EUR; at T2, 40 EUR is received and the current remaining forecast becomes 60 EUR; at T3, the remaining 60 EUR arrives. The operational outstanding forecast decreases as it is confirmed, while the EDWH retains all three states when forecast accuracy and late changes must be analyzed. This is a recommended warehouse model, not a claim about built-in SAP functionality.
For each load, retain batch ID, start/end time, watermark, source version, rows read/accepted/rejected, and rejection reasons. Quarantine and replay must not silently lose the source key.
Reconcile the same slice and separately by company, account, currency, date/horizon, certainty, and flow type:
Source and landing-layer row counts and amounts.
Duplicate identities, missing keys, unknown currencies/types, and late versions.
Applied totals against accepted rows, with reversals, deletions, and quarantine explained separately.
Forecasts and actual movements separately; internal transfers and repeated ingestion paths must not double-count external receipts/payments.
Replaying the same batch ID gives the same result and creates no new events.
Comparing totals without comparing row composition can hide offsetting omissions and duplicates. Do not correct a period or currency difference technically until its source and time semantics are understood.
This material partially covers CASH-24. Sources apply to SAP S/4HANA On-Premise 2025 FPS01/FPS02 and are registered as metadata_only. The interface, keys, CDC, dataset, configuration, and SAP runtime were not checked; this article defines an analytical transfer model rather than an implementation for a specific system.