SAP Business partner

In classic ECC, a customer and a vendor were separate master records even if they were the same company. The Business Partner unifies this: one BP can be both a customer and a vendor (and more) through different roles, eliminating duplication and inconsistency. In S/4HANA, BP is the mandatory, leading approach, this is a key change from ECC.

A single BP takes on roles such as FI Customer, FI Vendor, or a sales/purchasing role. The role determines which data is maintained and how the BP participates in processes. Behind the scenes, BP still updates the underlying customer/vendor tables via Customer-Vendor Integration (CVI).

One transaction does everything: BP. The old XD01, XD02, XK01 and XK02 are not the route in S/4HANA, and reaching for them is the clearest sign somebody learned on ECC and has not updated.

The screen has three dimensions and confusing any of them is the usual source of trouble. The role decides which data you are looking at: general data, FI customer, FI vendor, sales or purchasing. The BP category is person, organisation or group, fixed at creation. Relationships link partners to each other, such as a contact person belonging to a company.

Underneath, the classic tables still exist. KNA1 and LFA1 are still populated, kept in step by customer vendor integration, so older reports keep working. The BP tables themselves are BUT000 for the partner and BUT100 for its roles.

Number ranges are where conversions go wrong. The BP number and the customer or vendor number can be the same or different, and that choice is made once, at conversion, and lived with.

Twenty minutes, and it demonstrates the whole point of the unification.

1. Open BP and create an organisation in the general role. Name, address, and nothing else yet.
2. Switch the role to FI Customer and complete the company code data: reconciliation account, payment terms. Save.
3. Switch the role to FI Vendor on the same partner and complete its company code data. Save again.
4. Check KNA1 and LFA1 in SE16N. Both have a row, generated by customer vendor integration from the one partner you maintained.
5. Now try to change the address in the customer role. It is general data, so it changes for both, which is precisely the behaviour ECC could not give you.

Step five is the argument for BP in one action: one address, one partner, no drift between the customer record and the supplier record for the same company.

Anyone moving from ECC to S/4HANA must understand BP, master-data conversion to Business Partner is a mandatory and often significant part of migration. New learners should learn BP as the default.

For a conversion project this is rarely a small task. Legacy customers and vendors have to be matched where they are the same real organisation, number ranges decided, roles mapped, and the whole thing validated before anything transactional moves. It is usually one of the larger data workstreams. See SAP master data for how it sits with the rest.

• Same number or different. Keeping the legacy customer number as the BP number helps people find things and constrains the number ranges. Separating them is cleaner and means every user learns a new number.
• Which roles are mandatory. A partner created without the role somebody needs is invisible to them, and that is the most common day-two complaint.
• Who may create one. BP touches sales, purchasing and finance at once, so the old model of each team creating its own master no longer applies.
• Grouping and hierarchy. Relationships can model a head office and its branches, which reporting will want and nobody asks for until after go-live.

For most people BP is met during a conversion rather than on a clean install, so it is worth knowing what that work looks like.

Analysis first. The existing customer and vendor masters are profiled: how many, how many are the same real organisation appearing twice, how many are incomplete, and which number ranges are in use. The answer to the second question decides how much manual matching is coming.

Cleansing. Duplicates merged, obsolete records marked, missing mandatory fields filled. This is the part that needs the business, because only they know which of two similar suppliers is still trading. A conversion is also the one cheap opportunity to delete what should not come across.

Number range decisions. Whether the BP number equals the customer number, the vendor number, or neither. Same-number keeps every existing reference and report meaningful. Different-number is cleaner and means retraining everyone who quotes an account number on the phone.

Customer vendor integration setup. The configuration that keeps KNA1, LFA1 and the BP tables in step. If this is wrong the classic tables drift, and older reports quietly return the wrong answer rather than failing.

Then the synchronisation run, in a test system first, repeatedly, until the error list is empty. Errors are almost always missing mandatory data rather than technical faults.

Plan for this to take longer than the technical conversion around it. The system change is mechanical; agreeing which records are the same organisation is not.

A habit worth forming, because the screen shows a lot and most of it is not what you need.

Check the category first, at the top. Person, organisation or group. It cannot be changed later, so a partner created as the wrong one is a recreate rather than a correction.

Then the roles. The dropdown lists what this partner is configured to be. If the role somebody expects is absent, that is the whole explanation for why they cannot use it, and it is a five second check.

Then the company code and sales area data inside the relevant role. General data existing is not the same as being usable in a company code, and this is the level most "the customer does not work" reports are actually about.

Finally the relationships tab if the question involves a contact person or a head office arrangement.

Four checks in order, and they resolve most BP questions before anyone opens configuration.

• Treating customer and vendor as separate, BP unifies them in S/4HANA.
• Ignoring CVI, BP still feeds the classic tables.
• Missing required roles, a BP without the right role cannot act in a process.

• Maintaining an address in the wrong role. General data is shared, role data is not, and knowing which is which prevents an hour of confusion.
• Assuming customer vendor integration is automatic magic. It is configuration, and if it is not set up correctly the classic tables silently drift out of step.
• Looking for XD03 in an interview. See SAP company code for the organisational data BP hangs off.

Creating a partner is straightforward, and designing the roles, number ranges and conversion mapping for a real client is the part you do in the course.

If you remember one thing, make it this: general data is shared across roles and role data is not. Almost every confusion on this screen is somebody maintaining a field in the wrong one of those two places, then wondering why the other role did not see it.