Author: Paul Gendreau

Master Data for creating Master Data

This subject is like jumping out of an airplane. If you’re not afraid then maybe you haven’t sufficiently considered the scope, risk, and potential consequences.

The question: If master data is important then how much business importance should you assign to the master data used to create master data?

“Foundation” is an unsatisfying metaphor. Master data used to create master data — I’ll call this Reference Master Data — is more like a super-structure upon which master data is created.

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?

Master Data makes SAP Retail special

It’s a self-serving notion with the added benefit of being true!

Sure, it’s the unique business processes of Retail and Fashion Vertical Business that prompt these Industry solutions. But if you get the foundation wrong — if you fail to grasp what’s special about SAP Retail master data — then you can forget about effectively executing business processes.

Implementing and running SAP Retail requires experienced SAP Retail Master Data experts. That’s not snobbery. It’s a quest for competence worthy of all Master Data Aficionados.

Site Master Data Migration: What, When, and How To.

Creating master data (and customizing, without customizing requests!) is a serious matter. Your data migration process better be executed properly and accurately. For one thing, it’s a tedious mess to clean up (archive) if things goes awry. Of course, as a Master Data Aficionado reading this article, you now have a plan for success.

Let’s begin by recognizing that your Site Master business process design dictates where and when you’ll be executing Site Master data migration.

Site Master Distribution is Best Practice in S/4HANA. If you’ve adopted that architecture then plan to execute Site Master data migration only in your Development Customizing Golden client. Then use Site Master Distribution to distribute those Site Masters to downstream systems-clients that require Site Masters.

Introducing MDA Workbench

This sweet application for SAP functional (and technical!) resources is the product of a decade of thought, development, and constant revision based on real-world project experience.

Until now,  MDA Workbench was shared only with a close circle of SAP Master Data practitioners, whom I affectionately refer to as fellow Master Data Aficionados.

While I wrote (and still write) the code, a friend and colleague named Gregory Baase contributed mightily. For years now, and still, Greg asks super-smart questions and makes totally unreasonable demands.

A consequential example: Huh? What’s that, Greg? You want MDA Workbench to actually create the LSMW object so that you don’t have to? Yeah, okay … right away.

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!