What is Listing in SAP Retail?

Is this Product authorized for business processes at this Location on this date?

In SAP Retail, Listing Conditions answer this simple question, but the complexity of producing the answer is massively underappreciated.

There are three main parts to the story: Data Management (business process), Execution (system process), and Listing Conditions (the result). And then there are common exception scenarios to be handled.

Data Management (Business Process)

An SAP Retail business process named Assortment Management announces the intention to sell a Product, at a Location, within validity dates. There are several data management approaches available in S/4HANA ERP, such as: Manual, Automatic, and interface from a Space Management system. And there’s an S/4HANA application called SAP Assortment Planning. For an enterprise, using more than one approach is typical. But products within the same Merchandise Category should be managed using the same approach to avoid unmanageable complexity.

Apart from the specific business process of Assortment Management, there are also business processes that generate Listing Conditions. For example, both Promotions and Allocation include functionalities to create Listing Conditions.

Given the number of business processes and data management approaches in play, you should already be sensing the complexity of answering the initial question.

Program Execution

Regardless of the chosen data management approach, a system process (execution of a T-Code or program) — called Listing — is then executed in SAP Retail. The system uses an algorithm — a so-called Listing Procedure — to analyze master data maintained across Assortments, Locations, Products, and more. Because large sets of data are examined, processing can be resource intensive and time consuming. There are exceptions, but Listing is typically executed as a nightly job.

Listing produces two outputs:

Time-bound authorizations (Listing Conditions) are generated.
Location-specific product data is massively created (tables MARC and many more).

It’s a common mistake to conflate Listing Conditions and location-specific product data and. We think of the two outputs as one thing — the result of Listing — but it’s important to recognize the distinct outputs.

Listing Conditions change over time (as Listing programs are executed) and therefore expire with validity dates and changes in master data. Evaluation of Listing Conditions is the only way to answer the question: Is this Article authorized for business processes, at this Site, on this date?

In SAP Retail, Listing automates what is a manual process in SAP Standard: “extending Materials to Plants.” That’s the creation of location-specific product data, which persists until archived. If a Product is never Listed to a Location, then the material is never extended to the plant. Lack of location-specific product data will be a point of contention later in the story.

Listing Conditions

Listing Conditions are one result of the execution of Listing. It’s an odd name, given that listing “conditions” don’t make use of standard SAP condition techniques.

In SAP Retail, there’s a mandatory Listing Check performed in execution of many business processes.

The Listing Check consults existing Listing Conditions and answers the question: Is this Product authorized for business processes at this Location on this date? On that basis, a Product is permitted or not permitted to participate in the business process that’s requesting the Listing Check.

Listing Check is performed in many Business Processes.

Because the Listing Check is mandatory, the prerequisite business process (Assortment Management) and system process (execution of Listing) are likewise mandatory. At least minimally.

Subsequent Listing

There are some cases when it’s desirable for a product to be permitted in a business process regardless of Listing Check. One such example is enabled by Subsequent Listing for Articles.

Under certain circumstances, such as goods receipt or stock transfer, Products may arrive at a Location for which they are not listed. For example, a promotional product may be Listed in a distribution center, which ships it to stores where the product is not listed.

Using T-Code WB02 to change a Plant, you can maintain a Subsequent Listing Indicator (WFR1-NLMATFB) to indicate how subsequent listing is to be carried out on plant level.

T-Code WB02 enables control by Plant.

Here’s a pitfall to be aware of when using Subsequent Listing: in some cases the behavior is inconsistent in S/4HANA, and different than it was in ECC 6.0.

For example, in the case of a Stock Transfer Order (STO) then Location-specific product data (tables MARC and many more) must already exist. In this case, the system checks for MARC data before checking Listing conditions. If MARC data doesn’t exists then the STO is not permitted for that reason.

I suppose that this behavior in S/4HANA makes sense in the strictest interpretation of “Subsequent.” You can’t Subsequently List if you haven’t Listed in the first place, which would have created MARC data.

But the behavior is different in the case of a Goods Receipt. In this case, if MARC data is missing then it is created.

Allow POS Inbound for Non-Listed Articles

The other common scenario is the case of a product purchased at Store A, where the product is Listed, but returned to Store B, where the product was never Listed.

Retailers commonly permit such returns. But for Store B neither MARC data nor Listing conditions exist for the returned product.

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 called Allow POS Inbound for Non-Listed Articles. It’s configured as an option in the POS Inbound Profile that is assigned to a Store.

SPRO > Sales and Distribution > POS Interface > Inbound > Extension for Controlling Summarized Sales

When this function is activated, required master data segments (but no listing conditions) are created during POS inbound processing. Required article master data for the article and site comprise, in particular:

Logistics data (table MARC)
Storage location data (table MARD)
Valuation data (table MBEW)

If sales data (table MVKE) is not yet available for the article and distribution chain of the store then it’s created as well.

The article master segments are created using standard article master reference handling. For example, by copying data from a reference article or site.

This functionality enables the return to be accepted. The product is in the door. However, this scenario is a larger business discussion when inventory valuation and subsequent business processes for the returned product are considered.

Notes and Asides

The concept of Listing applies to 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.

Tags: Assortment, Listing

What is Listing in SAP Retail? – MDA Blog (masterdataaficionado.com)