In Pricefx, multiple business units, sales organizations (Sales Orgs), operational organizations (OpCos) or simply organizations in different countries can be configured to be held in the same partition. In this article, we will use the term “business units” which represents any of those. This can be tricky from the entitlements point of view, if the users should not see data from other business units. This article can help you with such a configuration and its implementation.

First, you need to decide whether to implement single or multiple partition.

Master Data

Product Master and Customer Master

Product master and customer master data are shared within the partition, so this data needs to be shared across the business units. The product master data and customer master data are used in product or customer master pickers used in Price Lists, Live Price Grids, Quotes, Agreements/Promotions, Rebates and custom Product or Customer input parameters, e.g. in Dashboards.

Since the data are shared, the prerequisite is that all the data are standardized across the business units so that each SKU resp. customerId represents the same product resp. customer in all business units. This assumes that the organizations have harmonized their product and customer masters. If this is not achieved, it needs to be ensured that at least the SKU/customerId numeric ranges are distinct between the business units. The last option is to use convention for a combined key as a virtual SKU or customerId as a concatenation of “<business unit>-<local sku>”, e.g. GB-1000124. But this solution leads to various limitations: the customer has to be aware of this convention, all the integrations (both inbound and outbound) need to perform this transformation and the same goes for all data uploaded from Excel by the users.

Product Picker and Customer Picker

If the SKU is shared across business units, but not every SKU is sold in every business unit, a PX or a name “LocalProduct” with the business key [sku, businessUnit] can be created. The PX or CX data are then typically marked with the Allow search flag and can be used for filtering in product picker or customer picker. The value will not get displayed, but the filtering can be done.

Which records should be displayed to the user can be defined on the user level. See the User Setup section below.

Company Parameters, Product Extensions, Customer Extensions

If the users should not view or edit data of other business units, the only way to achieve this is to create an instance of a given table (e.g. PP “TargetMargin”) for each business unit and use a naming convention “<table name>_<business unit>”, e.g. PP “TargetMargin_GB”. The User Group Edit or User Group View is the set up to a local user group.

In such a case, it is strictly recommended to use exactly the same source code at all places when working with such table, so you can always safely refactor the name in the future. You may consider creating a function that resolves a table name for a given business unit or function that retrieves the data from such a table.

If the data in the table is populated by the integration, the integration has to perform the split of the data into corresponding tables. If the users do not need the view or edit access, the data can be kept within a single table with attribute1 configured as a business unit.

Data Sources and Datamarts

The recommendation is pretty much the same as for Company Parameters or Product Extensions, but here is a difference: Data Sources and Datamarts support data entitlements, so you may utilize that and keep data from all business units in the same while providing row-level access only to records that belong to a certain business unit (business unit to be part of the primary key).

Price Lists, Live Price Grids, Quotes, Agreements/Promotions, Rebate Agreements

When the users create Price Lists, Quotes, Agreements/Promotions, Rebate Agreements which should not be visible/editable by the other business units, a user group for a business unit is to be created and each user is to be assigned Default user group edit and Default user group view. For details see the next section.

User Setup

Users can be assigned Default user group edit and Default user group view. The value set in these fields will determine the User group edit and User group view fields when a Price List, Live Price Grid, Quote, Agreement/Promotion or Rebate Agreement is created.

Additionally, the Product filter, Customer filter and Seller filter fields can be configured to set up filters for the product, customer or seller picker.

Optionally, you can also utilize and configure additionalInfo3 (Extra Info 3) of the user to be a business unit.

Logics

It is strongly recommended to use a single core logic applicable for all business units, if applicable. If that is not possible, make them applicable at least for a cluster of business units (e.g. US, EMEA, APAC).

If there is calculation functionality that should be enabled only for some business unit(s), this feature flag configuration can be achieved by setting up a PP table e.g. “General Setup”, “Business Units”, “SalesOrg” etc. maintained by the system admin user where the field to turn certain feature on or off can be configured.

Sales Insights Accelerator Package

Sales Insights Package currently has no built-in support for multiple business units. The only way, at the moment, is to create a custom version of Sales Insights.