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.
Additionally, by default buffer for a new SKU-Location (first time that an SKU is reported at a certain location), buffer is set equal to onhand + transit (see Configuration to change this setting to manual).
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.
-
Convert units to replenish: If this is marked, the requested quantities to the origin will be divided by multiple. The SKU code will be the same, though. For example, if the SKU is purchased in boxes of 6 units, then multiple is 6, and FILLRATE100 calculates to replenish 30, when this option is activated, the quantity requested will be 5 (boxes), however the SKU code will be that of the unit, not the box's.
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.
Note: equivalent SKUs have no buffer and are not included in the list of SKUs to replenish, precisely because they are intended to be wildcards for the 'parent SKU'.
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.
Origin of an SKU at a location is a property in FILLRATE100 that is optional however it is strongly recommended to keep it correctly set for each SKU-Location.
Why is this recommended?:
-
You can filter by origin in several views and also for the list of items to replenish that are sent to a group.
-
If origin is set and it is another location of the company, replenishment orders can filter out items with zero stock at origin, or adjust the quantity according to the available quantity at origin. NOTE: when using this feature, FILLRATE100 will not split the available quantity across different locations, because that is a managerial decision. What FILLRATE100 will try to do is to always replenish enough for all downstream locations in the first place.
When ALL items at a location are coming from the same origin, you can set the origin for the location in:
Configuration -> Configure Locations -> Set Origin for Locations
Once you set an origin for a location, every new and old item at that location will get the same origin that you set. This is not done immediately, it is a process that runs every hour that corrects these data.
Frequency and Transit Time (TT) are what makes replenishment time, which is one of the pillars of the Dynamic Buffer Adjustment mechanism. If either of both is incorrect for an SKU-Location, buffers will behave differently than intended. It is not catastrophic but it is much better to have them correctly set.
Equally as Origin, Frequency and TT are not properties that you find in your ERP so they must be configured in FILLRATE100.
Every new SKU-Location should have these set manually (importing a worksheet or just in FILLRATE100), but it is not part of the data that everyday is sent automatically.
It is reasonable that every SKU-Location with the same Origin will share the same Frequency and TT. So automating these settings saves time replacing the manual configuration for all new items or to change it massively.
You can set Frequency and TT for ALL items at a location configuring them in:
Configuration -> Configure Locations -> Parameters for Origin-Location
The way to configure these values is:
-
Choose Origin and Location from the dropdown lists and then set frequency (X:Y:Z:W) and TT.
-
This change is not immediately applied, rather a process runs every hour modifying these data with the correct ones.
NOTE: when using this feature, all frequencies or TT that were set in the past will be corrected with these values.