Product Information
SAP Retail for SAP (non-Retail) Experts
SAP (non-Retail) experts often encounter skepticism when joining an SAP Retail project.
If that’s you, then you’re likely thinking: Hey, I’m an expert in FI, IM, MM, SD, or whatever. How much different could “Retail” be?
You got this, right? Well, maybe. Maybe not.
This quick read is first aid for mitigating healthy skepticism.
And it applies for both SAP S/4HANA Retail for Merchandise Management and SAP S/4HANA for Fashion and Vertical Business. I use SAP Retail as shorthand to mean both applications. Activating either Business Function brings foundational master data differences into play, and that’s where the skepticism begins.
Use the right words, even if you can’t find them
If you’re an old hand at SAP, but new to Retail, then some new words should command your attention:
| SAP Standard | SAP Retail / Fashion | Future? |
| Material Groups | Merchandise Category | |
| Material Master | Article Master | Product |
| Plant | Site Master | Location |
These business objects aren’t named differently in SAP Retail simply to align with industry-specific jargon. No, each are named differently to convey that substantial differences exist between these SAP Retail business objects and their Standard counterparts. You care about this because if the master data has changed, then business processes that consume said master data have likewise changed.
With S/4HANA, SAP has technically reduced differences between Standard and SAP Retail. That’s very nice. But “simplification” and changing lexicon — not yet fully harmonized — have added a bit of confusion. You need to be aware of this history, and aware of what you’ll see on screens across SAP GUI, Web Dynpro, and Fiori applications.
In ECC 6.0, so-called “Retail Text” was applied to SAP Retail systems. With more or less consistency, it was obvious that you were dealing with a Retail system because on-screen labels displayed Merchandise Category, Article, and Site. We felt very special, indeed! With S/4HANA, Retail Text is no longer available. And it won’t become available. It makes enterprise-wide sense to harmonize business objects. But the words Material, Article, and Product were — and are still — sprinkled across SAP applications, and in many cases different words are used to designate the same “thing.” The consequence is that in S/4HANA, some Retail-specific transaction codes display Retail terminology — Site, Store, Article, Merchandise Category — but most transactions do not.
No matter the names you encounter, the functionalities they represent in SAP Retail differ from SAP Standard.
Material Group versus Merchandise Category
In SAP R/3 standard, Material Groups are defined in Customizing using this path: Logistics – General > Material Master > Settings for Key Fields > Define Material Groups. That configuration point — maintenance of table T023 — is never to be touched in an SAP Retail system.
Creating or changing Material Groups via Customizing will render them useless in SAP Retail. You’ll still see the “Material Group” in configuration, but the Merchandise Category is also represented in Classification (Table KLAH, Class Type 026). Standard transactions enable maintenance of Merchandise Categories (using both T023 and KLAH) and related features purely as master data.
Because Merchandise Category is a control parameter in many Retail-specific processes, it’s mandatory to assign Articles to a Merchandise Category at the time of Article creation.
Reference Articles, also assigned to Merchandise Categories, serve importantly as templates for creating new Article Master records.
While both Material Group and Merchandise Category records are defined in database table T023, this database table has been enhanced with Retail-specific attributes. For example, Merchandise Category maintenance includes functionality to assign additional Retail-specific attributes (Characteristics). Articles assigned to a Merchandise Category inherit characteristics that are assigned to the Merchandise Category.
Material Master versus Article Master
The terms “Material” and “Article” are used to differentiate between master data records created using transactions MM01, MM02, and MM03 (Materials), and master data records created using transactions MM41, MM42, and MM43 in SAP Retail (Articles).
An SAP Retail Article Master is fundamentally more than a Material Master. While Materials can still be maintained in SAP Retail, the majority of applications within SAP Retail can only be used with Articles and not with Materials.
In SAP Retail, Articles are assigned to Article Categories at the time of creation, and the designation cannot be changed thereafter. You can distinguish Materials from Articles by examining field ATTYP (Material Category) in database table MARA.
The counterpart of a Material is a single Article.
In addition you can create Generic Articles and corresponding Variants. This is a maintenance-saving concept for representing a group of Articles that vary mainly by a few attributes. The classic example is a Shirt (Generic) with Articles that vary by Color and Size variants). In SAP Retail, you can create the Generic shirt Article, choose the Color and Size combinations, and the system generates the Variant Articles accordingly.
Other Article Categories are so-called structured Articles. Sales Sets, Displays, and Prepacks are made up of components (i.e. single Articles). Behind the scenes, structured Articles use Bill of Materials (BOMs). But enhancements to standard logistics applications offer special handling for structured Articles.
Article Master is also unique in that reference master data and Retail business processes are used to massively create Article Master data. These concepts dramatically differ from creating a Material Master, which has limited capability to provide default values from the ERP Vendor Master or from customizing.
In SAP Retail, a comprehensive master data strategy, orchestration of master data, and technical functionality support creating new Article Masters from Reference Articles, which serve as templates. This minimizes effort in creating data. Extending Articles to Sites — extending Materials to Plants — is an automated business process in SAP Retail.
Configuration of Article Master types (Material Types) also allows maintenance of views that are typical for Materials. For example, fields in the context of production processes.
Plant versus Site (Store / Distribution Center)
Whereas, in SAP R/3 standard, Plants are clearly defined in Customizing, in SAP Retail specific transactions are available for the maintenance of Sites and corresponding features as mater data.
Anyone can be forgiven for thinking of a Site Master as only master data, given its name. But the metamorphosis of a standard Plant, as pure configuration, to a Retail Site Master, now as pure master data, remains incomplete, even in S/4HANA.
You’ll hear time and time again that SAP Retail Site Master is an object to be treated like no other.
That’s true because Site Master is one business object comprised of many technical objects, including customizing.
There are two categories of site in SAP Retail: Stores, which offer goods to consumers, and Distribution Centers, which supply the stores. You can distinguish Plants from Sites by field VLFKZ (Plant category; Site Category) in table T001W. This field is initial for a Plant. In SAP Retail it has value of A when the Site is a Store and B when the Site is a Distribution Center.
Both a Plant – defined in customizing – and a Site Master are represented by a set of database tables. Most of them are common for a Plant and a Site Master. But a Site Master uses additional database tables to store data specific for SAP Retail functionality.
There are two main, interdependent reasons why the organizational unit “Plant” was enhanced in SAP Retail to appear as master data. First, additional attributes for Site Master are required to control Retail-specific business processes. For example, the automatic listing of new Articles based on Merchandise Categories assigned to a Site, or for the control of the data exchange using the POS Interface.
In addition, the large number of Stores in a typical retail company required quick and flexible maintenance. This couldn’t be achieved only with customizing, so a Site Master appears as master data, which can be maintained with specific transaction codes.
Also, the Site master maintenance transaction includes features for reference handling to facilitate Site creation. In the Site profile that you have to specify when you create a new Site, you can define a reference Site, or you can specify a reference Site on the Site Create: Initial Screen. In this way, during Site creation, data from underlying customizing tables is copied from the reference Site to the new Site.
To enable certain business processes such as stock transfers, in SAP standard you establish a relationship between a Plant and a Customer and Vendor master record. You can assign a Customer to a Plant in Customizing. Plant and Customer can have different addresses. Plant and Vendor can have different addresses. In contrast, SAP Retail provides integrated maintenance of associated Business Partner, ERP Customer, and ERP Vendor.
A Site Master always requires a Customer Master; whether a Vendor Master is associated with a Site is defined by a Site profile. The Site and its associated Business Partner, Customer, and Vendor have a unique address. SAP Retail regards the Site and all components as a single entity from a business point of view.
Because the Site Master and its associated master data records are regarded as a single business entity, the Best Practice for Site Numbers is to make Site number, Business Partner number, Customer number, Vendor number, and Profit Center number (for Materials / Articles) the same number for a given site.
Distribution Chains, not Sales Areas, and not Division
A distribution chain is made up of a sales organization and a distribution channel. The purpose of a distribution chain is to structure sales within a Retail company. Divisions are not used for any functions developed specifically for SAP Retail. However, a single dummy division is provided as a technical necessity.
Customer relationships are important for controlling logistics processes. You maintain these according to sales area. A sales area is a combination of a sales organization, distribution channel, and division. Unlike in industrial companies, there is generally no differentiation made in SAP Retail between product-related divisions, therefore the distribution chain is definitive for the customer relationship.
Articles are assigned uniquely (client-wide) to one division. The significance of the distribution chain for logistics and price determination is also manifest in integrated article maintenance. In the distribution chain-related sales view you maintain data that is relevant for delivery, for example, the sales unit. For price determination, you maintain the actual sales price and other condition parameters but you also need to enter certain control data, such as the price fixing flag or the competition characterization of the article.
More Homework:
- Merchandise Category Hierarchy: WHY (Business View) offers a fuller view of how Merchandise Category and Merchandise Category Hierarchy are used in SAP Retail.
- The Essence of SAP Retail Master Data explains how master data is uniquely orchestrated in SAP Retail to massively create master data.
- The Secret of SAP Retail Master Data (video) explains the SAP Retail concept of Reference Handling, which enables maintaining large volumes of master data with least effort.
Hello Paul,
In case you need plant I/C Service Invoicing flows, in S/4 Retail ;
Would you advise to stick with normal plants or create S/4 Retail plant?
If you made clear what are the advantages of using a retail plant,
Can you confirm best practise? Is it possible that both types of plants get mixed?
Best regards,
Victor Sauvageot
Hello Victor:
The main difference is that a standard plant cannot be used in any Retail business processes. For this reason, we always create Site Masters (retail plants) and not standard plants in a Retail system. I prefer one business object in the system to represent Location (thus one business object to teach and support; one common business process and technical process).
In the case of a Retail system, I think it's incorrect to consider this question from the point of view: "what are the advantages of using a retail plant?" I would call the use of only Retail Sites a best practice, and say that it should be the default position. The question should be considered from the point of view: "what specific technical reason prevents using a Retail Site master in my business process?"
With that said, it's true that a standard plant can exist in the system and can be used in non-Retail business processes. It's possible, but unlikely, that a good technical reason exists to use a standard Plant. If you have one then please tell me 🙂 And later you may change your mind about that, and want the plant to be a Retail Site. Even that is possible. I've written a blog to demonstrate how to Convert Plant to Retail Site Master.
Hello Paul,
First of all big thanks for your quick answer.
Indeed, I decided with the team to create plants as retail plant mostly for having to deal with one single object (transports of plants via DRFOUT as retail and not mix with transport orders where conflicts could occur on some retail plant settings deletions for example)
However, since you ask me why there would be a reason to create it as a standard plant
there is a point related to business partners i would like to develop.
When we create a plant for I/C flow purposes (Please note i am working on this project as FI/CO consultant and that we are talking about setting up invoices between holdings with no need on having any stock materials data on them /logistics ) => Debit note to customer Company 2 with plant from company 1 => Invoice + RD04 => Supplier invoice in company 2 with supplier Company 1.
In standard industry SAP, the BP which represent the company gets linked to the plant after the BP is created.
In retail SAP, the BP must be created or affected when you create the plant. Which is totally normal as a retail site needs a particular adress and data from a logistic point of view and from what it is by definition : a distribution plateform, or a retail site.
I noticed there two options :
I truely believe, that in the case you still decide to create plants as retail plants to facilitate the transports, like you said, that solution 2 must be taken (and only deal with one BP there and affect the plant to the company BP in the WB01 process)
please comment.
Best regards,
Victor
Hi Victor:
I've never seen a requirement to create Plants for purpose of I/C flow. In every Retail implementation project, I've only every seen Customers and Vendors created for this purpose (and now BP in S/4HANA). I'm sure I don't understand your scenario yet; we should Zoom some day on this topic.
Retail Site Master technically requires a Customer Master, and therefore it requires a BP. The same BP can be extended to a Supplier role when needed, and now a Vendor Master is created and associated with the Retail Site Master. The Retail Site Master has one and only one BP. This aligns with your example # 2 above.
As an aside on the subject of mapping numbers ... check out this blog: Best Practice for Site Numbers
A best practice in SAP Retail is that the following objects all have the same 4-character number:
- Paul
Paul,
I am sorry if i wasn't totally clear and understable.
The requirement is to create a debit note in SD to invoice company 2.
To determine the shipping country of expedition, you need to fill the expedition plant field, the only purpose of having a plant is just for the SD document.
Let's say company = COM1
Plant = PLA1
Company 2 = COM2.
If you create the SD document, to invoice COM2, as being COM1, the plant is defined as being the supplier.
If you link PLA1 to COM1 in WB01 when you create the plant, the ID Of the supplier is immediatly correct, and equal ot plant, and = COM1. (T001W-LIFNR-KUNNR -T001-BUKRS = COM1) => that fitts what happens in our process.
Indeed the ID of the supplier on the IDOC RD04 = T001W-LIFNR linked to plant. In a standard SAP I/C, this is the ID of the company when you link the plant to it.
If you link PLA1 to a new business partner called PLA1, then, supplier = PLA1, when, the ID of the supplier should be COM1 (ID of company), then you would need to maintain conversion and maintain two business partners (PLA1 and COM1 instead of only COM1 if you would have linked plant PLA1 to COM1 when creating in WB01 to deal with only one BP)
I think that would be better in this particular case, where it's better to have two partners for real distribution sites. (because our plant for I/C does not really exist it's nothing more than the company itself in the end)
Regs,
Victor
Nice explaination and helpful article.
It is a very nice blog. This blog clearly serves a purpose.
Thank You 🙏 Paul Gendreau
hi ,
is there any config available to add more tables to site master copy rules
Below error i am getting while adding
Entry TCKM2 does not exist in TWRF1_CUST_TAB (check entry)
Message no. 00058
Regards
Sasidhar
Hello Sasidhar:
For Site distribution after copy, consider SAP Note 2659797; add an include to the structure SITE_DISTR_SITE_STY for standard tables.
thanks perfectly worked
can we do same as this for custom tables also or any other type of config i need to for that
Regards
sasidhar
Hello Sasidhar:
SAP Note 2659797 says: Add a component with the name of the table to the include.The component type must be a standard table and the name of the row type of the table must be the same as the name of the transparent table.
However, in my experience, both the copy rule configuration and appending the structure SITE_DISTR_SITE_STY will work for custom tables, providing that there is alignment of primary keys in those tables to support the association to T001W.
Here is an example:
SITE_DISTR_SITE_STY, with append structure for additional tables, including custom table ZTMRMD_SITE_ATTR
SPRO -- Logistics - General -- Plant Master -- Settings for Plant Replication -- Maintain Tables for Plant Transport. Added table ZTMRMD_SITE_ATTR to the list of tables to be replicated.
- Paul
fine thank you my issue got resolved
Well Written. Thanks Paul Gendreau