Peeking Behind the Curtain of S/4HANA Business Partner

Posted on August 6, 2020 by - Business Partner, MDA Magazine

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?

Yes, we understand that Business Partner (BP) is the leading entity – the strategic object model – for all Customer and Vendor master records in S/4HANA. In fact, BP is the only visible entity.

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. While hidden, plain old Customers and Vendors not only remain fully relevant – and singularly relevant for MM and SD – but are only accessible via BP and CVI, which knits the whole lot together.

While CVI manages the technical integration between BP and Customers and Vendors, it’s not magic. It does so only as a direct consequence of your BP design and configuration. It’s your responsibility to architect the journey from legacy Customers and Vendors to S/4HANA BP. It’s your responsibility to architect the end-state experience.

As you contemplate master data design of BP in S/4HANA ERP, it would be a grave error to either think mainly in terms of Customer and Vendor, as known in ECC 6.0, or to take your eyes off of Customer and Vendor in S/4HANA, even for a moment. It’s critical in S/4HANA ERP to think holistically about BP, Customer, Vendor, and CVI .

Table of Contents

Project Organization Matters

The first mistake that I made — on my first S/4HANA ERP implementation — was to continue thinking in terms of Customers and Vendors. We all make rookie mistakes … once.

Our project organized discussions and resources around Customers and Vendors, rationalizing that these were mainly separate legacy business objects, and certainly each had different business process concerns. What’s more, legacy Customers and Vendors had different stakeholders.

I won’t make that mistake again! At the very least, a single master data functional expert must have a comprehensive view and be completely responsible for BP design.

At best, you should be actively promoting the notion that enterprise-wide business process design suffers unless it’s clear that there’s one — and only one — BP design that comprehensively covers BP, Customer, and Supplier. BP is a single business object. Repeat the words until your friends begin repeating the words: BP is a single business object. In practice, that means a single functional expert, a single data owner, and a single view of data governance for BP.

If you’re working with — or are — an ECC 6.0 customer moving to S/4HANA, then it’s even more important to reinforce the understanding of a single business object. It’s not a trivial task; you’re striving to change the way experienced users think about business objects, and with good reason.

To that end, even the words matter. I avoid saying “Customer” and “Vendor” in conversation when speaking about S/4HANA. Those terms are appropriate for legacy systems. For S/4HANA, I say “BP.” The designation is to be understood as all encompassing. It’s “BP Supplier” or “BP Customer,” if I need to be specific. Yes, you need to be specific.

Is Business Partner a new concept?

ECC 6.0 featured multiple business objects and transactions, with Commonalities.

The concept of BP is far from being a new idea.

In fact, BP has existed for many years in ECC 6.0, where it was mainly relevant for SAP applications that required modelling complex relationships between a company and its customers and suppliers. Examples include SAP Customer Relationship Management (CRM) and SAP Financial Supply Chain Management (FSCM). For good business process examples, think of industries such as Insurance and Finance.

Business-Partner-centric applications have historically been implemented independently of ERP systems. In scenarios where such applications were integrated with ERP, or scenarios where a specific application (e.g. credit management) existed in the same SAP ERP system, then standard functionality provided for replication from ERP Customers and Vendors to BP. But typically, replication was not executed in real time.

Possibilities for redundant and incoherent master data abounded, as separate master data records existed between integrated systems and applications.

Principle of One

SAP S/4HANA Principle of One means providing a single solution for a given business requirement.

The necessity of applying this “simplification” concept -– simplification for the enterprise, but certainly not for you! — becomes apparent as applications using BP are brought into a central S/4HANA instance inhabited by Customers and Vendors. Beyond that, applications across the enterprise benefit from a common business object.

SAP S/4HANA Principle of One is a solid idea from an enterprise perspective. It’s the particulars of making it real in S/4HANA ERP that become, shall we say … interesting.

The S/4HANA implementation of BP centrally manages master data for BP, including views for Customers and Suppliers. Transaction Code BP is the single point of entry to create, edit, and display master data for BP, including data related to conventional Customer and Vendor objects.

Different Object Models

While the BP object model shares commonalities with Customer and Vendor object models (e.g. Basic Data, Business Address Services), they aren’t the same.

An obvious difference is that the BP object model doesn’t include validity areas (views) for:

  • Customer – Company Code
  • Customer – Sales Area
  • Supplier – Company Code
  • Supplier – Purchasing Organization
ECC 6.0 featured multiple Business Objects and transactions, with Differences!

What’s less obvious, is that the organization and controls points afforded by these objects are very different. These differences matter very much in practice in S/4HANA. It’s your job to sort out the differences during implementation.

What Is Seen And Not Seen

You’ll first notice what’s not seen in general terms. For example, the following SAP transactions are no longer available or are redirected to transaction BP:

  • FD01, FD02, FD03, FD05, FD06, FD08 (Create, Change, Display, Block, Deletion mark, Confirm Customer (Accounting))
  • FK01, FK02, FK03, FK05, FK06, FK08 (Create, Change, Display, Block, Deletion mark, Confirm Vendor (Accounting))
  • MAP1, MAP2, MAP3 (Create, Change, Display Contact Person)
  • MK01, MK02, MK03, MK05, MK06, MK12, MK18, MK19 (Create, Change, Display, Block, Deletion mark Vendor (Purchasing))
  • V-03, V-04, V-05, V-06, V-07, V-08, V-09, V-11, V+21, V+22, V+23 (Create invoice recipient, payer, consignee, one time Customer, ordering party, carrier, sales prospect, competitor, Business Partner (Sales/Centrally))
  • VAP1, VAP2, VAP3 (Create, Change, Display Contact Person)
  • VD01, VD02, VD03, VD05, VD06 (Create, Change, Display, Block, Deletion mark Customer (Sales))
  • XD01, XD02, XD03, XD05, XD06, XD07 (Customer: Create, Change, Display, Block, Deletion mark, Change Account Group (Centrally))
  • XK01, XK02, XK03, XK05, XK06, XK07 (Vendor: Create, Change, Display, Block, Deletion mark, Change Account Group (Centrally))

Mass maintenance for BP fields via transaction MASS is available via object “Business Partner”.

But looking at BP as a business object, you see that S/4HANA users enjoy an integrated experience across many technical objects.

Your BP design and configuration hides complexity from business users.

As a BP is extended to Customer and Supplier roles, plain-old Customer and Vendor objects are created and maintained behind-the-scenes by CVI.

CVI redundantly populates Business Address Services and many other tables. For example, plain-old Contact Persons are redundantly populated from BP and BP Relationships.

Redundant data is necessarily generated because SAP S/4HANA SD, MM, and more modules only use the classic Customer, Vendor, and related tables.

Always think holistically about BP, Customer, Vendor, and CVI!

However, the integrated user experience is a direct result of your BP design.

Because you’re responsible for business process results, you need to think in terms of validating BP results comprehensively. Ultimately, that means validating BP, but also drilling deeper by validating results in classic Customer / Vendor tables.

Customer Master remains fully implemented in S/4HANA ERP and must be configured. Vendor Master remains fully implemented in S/4HANA ERP and must be configured. In addition, BP and CVI must be configured. Your BP design must cover the lot.

Organizing Principles

A good way to approach BP Design is to begin by recognizing the conceptual differences between BP and Customer / Vendor.

Consider your specific business requirements in that context, with the objective of using configuration and CVI to achieve your specific business requirements. There isn’t a one-size-fits-all approach.

Here’s a high-level contrast between the two:

Business Partner

  • Arranged mainly by BP Category and BP Grouping, which cannot be changed after the BP is created.
  • BP Category designates whether the BP is a Person, Organization, or Group.
  • BP Groupings are logical groupings of BP that share similar business process, but not necessarily the same system configuration requirements.
  • BP are extended to Roles as needed (e.g. Supplier, Customer), limited by customizing and authorization.
  • A single BP can comprehensively represent a Supplier, a Customer, both, or neither, as in the case of a BP Contact Person.

Customer / Vendor

  • Arranged mainly by Account Groups, which can be changed over time (within constraints).
  • Customer and Vendor account groups are logical groupings of Customers and Vendors that share similar business process and system configuration requirements.
  • While it’s possible to link a Customer and Vendor in ECC 6.0, it often resulted in an inconsistent representation. For example, consider a so-called Returns Vendor, which creates a Customer Master with a shared Business Services Address record, whereas manually linking Customer and Vendor results in two separate Business Services Address records.

If you’re beginning to realize that these business objects are more than a bit different in organization and implementation … then you’re caching on.

More than anything, getting your BP design “right” is about understanding and reconciling the differences for your particular use cases.

BP and Customer/Vendor Integration (CVI)

BP, ERP Vendor, and ERP Customer object models with basic tables indicated.

While CVI can work bidirectionally, the most common scenario is simply from BP to Customer/Vendor. At least at first, your design is primarily focused on how you’ll create and maintain a BP, with an ERP Customer and ERP Vendor being created and maintained in the background via CVI.

The central issues are account groups and number ranges. The SAP term “account groups” carries specific meanings in terms of underlying configuration, but the same underlying factors are typically relevant for the organizing elements of legacy Customers and Vendors.

While gazing at the BP data model, take note of the blocks such as Address, Contact Persons, Tax Numbers, and Bank Details. When you see these attributes and objects at the BP level, it’s an indication that the data is maintained at the BP level with one-version-of-the-truth pushed down by CVI to the ERP Customer and ERP Vendor.

That means, for example, that a given BP cannot have different bank details for the BP Customer and BP Supplier. Certain Tax Numbers, maintained at BP level, are propagated down to relevant Tax fields (mapped via CVI) in the BP Customer and BP Supplier. And yes, the one address for the BP applies to both the BP Customer and BP Supplier.

From an ERP perspective, SD / MM remain unaware of BP. As a consequence, the many and interesting relationship functionalities of BP simply aren’t available in SD / MM. It doesn’t matter that Business Partner offers wonderful functionality for expressing complex relationships, including time-dependent addresses. In SD / MM business processes, Partner Functions remain relevant for expressing relationships such as alternate addresses. That directly influences your BP design.

BP Grouping, BP Roles, and Customer/Vendor Integration (CVI)

At first glance, BP Grouping appears similar in concept to Vendor Account Group and Customer Account Group. But they’re different in important ways that demand your attention. In fact, in S/4HANA ERP, Customer and Vendor Account Groups can only be considered in the context of BP Grouping.

CVI is the glue that holds these disparate objects together behind the scenes, and it’s implemented by configuring a hard link between BP Grouping and Customer and Vendor Account Groups.

A hard link is configured between BP Grouping and Customer / Vendor Account Groups.

A BP Grouping is linked through configuration to a Vendor Account Group and/or a Customer Account Group. Take notice of the singular. For a given BP Grouping, in the direction BP to Customer, you may assign one Customer Account Group. For a given BP Grouping, in the direction BP to Vendor, you may assign one Vendor Account Group.

CVI connects them with this hard configuration link. Number ranges across these objects immediately comes to mind as a pain point, but there’s much more to consider.

BP Grouping and Account Groups differ with respect to configuration implications.

BP Grouping and Customer / Vendor Account Group have fundamental differences with respect to configuration and control, as shown above. If you neglect to consider this, the system will remind you by behaving badly!

  • Customer and Vendor objects are only accessible through BP and CVI.
  • While BP Grouping is linked via CVI configuration to Customer and Vendor Account Group, unlike Customer and Vendor Account Group, none of the following can be configured or controlled by BP Grouping:
    • Partner Functions
    • Screen Field Status (Suppress, Display, Required, Optional)
    • Authorization

Reconcilable or Irreconcilable Differences?

In theory, the implementation of BP in S/4HANA lessens the importance of Customer and Vendor. At the very least, they are hidden behind BP. Does it then follow that the importance of Customer and Vendor Account Groups is lessened, perhaps even made irrelevant?

In standard, there are possibilities to control Screen Field Status and Authorizations using either or some combination of both BP and Customer / Vendor objects.

However, even in S/4HANA 1909, the only possibility to configure and control MM and/or SD Partner Functions is by Customer and Vendor Account Groups. In both MM and SD modules, Partner Functions and Partner Determination can be used for price determination, message determination, address determination, and statistics. Consider further, for example, that Partner Determination (Partner Schema) can vary with master data maintained at different data retention levels (e.g. in MM: purchasing organization, sub-range, and plant levels).

So, what’s a Master Data Aficionado to do? The answer to this foundational design question is, in the classic consultant formulation: It depends!

Option # 1: If Partner Functions are not relevant to your design today or in future, which is difficult to imagine in any implementation that includes MM or SD business processes, then you could choose to configure only one Customer Account Group and only one Vendor Account Group and attempt to manage Screen Field Status and Authorizations through BP functionalities.

In other words, all BP Groupings requiring a Vendor Role could be assigned to the one Vendor Account Group, and all BP Groupings requiring a Customer Role could be assigned to the one Customer Account Group. This is the extreme example to not consider Customer and Vendor Account Group at all; an attempt to consider only from the BP point of view.

Option # 2: It’s possible to deviate from standard and create your own custom Partner Determination functionality based on Business Partner Relationships. For example, in SD scenarios, such custom functionality was described a couple of years ago in a document named SAP S/4HANA Mitigation concept for Ship-To and Sold-To Role issues. In my view, this seems like a bad idea. It’s better to wait for such functionality to be delivered in standard, if it is ever to be delivered in standard.

Option # 3: If Partner Functions are relevant in your business processes then a Customer / Vendor Account Group centric design must likely be adopted in S/4HANA.

At the least, the relevance of Customer / Vendor Account Groups cannot be ignored. In this scenario, configure Customer and Vendor Account Groups pretty much as would be the case in ECC 6.0 and then configure BP Groupings to align with the Customer and Vendor Account Groups. As a starting point, with a one-to-one alignment.

Of course, there’s much more to consider. For example, you’ll likely prefer to configure BP Groupings that can include both Supplier and Customer roles when appropriate. Depending on your requirements, a given Vendor or Customer Account group might serve more than one BP Grouping.

Same Legal Entity?

In addition to general profiling of legacy data, you’re going to spend time considering legacy records with respect to Same Legal Entity. The result of your analysis — and what to do about it — will likely influence your BP Design, data migration complexity, and data quality efforts.

Remember that it’s possible to link a Customer and Vendor in ECC 6.0. But why? For what purpose? Looking for those links (KNA1-LIFNR and LFA1-KUNNR) and asking data owners to explain the linkage per Vendor and Customer is a good start.

It could be true that the Customer and Vendor are linked because they are the same legal entity. Usually this means, for example, that they have the same postal address and bank data. In this case, you’d like to create one BP and extend it to Customer and Supplier roles, which will create a Customer and Vendor in the background. Data quality issues typically flourish here, as address data is maintained separately — therefore, usually inconsistently — across separate legacy Customer and Vendor business objects.

Or it could be true that the Customer and Vendor are linked for other business process reasons. In this case, you’re more likely to create one BP for each legal entity: One BP extended to a Customer role to represent the ERP Customer, and another BP extended to a Supplier role to represent the ERP Vendor. Additionally, the original linkage between the two needs to be understood because it may need to be carried forward.

Business Partner Numbers

As you work through a design, the Best Practice objective in end-state is that BP number, BP Customer number, and BP Supplier number are all the same number.

This isn’t mandatory, and it may not be possible for legacy data.

Because MM and SD modules use Customer and Vendor number, not BP number, it’s significantly confusing for business users if there isn’t an alignment of numbers between these objects.

For example, if BP # 123 is extended to a Vendor Role (and Vendor # 456 is created) and extended to a Customer Role (and Customer # 789 is created), then imagine the confounding result as business processes are executed. A user would maintain BP # 123, but would have to create a Purchase Order using Vendor # 456, and perhaps create a Sales Order, a Credit, or a Debit using Customer # 789.

A hard link is configured between BP Grouping and Customer / Vendor Account Groups.

As you think about adoption of Best Practice for number ranges, it’s possible to accommodate a difference between migrated legacy data and new data to be created after go live. It may not be possible to align number ranges for legacy data and data migration, but it’s typically possible to adopt Best Practice for number ranges going forward. Data migration and go-forward approaches need not be the same.

You’re going to spend a great deal of time on this topic, especially if you’re migrating legacy ECC 6.0 data. Business process owners typically take a dim view of renumbering Customers and Vendors, some of which may be unavoidable.

Where to begin? You can’t create a map to where you’re going without first know where you are. It’s important to begin by creating a reference list of existing configuration for account groups and assigned number ranges, including the from, to, and next values for each assigned number range. That’s the context for current state.

Then start profiling legacy data across account groups and number ranges. You’re looking for outliers and low hanging fruit, and the result will help you understand and articulate the scope of the challenge ahead.

The Outliers: Odd Numbers

You’re likely to find outlier master data that doesn’t conform to current configuration.

These master data records will be in a certain account group, but have a Customer or Vendor number that falls outside of the currently configured range. This can happen for many reasons, such as:

  • Customers or Vendors were loaded by IDoc or by a program.
  • Customers or Vendors were moved from one account group to another.
  • Configuration changed over time.

These records may need special attention in context of future numbering or account group assignment.

The Outliers: Overlapping Number Ranges

When number ranges overlap between legacy Customer and legacy Vendors you’ll find a Customer and a Vendor with the same number, but the Customer and a Vendor are completely unrelated businesses.

If Customer # 12345 isn’t the same legal entity as Vendor # 12345, then you’re not going to merge them as one legal entity into one BP # 12345.

But records in this scenario remain a roadblock towards achieving the end-state-objective of one number for BP, Customer, and Vendor.

The Outliers: One Legal Entity

Consider legacy Customers and Vendors that represent one Legal Entity (the Legal Entity question already discussed).

Ideally, these are represented as a single BP extended to both Customer and Supplier roles. This is usually the most difficult scenario with respect to number ranges and legacy data. It’s likely that the legacy Customers and Vendors have different numbers.

Low Hanging Fruit

Outside of the outliers, consider this as a starting point for discussion:

  • migrate each legacy Customer to a BP grouping that includes a Customer role with appropriate Customer Account Group, with same number. e.g. legacy Customer 98765 migrates to BP 98765 and BP Customer 98765. This BP is not extended to a Supplier role.
  • migrate each legacy Vendor to a BP grouping that includes a Supplier role with an appropriate Vendor Account Group, with same number. e.g. legacy Vendor 123456 migrates to BP 123456 and BP Supplier 123456. This BP is not extended to a Customer role.

These records represent the low hanging fruit. But it’s not a BP design! You haven’t yet fully described each BP Grouping to be created.

Your struggles lie mainly with the outliers: odd numbers, one legal entity, and number range overlap. You’ve got to describe how each will be accommodated.

Don’t overlook data migration relevancy criteria as your friend in (avoiding) this task. Records that aren’t relevant to be moved to S/4HANA don’t require your attention outside of identifying such records. For this reason, it’s best to begin data migration relevancy criteria conversations as early as possible.

Outside of the low hanging fruit, everything is a compromise. And the ultimate compromise is renumbering of those legacy Customers and Vendors as they migrate to S/4HANA BP.

Business Partner “numbers” include many number range considerations.

Customer and Vendor number ranges are set to “External” in the “same numbers” scenario because they will be assigned externally, from the point of view of CVI.

Contact Persons

Plain old Contact Persons are also created via CVI.

When you create a BP Person and then assign it in a Relationship as a Contact to a BP Organization, if the BP has Supplier or Customer roles, then a plain-old Contact Person is created by CVI for the plain-old Vendor or plain-old Customer. In fact, if the BP has both Supplier and Customer roles, then a plain-old Contact Person is redundantly created by CVI for both the plain-old Vendor and plain-old Customer.

If distributing BP, the number range for Contact Partners must be unique across all systems-clients in your landscape where distribution will occur.

  • The number range for Contact Partners must be assigned internally. Do not set the number range as external.
  • Number range can be checked in T-Code SNRO, object PARTNER (Number ranges for Contacts), Interval AP.

This point obviously requires planning and intentional execution.

Screen Field Status

Field status could be tricky even in ECC 6.0. For example, for Vendor Master, a given field could be configured as either Suppress, Display, Required, or Optional.

The often-confusing aspect (in both ECC 6.0 and S/4HANA) is that field status can be configured by Customer or Vendor Account Group, and also by Activity (i.e display, create, change). In a given transaction, the system determines the applicable field status for a field by considering the configuration made by Account Group, and by also considering the configuration made by Activity, with the most restrictive option applied according to the logical sequence of Suppress, Display, Required, Optional.

I don’t know about your experience, but I found it annoying to chase down multiple configuration points to explain or correct the configured system behavior. Ultimately, I found it highly preferable (does that make it a Best Practice?) in ECC 6.0 to configure Field Status only by Account Group. Keep it simple.

The many inputs to determination of field status for any given field in T-Code BP.

S/4HANA does much the same for Business Partner fields in transaction BP, applying the most restrictive case using the logical sequence of Suppress, Display, Required, or Optional. But the complexity of this determination by field has exploded as settings across all objects and more configuration points are comprehensively considered.

With such astonishing complexity embedded in the determination of field status in T-Code BP, it’s no surprise that there’s a central SAP Note (SAP Note 2603898) detailing a rather long list of SAP Notes to be implemented and considered. Some of the notes include manual steps and some of the notes are simply explanations and guidance in this subject area.

Aside from applying needed SAP Notes (less likely in latest versions of S/4HANA) and educating yourself in the particulars of BP Screen Field Status in S/4HANA, it’s clear that a strategy is necessary from the onset for dealing with Screen Field Status in T-Code BP.

If your BP design is Customer / Vendor Account-Group-centric (this is likely the case, for MM and SD reasons, as previously discussed) then your Field Status configuration strategy is likewise going to be account-group-centric. Mainly maintain field status by Customer / Vendor Account Group, and then adjust BP settings as needed. Usually, “adjustment” at the BP level means removing constraints that are undesirably overriding account group settings, and which you would prefer to control by account group alone.

For example, when encountering undesired field status behavior, check the account group settings first. Then check BP settings that could result in fields being Suppressed, Display Only, or Required.

In the interest of simplicity, I continue to favor (remember, the “Best Practice”) not configuring Screen Field Status by Activity, in any object. Keep it simple.

Business Partner Design

If you’ve made it to this point, dear reader, then you’re likely exhausted by reading of the importance of “Business Partner Design.” What the heck does that mean, exactly?

Most of the words before these are the foundation for getting to this point. Your patience is rewarded by grasping the context for what’s next.

SAP S/4HANA Business Partner design is a business discussion informed by your analysis and system knowledge. Quite frankly, producing the result involves compromise.

The output of Business Partner Design is a clear definition of:

  • BP Groupings and Number Ranges
  • Identification of BP Groupings that include Customer Roles
    • For each, what Customer Account Group and Number Range?
  • Identification of BP Groupings that include Supplier Roles
    • For each, what Vendor Account Group and Number Ranges?

Armed with the above, you’re only minutes away from configuring the same in the system.

Achieving this definition necessarily includes, as a prerequisite, a comprehensive review and reconciliation of current account groups and number ranges against an initially proposed end state.

This isn’t a technical problem to be solved. It doesn’t involve configuration and prototyping. Sure, there are technical constraints that inform the discussion. But you should expect that — after analysis — that this is an exercise requiring business participation and likely data quality mitigation.

If you’re moving Customers and Vendors from ECC 6.0 to S/4HANA BP, then buckle up. You should already recognize that this is going to be a long ride as you resolve Account Group and Number Range conflicts across legacy, S/4HANA BP for data migration, and S/4HANA BP desired end state.

I always like to begin with the objective in mind. So here it is: for at-a-glance clarity, you want to (eventually) produce a worksheet with these columns, with only 1 row per BP Grouping.:

  • Legacy Vendor Account Group
    • ECC Vendor Number Range
    • ECC Vendor Number Range Internal/External
    • ECC Vendor Number Range From/To
  • Legacy Customer Account Group
    • ECC Customer Number Range
    • ECC Customer Number Range Internal/External
    • ECC Customer Number Range From/To
  • S/4HANA Business Partner Grouping
    • Business Partner Number Range
    • Business Partner Number Range Internal/External
    • Business Partner Number Range From/To
  • S/4HANA BP Supplier Acct Group (if Supplier role is valid for BP Grouping)
    • Vendor Number Range
    • Vendor Number Range Internal/External
    • Vendor Number Range From/To
    • Vendor Number Same Number (Y/N)
  • S/4HANA BP Customer Account Group (if Customer role is valid for BP Grouping)
    • Customer Number Range
    • Customer Number Range Internal/External
    • Customer Number Range From/To
    • Customer Number Same Number (Y/N)

With this, I want see how legacy Vendors and Customers map into S/4HANA BP, BP Customer, and BP Supplier. And I want to see — across the board — how the BP Grouping, Account Groups, and number ranges are assigned without overlap.

Pay special attention to BP Groupings that have the possibility of a Customer role or a Supplier role, but not both. That is to say, you plan to assign, via CVI, a Customer Account Group or a Vendor Account Group, but not both.

Remember that the Best Practice objective in end-state is that BP number, BP Customer number, and BP Supplier number are all the same number.

Because of the Best Practice objective, now is the time to be thinking about not blocking future requirements. That means you should anticipate the possibility of future Customer Account Groups (and number ranges!) for BP Groupings that only have the possibility of a Vendor Role. Likewise, you should anticipate the possibility of future Vendor Account Groups (and number ranges!) for BP Groupings that only have the possibility of a Supplier Vendor Role.

It’s probable that the “clear” definition of BP design includes one set of rules — or, at least, an explanation — for data migration, and then a different set of rules for post go live. For example, with respect to number ranges, such a difference could accommodate some deviation from the past while observing Best Practice going forward.

It’s not easy, and it’s not one conversation. It’s a progression of analysis, conversations, and compromise.

A progression for Business Partner design.

Data Migration of Business Partner

SAP S/4HANA Migration Cockpit is the recommended tool for loading Business Partners into S/4HANA. Neither Legacy System Migration Workbench (LSMW) nor processing by a Intermediate Document (IDoc) is an option for data migration of BP.

SAP S/4HANA Migration Cockpit enables the load step, but all data migration steps must be considered:

  • Analysis
  • Extract
  • Clean / Transform
  • Validate
  • Load
  • Reconcile

For this reason, I continue to strongly favor SAP Data Services as the primary and comprehensive data migration platform.

Rapid data migration to SAP S/4HANA (on premise), based on SAP Data Services, explicitly calls for the use of SAP S/4HANA Migration Cockpit for the load step when performing data migration of BP.

An alternative, both for data migration and integration, is to create your own load program based on a standard class provided for this purpose. Refer to SAP Note 2417298 – Creation of Business Partner with Customer and Supplier Roles, which advises that “to create Business Partner with Customer and/or Supplier roles in S/4HANA, we recommend to use standard API: CL_MD_BP_MAINTAIN.”

Integration of ECC Customer / Vendor to S/4HANA BP

You might face an integration scenario that requires flowing Customers or Vendors from a legacy system — including ECC 6.0 — into an S/4HANA system as a BP. Implementing SAP Central Finance is one such example.

Because it’s possible to configure CVI in both directions, it’s possible in some circumstances to integrate Customers / Vendors from ECC 6.0 to S/4HANA using standard IDocs and ALE.

This scenario requires implementation of Serialization Using Message Types: ADRMAS, DEBMAS, CREMAS.

There are many constrains, of course. Not the least of which include your design of BP Groupings and alignment with Customer and Vendor Account Groups, and number ranges across the board.

What’s more, I’ve found CVI to be quite robust in the direction of BP to Customer and BP to Vendor, but no so mature in the opposite direction.

This is manifested by the number of relevant SAP Notes (as of S/4HANA 1809). Examples include …

  • SAP Note 2606809 – DEBMAS/CREMAS : BP existing role validity changed during idoc processing
  • SAP Note 2607014 – DEBMAS/CREMAS : Coding improvements and CVI contact person issue changes
  • SAP Note 2623693 – CREMAS : IDOC code refactoring
  • SAP Note 2624196 – DEBMAS : Code refactoring (DEBMAS idoc processing)
  • SAP Note 2643518 – Required field check also takes place for unchanged customer and vendor datasets in transaction BP
  • SAP Note 2722848 – Error with the determination of the business partner grouping; assignment to business partner role is deleted
  • SAP Note 2735050 – Business Partner creation via DEBMAS/CREMAS fails with error R11 555
  • SAP Note 2743767 – CVI_VAL: Tax number is a required entry field
  • SAP Note 2748536 – DEBMAS/CREMAS: Filter BP roles based on customer/supplier account group
  • SAP Note 2751067 – CVI_VAL: “Language Key: Is a required entry field” when running migration of customer/supplier in test mode
  • SAP Note 2753226 – CVI_VAL: Tax Juris.: Is a required entry field
  • SAP Note 2801181 – DEBMAS CREMAS: create master data with partner function fails with ‘Invalid value (foreign key check failed)’ error

Be aware of Legal Entity Checks:

  • SAP Note 2617001 – DETERMINE_BP Method in DEBMAS/CREMAS_IDOC_EXTENSION BADI for Legal Entity Checks
  • SAP Note 2617002 – Legal Entity Check Implementation in DEBMAS/CREMAS Idocs

And beware of constraints:

  • IDOCs integration in S/4 for creation of Customer/Supplier with same number as BP (Customizing configured as BP Internal numbering and Customer/Supplier External numbering with same number) will not be supported.
  • Creating a BP per Customer and a BP per Vendor is the simple case. Merging related Customer and Vendor into a single BP is more complex and constrained (e.g. SAP Note 2617002 – Legal Entity Check).

Enhancement of Customer / Vendor

All BP, Customer, and Vendor data is managed through T-Code BP.

If you want custom fields to be available in T-Code BP, then enhancements to Vendor (e.g. fields appended to LFA1, LFB1, LFM1, etc.) and/or Customer (e.g. fields appended to KNA1, KNB1, KNVV, etc.) must necessarily include enhancement of Business Partner and Customer/Vendor Integration.

For very specific details, refer to SAP Note 2309153 – BP_CVI: Guideline Version 1.14 for customer enhancements in CVI (customer/vendor integration) in SAP S/4HANA releases. This SAP Note includes a cookbook as an attachment.

Read the cookbook. But, in summary, let’s just say that enhancement of Customer / Vendor through BP/CVI enhancement can be complex and time consuming. Mitigating risk in this area means finding a development resource with successful, real-world experience in this niche. Otherwise, you’re simply going to underestimate the overall effort and the number of iterations to get this working.

Distribution of Business Partner: DRF

If your implementation is SAP Retail, then you’ll almost certainly (certainly, if you observe Best Practice) have a requirement to implement Site Master Distribution. This is a requirement, in part, to distribute Business Partners.

A less common requirement is to maintain a small number of Business Partners in your Configuration Golden system-client and to distribute them to downstream systems-clients. These would generally be special purpose Business Partners, such as those created for SAP REA (Recycling Administration) or perhaps to represent Internal Customers/Vendors, where one version of the truth is important across a landscape. In such scenarios, we’re treating master data more as configuration.

For all the above, or for any BP distribution requirement, Data Replication Framework (DRF) is used to distribute Business Partners (with Customer / Vendor) between S/4HANA systems-clients. Distribution of Business Partners via standard ALE / IDoc is not an option.

Data Replication Framework (DRF) is used to distribute Business Partners (with Customer / Vendor) between S/4HANA systems-clients.

Notice that the distribution of BP occurs via Web Service and not by ALE or RFC. You should expect Web Services setup and subsequent configuration to take some time, recognizing that it’s a team effort: Basis 85%, Functional 10%, Security 5%.

Here again, you’re certain to underestimate the effort to get this process working. In my experience, this is mainly due to lack of cross-functional experience with DRF and Web Services.

Have your Basis friends thoroughly read and consider Configuring the SOA Manager for Business Partner, including the attendant steps for technical configuration of the web service runtime, to be performed according to SAP Note 1043195.

Even if your outbound integration scenario is to an ECC 6.0 system or a non-SAP system, in which case IDocs and not Web Services might be relevant, you may still be interested in using DRF rather than using change pointers and ALE to distribute Vendor (CREMAS IDoc) and Customer (DEBMAS IDoc).

By activating a function module (MDG_BS_BP_OUTBOUND_DRF) and using a different standard DRF outbound implementation (986_4 – MDG Vendor via ALE, or 986_5 – MDG Customer via ALE) in the DRF Replication Model, the standard system can trigger distribution of Customer and Vendor IDocs when a Business Partner is changed, rather than using change pointer processing.

Deleting a Business Partner

To delete BP, use of the standard archiving process is mandatory (T-Code SARA).

  • T-Code BUPA_DEL is obsolete. Do not use T-Code BUPA_DEL to delete BP data!
  • Report BUPA_TEST_DELETE and function module BUP_BUPA_MASS_DELETE are obsolete.

Refer to these SAP Notes for background and process steps:

S/4HANA Technical Conversion

Much of the content in this document applies universally to adopting Business Partner in S/4HANA ERP. But there are considerations that are particular if you’re adopting S/4HANA as a technical conversion of an ECC 6.0 system. If that’s your scenario, please pay attention to the following: