Business Partner Errors in Production

paul_gendreau · ‎11-30-2021

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.

End users might see a dump like this in production if PPO isn’t active. How nice is that?

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.

CVI synchronizes data: direction BP to Customer and Vendor.

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.

CVI also synchronizes data: direction Customer and Vendor to BP. It’s a two-way street!

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 framework.

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

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.

Related Tables

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).