October 26, 2026 admin

Case Study | Modernizing Purchase Requisition Approvals using SAP BTP, CAP and Integration Suite

Executive summary

This proposed case study illustrates how an enterprise can modernize a heavily customized purchase requisition (PR) approval experience while keeping SAP S/4HANA as the system of record. The target solution applies fit-to-standard, released APIs, and an SAP BTP side-by-side extension only for differentiated capabilities that standard SAP functionality cannot meet.

The scenario and outcomes are illustrative. Actual baseline metrics, API availability, approvals configuration and ROI must be validated for a specific customer landscape.

1. Business context and problem

An enterprise migrating from SAP ECC to SAP S/4HANA has a custom approval cockpit built with Z tables, bespoke ABAP screens, direct database reads and point-to-point integrations. Approval policies change frequently, and regression testing after upgrades is expensive.

Business requirement: requesters should submit and track PRs; approvers should review exceptions, approve or reject according to delegated policy, and receive timely notifications. Standard S/4HANA procurement and Flexible Workflow capabilities must be assessed first.

2. Clean Core decision principles

Clean Core does not mean “no extensions.” It means choosing the least invasive supported option, using stable released interfaces and governing changes across processes, data, integration, extensibility and operations.

Decision sequence: (1) adopt standard SAP process; (2) configure or use key-user extensibility; (3) use released on-stack developer extensibility where supported; (4) build a side-by-side extension on SAP BTP for genuine differentiation. Avoid direct changes to SAP standard objects and unreleased internal interfaces.

3. Before vs. target state

Dimension	Legacy approach	Clean Core target
Process	Custom approval logic embedded in ERP	Standard PR and Flexible Workflow first; external orchestration only for documented gaps
Extensibility	Z transactions and direct enhancements	Released extension points or CAP service on SAP BTP
Integration	Direct table access / custom RFCs	Released S/4HANA APIs and supported events
Data	Duplicate PR master and status	S/4HANA owns PR; BTP stores only extension metadata
Operations	Manual checks and tightly coupled releases	Central logs, monitoring, traceability and contract tests

4. Proposed solution architecture

Experience: SAP Fiori application exposed through SAP Build Work Zone or launchpad.

Application: CAP (Node.js) on SAP BTP manages the custom exception-review UI, extension metadata and policy-specific actions. For approval execution, prefer standard S/4HANA Flexible Workflow and its supported task interfaces; do not bypass the system’s approval authority.

Integration: SAP Integration Suite is used where mediation, mapping, governance or hybrid connectivity is needed; a simple direct released API call can be preferable when no mediation is required.

Identity and security: SAP Cloud Identity Services, least-privilege role collections, destination-based connectivity, and principal propagation where feasible.

Persistence: SAP HANA Cloud stores audit references, correlation IDs and application-specific configuration—not an uncontrolled copy of procurement transactional data.

5. Illustrative end-to-end flow

Requester creates PR using standard S/4HANA functionality or a supported released API.

S/4HANA validates and persists the PR; standard workflow determines the approval task.

CAP application reads relevant PR details through released APIs and shows additional exception context.

Authorized approver acts through a supported approval/task API or standard workflow UI; do not update approval status directly in tables.

Status changes are surfaced through supported events or controlled polling if no suitable event is available.

Monitoring correlates request, API call, workflow instance and business document ID.

6. Delivery plan

Discover: inventory custom code, integrations and approval variants; use SAP Readiness Check and available custom-code analysis tools as applicable.

Design: fit-to-standard workshops; identify released APIs and workflow extension options in the exact S/4HANA edition/release; document ADRs and data ownership.

Build: implement CAP service, Fiori experience, authorization model, automated tests and integration flows only where justified.

Validate: test approval segregation of duties, API contracts, exception handling, retries, idempotency, audit trail, performance and upgrade regression.

Deploy: pilot one purchasing organization, monitor outcomes, then expand in waves with rollback and support runbooks.

7. Success measures and risks

Measure / risk	How to validate
Upgrade regression effort	Compare test person-days before and after modernization
Custom code footprint	Count retired or remediated custom objects; track released-interface compliance
Approval cycle time	Compare median PR approval lead time over equivalent periods
Integration reliability	Measure success rate, retry volume, error recovery time
Security and controls	Prove role segregation, audit completeness and authorization checks
Risk: API gaps	Validate released APIs and workflow task capabilities before committing to CAP design
Risk: duplicated business logic	Keep approval determination in standard workflow wherever feasible

8. Expected outcomes

Potential outcomes include a smaller upgrade-sensitive customization footprint, clearer ownership of business data, improved monitoring and faster change cycles. No numerical benefit is asserted without customer baseline and post-implementation evidence.

9. Conclusion

A successful Clean Core transformation starts with process standardization, not technology selection. SAP BTP is a strategic extension platform, but not a replacement for standard S/4HANA business capabilities. The modernization roadmap should preserve the digital core and introduce side-by-side services only where they deliver measurable differentiation.