sap business partner account assignment group

• Programming
• Admin & EIM
• BI & BW
• FICO & BPC
• CRM & Sales
• Introductions
• SAP PRESS Subscription

Understanding the SAP S/4HANA Business Partner Structure

A business partner represents the highest-level object in an SAP S/4HANA system.

A business partner can be a person, an organization, or a group. A business partner can be characterized by the following basic structure:

• Business partner categories
• Business partner roles

Let’s now discuss the structure of a business partner in SAP S/4HANA .

Business Partner Category 1

As already mentioned, the business partner represents the highest-level object in the entire structure and consists of categories, such as person, organization, or group. The business partner category determines which data can be used for a particular business transaction. It’s used to define general attributes such as name and address. A business partner is always assigned to exactly one business partner category (person, organization, or group). This assignment can’t be changed in the future, nor can the predefined SAP business partner categories be extended. The following categories are available to be chosen:

• Person: Natural person, private person.
• Organization: Legal entity or part of a legal entity, for example, company, department in a company, club, or association.
• Group: For example, marriage or shared apartment.

When a user creates a business partner using Transaction BP, it’s mandatory to first select the business partner category. Based on the selected business partner category, the system will only then provide the relevant fields for master data entry.

After the business partner has been created using Transaction BP, it’s easier for a user to recognize the different business partner categories in the master record by the different symbols when processing them again. The person category is represented by a stylized icon , the organization category is represented by a factory icon, and the group category is represented by an icon showing two heads.

Note: If there’s no business need to select a business partner category at all, then it can be hidden using the SAP standard system via BAdl BUPA_PARTNER_CATEGORY .

If the category Person is chosen while creating a business partner, then some of the basic fields that appear are as follows:

• Academic Title
• Address Overview
• Address Usage
• Employer Status
• Identification

If the category Organization is chosen while creating a business partner, then some of the basic fields that appear are as follows:

• Company Name
• Company Title
• Foundation Data

Business Partner Grouping

The business partner grouping reflects the logical and structured grouping that a company follows while dealing with its various internal and external stakeholders. The internal stakeholders are, for example, employees, while the external stakeholders can be customers and vendors. The business partner grouping defines the number range of the business partner. The account group defines the number range of the customer or vendor master record. Together, these two groups determine the numbers in which a business partner and a customer or a vendor are created.

Meanwhile, note the following for a business partner grouping :

• Similar to the SAP S/4HANA Finance account group for customers or for vendors
• Mandatory for each business partner
• Defined in Customizing
• Used to assign number ranges (internal/external) to business partners

Business Partner Role

A business partner role is used for the business classification of a business partner (see below). The characteristics and attributes within the business partner role result from the requirements that the respective business relationship places on the link between a business partner role and a company. The link can be characterized by several roles, and each of these different roles defines a very specific type of business relationship, such as customer, goods supplier, vendor, bill recipient, biller, and so on.

Let’s take a look at the process of processing a customer invoice, for example. Here, a company needs a role in which details of the payment terms can be stored, that is, FI customer. If the business partner is also a vendor, vendor-related data such as the delivery address will be required. This data will accordingly be maintained in the role MM vendor. If a business partner is both a customer (he buys goods from a company) and a vendor (he also delivers goods to a company), the customer master record will be stored in the role customer (SD), and the vendor master record in the role vendor (MM) for these business relationships. The link between the two roles (master records) is defined, as in SAP ERP , by entering the vendor number in the customer master record and the customer number in the vendor master record. A role can only be added and not removed, but the limited effectiveness can be achieved by using validity periods. Consider the following regarding business partner roles:

• Roles define the display and the data of a business partner.
• SAP S/4HANA provides predefined roles.
• Customer-specific roles can also be customized.
• The Business Data Toolset (BDT) is used to influence the GUI.

Note: The customization settings for the category Persons can be made via the menu path SAP IMG > Cross-Application Components > SAP Business Partner > Business Partner > Persons . Here, maintain entries for name components such as academic titles, name affixes and prefixes, and occupations. In addition, you can maintain entries on gender, marital status, and nationality that can then be used in the Identification tab of a business partner.

The customization settings for the category Organizations are made via the menu path SAP IMG > Cross-Application Components > SAP Business Partner > Business Partner > Organizations . Here, maintain entries for industry systems, industries, and the legal framework. The entries maintained here can then be used while creating a business partner of category Organization .

The settings for the category Groups are made via the menu path SAP IMG > Cross- Application Components > SAP Business Partner > Business Partner > Groups . Different group types can be defined here that can then be used while creating a business partner of category Group .

Learn more about how SAP S/4HANA simplifies the business partner functionality in this post .

Editor’s note : This post has been adapted from a section of the book Business Partners in SAP S/4HANA: The Comprehensive Guide to Customer-Vendor Integration by Jawad Akhtar.

Recommendation

The distinction between “customers” and “vendors” is now a relic of the past—jump into the future with this all-in-one guide to business partners in SAP S/4HANA! Learn how to set up business partners from start to finish for greenfield implementations. Or, if you’re transitioning from SAP ERP to SAP S/4HANA, walk through customer-vendor integration (CVI) with detailed instructions. With guidance on maintaining and validating business partner data, this is the only book on business partners you’ll ever need!

SAP PRESS is the world's leading SAP publisher, with books on ABAP, SAP S/4HANA, SAP CX, intelligent technologies, SAP Business Technology Platform, and more!

FICO Logistics

Latest Blog Posts

Transaction Codes, Tables, and Roles for Business Partners in SAP S/4HANA

Key Differences Between SAP ECC and SAP S/4HANA: A Detailed Comparison

The official sap press blog.

As the world’s leading SAP publisher, SAP PRESS’ goal is to create resources that will help you accelerate your SAP journey. The SAP PRESS Blog is designed to provide helpful, actionable information on a variety of SAP topics, from SAP ERP to SAP S/4HANA. Explore ABAP, FICO, SAP HANA, and more!

SAP Blog Topics

• Administration
• Business Intelligence

Blog curated by

• Legal Notes
• Privacy Policy
• Terms of Use
• Guest Posting

Assign Vendor Account Group to Business Partner Group in SAP

How to assign vendor account group to bp group in sap.

In this SAP Business Partner configuration steps, we are going to assign Business Partner group to vendor account groups . The assignment of vendor account groups and BP groups enables integration between BP and vendor accounts, so that vendor details will be updated at same time in both vendor master data and BP.

You can update whether the vendor master data can be created as externally or internally or with the same numbers.

You can assign vendor account groups to BP Groups in SAP by using the following navigation method

• Transaction code: SPRO
• SAP IMG Path: SAP Customizing Implementation Guide > Cross-Application Components > Master Data Synchronization > Customer/Vendor Integration > Business Partner Settings > Settings for Vendor Integration > Field Assignment for Vendor Integration > Assign Keys > Define Number Assignment for Direction Vendor to BP

Step 1: Execute transaction code “SPRO” -> Choose SAP Reference IMG > Follow the IMG menu path and execute IMG activity “Define Number Assignment for Direction Vendor to BP”.

Step 2: On change view “Number Assignment Direction Vendor to BP” overview, screen, click on new entries button

Step 3 : On new entries screen: Number Assignment for Direction Vendor to BP, update vendor account group and BP group in the fields and press enter to continue,

Click on the Save option and save the configured details in SAP.

Sap business partner grouping and account group Table in SAP

• TBC001 Table for Business Partner: Assignment of Account Groups and Grouping Table Type : TRANSP Package : FLBPC Module : CA-FS-BP
• TBD001 Table for Business Partner: Assignment of Account Groups and Grouping Table Type : TRANSP Package : FLBPD Module : CA-FS-BP
• TP13 Table for Business Partner: Partner Grouping (Target Group) Table Type : TRANSP Package : FS_BP_AL_FS_ATTRIBUTES Module : FS-BP
• TP13T Table for Business Partner: Name of Partner Grouping (Target Group) Table Type : TRANSP Package : FS_BP_AL_FS_ATTRIBUTES Module : FS-BP
• JBDKKON Table for SAP Banking: Business Partner Account Table Type : TRANSP Package : JBD Module : IS-B-DP
• /DSD/RP_DRVKTOKD Table for Define Account Group as Account Group for Driver Table Type : TRANSP Package : /DSD/RP Module : LE-DSD-RP
• CDBC_ACGRPBPT Table for Account Assignment Group Texts: Business Partner Table Type : TRANSP Package : CDB Module : CRM-MSA
• CRMC_ACGRPBP_T Table for Business Partner Account Assignment Group Table Type : TRANSP Package : CRM_ACCTGRPPROD Module : CRM-MD
• TJG38 Table for IS-M/SD: Texts for Business Partner Account Group Table Type : TRANSP Package : JMDGEN Module : IS-M-MD
• BP2000 Table for BP: Business Partner - Business Partner - Relationship Table Type : TRANSP Package : FBPAR Module : CA-FS-BP
• BUT_HIER_NODE_BP Table for Business Partner Hierarchy Group - Bus. Partner Assignment Table Type : TRANSP Package : BUPA_HIERARCHY Module : AP-MD-BP-GRH
• /SAPSLL/TPAGRA Table for Assignment of Partner Function to Partner Function Grouping Table Type : TRANSP Package : /SAPSLL/CORE_PARTNER Module : SLL
• CRMD_TM_IACT_BP Table for Business context information: one order and business partner Table Type : TRANSP Package : CRM_CIC_CLM_BO Module : CRM-CIC-CAM
• TB102_2 Table for SAP BP Field Grouping, Client-Dep. Field Group 1751 - 3500 Table Type : TRANSP Package : BUPA Module : AP-MD-BP
• TB102_3 Table for SAP BP Field Grouping, Client-Dep. Field Group 3501 - 5250 Table Type : TRANSP Package : BUPA Module : AP-MD-BP
• TB102_4 Table for SAP BP Field Grouping, Client-Dep. Field Group 5251 - 7000 Table Type : TRANSP Package : BUPA Module : AP-MD-BP
• CRMBP_MAP_BUGRP Table for Mapping of Business Partner Grouping Table Type : TRANSP Package : COM_BUPA Module : CRM-MD-BP
• TIVBPGRPCC Table for Business Partner Grouping per Company Code Table Type : TRANSP Package : RE_BP_BP Module : RE-FX-BP
• TPZ2 Table for Business Partner: Customizing BP Grouping Table Type : TRANSP Package : FBPAR Module : CA-FS-BP
• TPZ2T Table for Business Partner: Name of Grouping Table Type : TRANSP Package : FBPAR Module : CA-FS-BP
• CRMC_BUT_MAPPG1 Table for Assign Classification and Grouping R/3 Account Groups Table Type : TRANSP Package : CRM_BUPA_MAPPING Module : CRM-MD-BP-IF
• CRMKTOKD Table for Assign Classification and Grouping R/3 Account Groups Table Type : TRANSP Package : CCCI Module : LO-MD-BP-CM
• CRMC_ACC_MAP Table for Assignment of Account Assignment Group to Account Table Type : TRANSP Package : CRM_LEASING_SRM Module : CRM-LAM-BTX
• TZB27 Table for Assignment of G/L account to account group Table Type : TRANSP Package : FVVD_PAYMENT Module : FS-CML-AC-RPM
• BKK45 Table for Relationship: Current Account - Business Partner Table Type : TRANSP Package : FKBK Module : IS-B-BCA-MD
• CDBC_ACGRPBP Table for Account Assignment Groups: Business Partner Table Type : TRANSP Package : CDB Module : CRM-MSA
• CRMC_ACGRPBP Table for Account Assignment Groups for Business Partner Table Type : TRANSP Package : CRM_ACCTGRPPROD Module : CRM-MD
• TBCHAIN2 Table for Bank Chains per Business Partner Account Table Type : TRANSP Package : FIBI Module : FI-BL-MD-BK
• TBCHAIN21 Table for Bank chains per business partner account (allocation) Table Type : TRANSP Package : FIBI Module : FI-BL-MD-BK
• TJG37 Table for IS-M/SD: Business Partner Account Groups Table Type : TRANSP Package : JMDGEN Module : IS-M-MD
• TICL832 Table for Entity Table: G/L Account (Chart of Accts and Coll.Account) Table Type : TRANSP Package : ICL_LAE Module : FS-CM
• /SAPSLL/TPAGR Table for Legal and Logistics Services: Partner Function Grouping Table Type : TRANSP Package : /SAPSLL/CORE Module : SLL
• JGTMIGRATION Table for Status of Migration of IS-M Business Partner to SAP BP Table Type : TRANSP Package : JMDGEN Module : IS-M-MD
• SDEMO_BP Table for SAP NetWeaver Demo Model - Business Partner Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• SDEMO_BP_AD Table for SAP NetWeaver Demo Model - Business Partner Address Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• SDEMO_BP_EM Table for SAP NetWeaver Demo Model - Business Partner E-Mail Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• SDEMO_BP_PH Table for SAP NetWeaver Demo Model - Business Partner Telephone Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• SDEMO_BP_RR Table for SAP NetWeaver Demo Model - Business Partner Role Relation Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• SDEMO_BP_WA Table for SAP NetWeaver Demo Model - Business Partner Web Address Table Type : TRANSP Package : S_NWDEMO_MODEL_BUSINESS_P Module : BC-SRV-NWD
• TSAD3HR Table for Conversion of Address: HR - Format - SAP Business Partner Table Type : TRANSP Package : CRM_EMPLOYEE Module : CA-HR
• TPAKL Table for Assignment of Partner Function to Account Group Vendor Table Type : TRANSP Package : WLIF Module : CRM
• BC001 Table for Business Partner: Assign Vendor - Partner Table Type : TRANSP Package : CVI_MAPPING Module : AP-MD-BF-SYN
• BD001 Table for Business Partner: Assignment Customer - Partner Table Type : TRANSP Package : CVI_MAPPING Module : AP-MD-BF-SYN
• CRMM_BUT_FRG0070 Table for Business Partner Excluded Partner Functions List Table Type : TRANSP Package : CRM_BUPA_FRG0070 Module : CRM-MD-BP
• CRMM_BUT_FRG0071 Table for Business Partner Excluded Partner Functions Table Type : TRANSP Package : CRM_BUPA_FRG0070 Module : CRM-MD-BP
• CRMM_BUT_FRG0080 Table for Business Partner - Sales Area - Partner Function List Table Type : TRANSP Package : CRM_BUPA_FRG0080 Module : CRM-MD-BP
• CRMM_BUT_FRG0081 Table for Business Partner - Sales Area - Partner Function Table Type : TRANSP Package : CRM_BUPA_FRG0080 Module : CRM-MD-BP
• CRM_LRP_PF_RPL Table for Partner Function Category of Business Partner Table Type : TRANSP Package : CRM_LRP_CUSTOMIZING Module : CRM-RPL-SRV
• JSDTPAER Table for Business Partner: Functions in Partner Determination Proced. Table Type : POOL Package : JSDI Module : IS-M
• SMOFRG071 Table for Business Partner Excluded Partner Functions Table Type : TRANSP Package : SMO3 Module : CRM-MSA
• SMOPPRBP Table for Partner Product Range: Business Partner Assignments (CDB) Table Type : TRANSP Package : CDB Module : CRM-MSA
• PPARGB Table Data element for Trading Partner Business Area of the Business Partner
• BU_RLTP2 Table Data element for Business partner role (business partner 2)
• SMO_SFAZ06 Table Data element for SFA Key of IL. Business Partner - Business Partner
• SUBSCR_GP_COV_PS Table Data element for Business Partner Overview: Number Business Partner Subscreen
• JGBP_PARTNER_TEMPLATE Table Data element for IS-M: Business Partner Template Business Partner
• /TDAG/RCSE_EP_LOA_EXT_PUR_BP Table Data element for Purchasing Business Partner (Business Partner)
• XPOSVP_KK Table Data element for Display Valuation per Contract Account and Business Partner
• /SAPSLL/PGCUS Table Data element for Check for Business Partner Use in Partner Group
• /SAPSLL/PGCCL Table Data element for Check Business Partner Classification in Partner Group
• JINSERTGROUP Table Data element for Business Partner - Insert Group (Sales and Distribution)
• CRM_ACCTGRPBP Table Data element for Business Partner Account Assignment Group
• TOGRU Table Data element for Tolerance group for the business partner/G/L account

Sap business partner grouping and account group related terms

Definitions.

SAP is the short form of Systems, Applications & Products in Data Processing. It is one of the largest business process related software. This software focused on business processes on ERP & CRM.

Like most other software, SAP also using database tables to store the data. In SAP thousands of tables are there to store different data. A table contains several fields and some of the fields will be key fields.

Popular Table Searches

Latest table searches.

• TBD001 - Business Partner: Assignment of Account Groups and Grouping

SAP Table TBD001

Business partner: assignment of account groups and grouping.

TBD001 (Business Partner: Assignment of Account Groups and Grouping) is a standard table in SAP R\3 ERP systems. Below you can find the technical details of the fields that make up this table. Key fields are marked in blue.

Additionally we provide an overview of foreign key relationships, if any, that link TBD001 to other SAP tables.

TBD001 table fields

Tbd001 foreign key relationships.

Exploring the Business Partner, Retail Sites, and Article Groupings

After completing this lesson, you will be able to:

• Explore the business partner, retail sites and article groupings
• Explain the use of merchandise category and article hierarchies
• Distinguish between the site categories distribution center and store

Customer, Supplier, and Site Master in SAP Retail

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.

There is also the concept of department stores and shops. The department store logically groups the shops defined for the department store. With the department store/shop concept you can map shop-in-shop, or shopping mall scenarios.

Like regular stores, also the department stores and shops are created as sites of site category A - Store. The additional identifier store category distinguishes a department store (store category 1) from a shop (store category 2).

Additional info can be found on http://help.sap.com.

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.

Merchandise Category Hierarchy

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.

Article Hierarchy

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".

There can only be one active distribution-chain independent hierarchy, or one active hierarchy for each distribution chain. Once you have activated an article hierarchy, it always remains active. For example in seasonal fashion retailing, new, planned article hierarchies are used to prepare the AH structure for the next season. These new segments are then copied into the active hierarchy. Furthermore, the active hierarchy should be re-organized regularly, that is, obsolete/outdated AH nodes,for example from previous seasons, should be removed from the AH to keep this structure up-to-date.

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.

Log in to track your progress & complete quizzes