Business Partner Errors in Production

[Link]/business-partner-production-errors/

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.

1/9
 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.

2/9
 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.

3/9
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.

4/9
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.

1. Activate the PPO in your system and check the entries in the PPO.
2. 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

5/9
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 Errors (root cause) are determined
standard T-Code MDS_PPO2. by debugging because dump
analysis may not be informative.

Inconsistent data is possible. For example, may Data is always “consistent” because
be correct for the BP, but not synchronized to a a create or change with errors
corresponding Vendor or Customer. This is results in a short dump. Data isn’t
mitigated by process. created or changed.

PPO entries must be viewed regularly and acted Short dumps must be resolved
on to resolve inconsistent data. before BP data can be processed.

PPO entries should be included in archiving

plans. Deletion as master data isn’t possible.

6/9
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 Reading

SAP Community blog: Business Partner Usage of Postprocessing Office (PPO)

Andi Mauersberger – February 25, 2020

7/9
 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

This blog is linked to from SAP Note 2355464 – Changes on BP are not saved

[Link]: 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.

[Link]: 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

8/9
 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 because 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).

9/9