CDS для финансовых данных: гранулярность, доступ и производительность#

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

Определите уровень строки до выбора полей#

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

В документации SAP S/4HANA On-Premise 2023 CDS view I_JournalEntryItem представляет детали позиции бухгалтерского документа и содержит измерения вроде ledger, компании, счёта и мест назначения затрат; в числе мер указаны суммы в разных валютах. Это пример определённой модели и выпуска. Он не задаёт универсальный ключ для любого отчёта, не доказывает наличие объекта в другой редакции и не заменяет проверку актуальной версии опубликованного API.

Не считайте key в CDS гарантией уникальности источника или результата после соединения. Сверяйте естественный ключ и фактическую кратность на тестовом наборе. В финансовом примере ключ позиции может включать контекст ledger и документа, но точный состав зависит от объекта, продукта и требуемого уровня детализации.

Проверяйте связи на умножение строк#

Рассмотрим синтетический пример: одна позиция на 100 USD связана с двумя активными назначениями. После разворачивания связи результат содержит две строки по 100 USD, и сумма становится 200 USD, хотя исходная сумма документа не менялась. Причина не в арифметике, а в несовпадении гранулярности.

Перед включением пути или association проверьте:

Сколько целевых записей может соответствовать одной исходной записи в нужный момент времени?
Какие условия делают связь уникальной: ключ, действующий интервал, язык, статус или тип назначения?
Нужно ли показать связь на уровне детализации строки, агрегировать её отдельно или вернуть только признак существования?
Изменились ли число строк и контрольные суммы до и после добавления поля связи?

Кардинальность CDS описывает отношение строк и может использоваться оптимизатором. Она не заставляет данные соответствовать заявленному отношению. Ошибочно указанная кратность способна привести к неожиданным результатам оптимизации. Поэтому задавайте её по подтверждённым данным и тестируйте путь с фактическими ключами и условиями.

Если атрибут один-ко-многим нельзя без потерь свести к одному значению, не присоединяйте его к денежному факту до агрегации. Постройте отдельную проекцию на нужный уровень детализации или примените правило выбора, для которого есть бизнес-основание. Не выбирайте произвольную MAX, MIN или первую строку только ради устранения дублей.

Не складывайте несовместимые суммы#

Сумма должна иметь явную семантическую ссылку на валюту; количество - на единицу. Аналитическая мера должна иметь обоснованное правило агрегирования. SAP документирует @Aggregation.Default для мер и различает их от измерений. Агрегаты уважают одинаковую семантику: суммы в разных валютах возвращаются раздельно, а не превращаются автоматически в однородный итог.

Для финансового показателя определите перед агрегацией:

валютный тип: транзакционная, валюта компании, группы или другая явно названная;
дату и тип курса, если выполняется конвертация;
ledger, компанию, финансовый период и источник суммы;
включение дебетовых/кредитовых признаков, сторно и статистических записей;
допустимое правило округления и ожидаемое число строк.

Не суммируйте transaction currency без группировки по валюте либо без отдельно обоснованного преобразования. Не складывайте разные ledger или типы валют только потому, что поле названо Amount. Аннотация помогает потребителю интерпретировать столбец, но не исправляет неверную дату курса или потерянный измерительный контекст.

Сохраняйте происхождение финансовых данных#

Для показателя сохраняйте путь от исходной позиции к отчётному результату: исходный документ и позицию, ledger, компанию, период, версию модели и правила фильтра. Header-поля могут повторяться на каждой позиции; объединение по заголовку допустимо только если модель сохраняет отношение «многие к одному». Для переходов и сверок отдельно учитывайте ссылочный документ, исходную систему и признаки реверса, если они доступны в выбранном контракте.

Полезный тестовый набор содержит: одну позицию без связи, связь один-к-одному, связь один-ко-многим, два документа с одинаковой суммой, две валюты, реверс, граничную дату и пустое необязательное измерение. Сравнивайте не только общий итог, но и состав по естественным ключам и измерениям. Взаимно компенсирующиеся пропуски и дубли могут оставить общий итог неизменным.

Защищайте каждый публикуемый слой#

CDS access control на ABAP SQL задаётся DCL-ролями и условиями чтения. Не предполагайте автоматическое наследование DCL от нижней сущности к потребляющей CDS-модели: защищайте каждый слой, который требуется ограничить, и отдельно проверяйте путь конкретного приложения. WITH PRIVILEGED ACCESS может обойти CDS access control, поэтому его применение требует явного обоснования и аудита.

Проверяйте выборку от имени пользователей с разными разрешёнными company code, ledger или сегментами. Сверяйте отсутствие данных, доступные строки, значения фильтров и поведение потребителя. DCL не заменяет проверку права запустить приложение и не доказывает, что все внешние потребители используют защищённый путь. В Public Edition учитывайте отдельную модель business roles и restriction types; ABAP Cross-Product DCL документация сама по себе не подтверждает конкретную конфигурацию tenant.

Измеряйте запрос в целевой среде#

Сначала проверьте правильность строк и суммы на небольшом наборе. Затем измеряйте обычный сценарий пользователя с реалистичными фильтрами и объёмом. Для указанного релиза документация SAP описывает SQL Trace в ADT/ABAP Workbench: включить запись перед действием, выполнить сценарий, выключить запись и анализировать зафиксированные SQL-операции. Трасса подтверждает только наблюдённый запуск с его пользователем, параметрами, данными и моментом времени.

Проверяйте фактически сформированные условия, количество обращений, повторные запросы, отбор по ключам, join-цепочки и объём результата. Не переносите цифры из синтетического Python-примера на SAP HANA и не оптимизируйте, удаляя обязательные условия доступа. После изменения кардинальности, DCL, projection или фильтров повторите функциональную сверку и замер.

Статус источников и проверки#

Сведения о Journal Entry Item ограничены SAP S/4HANA On-Premise 2023; SQL Trace - документированному контексту ABAP Platform 2025 FPS01. Остальные описания задают общие понятия CDS и не подтверждают доступность функции в конкретной системе. Источники зарегистрированы как metadata_only; исходные снимки не сохранены. Синтетический пример не является SAP-реализацией. В этом проекте не подключались к SAP, не запускали DCL, CDS, SQL Trace или финансовый тест.

CDS for financial data: grain, access, and performance#

A CDS model for financial analytics must preserve the meaning of each row from the source object to the final selection. The main risks are often not CDS syntax but the wrong level of detail, multiplied rows, sums across incompatible currencies, and implicit access boundaries.

Define the row grain before selecting fields#

Record what one row represents to the consumer: a document, a document item, a balance by account and period, an open item as of a key date, or an aggregate across dimensions. For each model, specify the key, filters, currency, key date, and rules for reversals, carryforward balances, and incomplete records.

In SAP S/4HANA On-Premise 2023 documentation, CDS view I_JournalEntryItem represents journal-entry-item details and includes dimensions such as ledger, company code, G/L account, and cost assignments; it lists measures in different currencies. This is an example of a particular model and release. It does not define a universal key for every report, prove that the object is available in another edition, or replace checking the current version of a released API.

Do not treat a CDS key declaration as proof that the source or post-join result is unique. Check the natural key and actual cardinality against a test dataset. A financial item key may include ledger and document context, but the exact key depends on the object, product, and required grain.

Check relationships for row multiplication#

Consider a synthetic example: one item for USD 100 is linked to two active assignments. After expanding the relationship, the result contains two rows of USD 100 and totals USD 200 even though the source document amount did not change. The issue is not arithmetic; the rows have different grains.

Before including an association or path, check:

How many target records can match one source record at the relevant point in time?
Which conditions make the relationship unique: key, validity interval, language, status, or assignment type?
Should the relation be shown at item grain, aggregated separately, or returned only as an existence flag?
Did the row count and control totals change after adding the relationship field?

CDS cardinality describes the relationship between rows and can inform the optimizer. It does not force the data to match the declared relationship. An incorrect cardinality can lead to unexpected optimization results. Define cardinality from verified data and test the path with actual keys and conditions.

If a one-to-many attribute cannot be reduced to one value without information loss, do not join it to the monetary fact before aggregation. Build a separate projection at the required grain or apply a selection rule with a business basis. Do not choose an arbitrary MAX, MIN, or first row merely to remove duplicates.

Do not add incompatible amounts#

An amount should have an explicit semantic link to its currency; a quantity to its unit. An analytical measure should have a justified aggregation rule. SAP documents @Aggregation.Default for measures and distinguishes measures from dimensions. Aggregation preserves semantic differences: amounts in different currencies are returned separately rather than automatically becoming a comparable total.

Before aggregating a financial measure, define:

currency type: transaction, company-code, group, or another explicitly named currency;
rate date and rate type if conversion is used;
ledger, company, fiscal period, and amount source;
treatment of debit/credit signs, reversals, and statistical records;
allowed rounding rule and expected row count.

Do not sum transaction-currency amounts without grouping by currency or applying a separately justified conversion. Do not combine different ledgers or currency types because a field happens to be called Amount. An annotation helps a consumer interpret a column, but it cannot fix the wrong rate date or a lost dimensional context.

Preserve financial data lineage#

For a measure, retain the path from the source item to the reported result: source document and item, ledger, company, period, model version, and filter rules. Header fields may repeat on each item; joining by header is valid only if the model preserves a many-to-one relationship. For transitions and reconciliation, also account for a reference document, source system, and reversal indicators when they are part of the selected contract.

A useful test dataset includes: an item without a relationship, a one-to-one relationship, a one-to-many relationship, two documents with the same amount, two currencies, a reversal, a boundary date, and an empty optional dimension. Compare the composition by natural keys and dimensions as well as the total. Offsetting omissions and duplicates can leave the grand total unchanged.

Protect every published layer#

CDS access control for ABAP SQL is defined through DCL roles and read conditions. Do not assume that DCL is automatically inherited from a lower-level entity to a consuming CDS model: protect each layer that needs restrictions and check the path used by the application. WITH PRIVILEGED ACCESS can bypass CDS access control, so its use needs explicit justification and audit.

Test selections as users with different authorized company codes, ledgers, or segments. Check missing data, permitted rows, filter values, and consumer behavior. DCL does not replace checking whether a user may start the application and does not prove that every external consumer uses a protected path. For Public Edition, account for its separate business-role and restriction-type model; ABAP Cross-Product DCL documentation alone does not confirm a tenant's configuration.

Measure queries in the target environment#

First check row and amount correctness on a small dataset. Then measure a normal user scenario with realistic filters and volumes. For the specified release, SAP documentation describes SQL Trace in ADT/ABAP Workbench: turn recording on before the action, run the scenario, turn recording off, and analyze the captured SQL operations. A trace supports conclusions only about the observed run, user, parameters, data, and time.

Check the generated conditions, number of calls, repeated requests, key selection, join chains, and result volume. Do not transfer figures from a synthetic Python example to SAP HANA, and do not optimize by removing required access conditions. After changing cardinality, DCL, projection, or filters, repeat both the functional reconciliation and measurement.

Source and verification status#

Journal Entry Item details are limited to SAP S/4HANA On-Premise 2023; SQL Trace details are limited to the ABAP Platform 2025 FPS01 documentation context. The other descriptions explain general CDS concepts and do not confirm availability in a particular system. The source records are metadata_only; source snapshots are not retained. The synthetic example is not an SAP implementation. This project did not connect to SAP or run CDS, DCL, SQL Trace, or a financial test.