BUSINESS PARTNER

Introduction

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 bi-
directionally 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. It’s critical in S/4HANA ERP to think holistically about BP,
Customer, Vendor, and CVI.

Organizational aspect of BP

Traditionally, vendors and customers are separate legacy business objects and each has separate
business process and separate stake holders. But in HANA, BP is a single business object which knits
together customer and supplier. Therefore, it is important that the master data manager should
have comprehensive view and responsible for BP design. In practice, that means a single functional
expert, a single data owner, and a single view of data governance for BP.

Is Business Partner a new concept?

The concept of BP is not new. In fact, BP existed in ECC applications where complex relationship
modelling existed between companies and their customers and suppliers. For example, SAP
applications such as CRM and FSCM have been using BP before it was introduced in HANA. Now,
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

Even though BP object model share commonalities with vendors and customers, they are not same.
Except general data, other data objects such as company code data, sales organization and purchase
organization data are different.

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. Customer and
vendor master are fully implemented in S4HANA. In addition, BP and CVI must be configured.
Difference between BP and Customer/Vendor

Business partner Customer/Vendor

 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.
 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.
BP and Customer/Vendor Integration (CVI)

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

BP Grouping and Customer / Vendor Account Group have fundamental differences with
respect to configuration and control.

Business partner number Vis-à-vis Customer/Vendor number

As per best practice, the BP number, BP Customer number and BP vendor number are
same even though this is not mandatory.

Since 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.
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. It is advised to set customer and vendor number as external
so that BP number will be assigned to customer and vendor by CVI.