Cash Management: API денежных потоков и безопасные границы интеграции#

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

Подтвержденный интерфейс CASHFLOW_IN#

В каталоге SAP S/4HANA On-Premise Cash and Liquidity Management API документирован сервис CASHFLOW_IN типа SOAP. SAP описывает создание, обновление, удаление и стирание существующих cash flow данных через API; в запросе передается payload, после успешного создания возвращаются ключ потока и данные. Для использования сервиса документация требует настроить сопоставление company code и мониторинг на основе AIF message monitor. Проверки значений и авторизаций выполняются в ходе обработки запроса.

Схема запроса включает обязательные company code, сумму в валюте операции, валюту, дату операции и OriginSystem; документ OriginDocument и транзакция OriginTransaction описаны как необязательные. Также API перечисляет варианты банковских реквизитов или G/L account. Фактическая обязательность и доступность полей должны проверяться в WSDL/API-документации и конфигурации именно целевого релиза.

Это интерфейс записи cash flow, а не универсальный API чтения всей истории One Exposure, не общий API банковской выписки и не подтверждение доступности в каждом S/4HANA deployment. Перед проектированием проверьте каталог API и communication setup для своего продукта, релиза, scope и сценария.

Минимальный контракт интеграции#

До разработки зафиксируйте:

1. Границу владения: какая внешняя система создает поток и какая сторона отвечает за изменение или удаление.
2. Идентичность: устойчивые OriginSystem, документ и транзакцию; правила повторной отправки и разрешения дубликатов.
3. Смысл суммы и даты: направление, знак, валюту, дату и бизнес-событие, к которому относится поток.
4. Организационное сопоставление: company code и проверку соответствия для каждого источника.
5. Классификацию: допустимые поля и правила определения flow type, liquidity item и других атрибутов по документации и настройкам системы.
6. Ошибки и повтор: корреляционный идентификатор, результаты AIF мониторинга, стратегию retry, обработку частичного/повторного запроса и сверку результата.
7. Авторизацию и аудит: технического пользователя, минимальные полномочия, журналирование вызова и контроль операций удаления/стирания.

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

Почему не следует писать напрямую в таблицы#

Прямое изменение таблиц обходит проверки допустимых значений, авторизации, прикладную обработку и мониторинг API. Оно может нарушить внутреннюю связь ключей, происхождение записи и последующие обновления. Чтение таблиц для поддерживаемого аналитического сценария тоже требует проверки release contract и назначения объекта; конкретная таблица не становится автоматически стабильным внешним интерфейсом.

Для чтения или выгрузки данных отдельно определите опубликованный read/API/CDS/extraction контракт, его ключ, фильтры, delta/deletion semantics и поддержку версии. Не выводите эти свойства из write API CASHFLOW_IN и не используйте его для предположений о CDC или доступе к FQM_FLOW.

Границы источников#

Материал частично покрывает CASH-23. Ссылки ведут на SAP Help для Cash and Liquidity Management в SAP S/4HANA 2025 FPS01/FPS02; записи реестра имеют статус metadata_only, полные тексты и WSDL здесь не архивировались. Вызов API, конфигурация AIF, доступность сервиса, роли и SAP runtime не проверялись. Примеры процесса являются проектной рекомендацией, а не наблюдением о конкретной системе.

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

• Происхождение и преобразование денежных потоков
• ECC, Liquidity Planner и S/4HANA
• Денежные потоки Cash Management в EDWH

Cash Management: Cash-Flow API and Safe Integration Boundaries#

Cash-flow integration should use an interface published and supported for the target release. The existence of a database table in SAP does not make direct writes to it a stable application contract.

Documented interface: CASHFLOW_IN#

The SAP S/4HANA On-Premise Cash and Liquidity Management API catalog documents CASHFLOW_IN as a SOAP service. SAP describes creating, updating, deleting, and erasing existing cash-flow data through the API. The request carries a payload; after successful creation, the response returns the flow key and data. The documentation requires company-code value mapping and monitoring based on the AIF message monitor. Value and authorization checks are performed during processing.

The request structure lists company code, transaction-currency amount and currency, transaction date, and OriginSystem as mandatory. OriginDocument and OriginTransaction are listed as optional, as are several bank and G/L account fields. Verify actual field requirements and availability in the WSDL/API documentation and configuration for the target release.

This is a cash-flow write interface, not a universal read API for all One Exposure history, not a general bank-statement API, and not proof of availability in every S/4HANA deployment. Check the API catalog and communication setup for the actual product, release, scope, and scenario before designing against it.

Minimum integration contract#

Before development, record: (1) ownership - who creates, changes, or deletes a flow; (2) identity - stable OriginSystem, document, and transaction values plus retry and duplicate rules; (3) amount and date semantics - direction, sign, currency, date, and business event; (4) company-code mapping; (5) classification rules for flow type, liquidity item, and other attributes; (6) error correlation, AIF results, retries, partial or repeated requests, and reconciliation; and (7) technical user, least privilege, logging, and controls over delete/erase operations.

Use synthetic test identifiers before connecting production flows. Separately test creation, repeated requests, update, mapping failure, authorization failure, correction, and documented deletion behavior. Do not assume idempotency without a documented key and verified behavior.

Why not write directly to tables#

Direct table updates bypass application value checks, authorization, application processing, and API monitoring. They can break internal key relationships, provenance, and downstream update behavior. Reading a table for an approved analytical scenario also requires checking the release contract and object's purpose; a concrete table name does not automatically make it a stable external interface.

For reads or extracts, identify a separately published read/API/CDS/extraction contract, its key, filters, delta/deletion semantics, and version support. Do not infer those properties from write API CASHFLOW_IN, or assume it provides CDC or access to FQM_FLOW.

Source boundaries#

This material partially covers CASH-23. The links point to SAP Help for Cash and Liquidity Management in S/4HANA 2025 FPS01/FPS02; registry entries are metadata_only, and full source text and WSDL were not archived. No API call, AIF setup, service availability, role, or SAP runtime was checked. Process examples are design recommendations, not observations from a particular system.

Related material#

• Cash-flow lineage and transformation
• ECC, Liquidity Planner, and S/4HANA
• Cash Management flows in EDWH