Merchandise Management on Product Documentation

MDA-ARE - Area Master Data Management

Mon, 01 Jan 0001 00:00:00 +0000

The master data management process cannot be considered separately; instead, the individual instances belong to the corresponding subprojects. Therefore, this instance is handled here and is linked with the meta process MDA - Master Data Management.

MDA-ARE - Area Master Data Management

A request is made for the new creation, extension, or modification of a master data record.

tbd

REM - Item Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

REM - Item Monitoring

Item monitoring, or in-season controlling, supports decisions in the system for merchandise management within store and sales-area operations. Using filter entries, items can be viewed at different levels with regard to their inventory and sell-through indicators. Based on this information, decisions are made regarding the redistribution or revaluation or markdown of stock. The resulting development of the goods can in turn be tracked with item monitoring.

PRM - Price Management

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

PRM - Price Management

graph LR;

%% Nodes
A(PRM<br>Price Management)
B(PRM-0010<br>Create document)
C(PRM-0020<br>Select items)
D(PRM-0030<br>Edit proposal)
E(PRM-0040<br>Complete document)
F(PRM-0050<br>Release document)
G(PRM-0060<br>Post document)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F
F ==> G

%% Classes
class A btProcessTitle
class B,C,D,E,F,G btProcessActive

Store price management is carried out. Price changes or price corrections as well as markdowns per item are created and issued as an instruction for relabelling and, if necessary, for label printing.

PRN - Store Price Notification

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

PRN - Store Price Notification

graph LR;

%% Nodes
A(PRN<br>Store Price Notification)
B(PRN-0010<br>Open price notification)
C(PRN-0020<br>Edit price change)
D(PRN-0030<br>Confirm price change)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D

%% Classes
class A btProcessTitle
class B,C,D btProcessActive

The processing of centrally triggered price notifications takes place decentrally in the stores or on the sales areas. These can be carried out manually in the store or label printing is triggered. A confirmation is made that the action has been carried out.

LSD - Location Size Distribution

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

LSD - Location Size Distribution

graph LR;

%% Nodes
A(LSD<br>Location Size Distribution)
B(LSD-0010<br>Create document header)
C(LSD-0020<br>Create distribution)
D(LSD-0030<br>Modify distribution)
E(LSD-0040<br>Save distribution)
F(LSD-0050<br>Create order)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

Using a distribution, quantities per colour-size combination are distributed to the stores, meaning locations, according to certain criteria, for example for an initial allocation.

KSM - Target Stock Management

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

KSM - Target Stock Management

graph LR;

%% Nodes
A(KSM<br>Target Stock Management)
B(KSM-0010<br>Open inventory display matrix)
C(KSM-0020<br>Filter items)
D(KSM-0030<br>Create inventory matrix)
E(KSM-0040<br>Create target quantities)
F(KSM-0050<br>Save target quantities)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

The KSM process describes the definition of target stock quantities for an item based on item variant for a location. Automatic replenishment or resupply from the warehouse is aligned to these target stocks. A target stock can be generated from different documents such as sales order, purchase order, or from the inventory display matrix.

NOS - NOS Replenishment

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

NOS - NOS Replenishment

graph LR;

%% Nodes
A(NOS<br>NOS Replenishment)
B(NOS-0010<br>Create replenishment)
C(NOS-0020<br>Calculate proposal)
D(NOS-0030<br>Edit proposal)
E(NOS-0040<br>Create document)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

In retail, the sales areas in the stores can be managed centrally. To ensure that a sufficient quantity of goods is available on the sales area, replenishment is triggered. Replenishment can be achieved either from the company’s own central stock or through targeted ordering for the stores. Replenishment is generally carried out automatically, but can also be triggered manually.

TOP - Transfer Order

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

TOP - Transfer Order

graph LR;

%% Nodes
A(TOP<br>Transfer Order)
B(TOP-0010<br>Create transfer order)
C(TOP-0020<br>Capture lines)
D(TOP-0030<br>Edit transfer order)
E(TOP-0040<br>Release transfer order)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

A transfer order is created when locations are physically or organisationally separated. The transfer order contains all items that must be transferred in inventory terms from one location to another location. A transfer order can include an in-transit location that represents a means of transport or the transport route. This is necessary in order to separate the inventories so that the items are not included in availability at the time of transport. The transfer order can be linked to warehouse logistics as a source document via goods receipts and goods issues.

IRE - Store Item Request

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

IRE - Store Item Request

graph LR;

%% Nodes
A(IRE<br>Store Item Request)
B(IRE-0010<br>Create item request)
C(IRE-0020<br>Edit item request)
D(IRE-0030<br>Complete item request)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D

%% Classes
class A btProcessTitle
class B,C,D btProcessActive

An item request takes place decentrally in the stores or on the sales areas. The item can be entered, scanned, or selected via item search. Linked transfer orders are created for posting the goods, and confirmation is fed back to the system.

REI - Redistribution Instruction

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

REI - Redistribution Instruction

graph LR;

%% Nodes
A(REI<br>Redistribution Instruction)
B(REI-0010<br>Create redistribution)
C(REI-0020<br>Edit redistribution)
D(REI-0030<br>Release redistribution)
E(REI-0040<br>Monitor status)
F(REI-0050<br>Complete redistribution)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

The merchandise management process of redistribution describes the planned redistribution of stock. The redistribution of stock takes place between the stores or sales areas. In doing so, the stores are analysed with regard to their sell-through indicators and classified into potential issuing and receiving stores. Stores whose sell-through does not correspond to planning or proves poor transfer their stock to better-selling stores. This process is carried out both automatically and manually. As a result, the stores or sales areas receive scan requests based on the generated redistribution proposal, which must be completed and confirmed in the system.

REP - Store Redistribution Processing

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

REP - Store Redistribution Processing

graph LR;

%% Nodes
A(REP<br>Store Redistribution Processing)
B(REP-0010<br>Receive scan request)
C(REP-0020<br>Start scanning)
D(REP-0030<br>Edit transfer order)
E(REP-0040<br>Finish scanning)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

The processing of centrally triggered redistribution instructions takes place decentrally in the stores or on the sales areas. The instructions are transmitted in the form of scan requests. These can be printed in the store and executed manually accordingly. For confirmation, feedback is sent to the system and linked transfer orders are recorded for posting the goods. After the activities have been completed, confirmation is sent to headquarters by scan that the process has been carried out.

PBI - Withdrawal Instruction

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

PBI - Withdrawal Instruction

graph LR;

%% Nodes
A(PBI<br>Withdrawal Instruction)
B(PBI-0010<br>Create withdrawal)
C(PBI-0020<br>Edit withdrawal)
D(PBI-0030<br>Release withdrawal)
E(PBI-0040<br>Monitor status)
F(PBI-0050<br>Complete withdrawal)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

Using so-called withdrawals, retailers are enabled to centrally arrange returns of goods from the stores. The reasons for this can vary. On the one hand, it may involve defective goods that were not conspicuous during quality control. On the other hand, it may also involve a season clearing, for example, in which old goods have to be removed from the stores so that the newer collections can be presented better.

PBP - Store Withdrawal Processing

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

PBP - Store Withdrawal Processing

graph LR;

%% Nodes
A(PBP<br>Store Withdrawal Processing)
B(PBP-0010<br>Receive scan request)
C(PBP-0020<br>Start scanning)
D(PBP-0030<br>Edit transfer order)
E(PBP-0040<br>Finish scanning)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

The processing of centrally triggered withdrawal instructions takes place decentrally in the stores or on the sales areas. The instructions are transmitted in the form of scan requests. These can be printed in the store and executed manually accordingly. For confirmation, feedback is sent to the system and linked transfer orders are recorded for posting the goods. After the activities have been completed, confirmation is sent to headquarters by scan that the process has been carried out.