If you work with service transactions such as service quotations, service orders, service contracts, and similar in SAP S/4HANA Service, the save sequence of the OneOrder framework is something you rely on every day, often without thinking about it. In the SAP S/4HANA 2025 FPS0 release, this sequence has been fundamentally redesigned to align with the RAP (RESTful ABAP Programming Model) transactional contract. 

This blog explains what changed, why it was necessary, and what the new phases mean in practice — especially the distinction between the introduced early save phase and the late save phase. If you maintain custom event handlers or BAdI implementations that rely on exchanging transaction IDs in the OneOrder save flow, this is directly relevant to you. 

  

The OneOrder framework is the shared domain model underneath all service transactions in SAP S/4HANA Service. When a service transaction is saved, a central function module CRM_ORDER_SAVE orchestrates a sequence of steps: preparing data, validating the transaction, assigning ID from the number range, and finally persisting everything to the database. 

Historically, this sequence of steps was implemented as a small set of function modules with registered event callbacks and BAdIs: 

• CRM_ORDER_SAVE_VALIDATE_OW: changes, validation, number assignment 

• CRM_ORDER_SAVE_SAVE_OW: the actual persistence step including data exchange 

The framework events such as BEFORE_SAVE and SAVE allow partners and application teams to hook into this sequence. The problem was that over time, the BEFORE_SAVE phase had accumulated both data-modifying logic and pure validation logic in the same callbacks, with no clean separation between them. 

RAP to One Order before 2025OP FPS0

With the introduction of RAP, this mixed approach became incompatible from an architecture point of view. 

 

RAP enforces a strict separation of phases using Behavior Definitions (BDEFs). When a COMMIT WORK or COMMIT ENTITIES is issued, the RAP runtime processes the following save sequence: 

*The creation of follow-up transactions in the late save phase via CL_CRMS4_DATAEXCH_MGR=>PROCESS_FORWARD still uses older (B)APIs which rely on the source transaction ID. The ideal case would be to use CL_CRMS4_DATAEXCH_MGR=>PROCESS_FINALIZE and call the RAP Facade of the follow-up BO with a RAP-managed key exchange invoked by the CONVERT KEY statement. 

The distinction between early and late save is fundamental: The point of no return lies between CHECK BEFORE SAVE and ADJUST NUMBERS.  

Before that point, a save can still be interrupted — by returning errors from FINALIZE coming from BAdIs/Events/Actions after an erroneous data change, or by raising an exception in CHECK BEFORE SAVE due to a save check hitting the brake. After that point, the transaction will be committed. This is why the rules for each phase are so strict. 

 

FINALIZE 

FINALIZE runs in the early save before any irreversible action takes place. It’s the last opportunity to: 

• Make changes to the source transaction 

• Create follow-up business objects (BO) by their RAP Facade 

But it is also capable of interrupting the save: If FINALIZE raises errors, the commit is cancelled and the transaction remains open for correction. 

CHECK BEFORE SAVE 

CHECK BEFORE SAVE is the final gate in the early save before the point of no return. It runs after FINALIZE, meaning that all data is already in its final pre-save state. Here: 

• All validation logic belongs here including checks for completeness, consistency, and business rules 

• No data modification is permitted at this stage — neither via MODIFY ENTITIES, nor CRM_ORDER_MAINTAIN, nor direct SQL UPDATE. The RAP runtime enforces this strictly, and any violation results in a short dump. 

• Errors returned at this stage will cancel the save, just like in FINALIZE. 

The key distinction: FINALIZE can still change things. CHECK BEFORE SAVE can only look at things. Both can stop the save. 

 

ADJUST NUMBERS 

Once CHECK BEFORE SAVE completes without errors, the point of no return is passed and the late save phases are reached. The transaction will be committed. 

The first late save phase ADJUST NUMBERS assigns the final transaction ID (from number ranges) for new transactions. Up to this point, objects use GUIDs. 

SAVE 

The last phase in the late save phase — SAVE — persists data to the database tables. This is also where legacy integrations, such as creating follow-up transactions via classic APIs, are triggered by the Data Exchange Manager (CL_CRMS4_DATAEXCH_MGR). 

 

Testing RAP Early Save Phases with COMMIT ENTITIES IN SIMULATION MODE 

RAP offers a special variant for “dry-run” saves: COMMIT ENTITIES IN SIMULATION MODE. 

This mode executes only FINALIZE and CHECK BEFORE SAVE, then stops. No numbers are assigned, and no data persisted. It allows callers to verify whether a transaction would pass validation without actually committing it—making it particularly useful for validation services and UI checks. 

 

Before the SAP S/4HANA 2025 FPS0 release, the OneOrder save sequence had no concept of FINALIZE or a separate ADJUST NUMBERS phase. The entire pre-save logic — both data modifications and validations — lived inside CRM_ORDER_SAVE_VALIDATE_OW, which was mapped to the RAP CHECK BEFORE SAVE behavior definition. 

 This caused several concrete problems: 

1. Data modifications in CHECK BEFORE SAVE caused dumps. 

CRM_ORDER_SAVE_VALIDATE_OW contained calls that modified data, including BAdI callbacks, event handlers, and internal updates. The RAP runtime detects such patterns and raises a short dump; consequently, any service transaction save triggering this logic in a RAP context would fail. 

1. There was no FINALIZE equivalent in OneOrder. 

Logic that should have been executed in the FINALIZE phase — such as preparatory steps and last-minute derivations — had no dedicated place in the process. As a result, it was either omitted entirely or incorrectly implemented in CHECK BEFORE SAVE. 

1. Number assignment was mixed into CHECK BEFORE SAVE. 

The number range assignment for service transactions was performed inside CRM_ORDER_SAVE_VALIDATE_OW. In RAP terms, this step belongs in the ADJUST NUMBERS phase rather than CHECK BEFORE SAVE. 

 4. Duplicate execution occurred in the SAVE BDEF. 

The SAVE BDEF called the full CRM_ORDER_SAVE Function Module, which internally called CRM_ORDER_SAVE_VALIDATE_OW again. As a result, validation logic ran twice, and in some cases, even the entire sequence ran multiple times. 

With SAP S/4HANA 2025 FPS0, the OneOrder save sequence has been redesigned to include four dedicated classes, each corresponding to exactly one RAP BDEF phase. 

RAP and One Order after 2025OP FPS0

Backward compatibility is preserved. The new classes are also invoked from non-RAP save paths, such as WebClient UI Framework, so existing integrations continue to work unchanged if they respect the phase contracts. 

One Order Save Sequence

What Changed for Event Handlers: New FINALIZE Event 

A new OneOrder FINALIZE event and a separate execution time 074 have been introduced. They are registered in transaction CRMV_EVENT. 

The existing BEFORE_SAVE event maps to CHECK BEFORE SAVE. Out of 78 standard callbacks registered for the BEFORE_SAVE event, nearly 2/3 were moved or split as part of this change because they contained data-modifying logic that does not belong in CHECK BEFORE SAVE. 

The rule for deciding where a callback belongs is as follows: 

• Does it modify data? → FINALIZE  

• Does it only check the condition and optionally raise an exception? → BEFORE_SAVE (CHECK BEFORE SAVE) 

  

Review Your Custom Callbacks 

If you have implemented custom event handlers in the OneOrder save sequence, it is important to review them now. We recommend proceeding as follows: 

Step 1. Identify your callbacks. Search for implementations of the BEFORE_SAVE event registered via transaction CRMV_EVENT or CRMV_EVENT_CUST View in IMG for the object types relevant to your scenario. 

Step 2. Classify each callback. For each function module, specify whether it changes data, verifies data, or does both tasks. 

Step 3. Register the callbacks under the appropriate event and execution time. If logic is moved to FINALIZE, re-register it under the FINALIZE event in CRMV_EVENT. Use execution time 074 for callbacks intended for the finalize phase. 

Step 4. Test using SIMULATION MODE. Use COMMIT ENTITIES IN SIMULATION MODE in a test report to exercise only FINALIZE + CHECK BEFORE SAVE without persisting data. This makes it straightforward to verify that your callbacks behave correctly in the early save phases. 

Review Your integrations that rely on transaction IDs 

If you have implemented custom integrations that rely on transaction IDs before they are assigned, you need to adapt. This affects new transactions that are saved for the first time and haven’t run through ADJUST_NUMBERS once but rely on the transaction ID in your custom BAdI-/PPF-/Event-supported integration. 

There is no simple solution to this. 

The cleanest approach aligned with the target architecture is to call a follow-up by their RAP-Facade and do the CONVERT KEY exchange in the late save. 

A more practical approach is to implement a pre-check in FINALIZE/CHECK BEFORE SAVE of the One Order early save and move the remaining logic into the late save, e.g.: into the Dataexchange-Manager. 

The new FINALIZE propagation has been implemented for all RAP BOs in SAP S/4HANA Service like:

• Service Order 
• Service Contract 
• Service Confirmation 
• Service Request 
• Service Order Template 
• Subscription Order 
• Subscription Contract 
• Solution Quotation 
• In-House Service 
• Master Agreement 
• Opportunity 
• Activities 

With the release of SAP S/4HANA 2025 FPS0, SAP introduces early save phases that provide a clear alignment between the OneOrder save sequence and the RAP transactional contract. 

Changes in a Nutshell 

• Four dedicated save-phase classes have been introduced. 

• Legacy FMs have been replaced; each now maps directly to a single RAP BDEF. 

• A new FINALIZE phase has been added to OneOrder. 

• An updated event and execution time are now available in CRMV_EVENT, where data preparation and last-minute adjustments are handled. 

• The CHECK BEFORE SAVE phase is now strictly read-only; any attempts to modify data will result in a short dump within the RAP context. 

• Number-range assignment has been separated into its own ADJUST NUMBERS class, extracted from CHECK BEFORE SAVE. 

• All BEFORE_SAVE event callbacks have been reviewed, with standard callbacks either relocated or split as appropriate. 

• The point of no return is now clearly defined between CHECK BEFORE SAVE and ADJUST NUMBERS. 

Core Takeaway 

FINALIZE handles any last-minute modifications and can still interrupt a save. In contrast, CHECK BEFORE SAVE acts as the ultimate validation step, examining the fully prepared data to make the definitive decision about whether the transaction should proceed or stop before it's irreversible.