You are on page 1of 26

SAP Retail Overview

SAP Retail is a completely integrated retailing system. It maps the complete set of business
processes required for competitive assortment strategies, different retail formats, and ECR-driven
logistics and distribution. It provides all the functions necessary for modeling business processes in a
retail company.

With SAP Retail, SAP has endeavored to model the full "Value Chain," all the links in the logistics
pipeline from consumer to vendor. Retailers can thus optimize the whole array of business processes
and control checks in managing the flow of merchandise and information among vendors, retailers
and consumers.

The business process area "Retailing" comprises the procurement, storage, distribution, and sale of
merchandise. SAP Retail supports both wholesale and retail scenarios.

The Retail Information System (RIS) enables goods movements to be planned, monitored and tracked
throughout the whole supply chain.

The key retailing processes include:

Assortment Management

Sales Price Calculation

Promotion Management


Requirements Planning and Purchasing

Goods Receipt

Invoice Verification and Subsequent Settlement of End-Of-Period Arrangements

Warehouse Management

Picking and Delivery


Store Supply

The retailing processes enable you to control and coordinate the whole value chain, and this react
swiftly to changes in consumer behavior.

New trends, such as electronic commerce or ECR, flow continually into ongoing development cycles.
SAP Retail also allows for changes in legal structures or business practices franchising, for
example. This ensures that retailers not only have a future-proof investment but are able to adapt
swiftly to a changing market. The growth of your company is not hampered by system constraints, and
you can incorporate changes in the real world smoothly and efficiently into the system.

Integration of SAP Retail in the R/3 Environment

SAP Retail includes the base R/3 components such as Financial Accounting, Controlling and Human
Resources. And at the heart of the system is functionality specially developed for Retailing (IS-R).

The following illustration shows the areas comprising SAP Retail:

SAP Retail is fully integrated in R/3, opening up whole new opportunities in the R/3 environment. Thus
retailers and suppliers can work even closer together and become true allies in the value chain,
without having to painstakingly build bridges between systems. Joint projects for optimizing business
processes can be launched, tests carried out and the results accepted or rejected, without any large
investments in uncertain projects being necessary.
Areas of Application of SAP Retail
SAP Retail integrates all the key areas of retailing and wholesaling, all the various stages in the
supply chain and takes into account the differing requirements of different types of goods, from food
and dairy to fashion and hardlines. It provides you with the tools necessary to model all the business
processes in the retail sector.

Distributed Retailing
Distributed Retailing enables you to decentralize your business processes. The use of distributed
retailing systems (DRS) brings the following benefits for retailers:

Improved performance

Greater security

They enable decentralized company policies, whereby sites have a high degree of autonomy,
to be modeled in the system. This allows whole areas of responsibility to be assigned to those
organizational units at which information - on customers, vendors or goods movements - is
usually gathered.

Distributed retailing can take three forms:

POS Interface

With the POS Interface functions, you can link your in-store POS systems to the SAP Retail

SAP Retail Store

SAP Retail Store allows you to execute SAP Retail functions that have been created or
altered especially for in-store use.

Access via R/3 Terminal

This access possibility allows you to use all R/3 functions from any PC.

Application Distribution in Various Systems (ALE)

The technology described here allows you to distribute your applications in various R/3

Retail Switch
You can set up your R/3 system as an SAP Retail system (i.e. set the Retail switch). Only by doing
this can you use the entire scope of the functions offered by SAP Retail.

Certain SAP Retail functions are only possible in an R/3 system if it has been set up as an SAP Retail
system. Other functions, on the other hand, are only possible in an R/3 system if it has not been set
up as an SAP Retail system.

Since certain SAP Retail functions cannot be combined with other R/3 functions and vice versa (in
particular PP functions, with the exception of Requirements Planning and Forecasting), not all
functions can be used at the same time.

You are only allowed to set up your system as an SAP Retail system if you have a valid license for
SAP Retail.

Once you have set up your system as an SAP Retail system, you cannot reverse the

For information on setting up your system as an SAP Retail system, see the guide to installing R/3.

Retail Terminology
R/3 is developed exclusively using terminology that is standard throughout the system and industry
sector. In the retail industry, however, some terms are used in some languages that differ from the
standard terms used in R/3. SAP therefore offers customers working in these languages a tool for
replacing the standard terms used in R/3 with the terms specific to the retail industry throughout the
entire user interface. This tool is used for what is referred to as "Short Text Replacement".

The SAP Retail documentation is based on the assumption that you have replaced the short texts in
your SAP Retail system. When you follow links from the SAP Retail documentation to other parts of
the R/3 documentation, please note that standard SAP terminology is used and not the terms specific
to the retail industry.
The following terms differ depending on where you are in the documentation:

SAP Retail Other parts of the documentation

Article Material

Site Plant

Merchandise category Material group

Requirements planning Materials requirements planning (MRP) /

materials planning

Stock planner MRP controller

Logistics calendar Factory calendar

For a list of the languages for which you can replace the terminology in SAP Retail, see CA Short
Text Replacement: Replacement Data Available.

Terminology is only replaced in the user interface. In certain situations such as in

the F1 help the terminology of the general documentation (material, plant, etc.) is
used and not the terminology specific to retail (article, site, etc.). Standard R/3
terminology is used, in particular, in the IMG.

Organizational Structure
Flexible organizational units make it possible to reproduce even the most complex corporate
structures in the R/3 system. The large number of organizational units available in the R/3 system
enables you to reflect the legal and organizational structure of your company in the system and
represent it from different viewpoints.

The most important organizational units are listed below. Their meaning in SAP Retail is described
briefly. Many organizational units are also data retention levels; this means that if there is more than
one of a particular organizational unit, different data can be stored for each one.
Organizational Structure: Example
The following example illustrates how the structure of a company could be reproduced in SAP Retail
and explains what the various organizational units mean. The fictitious company has several
subsidiaries, which themselves comprise several distribution chains.

Organizational Structure: Example Graphic

The organizational structure of the company in the example graphic would be modeled in SAP Retail
as follows:

Central purchasing

The highest element in the whole corporate group hierarchy is the client. All the organizational
units in a client are subject to the same control mechanisms. Data valid across the whole
corporate group is stored at client level. In the example, the central purchasing department of
the company is located in the SAP Retail structure at client level.

Local purchasing

Local purchasing departments are assigned to central purchasing. Each local purchasing
department is responsible for a different distribution chain. Each local purchasing department
corresponds to a company code or a purchasing organization in SAP Retail. Specific
purchasing activities are assigned to individual purchasing groups.

Distribution chains

Local purchasing procures merchandise for different distribution chains centrally. Distribution
chains in SAP Retail are a combination of sales organization and distribution channel. The
sales organizations are assigned to different company codes.

Distribution center, Store

Distribution chains consist of distribution centers (DC) and stores. The generic term for DCs
and stores in SAP Retail is "site."

Sites are also managed as customers in the system.

Storage location, Storage section, Department

Sites can also be seen as a combination of one or more locations in close proximity to each
other where stocks of merchandise can be found (examples are storage locations and
storage sections). Stores can also be subdivided into departments, which in turn can be
understood as cost centers. Each department can be assigned a receiving point.


The value chain concludes with the customer or consumer. If the customer is recorded in the
system (and is therefore not a non-identifiable customer), natural persons can be defined in
the customer master as the contact persons at that customer.
Organizational Structure: Example Graphic
The following illustration represents the structure of a typical retail business.

Organizational Structure: Corporate Group

A corporate group is the affiliation of legally independent companies under the common management
of a controlling company. It is the highest of all organizational units in the hierarchy, and corresponds
to a retailing company with several subsidiaries (for example), which are defined from a Financial
Accounting point of view as individual company codes.

Data defined at corporate group level is valid for all purchasing and sales organizations.

On the logistics side, the corporate group divides into sites. A site is a store, a distribution center or a
production location. In SAP Retail, the site is the organizational level at which merchandise
replenishment is planned and stocks are managed. Sites can be grouped together using the
Classification System.

Organizational Structure: Company Code

A company code is an independent accounting unit that represents an independent company in the
legal sense. It is the central organizational element in Financial Accounting.

In the retail sector, company codes can be used at distribution chain level or even at the level of
individual stores. For this reason, goods movements (such as stock transfers) between different
company codes are common in SAP Retail.

Various assignments between a company code and other organizational units are possible:

A purchasing organization can be assigned to a company code. In this case, the purchasing
organization can only order for sites within this company code.

The valuation area is the organizational unit of the R/3 system via which stock is managed on a
value basis. The valuation area can be a site but it can also be a company code. In SAP Retail it is
always assumed that valuation area and site are identical.

A site (or more precisely the valuation area which belongs to a site) is assigned a company code as
an attribute in site maintenance or in Customizing.

Each sales organization must be assigned to a company code in Customizing. This assignment
forms the link between Sales and Distribution and Accounts Receivable Accounting.

Organizational Structure: Site

A site is a store, a distribution center or a production location. In SAP Retail, the site is the
organizational level at which merchandise replenishment is planned and stocks are managed.

A store is assigned one purchasing organization and one sales area (sales organization,
distribution channel and division) and thereby also a distribution chain, to which the store belongs
and which is used primarily for intercompany billing purposes. The store must be authorized to receive
goods from the sales area to which the supplying distribution center belongs. If it is to be possible for
merchandise to be transferred from one store to another, then the recipient store must also be
authorized to receive goods from the sales area to which the supplying store belongs.

Each distribution center is assigned a purchasing organization (and, if required, a sales area) for
determining warehouse transfer prices and units of measure.

A distribution center can also be assigned to a site (normally to itself) and a distribution chain (for
determining sales prices). These assignments enable merchandise in the distribution center to be
valuated at retail prices. This sort of valuation is most common in the apparel industry.

Each site belongs to exactly one company code.

Organizational Structure: Site Group

A site group is a number of sites that have been grouped together using the Classification System.

You can use the Classification System to group together sites that have similar characteristics or are
located close to each other, for example. This simplifies data maintenance, and can also be of use for
reporting purposes.

To create site groups, at least one class type has to be defined in the Classification System.

Application groups are defined in Customizing and are assigned the class type required for creating
the relevant site groups. This class type uses the customer number of the site as the key. The
application groups Allocation Table, Promotions, Season and Labeling are predefined to allow these
applications to work with the intended site groups.

Site groups operate independently of company codes, distribution chains and other fixed
organizational structures.

Organizational Structure: Vendor

Vendors are the organizational units that deliver merchandise to sites or customers (the latter is
possible in wholesale, for example, if a third-party arrangement exists). These vendors are normally
external suppliers.

Whether sites exist as vendors in the system depends on the site category: Stores are not defined as
vendors but distribution centers usually are, because a DC has a vendor function from the point of
view of stores.

If returns from a site to a vendor are to be processed with the aid of sales and distribution documents,
the vendor must also be created as a customer in the system. This will apply if delivery documents
are to be generated and billed in the system for returns from a distribution center to a vendor, for

Organizational Structure: Customer

Customers are the organizational units that buy merchandise recorded in your retailing system.

The following types of customer exist:
Non-identifiable customers (consumers). This term is generally used to describe customers
who buy merchandise from stores.

Named customers. This term is used to describe customers for whom a customer master
record exists in R/3.

Customer records can be created in a simple form (for people) or in a more complex form that allows
the use of sales and distribution functionality (for example, external customers).

The latter type of customer master record can be created not only for external customers but also for
the sites in your own company that procure merchandise from a distribution center. If returns from a
site to a vendor are to be processed with the aid of sales and distribution documents, the vendor must
also be created as a customer in the system.

Each site always exists as a customer in SAP Retail as well. Defining a site as a customer is a
required action in site maintenance.

Organizational Structure: Purchasing Organization

The purchasing organization is an organizational unit which procures articles and negotiates general
purchase price conditions with vendors. It is responsible for all purchasing transactions in the

A purchasing transaction is processed completely by one single purchasing organization.
Authorizations to maintain master data and process purchasing transactions are assigned per
purchasing organization.

The purchasing organization is used in the following areas:

When a stock transport order (order type UB) is created, all the sites (stores) ordering
together must belong to the same company code. This company code must also be the one
defined for the purchasing organization specified.

If no company code is assigned to the purchasing organization, SAP Retail uses the company
code assigned to the ordering sites. Alternatively, you can enter a company code manually.
The system checks whether the purchasing organization is allowed to order for the sites
specified. The system does not use any data from the supplying site in the order, nor does it
use any data from the combination of supplying site and receiving site (except to calculate the
delivery costs).

When a stock transport order is created between two company codes, the purchasing
organization cannot be assigned to any fixed company code if it is to order for the supplying

In standard purchase orders (order type NB) the system also checks whether the ordering
purchasing organization is assigned to the vendor. This is important for purchase price
determination, for example.
Similar checks take place for outline agreements (contracts, scheduling agreements).

Because promotions and allocation tables can be used to generate purchase orders,
purchasing organizations play a role in these areas, too. Promotions need purchasing
organizations for supply source determination and price maintenance functions; they are used
in allocation table functions for scheduling (determining the latest possible purchase order
date), for example.

In a request for quotation issued to the vendor, the purchasing organization invites a
vendor assigned to it to submit a quotation.

Purchasing organizations are data retention levels for many types of master data.

One (and only one) company code can be assigned to a purchasing organization. A purchasing
organization that has been assigned a company code can only buy for sites that belong to that
company code. If the purchasing organization is to be responsible for sites that do not all belong to
the same company code, no company code should be assigned to that purchasing organization. This
is especially important to bear in mind if the ordering site and the supplying site for a warehouse order
or return delivery are assigned the same purchasing organization but these sites belong to different
company codes.

A site can be assigned to the purchasing organization that orders for it in site maintenance. This
standard (default) purchasing organization for a site can be changed both in site maintenance and via
Customizing. When the source of supply is determined for the purposes of a stock transfer or
consignment, the default purchasing organization is used automatically. Further purchasing
organizations can be assigned to the site in addition to the default. A site cannot order if it has not
been assigned to a purchasing organization.

A sales organization can be assigned a purchasing organization for statistical purposes. If this
assignment is made and the sales organization is then assigned to a site in site maintenance, the
default purchasing organization for the site must be the one that has been assigned to the sales

In Customizing it is possible to assign reference purchasing organizations to a purchasing

organization. This allows the purchasing organization access to the conditions and contracts of these
reference purchasing organizations. The purchasing organization can make use of up to two
reference purchasing organizations when the sequence in which it accesses conditions is determined.

Vendors are assigned a purchasing organization in the purchasing-related data in the vendor master
(purchasing organization vendor).This enables the purchasing organization to order from this vendor.
A vendor can supply more than one purchasing organization. Purchasing organization-specific
purchasing info records can only be created if corresponding table entries exist. The system also uses
the purchasing organization for vendor analyses and for vendor evaluation.

In purchase price determination, a purchasing organization can be assigned a schema group. This,
together with the schema group of the vendor, determines the calculation schema for Purchasing. A
purchasing organization can also be assigned a market price schema, which allows the average
market price of an article to be maintained (for the purposes of rating a vendors price history). In
addition, it is possible to process in the system any delivery costs that may arise in connection with a
stock transport order. The calculation schema for this is determined via the schema group for the
purchasing organization, the purchasing document type and the supplying site.

Each buyer is assigned to a purchasing organization in his or her user master.

Organizational Structure: Purchasing Group
A purchasing group corresponds to a buyer or group of buyers who perform the following purchasing

Procuring certain articles or merchandise categories

Acting as the contact for vendors

Purchasing groups can function strategically, operationally, or both.

The main strategic function of a purchasing group in SAP Retail is to maintain its master data and
control data. This includes defining outline agreements and volume rebate arrangements for
Purchasing, for example.

The purchasing group is also responsible for the day-to-day planning of requirements and ordering of
merchandise.This includes creating purchase orders, allocation tables and promotions. It can also
send vendors requests for quotation or create purchase requisitions.

Purchasing groups are assigned to the purchasing areas. They are not data retention levels; they are
used as a selection criterion, as a level at which analyses can take place in the Information System
and at which authorizations can be stored.

In the individual purchasing operations you are mostly required to enter a purchasing group and a
purchasing organization. It is not possible to define an explicit link in the system between these two
organizational units.

Every stock planner is assigned to a purchasing group. You make the assignment in the user master.

Organizational Structure: Purchasing Area

A purchasing areas is an organizational unit that is assigned to the purchasing organizations
responsible for negotiations with vendors and the master data maintenance that results from them.

Purchasing areas are only used in the Information System and in standard reporting. No data or
authorizations are stored at purchasing area level.

A purchasing group can only be assigned to one purchasing area in a purchasing organization.
Organizational Structure: Stock Planner Group
A stock planner group is a stock planner or group of stock planners responsible for requirements

A site is subdivided into stock planner groups. The assignment of a stock planner group to a site is
dependent on the article involved.

If a stock planner in a stock planner group has ordering autonomy, then the purchasing group that has
been assigned to the stock planner in the user master will automatically be copied to purchase orders.

Organizational Structure: Sales Organization

A sales organization is an organizational unit in Logistics that structures the company according to its
sales requirements.

Each sales organization represents a "selling unit" in the legal sense. Its responsibilities
include product liability and any claims to recourse that customers may make. It is also
responsible for the sale and distribution of merchandise and negotiates sales price conditions. Sales
organizations can be used to reflect regional subdivisions of the market, for example by states. A
sales transaction is always processed entirely within one sales organization.

Each sales organization is assigned one company code. This company code tracks the business
transactions of the sales organization from a mainly financial accounting point of view.

When a delivery is made for a sales order, a transfer posting from the company code
of the sales organization processing the order to the company code of the supplying
site is generated (if two different company codes are involved).

In SAP Retail, a sales organization can be assigned a purchasing organization. This allows you to
create an artificial hierarchy like the one shown in the diagram, giving you access to useful statistical
information. In some cases the two terms are identical.

Employees can be assigned to a sales organization.

If a sales organization is not allowed to use all types of sales and distribution documents, it is possible
to assign it a reference sales organization so that only those sales and distribution document types
found in the reference are allowed in the assigned sales organization.

Organizational Structure: Sales Group

Sales groups (for example, each with a sales manager) are subdivisions of a distribution chain.

Sales groups can be used for reporting purposes.

A store, in its role as customer, can be assigned a sales group which is responsible for sales to this

You can also base sales groups in a store. These sales groups are then responsible for SD sales
orders in that store.

You can assign employees to a sales group.

Organizational Structure: Sales Department

Sales departments are subdivisions of stores.

Sales departments are used to group together merchandise categories in a store and determine
procurement activities in the store.

If an article in a store is also sold in departments other than the one assigned via the
merchandise category, department-based sales statistics can only be generated
accurately if the relevant department can be determined from the sales transaction (if,
for example, the department is included in the information provided by the POS
system). The same applies for layout-based statistics, such as sales area profitability,
for example. This is not contained in the standard information structures.

Each department can be assigned a receiving point.
Organizational Structure: Distribution Channel
The distribution channel is the channel through which saleable materials or services reach the
customer. Distribution channels include selling to consumers through various types of retail outlet or
via mail order.

Each distribution channel is assigned to a sales organization, and these two units together form a
distribution chain. Multiple assignments are possible.

Data is not retained at distribution channel level. A distribution channel level is not a data retention
level until it has been combined with a sales organization or (later) a division as well.

Organizational Structure: Distribution Chain

A distribution chain is a combination of sales organization and distribution channel.

The distribution chain is used to target a particular group of customers. It attaches a permanent
("static") description to its sites, which associates them with the distinctive form typical of that
distribution chain. The distribution chain to site assignment is important for the Retail Information

This static assignment is made in site maintenance in the general organizational data for the site.

For every distribution chain, you must use an indicator to define whether it is to be used for supplying
consumers (from stores) or for supplying stores (from distribution centers). This is necessary for the
following reason:

Sales prices are generally defined for a distribution chain and not for individual sites or customers. So
if the same distribution chain is used for supplying both stores and consumers, then a distribution
center will charge the store the same price as the store charges the consumer, using the selling price
defined at distribution chain level. The same applies for the determination of the units of measure to
be used for each delivery. Such associations are not usually desirable and they can be easily avoided
by using separate distribution chains to supply stores and consumers.

In Customizing you define the distribution chains for which a site can deliver merchandise. No site
can deliver merchandise until it has been assigned to a distribution chain.
For each distribution chain (sales organization and distribution channel) there is a reference
distribution channel for customer and article master data, and also for condition data and sales
document types. The data used for each of these areas is that of the reference distribution channel
rather than that of the original distribution channel.

You specify various data for the combination of distribution chain and article, including sales unit and
delivering site.

Organizational Structure: Division

A division is an organizational unit based on responsibility for sales or profits from saleable materials
or services.

Divisions have two main applications: They are organizational units for Sales and Distribution, and
they are necessary for business area account assignment for logistics transactions in Financial
Accounting. Divisions can be used to describe specific product groups and can form the basis for
sales statistics, for example.

Divisions are not used for any functions developed specifically for SAP Retail. However, a single
dummy division is provided where necessary.

Articles are assigned uniquely (client-wide) to one division.

Divisions are assigned to sales organizations.

For each combination of sales organization and division there is a reference division for customer
and article master data, and also for condition data and sales document types. This allows the data in
the reference division to be used in the original division too.

Organizational Structure: Sales Area

The sales area is the combination of a distribution chain (a sales organization and a distribution
channel) and a division. Since divisions are not actively used in SAP Retail, however, sales areas are
of little significance here and can largely be seen as synonymous with distribution chains.

Just as the purchasing organization plays an important role in calculation schema determination in
Purchasing, the sales area (together with the document schema and the customer schema) is used to
determine the sales price calculation schema in Sales Pricing.

Each site is assigned one sales area, and therefore one distribution chain as well, permanently
("statically") in site maintenance. The sales organization does not necessarily have to belong to the
same company code as the site.

If a site is to be supplied by other sources, you can define (in site maintenance) the sales areas, and
therefore distribution chains, via which the site is allowed to procure merchandise.

The "static" sales area determines the sales prices and assortments of a site, and frequently the
internal and external presentation, too.

Sales areas appear in all the main sales and distribution documents, including customer inquiries,
customer quotations, sales orders, customer outline agreements, deliveries and billing documents.

Sales areas are used for updates in the Sales Information System.

Organizational Structure: Sales Office

A sales office is an organizational unit in sales and distribution which is responsible for sales within a
specific geographical area.

Sales offices are used in sales transactions in the Sales and Distribution component. They can be
used for reporting purposes. Sales offices are optional.

A sales office can be assigned to one or more distribution chains.

A store, in its role as the customer of a sales area, can be assigned a sales office which is responsible
for internal sales to this store.

Regional sales managers are common in the retail sector. They can be represented in the system by
sales offices with the appropriate employees assigned. This regional sales manager is then
responsible for supplying the stores assigned to him with merchandise.

You can also treat each store as a sales office. This enables you to obtain statistics on the sales
volume and revenue that a store achieves through SD sales orders.

Employees can be assigned to a sales office.

Organizational Structure: Storage Location

A storage location is an organizational unit that allows you to differentiate between various types of
stock in a site.

Stocks of an article can be managed within a site in different storage locations to differentiate, for
example, between the stock stored for returns, promotions and cross-docking. Storage locations are
intended to represent warehouses or areas in a warehouse.

To reflect the complex warehouses that are typical in retailing, each storage location can be divided
into warehouse numbers, storage types and storage bins using the Warehouse Management System.
Storage locations are then used to represent areas in a warehouse. This differentiation between
stocks is therefore of most relevance to distribution centers.

If stock is to be managed on an article basis, storage locations must be used.

Organizational Structure: Department, Receiving

Point and Unloading Point
Departments are subdivisions of a ship-to party. These might be, for example, different departments in
a store, doors in a distribution center, or areas in a manufacturing plant.

Departments are assigned to receiving points, which in turn are assigned to unloading points. One
receiving point may have several departments assigned to it, but each department is assigned to only
one receiving point. If you know a department, you can therefore also determine the receiving point
and the unloading point.

Using departments and receiving points enables you to specify the final destination for a shipment or
portions of a shipment more precisely, thus reducing the time it takes for the goods to become
available for the recipients use or sale.

A pallet load of merchandise is delivered to Door 1 at a department store (unloading

point) . The shipment is broken down and delivered to one or more floors (internal
receiving points). From there the packages are delivered to one or more departments,
such as Housewares, Home Entertainment, Health & Beauty, or Womens Fashion.

Sales orders

The receiving point and department are located on the Business Data Detail Shipment
screen, either at the header or item level. If the header contains this information, this
becomes the default for all items, but you can override it for individual items if you wish. Items
in a sales order may have different receiving points and/or departments.

Picking lists and delivery notes

You can print the receiving point and department on picking lists and delivery notes. If this
information was included in the sales order, then it will automatically be inserted in these other
documents; otherwise, you can enter it manually. (However, picking lists and delivery notes
are not split by receiving point or department.)
Billing documents

You can specify that the department and receiving point are to be printed on billing
documents. You can also specify that invoices are to be split by receiving point and

In Customizing for Sales (Sales Order Processing Maintain promo./receiving pt determinatn per
sales doc.type) you can specify for each type of document whether or not automatic department and
receiving point determination is to be done.

The department and receiving points are fields in sales orders and delivery notes.

The system can automatically determine the appropriate department and receiving point for an article.
To enable this:

For external customers, you assign merchandise categories in Customer Master Data.

For internal sites (for example, stores or distribution centers), you assign merchandise
categories in Site Master Data.

In either case, you then assign valid departments and receiving points to the customer or site, and a
department to each merchandise category. A merchandise category can only have one department.

When you enter an article in a sales order, for example, the system checks the merchandise category
to which the article belongs, then checks the merchandise category information for that site or
customer and locates the corresponding department and receiving point for the article. Then, the
relevant department and receiving point for the article are determined.

Background Processing
Background Processing: Site
Background Processing: Setting Central Block for
Program RWWLOCKD sets central blocks (delivery blocks, invoicing blocks and order blocks) in line
with the blocking profile if the sites are blocked on the current date.

We recommend you run the program daily.

Background Processing: Conditions

Background Processing: Generating a Worklist of
Changed Conditions
Program RMEBEIN4 finds all the changed conditions for a specific period for the selected document
categories. It generates a separate worklist for each document category selected. You can define
which condition changes are relevant for each document category in Customizing.

The worklists have various functions, including:

Worklists for purchasing documents (purchase orders and scheduling agreements)

The worklist can be processed further by program RMEBEIN1. This determines all documents
containing changed conditions. These documents are then updated.

Worklist for Pricing

The worklist can be processed further by program RWVKP008. This determines all price
calculations based on changed conditions. The price calculations are updated, with the period
of validity being taken into account, and put into the pricing worklist.

Worklist for load building

Worklists for purchasing documents and for Pricing can be processed together by
program RMEBEIN2.

We recommend you run the report periodically. The time between running the report depends on the
number of condition changes that are made each day.

Background Processing: Adjusting Documents after

Condition Changes
Worklists for purchasing documents and for Pricing created by program RMEBEIN4 can be processed
together by program RMEBEIN2.

You must run program RMEBEIN4 beforehand. This determines and collects the conditions with the
relevant changes.

We recommend you run the report periodically. The time between running the report depends on the
number of condition changes that are made each day.
Background Processing: Assortment
Background Processing: Value-Only Article
Program RWSORT17 generates listing conditions and article master data for value-only articles on
the basis of the following changes:

The first time the articles in a merchandise category are listed for an assortment owner.

This is the only way to list hierarchy articles and other types of value-only article.

If you wish, you can use this program to list all value-only articles in all assortment owners. This
enables articles from any merchandise category to be sold at the POS.

We recommend you run the program daily.

Program RWSORT17 is a prerequisite for POS outbound processing. For reasons of system
performance, it should be scheduled to run before program RWSORT07 ("Changes after

An assortment is an object in SAP Retail for which products are listed or to which they are assigned.

Assortment users (retail companies or customers) can be assigned to the assortment. The sum of all the
products assigned via assortments therefore counts as listed.

Background Processing: Change Assortment

Automatically Following Master Data Changes
Program RWSOT07 uses change documents to identify changes to master data and then adjusts the
assortment accordingly. It can identify changes to the following types of master data:

Site/merchandise category

Sources of supply for articles

Site layout

Site classification

Supplying site

We recommend you run the report daily.

It is a prerequisite for POS outbound processing.

Background Processing: Assortment List

Background Processing: Automatically Generating
Assortment Lists
If you use the automatic option, you can have the system generate either a full version or a change
version assortment list in cycles.

Before change versions and full versions of the assortment list can be generated in cycles, a site has
to be initialized.

The relevant programs for background processing are:

RWDBBINI for initializing a site

Program RWDBBINI is used for the initial transport of the assortment list/shelf-edge
labeling data to stores with the appropriate sales organization, distribution chain and
site, using selectable assortment list categories.

The program is only run when this data is transported to the stores for the first time.

If the data is transported again, you use program RWDBBUPD.

RWDBBUPD for generating full and change versions regularly

Program RWDBBUPD sends the relevant data to the stores.

Assortment program RWSORT07 must run beforehand.

It is not necessary to run the program daily. We recommend that you run the program
weekly, at the weekend.

In the Control check box, you can select parallel processing. This is recommended if a large number
of recipients (for example, stores) receive assortment lists. You can enter the maximum number of
parallel processes and a server group to be used.

Generate mixed versions means that you combine the last assortment list with assortment list
changes. SAP recommends you generate mixed versions to improve performance.

The cycle and the number of change versions which have to be created before a full
version is created, is defined in the assortment list type.

New to SAP IS Retail? Trying to understand what assortments and listing are precisely and
how they work together?

Let me take a stab here at explaining these concepts, as they apply to SAP.

Before I jump into those 2 specific areas, let me give an overview of some common SAP IS
Retail terminology:

Article: SKU/ Material. Where you would typically create/ maintain materials using MM01/02/03,
in SAP Retail articles are maintained using MM41/42/43.

Site: The term site refers to both DCs and stores. The DC is the equivalent of Plant in non-retail
lingo. Stores are the retail stores where the goods are sold to end customers.

Now lets talk about listing. You cannot perform transactions on an article at a specific site unless
and until the article is listed to that site. This means, you cannot receive or sell the article at the
site without listing it to that site.

There is a listing period associated with listing. The article can be allocated, procured, sold,
returned at a store that it is listed to provided the transaction happens within the listing period
(i.e., listing valid from date <= transaction date <= listing valid to date).

Now lets move on to assortments. At a very basic level, an assortment in SAP is nothing but a
collection/ grouping of 1 or more sites. What is the necessity for grouping? What is the criteria?
To answer these and expland on how listings and assortments are connected, let me give an

Let us assume you own a chain of retail bookstores with 100 or more stores throughout your
country. You sell all kinds of books fiction (paper back, hardbound, book on CD formats), non-
fiction (again paperback, hardbound, book on CD formats), text books, plus notebooks, pens,
pencils and assorted stationery.

You probably want to sell the stationery items in all your 100 stores. So, instead of listing each of
those stationery items to each and every store, you create an assortment and name it ALL
STORES. Now, list all the stationery items to the ALL STORES assortment. Voila you can
now perform transactions on these articles on any of your stores in the nation.

Of the 100 stores you own, maybe 25 are located very close to schools/ universities. You notice
that in these stores, the volume of text books you sell is very high. So you want to make sure that
any and every text book you carry is certainly available in these 25 stores. What do you do?

Create a UNIVERSITY/ SCHOOL STORES assortment which has these 25 stores. Any text
book article you have list it to this assortment.

Getting the idea?

Maybe you have 10 stores that are mega stores you wish to carry every single book or item
you ever carry in these stores. Create an assortment called MEGA STORES and make sure all
active articles are listed to this assortment.

There is a validity period associated with assortments, just like with listing. The listing validity
period trumps the assortment validity period.


Assortment ALL STORES 10/14/2013 12/31/9999
Article XYZ listed to ALL STORES 1/1/2014 5/1/2014
Although the assortment ALL STORES is valid from 10/14 to eternity, article XYZ can be
procured/sold/returned in any of the 100 stores only from 1/1/2014 5/1/2014. So if you created
a PO for this article where the receiving site is A (included in ALL STORES assortment) and PO
receiving date is 12/31/2013, the system will throw an error indicating article is not listed to the
site on that date. Similarly, a sales order for this article at store A on 5/2/2014 will error out for the
same reasons.

So that was my layman explanation.

Now for some common t-codes in this area:

WSOA1/2/3/4 create/ change/ display/ delete

WSOA6 Assortment maintenance tool

WSE6 Material discontinuation for assortments. Let me explain this one with an example. Say
youve listed the entire merch cat. of fiction-mystery-paperback to the ALL STORES
assortment. There is a new fiction novel that came in the paper back version is automatically
listed to all stores (since the merch cat is listed to all stores). Within a month, you realise that
sales for this particular novel are not good. Instead of carrying it in all stores, you can discontinue
this specific article from the ALL STORES assortment and list it to the MEGA STORES
assortment instead, which is a smaller set of stores.

WSLA Display the sites in an assortment. I believe this displays the same info as WSOA3
Assortment User tab for a specific assortment.

WSLB Find all the assortments that a site is listed to.

WSM3 Mass listing of article(s) to assortment(s).

WSL11 Find the listing conditions of 1 or more articles (what assortments the articles are listed
to; validity dates)

WSM6 Delete Individual listing of article.

Background Processing: Promotion

Background Processing: Message Bundling
Program RWNASTVP generates group NAST records from the individual NAST records created using
output determination. This sorts article-related data at site level.

When creating a promotion, start program RWNASTVP.

The group NAST records generated in this way are processed by the output processing
program RSNAST00. A paper printout is then made.

You should run program RWNASTVP immediately before program RSNAST00.

We recommend you run the program daily.

Background Processing: Pricing

Background Processing: Pricing Worklist Based on

Changes to Factors Relevant to Pricing
Program RWVKP008 determines all those price calculations that are based on conditions that have
changed. The price calculations are updated, with the period of validity being taken into account, and
put into the pricing worklist.

If you also want to automatically adjust purchasing documents, you can run
program RMEBEIN2 instead of generating a pricing worklist.

Before you generate the pricing worklist, you must run program RMEBEIN4. This finds and assembles
the changed conditions for further processing.

We recommend you run the report periodically. The time between running the report depends on the
number of condition changes that are made each day.

Background Processing: Requirements Planning

Background Processing: Forecast per Period
Program RMPROG00 for the forecast run is scheduled depending on the period lengths that are

All articles for a site are always processed with a specified period indicator.