SAP Journal в EDWH: ключи, валюты, история и сверка

Перед передачей финансовых строк в EDWH зафиксируйте контракт чтения: источник и выпуск, уровень детализации строки, ключ, ledger, компанию, год, временную семантику, валютный тип, фильтр извлечения, правила повторной загрузки и сверки. Само название Universal Journal не задаёт готовый контракт для любого API, представления или выпуска SAP.

Сначала зафиксируйте уровень детализации и ключ#

Для line-item чтения G/L Account Line Items API документация SAP приводит среди ключевых полей AccountingDocument, CompanyCode, FiscalYear, Ledger, LedgerGLLineItem и SourceLedger. Она отдельно уточняет, что AccountingDocumentItem (ACDOCA-BUZEI) используется для ассоциаций с представлениями BSEG. Это предупреждение против выбора поля BUZEI как универсального идентификатора строки любого ledger-view сценария.

Ключ нужно брать из контракта выбранного released API или CDS view, затем проверять на целевом выпуске и реальных данных. Не удаляйте ledger, компанию, финансовый год или источник из ключа при переносе в DWH, если они различают записи источника. Храните исходный ключ целиком либо его детерминированное представление с возможностью восстановить поля.

Ограничьте извлечение#

SAP предупреждает, что API чтения строк не предназначен для полной выгрузки огромного Universal Journal. Для line-item уровня документация рекомендует сильную фильтрацию и явное включение ключевых полей; примеры часто используют агрегацию, когда нужна аналитическая сумма, а не детализация каждой строки.

Поэтому отдельно опишите initial load и delta-процесс. Укажите допустимый диапазон ledger, компании, финансового года, периода и ключа продолжения. Не называйте процесс CDC, change data capture или гарантированно полным, пока такая возможность не подтверждена для выбранного интерфейса. Если интерфейс не даёт надёжного маркера изменений, спроектируйте повторное чтение контролируемого окна и сверку его результата.

Разделяйте дату проводки и момент знания#

Дата проводки отвечает за отнесение суммы к финансовому периоду. observed_at в EDWH фиксирует, когда конкретная версия строки стала доступна вашему процессу извлечения. Это поле наблюдения DWH, а не вывод о наличии такого timestamp в ACDOCA.

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

Не складывайте разные валютные оценки#

Universal Journal поддерживает параллельные валюты, настраиваемые в контексте ledger и компании. Поэтому сумма должна проходить через EDWH вместе с валютой и типом валюты, а агрегат должен сохранять валютный контекст. Совпадение числовой суммы в разных валютах не означает, что строки можно объединять.

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

Сверяйте детали и агрегаты#

Практический контроль строится на двух уровнях:

Построчная сверка по контрактному ключу: отсутствующие, неожиданные, повторные и изменившиеся строки.
Агрегатная сверка по ledger, компании, финансовому году/периоду, счёту, валютному типу и валюте. Сравнивайте количества строк и суммы с явно согласованными фильтрами.

Нулевой итог по всему набору не доказывает полноту: пропуск и лишняя строка могут взаимно компенсироваться. Сначала сравните состав ключей, затем суммы по каждой сопоставимой группе. Зафиксируйте снимок входа, версию контракта, параметры фильтра, момент знания и ожидаемые отличия.

Варианты извлечения и доступность дельты#

Для SAP-источника сначала проверьте поддерживаемый в целевой редакции интерфейс. Operational Data Provisioning (ODP) предоставляет инфраструктуру извлечения и репликации для ABAP-приложений. В числе провайдеров SAP документирует DataSources/extractors, ABAP CDS views и SAP Landscape Transformation Replication Server (SLT). Для поддерживаемых delta-процедур ODP записывает изменения в Operational Delta Queue (ODQ), откуда их забирают подписчики. Это описание инфраструктуры, а не утверждение, что любой CDS, API или SLT-сценарий доступен в каждом продукте.

Для отдельных CDS views возможность полного или delta-извлечения задаётся публикацией и метаданными конкретного view. Наличие CDS API само по себе не доказывает, что view подходит для репликации. Более того, для пользовательского CDS view, созданного через Data Extraction scenario в SAP S/4HANA Cloud Public Edition, SAP указывает поддержку только полной загрузки, без delta. Не переносите поддержку дельты с другого view, продукта или выпуска.

Разделяйте интерфейс чтения детальных строк и интерфейс извлечения для аналитики. API чтения строки журнала может иметь ограничения на объём и фильтрацию; аналитический экстрактор или ODP-провайдер имеет отдельный контракт. До проектирования загрузки зафиксируйте доступность механизма, полный ключ, исходную дату и время изменения, правила удаления, порядок сообщений, срок хранения delta-состояния и процедуру начальной загрузки.

Контракт доставки в Financial DWH#

Целевой DWH должен сохранять ключ источника полностью и обеспечивать повторное применение одной и той же поставки без двойного учёта. Для этого удобно отдельно хранить исходное событие, номер или время наблюдаемой версии, идентификатор загрузки и результат применения. Если источник прислал позднюю коррекцию, сохраняйте её как новую версию и пересчитывайте целевое представление по объявленному правилу. Не называйте процесс exactly once только потому, что очередь или API присылает последовательный пакет: повторная доставка и восстановление после сбоя требуют идемпотентности на стороне приёмника.

Контроль полноты должен сверять не только общую сумму. Сравните количество и состав ключей, затем суммы по ledger, компании, году, периоду и типу валюты. Явно обработайте физическое удаление, отмену, сторно и изменение задним числом. Если интерфейс не предоставляет маркер изменения или семантику удаления, нельзя считать инкрементальную загрузку полной без отдельного восстановления, сканирования или иной проверяемой процедуры.

Здесь описана граница между SAP-источником и инженерной моделью финансового хранилища. Отдельный сайт Financial EDWH посвящён моделям, загрузкам, истории и сверкам на стороне хранилища; эта страница ограничена выбором SAP-интерфейса и контрактом передачи. Ни один из сайтов не утверждает, что связанная промышленная интеграция уже настроена.

Порядок сообщений и продвижение загрузки#

Если интерфейс доставляет несколько версий одной строки, применяйте их по маркеру версии источника или по иной документированной последовательности. Более старая версия, пришедшая после новой, не должна молча перезаписать актуальное состояние; сохраните её как поздно доставленное событие и отправьте на повторную обработку либо карантин согласно контракту. Время поступления в DWH само по себе не определяет порядок изменений в источнике.

Показывайте наблюдаемые этапы отдельно: прочитано из источника, принято в landing, применено, отклонено, повторно обработано и помещено в карантин. Для отклонения или карантина сохраняйте идентификатор поставки, ключ строки, версию, причину и ссылку на исходное сообщение. Продвигайте checkpoint только после долговечной фиксации соответствующих данных и результата применения; иначе сбой между фиксацией checkpoint и записью данных может пропустить изменения. При повторном запуске тот же пакет должен безопасно пройти снова.

Границы локального примера#

В SAP-лаборатории есть независимая Python-модель строк с ключом ledger/company/year/document/ledger-item/source-ledger/currency-type. Она хранит версии неизменяемо, проверяет повторный импорт, позднюю корректировку, баланс документа по каждой валютной оценке и сверку агрегатов на синтетических данных. Это учебная модель контракта, а не эмуляция ACDOCA, SAP API, CDC или продуктивного DWH.

Официальные источники относятся к конкретным редакциям и интерфейсам S/4HANA Cloud и on-premise. Перед внедрением проверьте точный выпуск, доступность API/CDS, ограничения извлечения и полномочия в вашей системе. Реального SAP runtime здесь нет.

Связанные материалы#

Before sending financial rows to an EDWH, define the read contract: source and release, row grain, key, ledger, company, year, time semantics, currency type, extraction filter, replay rules, and reconciliation. The name Universal Journal alone does not define a ready-to-use contract for every API, view, or SAP release.

Start with row grain and key#

For line-item reads, the G/L Account Line Items API documentation lists AccountingDocument, CompanyCode, FiscalYear, Ledger, LedgerGLLineItem, and SourceLedger among key fields. It separately says AccountingDocumentItem (ACDOCA-BUZEI) is used for associations with BSEG views. This is a warning against using BUZEI as a universal identifier for every ledger-view scenario.

Take the key from the contract of the chosen released API or CDS view, then verify it for the target release and actual data. Do not remove ledger, company, fiscal year, or source ledger from the DWH key if they distinguish source records. Store the full source key or a deterministic representation from which the fields can be recovered.

Bound extraction#

SAP warns that the line-item read API is not intended for a full extraction of the very large Universal Journal. For line-item detail, the documentation recommends strong filters and explicit key fields; examples often use aggregation when analysis needs a total rather than every line.

Describe initial load and delta processing separately. State the allowed ledger, company, fiscal-year, period, and continuation-key range. Do not call a process CDC, change data capture, or guaranteed complete until that ability is confirmed for the selected interface. If the interface has no reliable change marker, design controlled rereads of a bounded window and reconcile the result.

Separate posting date from observation time#

The posting date assigns an amount to a financial period. observed_at in the EDWH records when a particular row version became available to your extraction process. It is an observation field maintained by the DWH, not a claim that ACDOCA supplies that timestamp.

For a late correction, preserve the earlier row version and append a later version with a new observation time. Then a query for what was known at close can be separated from a query for the latest known state. Replaying the same key and payload should be idempotent; conflicting content for the same version identifier should fail instead of silently replacing it.

Keep currency valuations separate#

The Universal Journal supports parallel currencies configured in a ledger and company context. Therefore an amount should travel through the EDWH with its currency and currency type, and an aggregate should preserve that currency context. Equal numeric amounts in different currencies do not imply that the rows can be combined.

Before aggregation, define the target currency, exchange-rate source, rate date, precision, and rounding rule. Those parameters belong to a separate transformation. They cannot be inferred only from the fact that rows are in the same source table.

Reconcile details and aggregates#

A practical control works at two levels:

Line reconciliation by the contractual key: missing, unexpected, repeated, and changed rows.
Aggregate reconciliation by ledger, company, fiscal year/period, account, currency type, and currency. Compare counts and sums under explicitly matching filters.

A zero total over the entire dataset does not prove completeness: a missing row and an extra row may offset each other. Compare the key sets first, then amounts in each comparable group. Retain the input snapshot, contract version, filter parameters, observation time, and expected differences.

Extraction options and delta availability#

First identify an extraction interface supported by the target product release. Operational Data Provisioning (ODP) provides extraction and replication infrastructure for ABAP applications. SAP documents DataSources and extractors, ABAP CDS views, and SAP Landscape Transformation Replication Server (SLT) among its providers. For supported delta procedures, ODP writes changes to an Operational Delta Queue (ODQ), from which subscribers retrieve them. This describes infrastructure; it does not mean that every CDS view, API, or SLT scenario is available in every product.

For individual CDS views, full or delta extraction depends on that view's publication and metadata. The existence of a CDS API does not prove it is suitable for replication. In SAP S/4HANA Cloud Public Edition, SAP states that a custom CDS view created with the Data Extraction scenario supports full load only and does not support delta. Do not transfer delta support from another view, product, or release.

Separate a line-item read API from an analytics extraction interface. A journal line read API may have volume and filtering limits; an analytics extractor or ODP provider has its own contract. Before designing a load, record mechanism availability, complete source key, source change date and time, deletion rules, message ordering, delta-state retention, and initial-load procedure.

Delivery contract with Financial EDWH#

The target warehouse should retain the complete source key and safely accept replay of the same delivery without double counting. Keep the source event, observed version or timestamp, load identifier, and application result separately. If a late correction arrives, retain it as a new version and recalculate the target view under a declared rule. Do not promise exactly-once delivery merely because a queue or API sends ordered batches: replay and crash recovery require receiver-side idempotency.

Completeness controls must compare more than the overall total. Compare key counts and composition, then amounts by ledger, company, year, period, and currency type. Handle physical deletion, cancellation, reversal, and backdated changes explicitly. If an interface supplies neither a change marker nor deletion semantics, an incremental load cannot be assumed complete without a separate reconciliation, scan, or other verifiable procedure.

Message ordering and checkpoint progression#

When the interface delivers multiple versions of a row, apply them by the source version marker or another documented sequence. An older version that arrives after a newer one must not silently overwrite the current state; retain it as a late-arriving event and route it for retry or quarantine under the contract. Warehouse arrival time alone does not define source change order.

Expose processing stages separately: read from source, accepted into landing, applied, rejected, replayed, and quarantined. For rejected or quarantined records, retain the delivery ID, row key, version, reason, and a reference to the original message. Advance the checkpoint only after the corresponding data and application result are durably committed; otherwise a failure between checkpoint and data writes can skip changes. A retry must safely process the same batch again.

This page describes the boundary between an SAP source and the engineering model of a finance warehouse. The separate Financial EDWH site covers warehouse models, loads, history, and reconciliation; this page focuses on choosing an SAP interface and specifying the delivery contract. Neither site claims that a production integration is configured.

Boundaries of the local example#

The SAP lab includes an independent Python line model with a ledger/company/year/document/ledger-item/source-ledger/currency-type key. It preserves immutable versions and checks replay, late correction, document balance for each currency valuation, and aggregate reconciliation on synthetic data. This is a learning model for the contract, not an emulation of ACDOCA, a SAP API, CDC, or a production DWH.

The official sources apply to specific S/4HANA Cloud and on-premise editions and interfaces. Verify the exact release, API/CDS availability, extraction limits, and authorization in your system. No SAP runtime is available here.