Configuration
SKU - stock keeping unit, is the term to refer to each specific product. And location is where the SKUs are stored. When we use one unit of an SKU, because we sold it or because we consumed it, we will call that consumption. SKU codes must be unique for each location, so there can be repetitions of the same SKU at different locations, but only one SKU-Location.
For each location, we need the list of SKUs that are going to be stored. FILLRATE100 will keep records for each SKU-Location.
For each SKU-Location we need to set:
SKU: the code for the item
Location: the warehouse or shop where the item is held in stock.
Description: description of the item (optional but recommended).
Unit cost: cost of one unit as indicated in quantity (optional, but recommended).
Day to replenish: a code to indicate the frequency to replenish the SKU at this location.
Transit time: number of days from order to reception of goods.
Buffer: target inventory for this SKU at this location.
Origin: the location from which the item is replenished (can be external).
* Minimum quantity can be dictated by a process or be a requirement of a vendor.
* Multiple is the number of units in the minimum package.
Examples:
Quantity to be replenished to complete the buffer is 25. See how this number is modified in these situations:
Min_qty = 30, Multiple = 1 ---> new quantity = 30.
Min_qty = 30, Multiple = 12 ---> new quantity = 36.
Min_qty = 0, Multiple = 6 ---> new quantity = 30.
'Replenishment frequency' replaces 'Day to Replenish'
This field remains free and you can use it as usual, however, a new feature is a structure that allows automating the exportation only of the replenishment orders corresponding to the current date.
The structure is X:Y:Z:W
X, Y, Z are numbers to designate days. 1 is Monday and 7 is Sunday.
W can be 0, 1 or 2.
The rationale of this structure is as follows:
Frequency must be fixed and as frequent as possible. The possible frequencies are daily, every other day, every three days, weekly and bi-weekly. If your frequency is lower that these, you won't get much benefit from the structure, or even from FILLRATE100.
Weekly means choosing one day of the week, every week.
When it is bi-weekly, we choose one day of the week and also if the week is even or odd., so the replenishment is triggered every other week.
W is 0 to indicate every week (weekly).
W is 1 for odd weeks, and 2 for even weeks (bi-weekly).
Examples:
0:0:0:0 or empty means everyday.
1:3:5:0 means on Monday, Wednesday and Friday.
2:4:0:0 means every Tuesday and Thursday.
2:0:0:1 means every other Tuesday on odd weeks.
Notes:
When the configuration is two or more days per week, W is irrelevant because it doesn't make sense a bi-weekly two days, because then frequency wouldn't be fixed. Therefore 2:4:0:1 = 2:4:0:2 = 2:4:0:0.
W can be 1 or 2, or any other odd and even numbers. This is useful in case you want to do some filtering isolating W.
If you don't use this structure, you still can filter your data but the automatic filter for the daily exporting process will not work and you will get all the replenishment orders everyday, regardless of the frequency.
In Configuration menu -> Configure Locations you can set a Transit time and a Frequency for a certain combination of Origin and Location, so all SKU with the same combination will inherit the same transit time and frequency. How it works:
It will change automatically transit time and frequency only if the combination is configured. So you can set values for some combinations and leave it free for others.
Changes in data are updated every four hours, so when you set new values in this configuration, allow some time to see the effects.
There are optional attributes that can be set for each SKU-Location:
-
Maximum buffer: automatic adjustments cannot increase buffer over this value.
-
Automatic buffer adjustment: if this not marked, this SKU-Location will be never adjust automatically.
-
Apply factor per day: when factors per day are different to 1, SKU-Location marked to be affected will produce a different quantity to replenish (by default is marked).
-
Red limit: by default Red Zone of buffer is 33.34%, so this can be altered here.
Additionally, when appropriate, Seasonality can be automated and also Equivalent SKUs. These two are explained in a different section hereunder
When in doubt, just make your best estimation and then let Dynamic Buffer Management adjust the buffer according to the real demand.
However, you may have different people replenishing different locations.
In RO mail configuration you can create as many groups as you need:
Group: name of the group that will appear in the subject of the mail.
Email list: list of emails separated with commas (no spaces).
Filter locations: if marked, it will filter results for only the locations in the list. If it is not marked, it will not filter out any location, regardless what the list says.
Locations: list of locations to include (see filter).
Filter origins: if marked, it will filter results for only the origins in the list. If it is not marked, it will not filter out any origin, regardless what the list says.
Origins: list of origins to include (see filter).
The mails sent to the email list have an attachment that can be a text file CSV (separated by semicolon), or a XLS worksheet. By default is CSV, and it can be changed in Configuration -> Replenishment Orders -> Attachment Type.
There are six pages with parameters to be configured.
Buffer Management::
-
Threshold of Reds: Percentage of reds to consider Too Much Red - TMR within a replenishment time. The default is 60.
-
Threshold of Greens: Percentage of greens to consider Too Much Green - TMG within a replenishment time. The default is 85.
-
Proportion of Blacks: Percentage of blacks when buffers are 1 or 2 units to be considered TMR.
-
Automatic Buffer Changes: Whether adjustments are automatically or manually accepted. Default is automatic. When this parameter is set to automatic, you will never see any suggested changes, however the history of all changes will be recorded. NOTE: even in automatic, you can set individually items to be in manual mode. This is a configuration of the item.
-
Automatic Buffer setting: When this is marked, any new SKU-Location that is imported will set the buffer equal to the onhand value provided. If there is no onhand value, the default is zero for the buffer.
Historic Data:
-
Days to keep color history: Number of days to keep history. Default is 360 days.
-
Days to keep adjustment history: Default is 360.
-
Days to check frequency: Number of days from today to check whether replenishment frequency was done according to planned frequency.
FTP Importing:
-
Import batch size: when files are big, this number split the data in batches to allow processing in small chunks. By default is set to 5000.
-
Field separator: data is sent to the server in files CSV, where delimiter can be a comma, semi colon or any other character. By default is semi colon. (Warning: never use a character used in descriptions or other fields).
Replenishment Orders:
-
Time to send file: Time of day to send orders. You set a date and time for today, where date is updated daily. The time is in your time zone and it is the first time that FILLRATE100 will try to generate the file to be retrieved via SFTP and sent by email to the created groups, if any.
-
Check stock at origin: if this is marked, replenishment suggestions will include a column with the availability at origin, when origin is a location in your system, otherwise it shows 'NA'.
-
Filter zeros at origin: if this marked, all items with no stock at origin will appear in replenishment suggestions, otherwise it will show the line with a zero.
-
Attachment Type: to choose the type of file that will be attached to the mails sent in groups.
Mass delete data:
-
To massively delete any set of data, just edit, mark the set, save and press the button 'Wipe selected'.
Factors to boost replenishment:
-
To alter the calculation in certain day, just edit and set the appropriate factor. Note that you can set a factor to reduce replenishment or to increase it.
-
Usually this feature allows to certain retail operations to boost replenishment on Thursdays for higher sales on weekends. Consider this are micro seasonalities within the week.
If the modification affects more than 500-1000 records, it is advisable to prepare a file to upload to the server as usual (when you have automation).
For sets of data relatively small, see instructions in the following video:
NOTE: the column 'External ID' that you get in the exportation. This is necessary to import back the modified records. However, as 'External ID' changes every time an automatic import is done, a spreadsheet prepared before that import will not work and it will show errors.
Seasonality refers to a phenomenon that is repeated year after year between the same dates, where buffers must be adjusted in factors out of the range of Dynamic Buffer Management.
This automation reduces attention to adjust buffers every time a season starts or ends.
There are two tables that must be configured.
Seasons:
-
Season: a name for the season.
-
Start date: Date to modify the buffers to trigger the appropriate replenishment before the season. When the season starts, this date is updated adding one year.
-
End Date: Date to stop replenishing in those quantities. When the season ends, this date is updated adding one year.
-
Reduction factor: if set to -1.0, at the end of the season, the buffer will take the value that had before the season started. Otherwise, the buffer will be calculated with the current buffer multiplied by this factor.
SKUs per season:
-
SKU-Location: it must exist in the data.
-
SKU, Location and Description: these are retrieved automatically.
-
Season: the season that affects this SKU-Location. Note that not all SKU-Locations must be affected by seasons.
-
Start Buffer: this is the buffer that this SKU-Location had at the end of the season the previous year, and it will be the buffer for the SKU-Location to start the season. The first time must be estimated.
-
End Buffer: This is the buffer that the SKU-Location had before starting the season. It is used only if Reduction Factor is set to -1.0.
NOTES:
-
Both Seasons and SKUS per season can be imported from Excel spreadsheets (.xls). in this case, include a column for External ID, so your data can be modified with the same spreadsheet as needed.
-
When a season is deleted, all SKU-Locations affected by that season are also deleted.
-
In few occasions, a season can be a period to reduce buffers, so Reduction factor should be higher than 1.0 or directly -1.0 to set buffers to the existing values before the season.
RECOMMENDATION: do not use this feature if you can avoid it. If two SKUs are perfect substitutes, choose one. This feature was included for specific retail operations where it is impossible to replenish exactly the same SKU every time.
If you have several SKUs that can be substituted perfectly, then you need to set a buffer for one 'parent' SKU that embraces all the 'equivalent' SKUs.
In this case, when FILLRATE100 ask to replenish X units for a parent SKU, this can be done with a combination of the equivalent SKUs adding up to X.
Configuration:
-
SKU to replenish: this is the parent SKU. In Current Status you only see parent SKUs. This can be repeated.
-
SKU equivalent: the code for another SKU that can substitute the parent SKU. This must be unique.
-
Description: description of the substitute, so in other reports you can see the exact item corresponding to this SKU equivalent.
NOTES:
-
Replenishment suggestions will just say a quantity for the parent SKU, however there will be no mention of equivalent SKUs: this must be decided by the user.
-
You can import your list of equivalents from an Excel spreadsheet (.xls). It is recommended that you add a column for External ID repeating SKU equivalent.
-
When using equivalents, you cannot manually import stock and transit data. And it is mandatory to include all the equivalent SKUs in the same file to allow FILLRATE100 to consolidate stock and transit all at once.