Allocation Help Section
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.
Column | Description |
---|---|
STORE_CODE | Store's code in store master |
CHANNEL | Store's channel in store master |
STYLE_CODE | Style's code in style master |
Store List:
Activate or deactivate stores to be considered for a particular run.
Column | Description |
---|---|
CHANNEL | Store's channel in store master |
STORE_CODE | Store's code in store master |
IST_GROUP | IST group name to which this store belongs. The IST will only be suggested between other stores within this IST group |
DIST_ENABLED | Indicates if the store is enabled for IST or not. 1 is enabled and 0 is disabled |
INWARD_FLAG | Indicates if stock can be inwarded to this store or not. 1 is enabled and 0 is disabled |
OUTWARD_FLAG | Indicates if stock can be outwarded from this store or not. 1 is enabled and 0 is disabled |
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.
Column | Description |
---|---|
STORE_CODE | Store's code in store master |
CHANNEL | Store's channel in store master |
STYLE_CODE | Style's code in style master |
Warehouse Planogram:
Warehouse capacity - the total quantity that the warehouse can hold at a given point of time at a category level. The same can be set as target cover days of inventory in the replenishment cycle days column
Column | Description |
---|---|
Warehouse | Auto-Fill in Template Warehouse codes updated in the warehouse master |
Category | Auto-Fill in Template as per the enabled categories |
Quantity | Warehouse capacity at Category level |
Replenishment Days | Target days |
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 |
---|---|
Channel | Auto Fill-in Template (As per the enabled store list) |
store_code | Auto Fill-in Template (As per the enabled store list) |
category | Auto Fill-in Template (As per the enabled category list) |
WAREHOUSES | For every Store and Category combination, this column specifies the relevant warehouses from which Stock can be distributed. |
JIT Style Depth Override:
JIT categories styles are the ones where we only keep 1 unit, and the rest of them are dispatched from the warehouse. This override is to define if there are some styles out of those in which we need a certain depth other than 1(the default is 1). We need to define that depth only in these columns for pivotal and non-pivotal qty sizes.
Column | Description |
---|---|
channel | Channel to which the store belongs |
store_code | Unique code of that particular store |
style_code | Style code for which we are giving override at that store. |
pivotal_depth | Override depth to be defined for pivotal sizes of that style |
non_pivotal_depth | Override depth to be defined for non pivotal sizes of that style |
Style Wise Reserve Percentage:
Define at a channel style level, what percentage of a new style's inventory has to be reserved for future replenishments and not used during allocation
Column | Description |
---|---|
CHANNEL | Store's channel in store master |
STYLE_CODE | Style's code in style master |
Reserve_Percentage | Percent of total EAN warehouse stock to reserve for replenishments |
Style Wise Pack Sizes:
The number of pieces in which a style is packed in a box for transiting from one place to another. The pack size input is given only for those styles that can be only transported in packs.
Column | Description |
---|---|
style_code | Style for which pack size is a constraint, for example while transporting brand choose to pack 8qty for premium product in each pack and for the regular product it can be 12qty. |
pack_size | Quantity capacity per pack for style_code. |
Store Style Depth Override:
This input is used to override the tool's suggestion of what should be the depth (in pieces) that should be maintained of a style in a particular store
Column | Description |
---|---|
STORE_CODE | Store's code in store master |
CHANNEL | Store's channel in store master |
STYLE_CODE | Style's code in style master |
DEPTH | Number of stock pieces to be maintained at the store for the style |
Pullbacks Constraint:
The Pullbacks constraint gives the flexibility to define the pullback inputs at a category level if required. In case the pullback inputs are defined both in configurations and in this upload input, the upload input will be superimposed
Column | Description |
---|---|
CATEGORY | Category for which constraints are to be applied |
MAX_SALE_QTY | Styles of the category having a sales quantity less than this benchmark at the store will qualify as bottom performers |
BOTTOM_SELLER_MULTIPLIER | In a store, styles of this category having revenue per day less than (multiplier input) * category average will be tagged as bottom Sellers |
MIN_PLANO_FILL_RATE | The minimum fill rate to be maintained for the category at the store (post pullback). This will be maintained excluding pullback of broken styles. |
BOTTOM_SELLER_DISC_MULTIPLIER | In a store, styles of this category having discount greater than (multiplier input) * category average will be tagged as bottom Sellers |
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 combination.
Column | Description |
---|---|
CHANNEL | Store's channel in store master (Auto) |
STORE_CODE | Store's code in store master |
CATEGORY | Auto Fill-in Template (As per the enabled sub-category list) |
SUBCATEGORY | Auto Fill-in Template (As per the enabled category list) |
NON_PIV_SKU_MAX_DEPTH | The maximum depth that can be kept in a store+SKU for non-pivotal sizes |
PIV_SKU_MAX_DEPTH | The maximum depth that can be kept in a store+SKU for pivotal sizes |
MIN_PIV_DEPTH | The minimum depth that should be kept in a store+SKU for pivotal sizes |
MIN_PIV_SIZES | The minimum number of pivotal sizes that should be kept in a store+style combination |
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.
This list needs to be given at the parent style level. If either a parent/child style is present in the tagging list, the entire family of styles will be part of the tagging.
Column | Description |
---|---|
Channel | Store’s Channel as per the store master |
Style Code | Unique code for each style |
Season | Tagging given to select stock |
Story Style List:
List of Stories/collections with the corresponding list of styles for every story/collection.
Column | Description |
---|---|
Story | Collection/theme for style groups |
Style Code | Unique code for each style |
Min Percentage | Min percentage of styles that should go as a part of story |
Max Percentage | Max percentage of styles that go as a part of story |
Store SKU depth override:
A direct override to the depth in calculation of alloc_suggested. This trumps the store-style depth override, well enabling the client to give the depth at a more granular - SKU level.
Column | Description |
---|---|
channel | Channel to which the store belongs |
store_code | Unique code for each store |
ean | Unique code for each SKU/EAN |
depth | number of pieces that should act as the depth |
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 –
The desired style is not in the output across all stores for a channel
Its season is not given in the season list.
The season is overridden with some channels, and no store for that channel is present in the distribution store list.
Distribution failed with the “No style is live” error
No style belongs to the given season list.
Season tagging is overridden for incorrect channels.
2. Getting inventory for in-season styles –
End-date stock is not taken correctly
The end date for the run doesn’t match the date of the end date stock.
Style is not in season.
Store_inventory_flag is turned off.
GIT, Open orders, and IST in transit are not taken correctly
The end date for the run doesn’t match the date of the corresponding tables.
Style is not in season.
Git_inventory_flag is off.
Warehouse stock is not considered properly
The end date for the run doesn’t match the date of the corresponding tables.
Warehouse mapping is not given for a store category, or the 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 the above-mentioned errors can cause this error.
Identifying live styles –
A style is not present in the distribution output
It was not present in the in-season style list.
Inventory was not present for the style.
Distribution failed with the “No style is live” error
No in-season style was present in the inventory.
Calculating size depths –
No allocation happened for a store style
The size set may not be there for the Store-cat-subcat combination.
Incorrect allocation happened for a store style
The 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 to warehouse inefficiency.
Some inventory got reserved due to lead time.
ROS calculation –
ROS is zero/incorrect even though sales are there
Sales might have been cleaned up, check cleanup benchmarks
Sales might not lie in the ROS period.
It is USPL.
Top seller identification –
A style is incorrectly identified/Not identified as a top seller
Check benchmarks for top seller identification.
If a style is not identified as a top seller then sales might have been cleaned up.
Rev per day calculations –
A store style is not present in the final distribution output
There was no sales present even at the channel category level for the store style.
The total inventory available in the 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 the rev per day printed is from the reference store.
It is a parenting 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 a lower level can be better ranked because we have to maintain relative ranking for store styles resolved at the 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 the same level and SS1 has better rev per day, and SS3 is better than SS2, so a comparison between SS2 and SS1 never happened.
A store style(SS1) with no sales is ranked above a store style(SS2) which has sales
Store 1 might be a new store and rev per day was computed wrt reference Store.