Introducing the Retail Article Master

The article master in SAP Retail is a comprehensive object, and the article maintenance function allows you to define all relevant data for an article so it can be used in all processes. In order to support retail-specific requirements and processes, different article categories are available.

Single articles are articles that are traded individually, and might exist in different units of measure. They can be considered a standard material, which is sold as is to the customer, for example, a 250g packet of chocolate chip cookies.

Generic articles exist in different versions, called variants. For example, a round-neck T-Shirt (generic article/style) exists in different color or size variants.

Structured articles consist of several different articles. These are entered as components with their respective quantities in the bill of material (BoM), and are supported in all logistics processes.

More details on the specific features and functions of generic and structured article are going to follow later in this lesson. The common retail article master structure is now introduced using the single article as an example.

An article master record contains all the required data for an article, sorted according to different criteria.

In general, an article master record contains:

• Descriptive data, such as size and weight

• Data with a control function, such as the article type

• Data that is automatically updated by the system (for example, stock quantities and valuation data)

An article master record contains not only general, basic article-relevant data, but also data from other areas of the system that are necessary for articles, such as purchasing, logistics, or sales. These areas are called user departments, or views, in the article master. Unnecessary data storage is reduced when all data is stored in a single database object.

The article master structure, and with that the number of views, depend on the kind of merchandise. For example, SAP provides several retail-specific screen designs (called screen sequences). Screen sequence 24 is typically used for food- and non-food merchandise, and has the article views shown in the previous figure, Article Master Data - Views: Basic Data, Basic Data 2, Listing, Purchasing, Sales, Logistics: Distribution Center, Logistics: Store, POS. Screen sequence F4 is typically used for fashion merchandise, and has the Logistics: DC 1, and the Logistics: DC 2 views instead of the Logistics: Distribution Center view, which provide further logistics detail settings, such as segmentation and production-related data. The F4 Fashion Screen Sequence also contains another tab in the Additional Data view: the Textile Composition tab. The section, Article Master Configuration, further below will explain briefly how you can influence the screen sequence selection, and which further configuration options are available.

The Retail article master is a comprehensive object, which pulls together data from all relevant areas of the system. This ensures that once the article views have been fully maintained, the article can be used right away in all processes, from (requirements) planning, to purchasing, logistics, and sales. All the data can be maintained in just one transaction, the (integrated) article maintenance. When data from different departments in the organization is pulled together, it requires to select and create data for various organizational levels, or areas of validity.

There are no restrictions to Basic Data. This data is stored using only the article number itself as a key field. In our system examples, there will be two Basic Data views: Basic Data, and Basic Data 2.

Listing can either be executed client-wide (for all distribution chains), or be restricted before you enter the article master, or within, to a specific Distribution Chain.

For creating Purchasing data (purchasing info record), you must enter a purchasing organization and a supplier (vendor). Within the purchasing data maintenance, you can also restrict the validity to a particular site, for creating a site-specific purchasing info record.

It does not matter whether or not you specify a site in the Areas of validity in the initial screen when you want to access the purchasing view. The purchasing view is displayed for the selected article, purchasing organization, and supplier, thus, any site number is ignored. This prevents the unintended creation of site-specific purchasing data. You can still create site-specific info records by choosing the Switch Validity Area button within the purchasing view. There, you can switch to another supplier, or open/exit a site-specific view.

*Unlike the other areas of validity, the supplier sub-range (SSR) is no data retention level, but an attribute in the purchasing information record. However, in order to have the system pull the right default data for a new purchasing info record from the SSR view in the supplier (vendor) master, you have to specify the supplier sub-range right away in the entry screen of the article master.

Sales data is always at least maintained for a distribution chain, which means a sales organization and a distribution channel have to be specified to access the data of this view. More detailed data maintenance is possible as well, that is at site or price list level, which you can choose within the sales view. There, you can also select a site group. However, take note that the data that is entered at site group level is not stored at this level - it is stored at the individual site level. So, doing this can lead to an increased volume of data in your system.

Logistics data for distribution centers and stores can be maintained at a general, that is client-wide level. The data is then initially used for all sites, as it is stored for the reference sites that are defined in Customizing. It is used as a copy-basis for the site-specific logistics data, which is usually created by means of the listing process. It is also possible to create site-specific logistics data manually. In the Logistics: Store view, you can additionally maintain the data on distribution chain level, given a corresponding reference site was defined in customizing beforehand.

You must enter at least a distribution chain be able to completely maintain the POS data. Optionally, you can select a site within the POS view to maintain site-specific control data. If you access the POS view client-wide, only the till receipt texts can be maintained, but no POS control data.

In SAP Retail, for each article, one article master record is created, which contains the various units of measure of this article. Accordingly, the GTINs (global trade item number, successor of EAN (European article number) and UPC (universal product code) are not defined on article level, but on unit of measure level in the retail article master.

An article number in SAP Retail can be assigned automatically by the system, based on an internal number range, or externally, that is by the user, based on an external number range. The CHAR 40 field length is standard in an SAP S/4HANA system. However, the use of an external article number range longer than 18 characters has to be activated in Customizing. Also, the maximum number of characters (up to 40) has to be set there.

Inventory management is carried out in this unit of measure. The base unit of measure is normally the smallest possible unit in which an article can be sold.

The unit of measure in which the article is usually ordered. It is maintained for each supplier, but it is still possible to allow variable purchasing units of measure.

Unit of measure normally used when an article is sold to a customer. It is normally the base unit of measure for consumers. The sales unit can be maintained separately for each distribution chain. It is still possible to allow variable sales units of measure.

Unit in which the article is normally delivered from a distribution center. It is maintained for each site.

You must enter the conversion factors for the various units of measure of an article. It is possible to enter the conversion data referencing the base unit of measure, or referencing an alternative unit of measure, as indicated in the previous figure, Units of Measure.

The article master can be configured to a large extent. The retail screen sequences 24 and F4 were already briefly introduced earlier in this lesson. Screen sequences are used to control the main views (from Basic Data to POS for example) and their secondary views of the article master (from Basic Data to POS for example), and which subscreens each view contains. The screen sequence can be set based on transaction, user, article (material) type, industry. It is common to use the article type to control the screen sequence. In our training system, we use screen sequence 24 for most article types, but article type fashion (FASH) uses screen sequence F4.

Furthermore, it is possible to control the field status for each field in the article master. The field status options are: hide (suppress), display, required entry, optional entry.

The structure of the article master as explained above is used in the classic retail article transactions MM41, MM42, MM43 (create/change/display article) of the SAP Gui frontend, as well as in the corresponding Web GUI based SAP Fiori apps Create - / Maintain - / Display Article.

In SAP S/4HANA, a new, additional maintenance user interface (UI) for products is available with the SAP Fiori app, Manage Product Master Data. It can be used to create and maintain products, which are either (standard) materials, or retail articles. The app supports the relevant retail article categories: single articles, generic articles, or structured articles (set, prepack, display).

Besides actually maintaining product master data, the SAP Fiori app Manage Product Master Data additionally provides comprehensive search functions, result lists, copy functions, and allows you to manage images. The object page displays comprehensive article-related data, including documents such as purchase orders containing the article, and it allows you to access related apps - for example, to display the stock overview, or to post a goods movement.

The following figure, Introducing the Manage Product Master Data App, shows you the most important settings and options available with this app:

The first, upper-part of the figure shows the comprehensive Search function, which enables you to find the product(s) for which you are looking. It allows you to define search variants, and set up filters per view/subscreen.

In the middle part, the result list for the Products, you can select an item to display the product, but you can also choose to create a new product, use the copy function to create a new product. This allows you to initially select the organizational data (distribution chains, DCs, stores) to be copied from your copy reference product. Another option is to call the object page for a selected product.

In the lower part of the figure, you can see how the Product view is structured. You can access this view by clicking the relevant product item line in the result list. In the product view, you can choose to edit or copy the product. Depending on your assigned apps, you can for example also choose to display your product in another app, such as Display Article.

When you choose to create an article, the app automatically stores a draft of your entries, without creating an actual article master record in the system. This is particularly useful, if you close the browser session intentionally or accidentally, or if you want to keep your entries for completing the data at a later stage, as you can get back to the app at any time and continue working on the draft. Only when you choose to save, then the actual article master data is created. In this case, the draft version is automatically deleted from the database. You can also discard a draft by choosing delete or cancel.

The Retail material master structure was introduced using the Single Article. In the following, the special features and functions of the other, retail-specific article categories, the Generic Article with their Variants, and the Structured Articles with their Components maintained in a Bill of Material, are going to be explained.

If certain articles only differ in their characteristics, for example color, size, or flavor, the individual articles can either be created as single articles, but also as variants of a generic article. This means the generic article concept is not limited to fashion articles, but can also be used for non-fashion merchandise.

Generic articles are heavily used in fashion retailing.

The generic article concept can be used to efficiently create and maintain articles, which only differ in characteristic values, for example colors, sizes, flavors, scents, and so on.

When you create a generic article and its variants, you create both an article master record for the generic article (dummy header article), and an own article master record for each individual variant (operational article).

Using generic articles makes variant maintenance easier, as the data that is valid for all variants only needs to be entered once for the generic article. The variants are defined by selecting the relevant characteristic value combinations.

The variants represent the actual physical articles (operational articles) used in all business processes, from planning to purchasing, logistics and sales. The generic article (dummy header article) serves as selection and entry help in system transactions and documents.

In order to create generic articles, some preparation is necessary: Characteristics have to be defined with their characteristic values - for example, characteristic color with the values white, yellow, green, blue, and so on.

Then, these characteristics have to be assigned to a class of configuration class type 300.

The configuration class then has to be selected when creating a generic article. The variant matrix then allows you to select the characteristic value combinations, which are to be created as variants. The variant matrix is a grid of the characteristic value combinations. This is a 2-dimensional table, with each axis showing the values of one characteristic. If there are more than two variant-creating characteristics, then the 2-dimensional table is generated for each value of the third characteristic, which are displayed in a separate tab each. It is recommended to not use more than three variant-creating characteristics. A typical example in fashion with three characteristics are denims with color, waist (size 1), and length (size 2).

Structured Articles are used in SAP Retail to group articles for specific purposes. The display, set, and prepack articles are (dummy) header articles. The operational articles are assigned to the header article as components of a retail bill of materials (BOM).

A display consists of a number of single articles or variants of one or more generic articles, and is purchased as an individual article. A display therefore has its own article number, purchase price, and purchasing conditions. Displays are typically made up by the manufacturer or supplier, and often come with packaging that can be used to present the merchandise on the sales floor. In a retailer's supply chain, usually the distribution centers manage the inventory on display level, as they ship complete displays to stores or wholesale customers. Stores usually manage inventory on component level, as they sell the individual components to consumers.

A set can be defined from a sales or purchasing point of view:

• A sales set consists of a number of single articles or variants of one or more generic articles. A sales set has an own article number, sales price, and sales conditions.

• A purchasing set is a combination of articles which are purchased together (as a set). They can either be managed as a set right through the supply chain, or managed on component level in inventory management. They can be sold as a set or as individual components.

A prepack consists of a number of variants of one or more generic articles. It is purchased as an individual article, and therefore has an article number, a purchase price and purchasing conditions. Unlike displays, the components in prepacks must belong to the same merchandise category as the prepack itself. For inventory management, usually the prepacks are set up in the same way as displays, that is with inventory management on the header article (prepack) in distribution centers, and at component level in stores.

The previous figure, Structured Article - Example, shows a display article, for which a bill of materials was created. In Customizing, it is possible to determine the inventory management level along the supply chain, that is, if inventory management should be done at header level (usually in distribution centers), or at component level (usually for stores). Besides the level of inventory management, it is also possible to decide, if the bill of material components should be displayed in a purchase order, or if it should only contain one line item for the header article.

An empties article is a form of returnable transport packaging or sales packaging that is usually subject to a deposit. Empties are assigned to a full product per unit of measure. In SAP Retail, you create empties as single articles of the article type, Empties. The full product can be created for the article categories single article, or variant of a generic article. The individual empties bill of material (BOM) components, and the full product itself all have their own article master record.

In order to define an empties bill of material, you have to set the "with empties" flag in the full product master record.

When assigning the empties articles to the full product, the full product and its unit of measure together make up the BOM header. In the previous example, the mineral water (full product) is maintained in units of measure each (single bottle), and crate (crate containing 6 bottles). So, two empties bills of material are created: one for unit of measure each, with one empties bottle, and another one for unit of measure crate, with one empties crate, and 6 empties bottles.

If you are listing a full product that is assigned an empty, the system also lists the empty automatically. You can only post goods movements with tied empties when you have activated empties processing in Customizing. Inventory management distinguishes between tied stock (empties stock containing the relevant full product), and untied stock (empties stock which for example can be returned to the supplier for re-fill).

It is possible to create structured articles with components that are full products with an empties bill of materials. Typical examples are a display of different flavors of yogurts (full product), with the yogurt glasses as the empties articles, or a mixed pallet (display) of various beverages such sodas in different flavors (full products) with their empties (bottles, crates). In addition, for example, a sales set containing beverages (as full products) with empties and a drinking glass can be created.

You can use this function to quickly and efficiently - either completely or partially - copy article master records, or to enhance, or complete, existing ones. In addition to the main article data, you can also copy additional master data, such as purchasing info records, purchasing and sales conditions, bills of material, and replenishment data.

• The article copy function allows you to simply and quickly create new articles by copying the data of a source article.

• In contrast to creating a new article manually using a reference article, the article copy function allows you to either copy all data or to restrict the copy process to certain segments only (*).

You can use the article change function (SAP Fiori app: Maintain Article) to adjust the new article, for example, to change the article description.

You have the following options when copying articles:

• Copying a source article:

  All field values of the selected segments are copied.

• Copying a source article with Key or Variant Filters set:

  Copying all field values of the source article except for defined filter values. Key filter values are, for example, site storage location, and assortment numbers.

• Individual control of the segments to be copied:

  The copy volume is defined by restricting specific segments, for example, info records, listing conditions, or prices.

You can use Global Data Synchronization (GDS) to import article data to SAP Retail (price catalog inbound). This means that you can receive information on new articles or changes to existing articles from a supplier or a data pool.

Global Data Synchronization (GDS) in SAP Retail (Inbound) allows retailers to receive article data directly into their system, eliminating manual article and pricing data management processes. This is especially important as the amount and detail level of article data continuously increases. Retailers can subscribe to articles or groups of articles from a supplier through a data pool. The latest information about new articles or changes to existing articles is then automatically sent to the retailer. This ensures both data accuracy, and a fast reaction to changes through flexible validation and enrichment rules. Retailers can receive, process, and approve new items within hours. GDS allows you to create SAP Retail specific article categories, that is single, generic, and structured articles.

Global Data Synchronization (GDS) complies with global standards:

The Global Data Synchronization Network (GDSN) is a network of data pools that facilitates the synchronization of item information between retailer and supplier through a single global registry, GS1.

The main GDS process steps for a retailer are as follows:

In SAP Retail, the retailer (recipient) creates a subscription at the recipient data pool, which sends the subscription information to the global registry. From there, the subscription is forwarded to the appropriate source data pool(s). Subscriptions can be established for an individual product (GTIN), a supplier (global location number, or GLN), or a category of products (global product classification, GPC).

The source data pool sends a confirmation of the subscription, followed by the actual product (GTIN) data to the recipient data pool, and then on to the retailer’s SAP ERP system. The inbound processing of catalog items is based on the global GS1 standard. The global registry and the data pools keep track of the GTIN hierarchies sent and their status (confirmed, rejected, …). Received Catalogue Item Notification (CIN) messages are stored in SAP Retail and can be viewed in the Storage Monitor.

To verify, match and synchronize the received CINs with existing articles in master data tables, flexible validation rules can be applied using the rule engine in SAP Retail. When the retailer has the new article data, they can either automatically update the old article master data with the new specifications, or manually update the data on a case-by-case basis. Rules can be established so that data from certain manufacturers or classifications are either always automatically accepted, or always manually confirmed. In the latter case, the interface allows the retailer to view the new specifications line-by-line with the old article master data. The retailer can select or reject the updates as he sees fit for each article and then save the updated information in the SAP Retail system.

The retailer can send the processing status of the data to the data pool by sending Catalogue Item Confirmation (CIC) messages. The data pool can forward it to the supplier. In case of errors, the retailer can send an error report to request a new CIN with corrected items. The confirmation/error reports to the supplier using CIC messages are also based on GS1 standard. It is also possible to enhance the solution to send the confirmation using different communication methods, for example e-mail.

This figure gives you an impression of the catalog editing screen, and the maintenance options it provides. The data as well as the layout can be configured and adjusted.

Due to typically large data volumes in a SAP Retail system, mass maintenance tools are important to update master data and documents.

Several mass maintenance tools were developed over time. The original mass maintenance tool (MASS) is available for various master data objects, such as materials and retail articles, but also for documents, such as purchase orders. The figure above, Mass Maintenance - Options, shows the Maintain Mass Articles app (MASS, or MM46) as an example.

However, this application doesn't support all retail article data. To fill the gap, the Maintain Mass Logistics Data - Article app (MASS_MARC) was introduced. At the same time, further retail-specific mass maintenance functions became available, for example the Maintain Mass Purchasing Info Record app (MASS_EINE), and another function for the mass maintenance of purchase orders (MASS_EKKO).

For the mass maintenance of article master records, the latest function is the Integrated Mass Change, app Maintain Mass Articles - Integrated (WRFMASSMAT). In order to determine the fields to be changed, a maintenance group has to be selected. Maintenance groups are created using the Maintain Group - Article Maintenance app (WRFMGROUP). Several maintenance groups can be created to predefine the fields to be changed, for example, one for basic data fields, another for basic data and logistics fields, and so on. The Integrated Mass Change function allows you to change data on all main views, with the exception of the Listing view and its fields.

A maintenance group includes a number of article master field groups. The field groups are defined in customizing, and contain individual, or logically grouped fields, for example field group ‘validity period’ contains the fields valid-from and valid-to. In the application, you can define cross-application or application-specific maintenance groups. You can create one or more templates for a maintenance group. You can use these templates to define default data, for example organizational data, supplier, merchandise category, and so on. A template can be selected, when a maintenance group is used for creating a core article. This means, the maintenance groups are used in various functions: They are mandatory for the integrated mass change and for creating core articles, and can optionally be used in the article list and article monitor to adjust the display of article data. The system uses a default display version if the user does not explicitly specify a maintenance group in these functions.

Due to typically large numbers of articles in a retail system, the article data base should be cleared regularly from articles, which are obsolete. This is especially relevant for retailers with mainly seasonal merchandise, as for each season, new articles are created, like in fashion retailing. However, there are different levels of discontinuation, which means not always the whole article master record needs to be discontinued, but only parts of it. For example, when one of your suppliers goes out of business, but other suppliers still deliver these articles.

• Partial Discontinuation, deleting listing conditions for the article:

  If you delete an article assignment to an assortment, it means the listing conditions are deleted (end date set to current date). With that, the article master record is still there, and there may still be stock available, however, no more orders can be placed for the article. It can still be sold, if the POS sales period is maintained accordingly. In addition, the article status could be used to prevent the article from being ordered through the requirements planning process. Deleting listing conditions can be done manually, also as a pre-step to partial discontinuation for an assortment, where then further checks are run, such as for existing stock or open documents. You can discontinue articles for assortments, for individual sites, or for example for sites of a specific distribution chain. Several site selection options are available, including the article (material) status.

• It is also possible to discontinue article data for a specific supplier, or on supplier/site level. The supplier sub-range is another selection option.

• Discontinue article (client-wide)

  The consequences of discontinuing an article completely, that is client-wide, are much greater than just deleting listing conditions. When an article is fully discontinued, the article master record will be deleted from the database along with all the article data that belongs to it, for example including purchasing info records and listing conditions. This deletion is triggered by the archiving program on due date (the residence time of an article master on the database after discontinuation can be customized).

Depending on the selected level of discontinuation, the system performs the discontinuation checks as appropriate, such as a check for listing conditions, stocks, purchasing info records, open documents (e.g. purchase orders), follow-up articles, and so on.

Data prevention: If possible, switch off updating for all data that you do not require. For example, you can deactivate billing document creation for POS inbound in Customizing.

Data compression: If possible, compress data at higher levels.

Delete: Delete data that does not need to be archived.

Archiving: Data archiving is used for data that cannot be prevented, but also can't just be deleted. In an SAP Retail project, we recommend that you activate data archiving shortly after going live. As implementing the archiving processes generally takes some time, it is important that you start this well in advance of going live with SAP Retail.

The retail environment usually involves large volumes of data.

This is due, among other things, to the large number of articles and stores. This number can have the following scale:

• Number of articles = 10 to the power of 5

• Number of stores = 10 to the power of 3

Large amounts of data are updated at article/store level:

==> Scale of data at article/store level = 10 to the power of 8

• Article data at store level (for example, stock and valuation data)

• Listing conditions

• Processing of sales data from the stores using POS inbound (resulting in stock adjustments and revenue postings)

An article list is a predefined selection of articles. It allows you to use a defined group of articles across applications. Article lists are available in the F4 Help of the article field across the system, including multiple article selection.

There are two article list types in SAP Retail: Dynamic article lists are composed of saved selection criteria, which can be used to determine the currently valid range of article numbers when executed. Static article lists contain the list of article numbers that were selected and maintained manually when the article list was created.

Static article lists can also be created in SAP BW/4HANA and transferred to SAP Retail, and vice versa. An example of this is as follows: a report in SAP BW/4HANA analyzes articles without sales turnover, which should be discontinued. This static article list is used in SAP Retail in the discontinuation workbench to start the discontinuation process.

The availability of article lists for system users is controlled by a status that has the possible values Planned, Released, and Released/Not Modifiable. Article lists with the status Planned can only be used and changed by the user who created them. Released article lists can be used and changed by all users, and the status Released/Not Modifiable means all users can use the article list, but it can not be changed except for the valid-to date.