Listing in SAP Retail and Fashion is a pain point. After coming to grips with the art and effort of assortment management, you’ll find that execution of Listing is performance intensive. Maybe problematically performance intensive. Sooner or later, it begs the question: Is all of this really necessary?
Of course, the simplistic answer is: Yes, you have to. But this answer isn’t only unsatisfying. In some cases, it’s simply wrong.
If you’ve been given an explanation of Listing that more-or-less begins and ends with “it’s mandatory,” then press on. I’d begin with: What business purpose does this serve in SAP ERP? Here’s a tip: Reject any generic or technical answer. You need to ask, very specifically: What business purpose does this serve for me, right now, in the context of my particular business processes? Why? Why? Why?
Before asking pointed questions, let’s recognize up front that using Assortment Management and Listing in SAP Retail and Fashion is the norm. And it should be the norm, because Listing is (in part) fundamental to The Essence of SAP Retail Master Data. You wouldn’t consider doing otherwise imprudently. In any case, an informed choice is appropriate.
Assortment Management and Listing produces two results.
I’m not going to discuss the several strategies for managing data (assortments and master data) and options for executing system processes (so-called Listing Procedures). The possibilities would fill a book. Purpose and results are the subjects at hand. Because, regardless of your up-front choices, there’s seemingly one end in mind.
We tend to think and speak of the output of Listing as one thing — the result of Assortment Management and Listing — but it’s important to recognize the distinct outputs. This next level of detail is the key to understanding why Assortment Management and Listing is a best practice, as well as informing any decision to deviate from best practice.
Result # 1 – Authorization Data (Listing Conditions)
Listing Conditions answer the question: Is this Product authorized for business processes at this Location on this date? We commonly hear the question in abbreviated form: “Is this Article listed to this Site?” But we can intend no less than the full question. Listing conditions are bound by validity dates.
The ultimate answer, an unambiguous Yes or No, determines whether a Product is permitted to participate in the business process that’s asking the question. And the question is asked in many business processes.
Evaluation of Listing Conditions (a Listing Check) is performed in many Business Processes.
Evaluation of Listing Conditions (e.g. T-Code WSL11) — examining master data to answer the question — isn’t as simple as looking up a “Yes” or “No” from a single table. Depending on your strategy for managing data (assortments and master data), table WLK1 (Listing Conditions SAP Retail Assortments) could contain many rows of data. What’s more, table WLK1 doesn’t explicitly include Location (Site) number. Thus the Listing Check is itself a master-data-driven process that considers inputs, accommodating various strategies for managing data.
Notice that Listing Conditions typically act as a constraint in business processes. If the Listing Check fails — no, the Product is not authorized for business processes at this Location on this date — then the business process is stopped or the Product isn’t included in the business process. For example, failing a Listing Check, a Product cannot be used in a Purchase Order for a given Location on a given date. Likewise, Product data would not be sent to a given Store in Point of Sale Outbound unless and until it’s authorized by Listing Conditions.
It’s worth noting that Listing Conditions aren’t the only control point for constraining business processes. But it’s true that Listing Conditions — an affirmative answer returned by the Listing Check — is a unique prerequisite for authorizing business processes in the first place.
Result # 2 – Mass Creation of Master Data
Master data created as a consequence of Listing is the most obvious manifestation of The Essence of SAP Retail Master Data. The detail of what’s created depends entirely on the master data you’ve orchestrated to support the concept. Reference Articles, Reference Sites, and Reference Handling concepts all come together in the moment.
If a Product is authorized for business processes at a Location, it then follows that the Article must be extended to the Location (i.e. the Material must be extended to the Plant). For this reason, we tend to focus on the Article-Site-specific data that’s created by execution of Listing, beginning with table MARC (Plant Data for Material). Secondarily, it’s typical for Articles to be extended to Distribution Chains by execution of Listing, beginning with table MVKE (Sales Data for Material).
Andras Strobl‘s blog, Listing process in SAP Retail – behind the scenes, describes Mass Creation of Master Data as “probably one of the most performance intensive processes in Retail.” He goes on to offer an insightful explanation of Locking concepts that apply in this process. It’s worth grasping the detail because the consequences apply universally.
What’s the Difference?
My friends who haven’t been exposed to SAP Retail often conflate an Article being extended to a Site with an Article being Listed to the Site. But these are completely different things. The presence of Article-Site-specific data (e.g. table MARC) is no indication whatsoever of Listing (i.e. authorization, Listing Conditions). Remember the full question: Is this Product authorized for business processes at this Location on this date? Listing Conditions are time bound, and table MARC has nothing to tell us about validity dates.
It’s true that successful execution of Listing creates Article-Site-specific data. But Listing isn’t the only way that Article-Site-specific data can be created. Therefore, the presence of Article-Site-specific data cannot be understood with certainty to mean that an Article was ever Listed to a Site. Listing Conditions can be reorganized (deleted, as master data). But MARC records remain in the system until archived.
The only way to answer the question of whether an Article is Listed to a Site (on a particular date) is by Evaluation of Listing Conditions. Don’t look to Article-Site-specific data to answer the question.
Techies can drill down further into the logic used for Evaluation of Listing Conditions. Example function modules include POS_LISTING_SALES_CHECK, WLK1_READ_MULTIPLE_FUNCTIONS, and WLK1_CHECK.
What’s the Purpose?
It’s a good exercise to consider whether each result, created by one process (Listing), is a requirement for satisfying your present business process objectives.
The purpose of the Assortment Management and Listing business process is to announce the intention to sell a Product, at a Location, within validity dates. Listing Conditions ultimately express that business intent. As we’ve seen, the expressed business intent is later used to inform (typically, constrain) business processes. The most obvious examples are business processes that perform a Listing Check. But there are also applications, such as Forecasting and Replenishment, that consider historical Listing Conditions.
The purpose of mass creation of master data as a consequence of Listing is quite different.
Outside of SAP Retail, where there’s no Listing concept and therefore no Listing Check, the necessity of extending a “Material to a Plant” is first observable by business process failure. For example, a Material cannot be added to a Purchase Order for a Plant, or a goods movement performed, if the Material is not first extended to the Plant. It’s technically necessary to create the Material-Plant view before using the Material in a business process for that Plant. This technical requirement also applies to Article Masters in SAP Retail and Fashion.
For this reason, I think of mass creation of master data via Listing as fulfilling a technical requirement, or as a technical benefit. However you think of it, the key note is that it’s not an expression of business intent. It’s one part of a supremely elegant strategy to solve a massive data management challenge that’s common to Retail systems.
Listing is Mandatory if …
For a moment, forget about the mass creation of master data. Focus on the question of whether you have a business requirement for Assortments and Listing Conditions.
Implementing Assortment Management and Listing is plainly “mandatory” if you have a business requirement to constrain business processes based on Listing Conditions. A classic example would be to restrict snow-related Products from being ordered for, or transferred to, a Location that never experiences such weather. Another example would be restricting business processes for certain Locations within certain dates. Other examples include implementation of:
In all of the above examples, you implement Assortment Management and Listing because one result, Listing Conditions, is unambiguously useful to your immediate business objectives. You’ve identified a business requirement that must be informed by the expression of business intent, or must be informed by the binary answer to the key question: Is this Product authorized for business processes at this Location on this date?
When this is true, then the ongoing effort of standing up a standard business process (manage assortment-related data) and substantial data processing (execute Listing) is warranted by one or more identified business process requirements. The story ends here.
A Rant on Necessity and Combined Ideas
Combining mass creation of master data with creation of Listing Conditions, in a single business process called Assortment Management and Listing, is unquestionably a masterstroke … if Assortments and Listing Conditions are business requirements in your SAP ERP system.
But this isn’t universally true. It’s not that Retailers don’t manage assortments. They do. It’s that most Retailers make assortment decisions outside of SAP ERP, and some Retailers have no business requirement for that information in SAP ERP.
Beyond this, does it make sense anymore to use assortment decisions as the key input for authorizing procurement, logistics, and sales processes by location? Does it make sense anymore to tightly link assortment decisions with master data creation for those same business processes? Think about increasingly common business models that trend towards omni-channel, buy-online and pick-up in store, and potentially fulfill to any customer from any location. The opinion of some industry experts, with whom I agree, is that a hard linkage between assortment and business process authorization in ERP makes little or no business sense nowadays. The same is true, in my opinion, for the hard linkage to mass creation of master data.
By this point or earlier in the conversation, I’ve heard experts — including smart people whom I respect — resort to declaring “It’s mandatory” as a means to ending the discussion. I’ve also heard business process owners informed, “It’s critical that you maintain assortment data in SAP Retail.” But this avoids the question: Why? To what end?
“It’s mandatory” isn’t an unassailable assumption! If it’s critical, then please explain it to me like I’m a 6-year-old child. Otherwise, healthy skepticism is appropriate.
This story’s denouement asks: What if Assortments and Listing Conditions aren’t a business requirement in my SAP Retail system?
Unnecessary Assortments and Listing Conditions
The most common manifestation of “no such business requirement” is a decision to List all Articles to all Sites. In this case, assortments aren’t really managed at all. Yes, assortments are created, and Listing is executed. But for technical reasons, not business reasons. The benefit of mass creation of master data is captured, but in a clumsy manner, as unnecessary master data is created. In fact, if the number of Products times the number of Locations is a very large number, then massive unnecessary data may be created.
But, to be quite clear on this point: if data management, volume, and processing performance are not problematic, then my opinion is that it’s still preferrable to “List all Articles to all Sites.”
An increasingly common scenario involves an SAP Retail system that’s more-or-less a back-end system, at least initially. And “initially” could be a period measured in years. Think of implementing a Financial system or a Master Data system ahead of implementing Logistics business processes. In this case, business processes are executed outside of SAP by legacy systems, with purchase orders, goods movements, and more sent to SAP ERP via interface.
In this architecture, SAP Retail may be the financial system of record, and may even be a master data system of record. But transactions arriving via interface mustn’t be constrained by Listing Conditions. Failing inbound messages are process failures requiring resolution efforts; the SAP ERP system must accept inbound transactional data as fact.
Avoiding Assortment and Listing
What the above examples have in common is that Assortments and Listing Conditions aren’t only unnecessary but may actually impede business objectives. In such scenarios, data management and system process efforts represent ongoing costs that produce a negative business benefit.
Even when this is objectively true, Retailers still tend to manage assortments and execute Listing because:
- it’s a standard process.
- the incidental mass creation of master data is beneficial.
- they’ve been told “It’s mandatory.”
Yes, it’s standard and it’s best practice. And Master Data Aficionados strongly prefer both. But is it mandatory?
What if I’d prefer to avoid:
- unnecessary business process effort (manage assortments and related master data).
- performance-intensive data processing (execute Listing).
- mass creation of unnecessary master data (List all Articles to all Sites).
- unnecessary or unwanted business process constraints.
Oh, and while avoiding the list of unpleasantries, may I please retain the benefit of mass creation of master data?
The answer is: Yes. But it’s always a consequential decision to deviate from “best practice,” and it’s some effort. Proceed deliberately.
To begin, a decision to not use Assortments and Listing is totally standard. Global control of this feature is a single setting in customizing. A decision by Site is also possible, but I have to say, I can’t imagine a use case for making such a decision by Site.
Use of Listing Conditions can be disabled globally via T-Code WSS1. This is table-field TWPA-LIKON – Create listing conditions yes/no.
Use of Listing Conditions can be disabled per Site using T-Code WB02. This is table-field WRF1-KZLIK – Listing Conditions for Assortments.
Because Listing Conditions aren’t used, you don’t manage any assortment data in SAP ERP and you never execute Listing. Because Listing Conditions will never be created, the SAP Retail system never performs any Listing Checks in the aforementioned business processes.
Poof … with the flip of a single switch, unnecessary activities and results are avoided. If this seems too easy, remember that we’ve yet to explore how Articles will be extended without execution of Listing.
Just-in-Time Article Extension
If I had to name the concept of creating master data on demand, I’d call it Just-in-Time Article Extension (now you understand why I’m not invited to Marketing meetings). But I’d be lying if I said this was an original idea. It’s more like shameless renaming and embellishment of standard functionality. There’s not much creativity here, and that’s a good thing; Master Data Aficionados aren’t especially fond of creativity.
The purpose of Just-in-Time Article Extension is to systematically create master data, either before or at the time it’s required by a business process. The objective is to capture the benefit of automated master data creation without implementing a business process or even a specific master data process.
A strategy for implementing such functionality …
- First and foremost, assumes no identifiable business or technical requirement for Assortments and Listing Conditions in SAP ERP.
- Does not preclude — or make more difficult — future adoption of standard Assortment Management and Listing.
- Follows the example of similar standard system functionalities.
- Requires coding, using standard functions, and is not a modification.
- Depends on, but doesn’t interfere with, use of Reference Articles, Reference Sites, and standard Reference Handling concepts.
A step-by-step implementation guide would be nice. But none exists, and with good reason.
Consider that Assortment Management and Listing is a concept. Article Master reference handling is The Essence of SAP Retail Master Data, and it’s also a concept. Neither of these is a prescriptive, one-size-fits-all solution. Instead, both require design effort, based on standard components, to produce an outcome that’s aligned with your specific business requirements.
The same is true of Just-in-Time Article Extension. The implementation details must be particular to your enterprise, system architecture, and master data requirements. Fortunately, here too, there are standard bits to be used, and standard functionalities that serve as precedent and reference.
Practical Implementation Experience
Implementing an SAP Retail system as a back-end system, as mentioned above, presents the clearest use case for considering Just-in-Time Article Extension. The concept has broader appeal, but this one is particularly useful for illustrating some design considerations.
Make Use of Standard
Beyond standard business processes (e.g. Promotions, Allocation) that create Listing Conditions and master data outside of Assortment Management business processes, there’s ample precedent in standard for creating master data — extending Articles — on demand.
Subsequent Listing for Articles
- Sometimes products should be accepted at a Location for which they aren’t listed. For example, a promotional item may be Listed in a distribution center that ships it to stores where the product is not listed.
- Using T-Code WB02 to maintain a Site, on the Listing/Materials Planning tab, there’s a Subsequent Listing Indicator (table-field WFR1-NLMATFB) that enables this use case.
- In ECC 6.0, Article-Site data (e.g. MARC) is created automatically at stock transfer or goods receipt.
- In S/4HANA, Article-Site data (e.g. MARC) is created automatically at goods receipt.
Allow POS Inbound for Non-Listed Articles
- Retailers commonly permit product returns at stores that didn’t sell or never sold the product. In this case, MARC data and Listing conditions may not exist for the store accepting the return.
- In ECC 6.0 there was a Business Function (ISR_RETAIL_POS_INBOUND) that could be activated to enable this business requirement.
- In S/4HANA, the new functionality is named Allow POS Inbound for Non-Listed Articles. It’s configured as an option in the POS Inbound Profile that’s assigned to a Store.
- Customizing path: SPRO > Sales and Distribution > POS Interface > Inbound > Extension for Controlling Summarized Sales
- When Allow POS Inbound for Non-Listed Articles (table-field TWPIV-POS_WO_LISTING) is activated, master data segments (but no listing conditions) are created during POS inbound processing, enabling the return of goods.
Here’s a golden nugget: Both of the above standard functionalities continue to create master data on demand after customizing is changed to work without listing conditions. Nice!
Plan to use these to your advantage if relevant. What’s more, and in any case, follow their example. It’s instructive to explore the customizing help attached to Allow POS Inbound for Non-Listed Articles. This functionality is rich, and you’ll find a range of concerns and possibilities that should inform your design and implementation of Just-in-Time Article Extension.
Make Use of Available Data
Experience teaches that overreliance on Allow POS Inbound for Non-Listed Articles in high-volume systems can result in failed inbound IDoc processing (e.g. IDoc WPUBON for sales as per receipts, or IDoc WPUUMS for aggregated sales). Parallel processing of these IDocs can fail due to record locking as Articles are extended to multiple Sites. Even when using completely standard business processes, you can’t ignore the reality of record locking that occurs while extending Article to Site
For this reason, it’s prudent to moderate the Just-in-Time aspect of Article Extension. This is likely enabled by the typical practice of making assortment decisions outside of SAP Retail, in which case you can intend to ingest that data in SAP Retail to your benefit.
Fortunately, an inbound interface for extending Articles to Sites is far simpler than any inbound assortment interface, both in terms of source data requirements and processing in S/4HANA. To begin with, the relevant data elements are simply the combinations of Article Number and Site Number. On the processing side, there isn’t any consideration of validity dates, assortments, or listing conditions, as understood in SAP ERP.
Following the example of standard, it’s important not to be reliant on a single mechanism for Article Extension. To that end, the nod to record locking means thinking about Article Extension as something like an 80/20 proposition. An inbound interface would preferably extend articles about 80% of the time before the master data is required by a business process. And this interface would preferably be processed outside of business hours. On-demand extension then takes up the slack on an exception basis, either by standard or custom functionality. The upshot is that available inbound data needn’t be perfect, especially with respect to timing.
Common Code and Touchpoints
The few inputs and minimal processing logic (and examples found in standard) give rise to the notion of implementing a central function for enabling Just-in-Time Article Extension. The same functionality enabling an inbound interface can facilitate Just-in-Time Article Extension.
Process flow for Just-in-Time Article Extension.
The first step, a check for existing master data in table MARC, is highly performant because it’s a check against the primary key for that table. Because this is true, performance isn’t an issue even when this check is performed in high-volume processing. The second step, Article Extension, only occurs when necessary, when master data doesn’t exist for a given Article / Site combination.
For our example integration scenario, this means calling the central function during inbound processing of purchase orders and goods movements. These events encapsulate when master data is technically first required to execute a business process.
If you’re considering a scenario that must work by interface and online (e.g. SAP GUI) then you have to dig a bit deeper for a common BAdI. For example, BAdI ME_PROCESS_PO_CUST has a method PROCESS_HEADER that’s called by both.
To give you an idea of performance in this scenario, I’ll offer an example of a customer with more than 2,000,000,000 (yes, 2 billion!) existing MARC records. The customer has extremely high volume inbound purchase orders and we were concerned to understand the performance implications of Just-in-Time Article Extension. Our benchmarking assumed the worst-case: every item on an inbound purchase order would need to be extended. Our test process implemented BAdI ME_PROCESS_PO_CUST and called function module ASSORTMENT_MAINTAIN_MATERIAL to perform Article extension when a MARC record was missing. Running batches with as many as 100,000 article/site combinations, we observed only about 1.4% additional processing time required for Article extension. This demonstrated that the performance difference wasn’t a concern, even in the worst case scenario.
Standard Bits
It’s possible to craft your own central function to create master data on demand, according to your particular requirements, using standard function modules.
BAPI_MATERIAL_MAINTAINDATA_RT – Create and Change Material Master Data (Retail)
This is the robust and reliable (and heavy) function module that’s used to process inbound ARTMAS IDocs.
- If you’re enabling extension to multiple Locations in one call, then for performance reasons be sure to make use of the structure intended for that purpose: BAPIE1WRKKEY – Retail Data Transfer: List of Identically Maintained Plants
ASSORTMENT_MAINTAIN_MATERIAL – Call of Maintenance Module for Product Segment Creation
- This function module is not released for use by SAP customers.
- It’s used by standard T-Code WSPK – Finish material master segments that cannot be generated. (Program RWSORT19).
- It’s used by standard report RWDIFFERENCEMARCWLK1_ENHANCED – Creation of missing article segments.
MATERIAL_MAINTAIN_DARK_RETAIL – Retail Material Master Maint. w/o Dialog
- This function module is not released for use by SAP customers.
- It’s used by function module ASSORTMENT_MAINTAIN_MATERIAL.
Reference
- SAP Help – Retail and Fashion – Assortment Management and Listing
- MDA Blog: What is Listing in SAP Retail?
- SCN Blog: Listing process in SAP Retail – behind the scenes, by Andras Strobl
- SCN Blog: IS-Retail Assortment, by Maciej Jarecki
- SAP Note 1996647 – FAQ: Listing
- SAP Note 2851283 – Creation of MVKE entries during listing: FAQ
- SAP Note 1887806 – Report for creating missing article segments (RWDIFFERENCEMARCWLK1_ENHANCED)
Notes and Asides
- SAP Retail is used as a shorthand to mean both SAP S/4HANA Retail for Merchandise Management and SAP S/4HANA for Fashion and Vertical Business. Listing is relevant for both applications.
- The terms Product, Article, and Material are used interchangeably to mean SAP Retail Article Master. Location, Site, and Plant are used interchangeably to mean SAP Retail Site Master. SAP Retail Text was deprecated with SAP S/4HANA, but the Retail terms remain inconsistently applied across various user interfaces, documentation, and even in conversation.
- SAP Managed Tags:
5 Comments