Category: MDA Magazine

SAP S/4HANA Business Partner Objects

If you want to understand S/4HANA Business Partner, then you need to stop thinking π™žπ™£ π™©π™šπ™§π™’π™¨ 𝙀𝙛 Customers and Vendors, but continually think 𝙖𝙗𝙀π™ͺ𝙩 Customers and Vendors.

If you know about Customers and Vendors in ECC 6.0 then this requires a dramatic shift in thinking!

I’ll confess, even experts need an occasional reminder of exactly how Business Partner is astonishingly complex, massively duplicative, simplification. All at once. But simplification accrues to users and the enterprise. You and I — responsible to implement Business Partner — get to wrestle with complexity and duplicative data.

I can tell you this much with certainty:  Continuing to think  π™žπ™£ π™©π™šπ™§π™’π™¨ 𝙀𝙛 Customers and Vendors is a path to misery.

Business Partner Errors in Production

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.

Is Listing Mandatory in SAP Retail?

Listing in SAP Retail and Fashion is a pain point. After coming to grips with the art and effort of assortment management, you’ll find that execution of Listing is performance intensive. Maybe problematically performance intensive. Sooner or later, it begs the question: Is all of this really necessary?

Of course, the simplistic answer is: Yes, you have to. But this answer isn’t only unsatisfying. In some cases, it’s simply wrong.

If you’ve been given an explanation of Listing that more-or-less begins and ends with “it’s mandatory,” then press on. I’d begin with: What business purpose does this serve in SAP ERP?  Here’s a tip: Reject any generic or technical answer. You need to ask, very specifically: What business purpose does this serve for me, right now, in the context of my particular business processes? Why? Why? Why?

SAP Data Migration Transparency

Data Migration doesn’t fit well into project tracking schemes. Unsurprisingly, the frustration of stakeholders eventually becomes palpable on every project.

The universal question I hear is:  “When will the data migration deliverables be “done?”

If you ask me — the functional master data guy — when data migration will be “done” then the honest answer is clear: “The day before go-live.”Β  When will the data migration functional specification be done?Β  Same answer.Β  Go ahead and ask the technical team when the data load program will be finished.Β  “That depends on the functional specification.Β  Oh, and you’re not going to change anything over time, are you?”Β  For some reason, replies like these reliably produce eye rolls.

The Essence of SAP Retail Master Data

The essence of SAP Retail Master Data is manifested at the intersection of Products and Locations. We also call them Articles and Sites, or Materials and Plants. Take your pick; the SAP lexicon is forever morphing for your enjoyment πŸ™‚

Whatever you call them, the number of Products times the number of Locations is a big number in SAP Retail. It quantifies the Retail Master Data challenge, and billions is the typical unit of measure.

You’ve got to massively create and maintain product data, location data, and product data that’s location specific. Yes, please, and with least effort.

A central concept permeates SAP Retail Master Data to enable master data creation: using master data to create master data. If you get your head around this idea — even at a high level — then you’ll begin to grasp the elegance and uniqueness of SAP Retail Master Data.

Simple eCATT Data Migration Example

My first experience with Extended Computer Aided Test Tool (eCATT) wasn’t much fun. In fact, I still cringe when I hear or say “eCATT.”

You don’t have to be a techno-wizard to take advantage of eCATT basics.

It would be fair to say that I still dislike eCATT. But the best SAP Functional folks are the best, in part, because they’re aware of every tool in their kit. And sometimes eCATT is the right tool for the job. In rare cases, it’s the only tool for the job.

You should know a bit about eCATT, even if you plan to avoid it, as I do.

Peeking Behind the Curtain of S/4HANA Business Partner

Of all that you’ve likely read on the topic of S/4HANA Business Partner, it’s typically not clear – or simply said – that Customer and Vendor Masters fully exist in S/4HANA, exactly as they did in ECC 6.0. They’re just hidden behind Business Partner.

What’s more, and to the point, SAP S/4HANA Sales and Distribution (SD) and Materials Management (MM) modules — and many others — remain blissfully unaware of Business Partner. They continue to use only plain old Customer and Vendor Masters.

Full stop! What does that mean for your Business Partner master data design in SAP S/4HANA ERP? It means that you’re more responsible than ever for the maintenance and outcome of Customer and Vendor.

Years after introduction, plain statements such as these about the S/4HANA implementation of Business Partner – practical implementation advice for SAP Architects and SAP Master Data practitioners – remain in short supply. Written hot on the heels of surviving the crucible of multiple implementations of S/4HANA ERP in 1709 and 1809, this document aims to mitigate that deficiency.

Let’s take a good, long peek behind the curtain, shall we?

Profit Center Number Complexity

Profit Center number decisions that add complexity.

Your decision for Profit Center numbers can add ongoing operation costs and complexity, especially in SAP Retail.

We’re talking strictly about Profit Centers in Material Master that are assigned for each Plant (MARC-PRCTR).

The Best Practice in SAP Retail is that only one Profit Center per Plant (Site) is relevant for all Materials (Articles), and that the Profit Center number is the same as the Plant number.   

Profit Center number = Plant number. Simple. But why is this Best Practice? What pitfalls await those who deviate? And how is Best Practice implemented? Spoiler alert: it isn’t standard, and that’s standard!