Exploring the Business Partner, Retail Sites, and Article Groupings

The SAP Business Partner (BP) concept is used for maintaining the customer and supplier master in the SAP S/4HANA system. In general, there are three SAP BP categories:

• (Natural) Person: a private individual, like a consumer
• Group: a group of individuals, like a family, or a couple
• Organization: a legal entity, or a part of a legal entity, like a company, or a department of a company

The business partner category determines which specific, additional fields are available for data entry. For example for individuals, there are fields for name components (for example, academic titles), marital statuses, occupations. For organizations, you can define various industry systems and industries, legal forms and entities, and so on.

The commercial business partners (customers and suppliers) in a retailer's system are of category Organization.

The transaction BP - Edit Business Partner is the central transaction to create, edit, and display master data for any kind of business partner including suppliers, and customers.

The data in the customer master record is subdivided into three areas:

• General Business Partner (BP Role 000000): This is the default, standard entry role in the BP transaction. It allows you to maintain data, which is valid client-wide. Examples of this include the address, additional addresses, and bank details of the customer.
• CVI: FI Customer (BP Role FLCU00) covers the Accounting data: For example, this includes the number of the reconciliation account and the payment methods for the automatic payment transactions. Financial accounting data is entered at the company code level.
• CVI: Customer (BP Role FLCU01) covers the Sales and Distribution data: For example, this includes the customer data for orders, shipping, and billing. This data is maintained for the relevant sales area(s).

A customer is not only a business partner in sales, but also a debit-side business partner, for financial accounting purposes. For this reason, the customer master record is used by both the sales and the financial accounting department. Customers are classified as debtors in Financial Accounting.

Every site has an internal customer master record.

The data in the supplier master record is also subdivided into three areas:

• General Business Partner (BP Role 000000): As for the customer, this includes the address, additional addresses and bank details of the creditor. The data is valid client-wide.

• CVI: FI Vendor (BP Role FLVN00) covers the Accounting data: This includes, for example, the number of the reconciliation account and the payment methods for the automatic payment transactions. Financial accounting data is entered at the company code level.

• CVI: Vendor (BP Role FLVN01) covers the Purchasing Data: This includes the purchase order currency, incoterms, and various control data of the supplier. This data is maintained for the relevant purchasing organization(s). You can also enter alternative data that is only valid for specific sites or for supplier sub-ranges.

A supplier master record may be blocked, if, for example, the quality of the products delivered by the supplier does not meet quality standards. You can also block a supplier from providing a particular product in the relevant source list.

A site is an organizational unit that is used to prove evidence of merchandise stored in distribution centers or stores for inventory management and to execute the related business processes, such as goods receipt, physical inventory, and goods issue.

Each site belongs to a company code and represents an organizational unit that performs requirements planning and inventory management. A site is also a customer as, from a central point of view, sales functions, such as deliveries, including returns processes, are carried out for it. For this reason, a site is always also created including a customer master record, that is, a business partner (BP) in SAP Retail. Therefore, the business partner maintenance is integrated in the site master. It is possible to assign an already existing business partner when creating a new site, but it is not possible to change the BP assignment subsequently. The site address is maintained in the business partner.

Two categories of sites are used in SAP Retail:

• Stores (site category: A) present merchandise on the sales floor and sell it to consumers

• Distribution centers (site category: B) carry stocks to provide merchandise for other sites or customers

The distribution chain category describes the logistical function of a distribution chain. In SAP Retail, a distinction is made between consumer/retail distribution chains (for stores), and distribution chains that are used by distribution centers or in wholesale.

A distribution center (DC) also functions as a supplier (internally), as it provides other sites with merchandise. A distribution center delivers merchandise to stores belonging to one or more distribution chains.

Each store is organizationally assigned to a main store distribution chain, but it can receive merchandise from distribution centers using different DC distribution chains.

A distribution center (DC) can be supplied with merchandise by a higher-level DC. For example, a local warehouse receives goods from the regional warehouse. A DC can also receive merchandise from stores or customers in returns processes. This means that the distribution center is, in effect, an internal customer, and a customer master record for the DC must exist in the system. It is an integral part of the site master for the distribution center.

A distribution center is also an internal supplier as it supplies other sites with merchandise. For this reason, a supplier master record is created in the system, especially for cross company code scenarios. When, for example, details such as payment terms and condition control are picked up by the system from the DC's supplier view when creating the resp. purchase order documents. The supplier master record is an integral part of the site master for the distribution center.

Customers who are supplied with merchandise from a DC can be internal (for example, your stores or other distribution centers), or can be external (for example wholesale customers). In any case, customer master records must be created in the system: these are individual customer master records for external customers, and internal customer master records for sites.

The internal customer number of a site is also used for generating the local assortment of the site.

Each article in the company is assigned to one merchandise category. Merchandise categories are grouped in merchandise category hierarchy levels. These, in turn, are assigned to the resp. next higher hierarchy level each.

This forms a merchandise category hierarchy, which is a mandatory function in the SAP Retail system. This structure simplifies monitoring and control within the company, as well as data maintenance (for example, conditions in retail pricing). The merchandise category hierarchy structure is based on the SAP classification system, and is of class type 026.

In many functions, merchandise categories and hierarchy levels serve as selection criteria, and typically form the basis for reports and analyzes. The merchandise category hierarchy can also be used to pass on descriptive, that is informative, characteristics from higher to lower levels. The structure is usually transported to the relevant data warehouse, where reports and analyzes are executed.

You can create an own merchandise category reference article for each merchandise category. The merchandise category reference article is a dummy article master record, and is used to maintain default values. It serves as a copy template when creating new retail article master records. Moreover, you can alternatively also assign an existing merchandise category reference article to several other merchandise categories.

You can also create and assign a merchandise category value-only article for each merchandise category. This enables you to use inventory management on a value basis at merchandise category level. The value-only article for your merchandise category can be used at POS for transactions at merchandise category level. For example, this could be used for remainders of one-time promotional merchandise, which should be sold off after the promotion ended. These articles are posted to the value-only article to clear their individual stocks, and are then sold off "anonymously", that is just by capturing their retail price at POS. The value-only article is linked to a merchandise category key of the POS system.

A merchandise category hierarchy value-only article can also be defined for each hierarchy level. This enables you to use inventory management on a value basis at merchandise category hierarchy level.

Characteristics can be assigned to merchandise categories, and to hierarchy levels, or to characteristics profiles, which can be assigned to merchandise categories. The lower hierarchy levels inherit the characteristics that are assigned to the hierarchy levels above. This is called Characteristic inheritance.

The characteristics and their values are then available for the articles (remember, each article is created for a merchandise category. You can assign a characteristic value to the article for information purposes, that is, the characteristic value assignments can be used in analyzes and reports.

Merchandise categories can be assigned to sites in order to maintain merchandise-category specific settings for various functions and processes. For example, there are settings which are relevant for retail pricing, such as the assignment of a price list, or for competitor pricing. In addition, store order/replenishment control data can be maintained at site/merchandise category level. Furthermore, valuation- and inventory-management settings can be made in this view.

It is also possible to define the supplying site(s) at site/merchandise category level. This then overrules the supplying site(s) defined at the general site level. For example, a food retailer operates a special distribution center for perishables, whereas all other merchandise is supplied from the regular dry goods DC. In this case, the perishables DC is assigned as supplying site to all perishables merchandise categories (such as Loose Fruit, Packaged Lettuce, and so on), whereas the other, non-perishables merchandise categories have no specific supplying site assignment. With that, automatically the supplying site assigned at the general site level is used.

The article hierarchy (AH) is an additional option for grouping articles. It could be used in assortment planning processes, as an alternative to planning along the merchandise category hierarchy. Therefore, the AH can be transported to the data warehouse, or SAP Customer Activity Repository for reporting and planning. It is also possible to (optionally) activate scheduling for the AH to better support seasonal merchandise processes. This means each article hierarchy node then has a validity period.

In the figure, Article Hierarchy — Attributes, the descriptions of the article hierarchy levels are Enterprise, Department, Theme, Area. These are just examples, as these descriptions can be defined customer-specific in Customizing.

While the merchandise category hierarchy tends to be based on the material attributes of the articles (food/non-food, perishables (fruit and vegetables), frozen foods, and so on), the article hierarchy can take sales aspects into consideration, such as brands, how merchandise is presented on the sales floor, forms of packaging, and so on. Article hierarchies comprise a number of structure levels. There are no restrictions to the depth of an article hierarchy. However, experience has shown that a structure depth of up to ten levels is advisable, according to category management standards.

For example, the article hierarchy can be structured in such a way that it corresponds to the presentation of the merchandise in the shop - for, example by shelf (section), or by sales floor areas. The article hierarchy can also be used to further subdivide the merchandise categories. For example, merchandise category dairy products: in the article hierarchy, a high level node may represent the dairy products merchandise category, and the levels underneath further subdivide the products (for instance, into three categories representing the fat content: 3.5 %, 1.5 %, and 0.1 %). Each of these levels could be again divided further into bottles and Tetra Pak. Because the system allows you to plan your assortments, and to do the reporting based on the article hierarchy, you could then compare the sales figures for bottles or Tetra Pak per fat content within the dairy products.

An article hierarchy can be asymmetrical.

An article hierarchy is always created with the status "Planned". When planning is complete for the hierarchy, you can activate it. After certain checks have been run, the status of the hierarchy is set to "Active".

Typically, the high-level nodes of an article hierarchy are defined as category level, in our example, this is the Department level. The category is the root node of the corresponding CDT (consumer decision tree). For each category node, there has to be at least one assortment, and the category is the highest update-relevant node in category management in the SAP BW/4HANA. With multiple article assignment active, the category level is used for the shop assignment, and within one category (and thus, within one shop), an article can only occur once.