Vous êtes sur la page 1sur 68


Historically apparel and footwear companies were wholesale/manufacturing or retail

businesses but not both.

The growth of private label and the margin and marketing benefits of growing own
retail has led to brands supporting multiple sales channels:

Wholesalers and Manufacturers are expanding sales channels into retail, digital and
Retailers with strong brands are expanding sales channels into wholesale
Retailers realize they need more sophisticated solutions to get the value from long,
global apparel, footwear and fashion supply chains

Systems evolved separately to support each business, so companies often use two
ERP solutions (one AFS, one Retail) and two separate sets of business suite
applications around each ERP.

Remark: not all topics are covered in this presentation (e.g. Assortment
Planning, Retail Promotion, Retail Markdowns)

Integration of SAP Fashion Management with the SAP Business Suite

In addition to AFS retrofit and process harmonization within FMS, there is also
the need to integrate FMS with other solutions in the SAP Business Suite (BS).
As a rule of thumb, FMS (latest with its second release) will support the same
level of integration as it exists today between existing solutions of SAPs BS
with either SAP AFS or SAP Retail. Exceptions from that have been agreed
The contract does not include the enablement of the Business Suite with
fashion-specific information where it was not available before. This refers to the
fashion article (or generic article) if it was not supported before as well as for
the FMS season, FMS distribution profiles or FMS requirements and stock
segmentation. Regarding segmentation: if stock segments are modeled as
badges, solutions that can work with badges are supported. However,
requirements segments are not known in BS solutions.


Remark: The article views in general are configurable based on customer

needs. The views illustrated are only a template.


User Parameter: WMMB_MATRIX_ALV

Variant matrix is also enabled in retail specific transactions Seasonal Purchase
Order (WPOHF4C) and Purchasing List (WRFAPC01). But these TAs are not
recommended for SAP Fashion Management (no harmonization).




For SAP Fashion Management a new season concept was introduced

The old SAP Retail season fields and maintenance within customizing is disabled
within SAP Fashion Management
The season definition is a master data maintenance

Up to Season Year, Season, Collection, Theme possible

Definition of purchasing periods
Definition of sales periods

Season usage definiton at article level

More than 1 season can be assigned to an article
Season Determination within the processes


The seasons are maintained within the Season Workbench (FSH_SWB)

Within the Season Workbench all available season data are available based on
A tree with season data, a purchasing view and a sales view is available
Functions for maintenance are available
A switch to tree only display is possible
Possibility to assign articles to the season
Exceptions at variant level from a generic must be assigned within the article
master data
The highest possible data level is season year/ season + validity period
Optional: Collection definition for a season year/ season
Optional: Theme definition for a season year/ season / collection


There are two possibilities:

Season can be manually entered on sales order item level.
The system checks whether the requested delivery date is inside the delivery
window of the sales view.
Season can be determined by system (sales order item level).
In this case the system selects all possible entries for the specified sales area (Org,
channel, country, ). It is possible that more than one season are selected. In this
case the first entry is taken. The user can change this proposal via F4 help.

The season check is identically for manually entered seasons and system
determined season.

If season determination is activated on document type level either an error or

warning can be thrown. It is also possible to set it on information only.
Season re-determination report is available for both the sales and the
purchasing documents. Using this report, multiple sales or purchasing
documents can be selected and re-determination can be executed for all these
document items together.


Maintenance level for season procession (Customizing document type)

Purchase document: Purchase document type, purchase organization, purchase
Sales documents: Sales document type, sales organization, distribution channel,


Further Notes:
Advanced Shipping Notification (ASN):
When creating ASN with reference to purchase order, season information is copied
from PO
System validates information regarding season, collection, and theme during ASN

Logistic Invoice Verification:

Season information is copied from purchase order and cannot be changed

Goods Movement (MIGO):

No season determination logic available in MIGO


Characteristics like size can be called by different scales in different countries.

For example shoe size can have US size, UK size, printed in shoes.
Characteristics like color can have different names in different languages.


This slide shows a general overview of how conversion type identifier is linked
to article master, vendor master and customer master records so that when a
combination of the article and customer / vendor is used in a process
document, then appropriate value conversion gets applied to the article / variant
description by default.



Advanced Shipping Notification (ASN):

Item based and document based conversion is possible in ASN

Purchase Contracts:
Document and item based conversion of characteristic values is possible in

Goods Movement (MIGO):

Supports characteristic value conversion based on items only. (Document based
conversion can take customer and vendor information into account)



Businesses compete today in an increasingly customer-oriented market. Therefore, it

becomes necessary to streamline internal processes and logistics around the needs of each
market and its unique requirements through appropriate sourcing, planning, and supply of
goods to meet market demands.
Some articles are expected to support large volumes of data. Segmentation can be used to
order such articles by logically categorizing them based on certain criteria or characteristics.
For example, in the fashion industry, you can distinguish a fashion article such as a t-shirt
based on the size and the color. This t-shirt in a particular size and color is called an article
variant. You can enter a specific item line for an article variant. Using segmentation, you can
also order article variants of different quality levels, for different customer channels, and from
different countries of origin.

Segmentation categorizes demand and supply based on logical and/or physical

aspects of a product.
Your implemented segmentation strategy should answer the following questions:
Protect or share stock?
Separate stock physically or logically? Or both?
Criteria to define the segments? Channel? Quality?
Prioritization of segments?
In which processes and functions to use segmentation? Planning? ATP? ?
Segmentation information is kept throughout the whole E2E process chain




*Stock transport from segmented location to segmented location STO can

carry requirement and stock segment
Stock transport from segmented location to not segmented location STO can
only carry requirement segment


Stock transport order DC to DC (both segmentation relevant):

STO can carry both, requirement and stock segment

Stock transport order DC to store (only DC segmentation relevant):

STO can only carry requirement segment
Remark: List above is not complete. Please see slide Segmentation in







Use case stock protection with physical separation: Instead of using real values
for channel (e.g. Wholesale, Retail) you can also use e.g. the value common
for all channels: Common QualityA, Common QualityB.


Scope 2


Example with Scope 2



All sales relevant document types have been enhanced to support fashion
specific data:

Sales Orders

Segmentation information is copied automatically if documents are created with



Purchase documents with segmentation:

Purchase Info Rec

Purchase Requisition
Purchase Contract
Purchase Order
Stock Transport Order
Inbound Delivery
Goods Movement
Retail Stock Overview
Invoice Verification
Physical Inventory






SAP Fashion Management uses MRP Live (based on SAP HANA).

Purchase requisition and purchase orders can be internal (Stock transport from
DC to DC) or external.
Grouping for Purchase Requisitions during MRP run
combines the requirements of all variants of a generic article into one Purchase
Requisition (to be activated in Customizing)
Applicable only for variants of a generic article
Following attributes must have the same value across variants of the generic

Release date
Delivery date
Supplying plant (in stock transport requisition)
Supplier or vendor (in external procurement)
Account assignment category
Purchasing organization
Purchasing group
Requirement segments
Stock segments
Document Type
Document Category (Item category)
Storage Location



Note : Segmentation Strategy Scope

Scope option defines mapping rules or segment combinations in segmentation
strategy. Following scope options are defined:
1 Requirements and Stock Segments Maintained,
2 Only Requirements Segments Maintained


Retailers often have to centrally distribute merchandise among a large number of recipients (for
example, stores). One example would be fashion merchandise or promotional items. Using
allocation tables, you can plan the distribution of this type of merchandise and then trigger the
necessary goods movements.
An allocation table is a tool for planning merchandise distribution used by a head office to
plan, control, and monitor supplies to sites (stores, distribution centers). It is used, for example,
in initial
distribution of articles, distribution of promotional goods, distribution of stocks, and distribution
of imported goods procured centrally.
You create an allocation table in SAP Retail to split up a specific quantity of merchandise. The
allocation table contains all the important information on the how the merchandise is to be
distributed, such as the articles to be allocated, the source of supply, the recipients, the quantity
each is to receive and the delivery dates.
You also determine the goods movements (for example, direct-store-delivery) at this point. You
can have the system propose the sites. To do this, you enter an allocation rule or a site group.
You can include your own allocation strategy. You can change any default data suggested by
the system.
Allocation strategy
The allocation strategy defines how the system calculates the planned quantities for the
recipients. A strategy can process data from SAP Retail, but also data from SAP BI (for
example, sales history).
Some allocation strategies are included in the scope of delivery, others can be created by you.
You can use an allocation strategy instead of an allocation rule or manual distribution.
You can maintain an allocation strategy in the Customizing settings for the allocation table type.
This strategy is proposed in the allocation table at item level.


New Button inside Allocation Table: Soft ATP Check:

on DC Level
with Article and quantity
delivery date or delivery phases

Pop-Up with the available quantity coming back from ATP.

The user can choose either to adopt them into allocation table or cancel it and
stick to the original planned quantity.





Further fashion specific enhancements in purchase info record:

Possibility to add planned delivery time components like packing lead times



Structured article: The stock segment you select for the structured article at the
header level is not copied to its components. When you process these articles
in the purchasing documents, the system only considers the stock segment
assigned at the header level. If the components have different stock segments,
they are neither displayed nor considered for processing inside the purchase




Depending on the use case there are different Customizing entries to set up the
requirement segment determination:

A) If the site is relevant for segmentation (e.g. DC) and is supplying to site relevant for
segmentation (e.g. DC) the requirement segment is determined based on the stock
segment in one of the following ways:
Priority 1: Based on the segment value you maintain in the Customizing Logistics General
-> Segmentation -> Define Segmentation Strategies

Priority 2: Based on the default segment you maintain in the Customizing Logistics
General -> Segmentation -> Define Segmentation Structures

Priority 3: Based on BAdI: Segment Values in Purchase Order

Priority 4: If BLANK is not a valid segment and no segment value is found, the system
displays an error message

B) Site relevant for segmentation (e.g. DC) is supplying to site not relevant for
segmentation (e.g. Store). The appropriate requirement segment is determined in one
of the following ways:
Priority 1: Based on the segment value assignment you maintain in the
Customizing Logistics General -> Segmentation -> Define Requirement Segment for
Supplying Plants
Priority 2: Based on the default stock segment you maintain in the Customizing
Logistics General -> Segmentation -> Define Segmentation Structures
Priority 3: If BLANK is not a valid segment and no segment value is found, the system
displays an error message





All variants of a generic article can be displayed with detailed information

(Prerequisite: user parameter WGEN_VAR is entered in the user profile).



In IMG: split valuation is activated and configured
In the characteristic for segmentation (e.g. Quality), TA = CT04:

Segment specific valuation is flagged (relevancy of segmentation)

In article master:

Article is segmented
In Accounting Distribution Channel Data:
Valuation Category X is enabled to do new value calculation during batch creations and
(For each segment value both, standard price and moving average price can be used)


Maintenance of valuation types and standard prices is supported by

Fast Entry
Characteristic Value Conversion