When designing the Business Partner model in STEP, BP extensions such as Company Code, Sales Area, and Purchasing Organization can be represented in two main ways:
-
As data containers within the BP object
-
As separate entity objects linked from the BP
The following sections outline the advantages and disadvantages of each approach.
Data containers within the Business Partner
Advantages
-
Simplifies the data model by keeping all related data in one object, reducing complexity in reference management
-
Simplifies event processing of BP data by consolidating events on the BP level
-
Works well with STEP’s Match & Merge framework, allowing holistic matching & merging across both BP level and data container level attributes
-
Ideal for coexistence-style implementations where integration and consolidation of external data from source systems is a priority
Disadvantages
-
Limited access control - STEP does not allow permissions at the individual data container instance level
-
Workflow separation is restricted - it is difficult to route approvals or tasks only to Finance, Sales, or Logistics without involving the entire BP
In short, modeling these domains as data containers within the Business Partner provides a streamlined solution ideal for harmonized matching and centralized governance, but may not be appropriate in scenarios requiring high administrative segmentation, workflow independence, or granular user control.
Company Code Data Container
In STEP, company codes may be modeled as separate entity objects that are associated with a Business Partner via a data container and references. These containers store attributes relevant to the Business Partner’s relationship with a specific company code, such as reconciliation accounts and payment terms.
For Customers, this data is captured in the Customer Company Code Data Container (ID=SAPCustomerCompanyCodeData), and for suppliers, in the 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 such instances, each role-specific company code would need to be mapped to their respective SAP tables within an outbound integration, i.e., FLCU00 for Customer Company Code data and FLVN00 for Supplier Company Code data. Additionally, attributes for each of the two data container types will also need to be mapped to their respective tables.
Sales Area data container
Sales Areas are referenced from the Business Partner object using a reference (ID= SAPCustomerSalesAreaDataSalesArea) from the Sales Area data container (ID= SAPCustomerSalesAreaData).
Purchasing Organization data container
In STEP, purchasing organizations (ID=SAPPurchasingOrganization) are referenced from a BP using a reference (ID= SAPSupplierPurchasingOrgDataPurchasingOrg) from the Purchasing Organization data container (ID= SAPPurchaseOrganizationData).
Separate Entity Objects linked from the Business Partner
An alternate approach is to model BP extension data as separate entity objects (rather than data container objects) that live between the BP object and the BP extension object (i.e., sales area, company code, purchasing organization). These data entity objects serve the same purpose as they contain the attribution describing the relationship of the BP with each BP extension.
As an example, the BP object would own the reference to a company code data entity object, which owns the reference to the company code extension (refer to Company Code data entity section below for an illustration). In STEP, these three objects reside under separate root nodes in the ‘Tree’ tab.
This approach allows for privileges that are defined for the company code entity to be inherited to the company code data entity, providing more granular access control. This functionality is especially relevant when large corporations require strict privilege control for their users across multiple company codes, sales areas, and/or purchasing organizations.
Advantages
-
Enables fine-grained access control, allowing visibility and editing rights to be limited by sales area, company code, or purchasing organization
-
Supports independent workflows and approvals for each entity
-
Best suited for centralized solution implementations
Disadvantages
-
Increases complexity, as additional orchestration is required to manage creation and relationships between entities
-
Match & Merge does not support this model since STEP’s matching logic is optimized for single-object models
-
Requires extra validation rules to maintain consistency across separate entities
-
Event handling is more complex as consolidation of events to the BP level must be handled with business rules in the event processor
-
It is not possible for Faceted Search to find BPs by references from the BP extensions
Despite these trade-offs, this modeling style is often preferred when access control, modular workflows, and organizational separation of duties are key priorities.
Company Code data entity
In STEP, company codes may be modeled as separate entity objects that are associated with a Business Partner via a company code data entity and references. These objects capture financial and accounting attributes that apply to a specific relationship between a Business Partner and a Company Code.
For Customers, this data is captured in the Customer Company Code Data (ID=SAPCustomerCompanyCodeData); and for suppliers, in the Supplier Company Code Data (ID= SAPSupplierCompanyCodeData).
When a BP is both a Customer and a Supplier, both data entity 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 entity
Sales Areas are referenced from the Business Partner object using a reference (ID= SAPCustomerSalesAreaDataSalesArea) from the Sales Area data entity (ID= SAPCustomerSalesAreaData).
Purchasing Organization data container
In STEP, Purchasing Organizations (ID=SAPPurchasingOrganization) are referenced from a BP using a reference (ID= SAPSupplierPurchasingOrgDataPurchasingOrg) from the Purchasing Organization data entity (ID= SAPPurchaseOrganizationData).
