SAP S/4HANA Business Partners, extended to a Customer or Supplier role, bring the possibility of a special class of errors. Are you prepared for these in your Production environment?
Let’s frame the key decision: What is Postprocessing Office and should it be active for Business Partner in Production?
A bevy of related SAP Notes seemingly offer contradictory advice — or no advice — about whether Postprocessing Office (PPO) should be active for Business Partner (BP) synchronization in an S/4HANA production environment. SAP Note 1573189, specifically recommends that PPO “should be deactivated in production system …”
Maybe, and maybe not. I agree with experts who say that this “recommendation” should be understood as one option, with tradeoffs to be carefully weighed. Further, we agree that — with eyes wide open — activating PPO in Production may be your best alternative.
Business Partner and Customer/Vendor Integration
As context for the problem at hand, Peeking Behind the Curtain of S/4HANA Business Partner explains that Customer and Vendor Masters fully and necessarily exist in SAP S/4HANA, as they did in ECC 6.0. They’re just hidden behind Business Partner. Behind the scenes, so-called Customer / Vendor Integration (CVI) in S/4HANA bidirectionally integrates BP with plain-old Customer and Vendor Masters in real time.
The complexity of synchronization is astonishing, but it’s extremely well hidden from end users. Ideally, it requires no attention whatsoever.
Synchronization in the direction of BP to Customer and Vendor comes into play when maintaining Business Partners by user interface, mass update programs, or via standard Business Partner API. In all of these cases, experience teaches that users are generally well informed in case of errors. But not always, as explained by SAP Note 2355464 – Changes on BP are not saved.
In the reverse direction, which is less common, the complexity of CVI is beyond astonishing.
For example, consider the case of an inbound Vendor Master (CREMAS IDoc) with an assigned Contact Person. In one fell swoop the system creates a new Business Partner to represent the Contact Person, creates a new Supplier Business Partner to represent the Vendor, and finally creates a relationship between the Contact Person Business Partner and the Supplier Business Partner. All this triggered by processing a CREMAS IDoc!
How many things could possibly go wrong in this scenario? More than any mere human could predict, as evidenced by the number of SAP Notes related to this scenario 🙂 To be fair, it’s an engineering marvel — and good news — that this actually works in standard nowadays, within expected constraints. Nirvana is near.
Because synchronization in the direction of Customer and Vendor to BP is generally a consequence of an inbound interface, the complexity is completely hidden from users, except when failures occur.
PPO What and Why
Regardless of synchronization direction, the number of moving parts provides ample opportunity for trouble. In the direction of Customer and Vendor to BP, consider the differences between data models, determination of same legal entity (a customer and vendor assigned to one Business Partner), and finally throw in ancillary complexities such as tax jurisdiction code determination. These are ingredients for a stew of errors.
Postprocessing Office is a framework that can be used across systems and many components. It collects messages from connected business processes, and all messages from a business process for the same object are combined under a main message in a so-called postprocessing order. Worklist distribution is used to assign the postprocessing orders to processors.
If this sounds like a robust business process all on its own, that’s because it is. PPO isn’t only about Business Partner, but it can enable a business process for identifying and resolving synchronization errors between Business Partners and plain-old Customers and Vendors.
During an implementation project, it’s typical to activate PPO. Not because we’re interested in any business process for error resolution, but because it’s the only practical way to collect informative error messages. It helps us, in particular, to quickly identify and resolve customizing and data errors that occur during CVI synchronization.
Don’t the same practical requirements exist in a productive system?
Impractical Options in Production
Remember that the scenario at hand isn’t Business Partner in ECC 6.0, as in SAP Note 956054, or working out the kinks of converting Customers and Vendors to Business Partners, as in a system conversion. An S/4HANA production environment is typically well beyond those concerns.
SAP Note 1573189 presents two possibilities for understanding synchronization errors when PPO is not active.
- Activate the PPO in your system and check the entries in the PPO.
- Do not activate the PPO but reproduce this issue with a user with debugging authorization instead.
To begin with, the stated premise — for both possibilities — is that the synchronization errors result from wrong customizing. In my experience, at least as of S/4HANA 1909, the premise is wrong, or at least incomplete. Synchronization errors can result for a variety of reasons not related to customizing. For example, authorization errors can result in synchronization errors. Importantly, synchronization errors can be data driven. In this case, the customizing is correct, but the data being synchronized violates business rules. An obvious example would be a mandatory field that isn’t filled.
If synchronization errors are data driven then these aren’t customizing errors that should have been caught and corrected during implementation of Business Partner. Instead, there’s an ongoing possibility of such errors in a production environment. The premise is wrong, which leads to impractical solution proposals.
Here’s the sticking point: If PPO isn’t active then the result is a runtime error — a short dump — and a potentially uninformative error message is recorded in ABAP Dump Analysis (T-Code ST22). What to do about it? Let’s consider the options described by SAP Note 1573189 when PPO isn’t active.
Option 1: Activating PPO. This is customizing. Switching PPO on and off again isn’t a serious proposal for supporting a production environment. If dumps would occur only due to wrong customizing, then this might be a reasonable (and one-time) course of action. In that case, the customizing is corrected and the errors stop. But this isn’t necessarily the case.
Option 2: Debugging to determine root cause. This is serious. In fact, far too serious. Data-driven errors aren’t easily reproduced in test environments. That means debugging in production. In any case, this option — requiring specialized functional and technical resources to be effective — is also super unattractive in the context of supporting a productive system. What’s more, the option is only required if and because informative error messages are not recorded.
Weighing the Options
The full functionality of PPO is almost certainly overkill for supporting Business Partner synchronization in a productive environment. But that’s not necessarily the scope of what’s suggested here.
As during implementation of Business Partner, what’s minimally needed in a productive environment is an informative error message to enable quick identification and resolution of CVI synchronization errors. Especially in the case of data-dependent errors, informative error messages can be handled by production support processes and direction supplied to users. It needn’t require the efforts of specialized resources.
Despite the contents of SAP Note 1239993 – Informative DUMP in case of inactive PPO, experience teaches that uninformative dumps are sometimes created. This especially seems to be the case in the synchronization direction of Customer and Vendor to BP. Without informative dumps, no practical alternative to activating PPO seems possible.
Here’s an at-a-glance list of pros and cons to help you decide which is best for your particular circumstances.
|Activate PPO||Do Not Activate PPO|
|CVI errors are recorded in PPO.||CVI errors result in a runtime error (a short dump).|
|Errors are informative and may be viewed via standard T-Code MDS_PPO2.||Errors (root cause) are determined by debugging because dump analysis may not be informative.|
|Inconsistent data is possible. For example, may be correct for the BP, but not synchronized to a corresponding Vendor or Customer. This is mitigated by process.||Data is always “consistent” because a create or change with errors results in a short dump. Data isn’t created or changed.|
|PPO entries must be viewed regularly and acted on to resolve inconsistent data.||Short dumps must be resolved before BP data can be processed.|
|PPO entries should be included in archiving plans. Deletion as master data isn’t possible.|
Activating PPO for BP
The first step is to activate PPO for the synchronization object BP.
In SAP Customizing, choose Cross-Application Components > Master Data Synchronization > Synchronization Control > Synchronization Control > Activate PPO Requests for Platform Objects in the Dialog
The next step is to activate the business processes that are relevant for your business requirements.
In SAP Customizing, choose Cross-Application Components > General Application Functions > Postprocessing Office > Business Processes > Activate Creation of Postprocessing Orders
For software Component AP-MD, add the relevant Business Processes.
For direction Customer and Vendor to BP add these business processes:
- CVI_01 Customer -> Business Partner
- CVI_02 Vendor -> Business Partner
For direction BP to Customer and Vendor add these business processes:
- CVI_03 Business Partner -> Customer
- CVI_04 Business Partner -> Vendor
- If you’re not following Andi Mauersberger then you’re missing out on some best-in-class content.
SAP Community blog: How to use T-Code MDS_PPO2
Julin Xin – November 18, 2016
help.sap.com: Postprocessing Office
- This component is used to support the rational processing of events that originate in any business process. All the data relevant for processing events is combined in a postprocessing order. You can, therefore, process error messages from mass runs of different object types, for example. Processing can be done across systems and components.
- Postprocessing Office replaces the application logs of the mass runs as the initial function for error processing. You only need to call up the error logs to display an overview of the objects that were processed successfully in the mass runs.
help.sap.com: Making Settings for the Postprocessing Office
- During error processing, the Postprocessing Office (PPO) replaces the application log. Using the PPO is optional; therefore, you have to activate the PPO explicitly.
- If you do not activate the PPO, then errors during synchronization can lead to short dumps.
Related SAP Notes
SAP Note 956054 – BP_CVI: Customer/vendor integration as of ERP 6.00
- If the PPO is activated in a productive environment, you must ensure that the PPO entries are viewed and edited regularly.
SAP Note 1239993 – Informative DUMP in case of inactive PPO
- When in case of Master data synchronization the post processing office (PPO) is not active (e.g. on the production system in order to avoid data inconsistencies), errors occurring during synchronization raise a short dump. This short dump does not contain any information about the reason(s) for the abortion.
- Currently an X-message is processed, when PPO is inactive and errors occur. Only a standard message with information about inactive ppo and how to activate it is transferred to the dump. With this note the logic is changed. Instead of an X-message (leading to a message_type_x dump) an “assert fields” key word is used to create the dump. Here up to 7 messages that have been added to the error-table are transferred to the dump in addition to the standard message.
SAP Note 1573189 – Dump MESSAGE_TYPE_X on class CL_MDS_PPO_API method ORDER_CREATE
- It should be deactivated in production system due to the fact that if an error occurs during the synchronization, you do not notice the error.
SAP Note 2290429 – The synchronization between BP and Customer/Vendor or vice versa does not happen
- The customizing is not correct.
SAP Note 2351694 – How to activate PPO and resolve ASSERTION_FAILED dump during synchronization
- The dump happens due to the PPO is not activated in your system.
- After activating the PPO, you could check the errors in transaction MDS_PPO2 instead of the dump.
SAP Note 2355464 – Changes on BP are not saved
- Check if there is any error in the PPO log. If there is error, please correct them then perform the change on BP again.
There’s a master table for all the PPOs raised: /SAPPO/ORDER_HDR – Postprocessing Order – Header Data
- /SAPPO/ORDER_HDR – Postprocessing Order – Header Data
- /SAPPO/ORDER_MSG – Messages for Postprocessing Order
- /SAPPO/ORDER_OBJ – Related Objects for Postprocessing Order
- /SAPPO/ORDER_LOG – Logging Processing Times of an Order
- /SAPPO/ORDER_DAT – Additional Data for Postprocessing Order
Clean Up PPO
T-Code /SAPPO/DELETE_ORDERS Delete postprocessing orders
This transaction is deprecated. Deletion of PPO orders is not supported (Message no. /SAPPO/MSG520).
- There is an archiving solution for PPO orders since PPO orders must be accessible after they have been processed to enable tracking.
- Note: Report /SAPPO/DELETE_ORDERS for the deletion of PPO orders is no longer in use.
- Use the archiving solution. For more information about Archiving Object /SAPPO/PPO, see Error and Conflict Handler (CA-FS-ECH).