The following entity relationship diagram outlines a logical model for a STEP-to-SAP integration. The individual elements are defined in the sections below.
Click here to open the image in a new window.
When a Business Partner (BP) is a customer, the data model extends as shown below:
When a Business Partner (BP) is a supplier, the data model extends as shown below:
Business Partner versus Customer and Supplier Object Types
Through Business Partner (BP) roles, SAP allows the same BP record to act as a customer as well as a supplier.
Deciding to implement this same construct in STEP or not must be determined from a data governance point of view instead of a system setup reduction point of view.
Answer this question to determine the most beneficial construct: Is it required to share the management of data for the same legal entity or the same person across the buying and the selling part of the organization?
-
Yes - manage objects as business partners.
-
No - have distinct object types for customer and supplier, which makes it significantly simpler to manage all system setup, like attribute validity, workflows, privileges, and Web UI configuration.
The initial configuration includes distinct object types for customer (individual, organization, contact person) and supplier.
Contact Persons
Through Business Partner Roles, SAP supports that the same BP record may act as a Customer as well as a Contact Person. The considerations for reflecting this generalization in STEP are the same as for Customer and Supplier.
Since the most common approach is that Individual Customers and Contact Persons for an organization are managed separately, the initial configuration contains Contact Person as a separate object type.
Addresses, Emails, and Phone Numbers
SAP offers a general service for managing address, email, and phone number data for many purposes, including BPs. This makes it possible for SAP to optimize the functionality around managing this data.
Since STEP takes a different approach to making general capabilities around this data available in relation to different business objects, to achieve this reuse it is not necessary to model this data as a separate object type. Addresses, emails, and phone numbers are modeled as data containers on the BP object.
Ownership of an Address
In SAP, one address belongs to exactly one BP and is managed in context of one specific BP.
It makes sense to implement the same pattern in STEP, as it is the BP (or customer, supplier, and contact person) objects that are understood by users as the owners of the lifecycle of the relevant data.
Multiple Addresses and Usages
In SAP, one BP may have multiple addresses and each address may have multiple usages. The address itself is valid from a start date to an end date. In addition, each usage of the address has a validity period that must be within the validity period of the address itself.
In STEP, this is simplified, so that each address may have a validity period, but the usages of the address inherit the validity period of the address. A BP object contains Address data containers, which are referenced (ID=SAPUsage) to separate Address Usage (TB009) entities (ID=SAPBPAddressUsage).
Multiple Versions
In SAP, one address can exist in multiple versions. A version of an address is ultimately a language of the address. For example, the same address may exist in English and Chinese (for international trade in China) or in German and Italian (demographics of northern part of Italy).
In STEP, this is handled with a simpler model where each address is assigned a language, but the relationship between the two versions of the same address is not expressed. However, it is possible to logically identify which address should be used for a specific usage in a specific language at a given point in time if that is unique. When multiple addresses of the same usage are valid at a given point in time, it is also possible to identify the set of those that are in a specific language.
Addresses in Contact Person to Organization Relations
In SAP, as contact persons are related to organizations, as BP Relations, SAP makes it possible to associate the contact person to one of many addresses owned by that organization BP.
In STEP, this relation is expressed logically to the address usage so that if a specific reference type requires that the organization has an address of a specific usage, it is validated as the relationship is established.
The limitation is that if the organization has multiple valid addresses of the same usage, a specific address cannot be identified. It is recommended to avoid such complexities, as they are difficult for data owners to understand, and they also severely complicate integration with other systems that do not support such complexities. Instead, it is recommended to express such complexities as multiple related BP objects.
Emails and Phone Numbers and the Approve Trigger
In SAP, emails and phone numbers belong to addresses, meaning that two addresses of the same BP may have different emails and phone numbers.
In STEP, the relationship between emails and phone numbers and addresses are through usages since that simplifies the understanding of the data. The limitation is that when there are multiple addresses of the same usage, STEP expresses that the emails and phone numbers with the same usage belong to all of those addresses. As emails and phone numbers are commonly identifiers of a person and not an organization, this is not usually a problem. When it is necessary to express such complexities of multiple addresses of the same usage, it is recommended to do this as multiple BPs, as that also defines a clearer lifecycle and governance of such data.
The BP object includes data containers for emails (ID=EmailDataContainer) and phone numbers (ID=PhoneDataContainer). Each data container contains a reference (ID= SAPUsage) to an address usage object (ID=SAPBPAddressUsage) which indicates the usages of each email or phone number.
To simplify the data model transformations in the outbound BP and Relationship Link (RL) replication, the resolution of which address UUIDs of DC:Emails and DC:Phone that belong to which DC:Address, an approval trigger must resolve the logical relationships through Usages in to UUIDs and add those to the SAP Address IDs attribute on the DC:Emails and DC:Phone objects and afterward also maintain the SAP Address Source Record Relations.
For details on this approve trigger, refer to the Email and Phone Number Approve Trigger section in the SAP Publishing From STEP topic here.
Source Record Status
Source Record Status is a data container (ID= SAPBPSourceRecordStatusData).
-
Source Record ID - As inbound integrations or merges of existing golden records add source records to the source system relation, survivorship rules must also add those source record IDs as source record status objects, so that 'Is Survivor' and 'Replication Error Messages' can be managed.
SAP Address Source Record Relations
In SAP, address objects are assigned a UUID so they can be uniquely identified in integrations and so that they can be referenced in certain cases.
-
In one SAP system, two addresses must not have the same UUID.
-
In SAP, one address belongs to exactly one Business Partner.
In STEP, as multiple source records merge into one golden record or as one golden record is exported to multiple SAP systems, one address in STEP may represent multiple addresses in one or multiple SAP systems.
To identify existing addresses for update and reference, it is necessary to keep track of which UUID the address has per Source Record ID.
Inbound integrations and merges of existing golden records can add address, email, and phone objects and can associate incoming objects to existing objects. To ensure that future exports can consistently make updates to the right address objects, survivorship rules must add the UUID of the incoming address to the DC: SAP Address Source Record Relation objects.
For more information on survivorship rules, refer to the Survivorship of Addresses, Emails, and Phones section of the SAP Survivorship Rules topic here.
Business Partner Role
BP roles are used to classify BP entities in their specific role(s). The roles that are assigned indicate the business functions and transactions allowed for a BP.
A BP may be assigned more than one BP role. This indicates that the BP may be involved in different business transactions with different roles.
Examples of BP roles include:
-
Beneficiary
-
Business Partner (General)
-
Business Partner Customer
-
Business Partner Vendor
In STEP, the BP entity contains a BP Role data container (ID=SAPBPRoleData) that references (ID=SAPBPRoleDataRole) a BP Role object (ID=SAPBPRole).
Account Group
The Customer Account Groups and the Vendor Account Groups of a Business Partner are derived from the Business Partner entity. One Business Partner can have 0..1 Customer Account Group and 0..1 Vendor Account Group. For more information, refer to the Business Partner Role Constraints section of the SAP Business Partner Data Integrity Constraints topic here.
Company Code Data
In SAP, the company code is the central organizational unit of external accounting within the SAP System. A BP may be extended to one or more Company Codes.
In STEP, company codes are separate entity objects that are associated to a business partner using a sales organization referenced by a Customer Company Code Data Container (ID= SAPCustomerCompanyCodeData) for customers or using a purchasing organization referenced by a Supplier Company Code Data Container (ID= SAPSupplierCompanyCodeData).
When a BP is both a customer and a supplier, both data container types are valid and as an indirect / direct reference to a company code. In this case, some attributes may overlap between the two data container types.
Sales Area Data
In SAP, a Sales Area defines the Sales Organization and Distribution Channel that a Division uses to sell products. Therefore, Sales Areas are comprised of:
-
Distribution channel: Channel through which materials or services reach customers, for example, direct sales, retail, or wholesale. Distribution channels may be assigned to one or more sales organizations.
-
Division: Product groups can be defined for a wide-ranging spectrum of products. Customer-specific agreements (for example, partial deliveries, pricing, and terms of payment) are allowed for each division. Within a division you can carry out statistical analysis or set up separate marketing.
-
Sales organization: The organizational unit of a business that negotiates sales terms and distributes products. Sales organizations may be referenced to a company code.
In STEP, Sales Areas are referenced from the business partner object using a reference (ID= SAPCustomerSalesAreaDataSalesArea) from the Sales Area data container (ID= SAPCustomerSalesAreaData).
Purchase Organization Data
In SAP, a Purchase Organization (also called a 'purchasing organization') is responsible for the procurement of materials or services with negotiation terms and conditions from vendors. Purchase organizations are also responsible for pricing agreements with external vendors and can only be assigned to one Company Code.
In STEP, purchasing organizations (ID=SAPPurchasingOrganization) are referenced from a BP using a reference (ID= SAPSupplierPurchasingOrgDataPurchasingOrg) from the Purchase Organization Data Container (ID= SAPPurchaseOrganizationData).
Partner Functions
In SAP, Partner Functions are designations that describe the rights and responsibilities of each individual and/or organization BP with whom you conduct business transactions.
In STEP, partner functions are modeled as references between Sales Area- and Purchase Organization Data Containers to BPs.
Each Partner Function type is a dedicated reference type.
Examples of Partner Functions for Customer BPs include:
-
Sold-to Party
-
Ship-to Party
-
Bill-to Party
-
Payer
Partner functions for customer BPs are referenced from the Sales Area Data Container to a BP object.
Examples of Partner functions for supplier BPs include:
-
Ordering address
-
Invoice represented by
-
Goods supplier
-
Alternative Payee
Partner Functions for supplier BPs are referenced from the Purchase Organization Data Container to a BP object.
A BP may fulfill a certain Partner Function to itself. For example, a BP placing an order can be the same BP receiving the goods. Each partner function reference type may be referenced from a data container back to the same BP that owns the data container.
Bank Data
In SAP, for financial transactional purposes, BPs must maintain banking information. The bank account of a BP can be identified using country key of the bank, bank key, and the account number.
In STEP, bank details are modeled as a data container (ID= SAPBankDetailsData) on the BP object.
Business Partner Relationships
In SAP, BP Relationships are all managed through the same data model (SAP table BUT050, BUT051, etc.), regardless of the complexity of their cardinalities, constraints, etc. The complexity of cardinalities, constraints, etc., of a particular kind of BP relations are controlled through BP Relationship Categories (SAP Table TBZ9).
In STEP, each BP Relationship Category should be managed as its own reference type so that STEP’s built-in mechanism for managing cardinalities, constraints, privileges, UI components, etc., can be used.
For BP Relationships where time dependency must be managed, each BP relationship should be modeled as a separate data container type, so that valid-from and valid-to sales can be managed.
Examples of common BP Relationship Types are:
-
FB8P002 - Has the Invoicing Party
-
FBIJROOI - Has Contact Person
-
FBIJR002 - Has Activity Partner
-
FBIJROIO - Has the Employee
-
FBIJROII - Has the Employee Responsible
-
FBIJR013 - Is Replaced By
-
FBUR020 - Has Department
-
FBUR025 - Has Service Provider
-
FBIJRCOI - Is Shareholder Of
-
FCRMH04 - Has the Bill-To Party
-
FEWMOOI - Has the Dock Appointment Scheduling Planner
-
FFS0030 - Borrower Entity Member
-
FFSBOOI - Is A Shareholder Of
Business Partner Relation Category
In SAP, in some cases, the validity of Reference Source and Reference Target is more specific than what constitutes the Valid Object Types of a Reference Type in STEP. This may depend on the strategy chosen for Object Types of Business Partner Objects in STEP. Refer to the Business Partner versus Customer and Supplier Object Types section above.
To enable the validation of such constraints, BP Relationship Category Entities are created with the relevant configuration.
Refer to the Business Partner Relationship Constraints section in the SAP Business Partner Data Integrity Constraints topic here.
