Exclusion List:
Specifies the store + style combinations that should not be allocated/replenished. Store name can be left blank if a Style needs to be excluded from all the Stores or a channel name can be mentioned against the style to exclude it from all stores belonging to that channel. This list needs to be changed every time there is a change in the season.
This list needs to be given at the parent style level. If either a parent/child style is present in the exclusion list, the entire family of styles will be part of the exclusion.
This input is automated.
Warehouse Master:
Contains the list of different Warehouses with the assigned IDs.
Column | Description |
|---|---|
WAREHOUSE | ID assigned to each warehouse. The same needs to be used in Warehouse Stock and Store Category warehouse mapping |
ONLINE_FULFILLMENT_FLAG | Indicates whether the warehouse’s inventory is used for Online channels as well |
Inclusion List:
The store + style combinations inputs relevant should be given preference over any other style to fill the gap at a store.
In case there are multiple styles for a single store in this list, the system decides the priority using its algorithm. This list needs to be given at the parent style level. If either a parent/child style is present in the inclusion list, the entire family of styles will be part of the inclusion.
Warehouse Store Category Mapping:
Defines the relevant warehouses from which stock can be sent along with the priority of these warehouses. Input is defined at a Store+ Category combination.
Column | Description |
|---|---|
WAREHOUSES | For every Store and Category combination, this column specifies the relevant warehouses from which Stock can be distributed. |
Freshness Status:
Style Freshness Status: Defines the Channel+ Style level Percentage of Warehouse Stock to be saved for future replenishments.
Column | Description |
|---|---|
RESERVE_PERCENTAGE | Percentage of Warehouse inventory that should be reserved for a fresh style |
Max Allowed SKU depth:
Defines the Maximum allowed quantity in Pivotal and Non-pivotal SKUs for every Store+ Category+ Sub Category combinations.
Style Level Merchandise Tagging:
This input is used to upload a set of styles for easier stock selection during the distribution run. Styles can be tagged with a name that can be different channel-wise. This name will appear in the drop-down of stock selection input which is used to read and distribute corresponding stock at stores and warehouses. |
Story Style List: List of Stories/collections with the corresponding list of styles for every story/collection.
Store Category Min Options: Minimum number of options required in each category for every store within a story/collection. The distribution will happen only if there are enough healthy options in both store and warehouse together in a particular category + story/collection.
Store Category combination priority: The combination of categories that are allowed to be dispatched to a store in a story/theme/collection in case all the categories of the story/collection are not available. The priority defined here does not play any role in the order in which the combinations are dispatched.
Possible Pitfalls:
Getting in season styles –
Desired style not in the output across all stores for a channel
It’s season is not given in the season list.
Season is overridden with some channels, and no store for that channel is present in the distribution store list.
Distribution failed with “No style is live” error
No style belongs to the given season list.
Season tagging is overridden for incorrect channels.
Getting inventory for in season styles –
End date stock is not taken correctly
End date for the run, doesn’t match the date of end date stock.
Style is not in season.
Store_inventory_flag is turned off.
GIT, Open orders, IST in transit are not taken correctly
End date for the run, doesn’t match the date of corresponding tables.
Style is not in season.
Git_inventory_flag is off.
Warehouse stock is not considered properly
End date for the run, doesn’t match the date of corresponding tables.
Warehouse mapping is not given for a store category, or table is empty.
Wh_stock_alloc_flag is set to false.
Style is not in season.
Distribution failed with “No style is live” error – All above mentioned errors can cause this error.
Identifying live styles –
A style is not present in distribution output
It was not present in the in season style list.
Inventory was not present for the style.
Distribution failed with “No style is live” error
No in season style was present in inventory.
Calculating size depths –
No allocation happened for a store style
Size set may not be there for the Store-cat-subcat combination.
Incorrect allocation happened for a store style
Size set may not be there for the Store-cat-subcat combination and suggested allocation might be coming only from ROS , so for zero ROS store skus, alloc_suggested is zero.
Warehouse data cleanup –
Incorrect warehouse stock in distribution output :
Some inventory got removed due warehouse inefficiency.
Some inventory got reserved due to lead time.
ROS calculation –
ROS is zero/incorrect even though sales is there
Sales might have been cleaned up, check cleanup benchmarks
Sales might not lie in ROS period.
It is USPL.
Top seller identification –
A style is incorrectly identified/Not identified as top seller
Check benchmarks for top seller identification.
If style is not identified as top seller then sales might have been cleaned up.
Rev per day calculations –
A store style is not present in final distribution output
There was no sales present even at channel category level for the store style.
Total inventory available in store and warehouse for the store style is zero.
Rev Per Day for a store style is printed wrongly
Sales might have been cleaned up for the store style.
It is a new store, and rev per day printed is from the reference store.
It is a parent style and revenue and live days are coming from child styles.
Store style ranking –
Store Style 1 is below/above Store Style 2 even though Store Style 1 is better/worse than store style 2
It can happen for store style resolved at different levels, and store style which was resolved at lower level can be better ranked because we have to maintain relative ranking for store styles resolved at same level. For example There is a store style SS3 between SS1 And SS2 such that ranking is SS1 > SS3> SS2, where SS1 was better than SS3 because both were resolved at same level and SS1 has better rev per day, and SS3 is better than SS2 , so comparison between SS2 and SS1 never happened.
A store style(SS1) with no sales is ranked above than a store style(SS2) which has sales
Store 1 might be a new store and rev per day was computed wrt reference Store.