| Oracle® Retail Advanced Inventory Planning Data Management User Guide Release 14.1.2 |
|
 Previous |
| Oracle® Retail Advanced Inventory Planning Data Management User Guide Release 14.1.2 |
|
Previous |
This chapter provides information about the Data Management (DM) scheduling calculations including:
About the Release Schedule
The release schedule (also referred to as the lead time schedule) is the resulting output of processes that combine all of the attributes that define a supply chain including:
Receiving calendars
Lead time cycles
A number of ordering and delivery exceptions
Sourcing
Ranging
For each product, the schedule will be a series of lead times between source and destination on each day in the planning horizon that is able to receive.
This process describes how to put together the final primary lead time and alternate lead time schedule for all product/locations. The resulting schedule represents all delivery opportunities and their lead-times.
About the Release Schedule Calculation Process
The attributes that define a supply chain differ for warehouse destinations and store destinations. Therefore the process for stores is different than warehouses. Two different schedules may be output for a warehouse destination, one for primary sourcing and one for alternate sourcing. Additionally, destinations that receive cross-docked products require a different method of calculating the schedule.
The release schedule calculation includes:
The DM system allows you to set and manipulate the parameters for the store release schedule. The store release schedule must be calculated for each valid SKU/Store/day combination. This schedule is calculated real-time in the DM Store Schedule window and in the nightly batch.
The store schedule is calculated across the planning horizon for all non-cross-docked routes. This is logically defined for a SKU/Store/Day.
The store release schedule must be calculated for each valid SKU/Store/day combination. A SKU/Store/day combination is valid when the SKU is on-supply at the store on the day being processed, and the day is within the planning horizon defined for the SKU at Stores. The schedule is also calculated outside of the on-supply period to allow for User Specified Allocations (USAs).
This section describes the cycle day for all default and exception order cycles including:
Pattern Length
Every order cycle has a pattern length. For instance, the valid pattern lengths for creating an order cycle are:
Week—7 days
Fortnight—14 days
Four-Week—28 days
Day-of-Cycle
To determine the Day-of-Cycle, first determine the order cycle's pattern length. Next subtract the system wide cycle start date from the current date being processed. Finally, mod the resulting difference with the cycle length and add one (1) to get the day-of-cycle.
Perform the following actions to determine the store schedules:
Check the Corporate Non-Receipt Day and the Store Receiving Calendar. Any day that is a Corporate Non-receipt day or which is not a receiving day will not have a lead time in the release schedule.
Retrieve the single profile and the default order cycle based on the store source value.
Retrieve the day-of-cycle release lead time defined for the default order cycle. The default lead time will be overwritten by all exceptions.
Determine if the following exception exists, and apply all the existing exceptions:
Profile Release Exception
SKU Order Cycle exception
Store/Profile Order Cycle Exception
SKU/Store Order Cycle exception
SKU/Store Release Exception
If a non-N/A lead time exists for the SKU/Store/Day, determine the release date by subtracting the lead time from the current day/date.
If the release date falls on a Corporate Non-Release Date apply the Non-Release Date and Non-Release Date Exceptions to the release schedule:
If Non-Release Date Exception exists for the release date, then a valid lead time has been determined.
If no exception exists, increase the lead time by one and validate the new release date.
At no point may the release date fall before Today.
The resultant release lead time has been determined for the SKU/Store/Day. A valid lead time will be saved to the SKU/Store release schedule.
Warehouses can have primary and alternate sources. The DM system allows you to setup and manipulate the parameters for the warehouse release schedule. The warehouse release schedule defines the lead time for each day in the schedule as well as the valid receiving days.
For each day in the planning horizon, the default order cycle and other parameters are combined to produce two release schedules. They are the primary source schedule and the alternate source schedule, both of which are at the Source/SKU-pack size/Warehouse/Date combination.
Warehouse Primary-source Schedule
The warehouse primary-source schedule is calculated across the planning horizon for all non-cross-docked routes from primary sources. This is logically defined for a source/SKU/Pack-size/Warehouse/Day.
The primary source schedule is the schedule that should be used in replenishment to determine on what days an order can be placed on a specific source for delivery into a specified destination. This schedule is calculated real-time in the DM Warehouse From Source Schedule window, and in the nightly batch.
Warehouse Alternate-source Schedule
When the Warehouse has alternate sources the warehouse alternate-source schedule is calculated across the planning horizon for all non-cross-docked routes from alternate sources. This is logically defined for a source/SKU/Pack-size/Warehouse/Day.
The alternate source schedule is only used by Reconciliation as a result of the need to get inventory into a destination from a source that was not planned by Replenishment. This schedule is also calculated real-time in DM and is calculated in the nightly batch.
The process for determining the warehouse release schedule includes:
Perform the following actions to determine the primary and alternate source schedules:
Loop over the Order Group Assignments to get possible Source/SKU/Warehouse-chamber/day combinations requiring a release schedule. The process will ensure that the source is still a valid supplier or ranged warehouse.
Determine if a valid warehouse orderable unit (SKU-pack size) is defined.
Check the Warehouse Receiving Calendar. Any day that is not a receiving day will not have a lead time in the release schedule.
Also Check the Corporate non-delivery date and exceptions to determine if the day is valid to receive.
Get the order cycle assigned to the current assignment's order group. Then get the appropriate day-of-cycle lead time for the order cycle. If the lead time is an N/A value, the current date is not valid for deliveries.
Subtract the lead time from the current day to get the order release date. Check the Corporate Non-order Date and exceptions to determine if the day is valid to order.
If the resulting order release date is before the current batch run date (TODAY), no deliveries can be received on the current day.
If a source is a primary source and/or alternate source for a SKU-packsize/Warehouse day combination, then the lead time for that day should be written out to the appropriate schedule. A positive, non-zero Time-balanced Order Source Split value identifies a primary source. The lead time should be applied to the primary schedule. If the source is a alternate source the lead time should be applied to the alternate schedule.
Where a store or warehouse is the final receiving destination of cross-docked products a cross-dock schedule is calculated. Store cross-dock schedules are logically defined for a SKU/Store/Day. Warehouse cross-dock schedules are logically defined for a source/SKU/Pack-size/Warehouse/Day.
Within AIP, the term cross-docked describes the movement of a discrete quantity of inventory between an original source and a final destination through one or more intermediate locations.
Cross-docking is set up in a dedicated screen which requires the user to specify the exact path the inventory must take when being moved from original source to final destination.
The cross-dock calculation takes the individual node to node lead times, processing and max hold times and puts them together to get a single original source to final destination schedule.
This process has three steps:
Initial Checks is performed to see if it is appropriate to calculate a cross-dock schedule for the day in the planning horizon. The initial checks include two parts:
To pass the first check, the DM repository should indicate that orders between the source and destination for the SKU on the given date are cross-docked.
Perform the checks according to the final destination type.
| If the final destination is a... | Then... |
|---|---|
| Store |
|
| Warehouse |
|
If any check fails, then it is indicated that there is no delivery opportunity for the originating-source/SKU/final-destination on the given delivery-date
Cross-dock movements are made up of multiple node to node component movements. The second step of the broader process involves working out a schedule for each node to node movement that considers all additional DM-related data such as calendars, corporate delivery and receiving exceptions, sourcing and ranging data
For each node to node movement the following criteria must be met:
The day of week default value from the order cycle identified by the user for the date indicates deliveries are possible on the date in question (there is a valid lead time greater than or equal to zero days).
The lead-time on the date indicates the release date is on or after Today.
The location specific calendar and its exceptions indicate that the location is open to receive on the date.
The corporate non-delivery (to warehouse) or non-receipt date (to store) don't rule out the day as being one on which a delivery cannot take place. Note that exceptions are not considered due to the lack of Order Groups and Profiles for cross-docked locations.
The delivery date is before the Stop Receiving Date of the SKU into the warehouse.
If the delivery date meets all of the previously listed criteria, determine if its release date falls on a non-order date (valid only for warehouses) or a non-release date (valid only for stores).
If a non-order date is encountered then the delivery date can no longer be considered valid.
If a non-release dates is encountered, then the lead-time for delivery date must be incrementally increased one day at a time until it no longer falls on a non-release date.
If by increasing the lead time, the newly determined release date of the delivery falls before Today, then the delivery date can no longer be considered valid.
If the delivery date is considered valid, the resulting lead-time is written to the node to node schedule for that date.
The third step of the process is to determine the final cross-dock schedule. This schedule is calculated by putting the calculated node to node movements schedule together in combination with processing and holds times.
As a starting point, this process uses the schedule for the final node to node movement in the chain that was determined in the previous step. For each valid delivery opportunity in the final node to node schedule, the process must attempt to find valid delivery opportunities in the schedules of all the upstream movements. When searching upstream for delivery opportunities that can serve downstream movements, the downstream movement must fall no earlier than the (upstream delivery date plus processing time) and no later than the (upstream delivery date plus processing time plus max hold time).
For a valid delivery opportunity at the final destination, if a set up upstream movements can be identified that serve the final destination on the specific date, then the release date of the originating movement from the original source is used, along with the delivery date into the final destination to calculate a lead time. That lead time then indicates the total time it takes to validly move inventory from original source to final destination on the date in question in the final cross-dock schedule. Otherwise, that delivery opportunity into the final destination should be considered a non-delivery date and the final cross-dock schedule between original source and final destination should indicate it as so.
This section describes these schedule calculations:
The Final Schedule calculations include these process inputs:
| Process Inputs | Description |
|---|---|
| Store Schedule | The store schedule is calculated across the planning horizon for all non-cross-docked routes. |
| Warehouse Primary-source Schedule | Warehouses can have primary and alternate sources. The warehouse primary-source schedule is calculated across the planning horizon for all non-cross-docked routes from primary sources. |
| Warehouse Alternate-source Schedule | When the Warehouse has alternate sources the warehouse alternate-source schedule is calculated across the planning horizon for all non-cross-docked routes from alternate sources. |
| Store and Warehouse Cross-dock Schedules | Where a store or warehouse is the final receiving destination of cross-docked products a cross-dock schedule is calculated. |
| Alternates as Primary Indicator | The Alternates as Primaries indicator is a user specified setting that indicates whether or not Alternate Source lead times can be used to plan deliveries inside of the primary sources' lead times. When allowed, a lead time must be written to the primary schedule. |
The calculation takes the individual non-cross-dock and cross-dock schedules and puts them together into a single schedule by destination type. For warehouse destinations the Alternates as Primaries indicator is then used to add additional lead times to the final primary schedule.
This process performs these functions:
Because a store can only have a single source of a SKU per day the store schedule is not source specific and there is only a single possible lead time per day. As a result this process can simply overlay the SKU/store/day cross-dock schedule on top of the standard non-cross-docked schedule for the period of time where the store is the final receiving destination of a cross-dock and the store source matches the originating source of a cross-dock.
A warehouse can have multiple primary sources per SKU/pack-size/day. A schedule is output for each primary source. The warehouse cross-dock schedule is overlaid on top of the standard non-cross-dock schedule for the period of time where the warehouse is the final receiving destination of a cross-dock and the sources with a positive, non-zero source split percent matches the originating source of a cross-dock.
Where a warehouse is an intermediate node of a cross-dock route, the non-cross-dock schedule is output to the final schedule so that the warehouse may serve other destinations which are not part of a cross-dock route.
The Alternates as Primaries indicator is a user specified setting that indicates whether or not Alternate Source lead times can be used to plan deliveries inside of the primary sources' lead times. When allowed, a lead time must be written to the primary schedule.
This indicator is a scalar measure with three settings. The default value is None and this indicates that none of the processing discussed in this section should be performed. When it has any other value, the additional logic described in this section should be performed.
The aim of this additional logic is, from a business perspective, to leverage the ability of a warehouse's alternate source to deliver on a shorter lead time than any of the legitimate Primary sources. If there is an alternate source who can deliver earlier than the earliest Primary, then either the earliest or all of those delivery opportunities (depending upon the indicator) that are earlier than the earliest Primary delivery opportunity should be written out to the Primary Schedule of that Alternate Source. In effect, that Alternate Source becomes the Primary Source for the time period between the beginning of the Planning Horizon and the point at which the real Primary Sources can first deliver.
While there could be more than one Alternate Source that legitimately has a delivery opportunity before the first Primary Delivery, only the highest priority Alternate Source with a delivery opportunity before the first Primary Delivery is processed. Alternate Sources are accessed in priority order until one that meets the delivery opportunity criteria. The priority of the Alternate Sources is determined by a process called Pre-processing Alternate Source List which is documented in a separate functional spec. Once the selected Alternate Source has been processed, the processing for the current SKU-pack/Destination stops.
If there are no Alternate Sources with a delivery opportunity earlier than the earliest Primary Delivery, then the additional processing ceases having made no changes to any schedules.
The Alternates as Primaries indicator has two values that dictate whether just the earliest delivery opportunity or all delivery opportunities earlier than the earliest Primary Delivery should be written to the Alternate's Primary Schedule. The rationale for wanting to select just the earliest alternate delivery opportunity is that a retailer may prefer to plan a single delivery from the alternate source to cover the period of time before the first Primary Source's delivery rather than many.
This process performs this function:
The calculation takes the individual alternate non-cross-dock and alternate cross-dock schedules and puts them together into a single alternate schedule.
The warehouse alternate cross-dock schedule is overlaid on top of the alternate non-cross-dock schedule for the period of time where the warehouse is the final receiving destination of a cross-dock and the sources identified as alternate sources match the originating source of a cross-dock.
Where a warehouse is an intermediate node of a cross-dock route (not a final destination) the non-cross-dock alternate schedule is output to the final alternate schedule so that the warehouse may serve other destinations which are not part of a cross-dock route.
A pack change event identifies the order point where a source provides a new pack to the supply chain instead of the old pack. The event is created to trigger the automated maintenance of Data Management data that is tedious to manually change.
You can create a pack change event for one or more sources and one pack. Identify the sources highest in the supply chain where the pack change starts and not all of its affected sources. Typically this is a supplier or a set of warehouses that break packs for its destinations.
A pack change event may be permanent or temporary.
A permanent pack change:
Has no end date and does not revert back to the previous pack
May be changed to a temporary pack change (end dated)
A temporary pack change:
Has an end date at which point the locations revert back to ordering the previous pack
May be changed to a permanent pack change (no end date)
A pack change event may also have warehouse and store destination exclusions. The exclusions need only be the destinations highest in the supply chain where the pack change should not be applied.
Process
This process describes how to navigate the supply chain of a SKU pack from a source to all destinations which are not excluded from the event.
The process is the same regardless of what action is being performed, for example, an initial spread, an update of a date, or canceling the event, and so on. The process begins by undoing all pack changes created as a result of the event. This is done to ensure that no gaps are created in the timeline, particularly where dates are being modified.
The process then uses raw cycle lead times (without various exceptions and receiving calendars applied) to identify all source/destination combinations and the first delivery opportunity where the pack (either the new or reverted pack) can pass through the appropriate nodes of the supply chain to reach that destination.
Output
Applying a pack change creates an override of the preferred Orderable Unit (OU) for all SKU/locations downstream of the initiating sources which order the changing pack at the determined start of the pack change.
When the pack change is temporary the process affects two sets of changes to the OU:
From the original pack to the temporary pack
From the earliest time the original pack can be re-introduced into the supply chain
Inputs
When applying a pack change, Pack Change Events are the primary input which have the following attributes associated with them.
| Attribute | Description |
|---|---|
| Change-from pack | The initial ordering pack that will be changed either permanently or temporarily. |
| Change-to pack | The new pack that will be ordered either permanently or temporarily. |
| Sources | The list of the suppliers , warehouses, or both at the highest level of the supply chain where the change takes place. |
| First Order Date | The first date that the Change-to pack can be ordered from the sources. |
| Last Order Date | The last date that the change-to pack can be ordered from the sources. This field can be blank if the pack change is permanent. |
| Location exclusions | Destinations that should be completely excluded from the change. Each location is marked as being excluded as a primary destination and/or a secondary destination.
All destinations lower than an excluded primary destination are also automatically excluded unless the downstream destination is multi-supplied and its other source is included in the pack change. |
You can update certain aspects of the Pack Change Event, cancel the event altogether, or simply initiate event re-creation in order to capture sourcing or lead time changes.
Where an event is being changed/re-created after the initial creation the existing event pack changes, for the event in question, are removed so that a complete re-spread of the changes can take place.
When the event is being canceled no further processing occurs after removal except to update the event status indicating that all pending changes have been applied.
For each Pack Change Event with pending changes, calculation begins with the sources directly defined in the event and their destinations are found. The destinations are then used as sources and the process is repeated, finding new destinations, until no destinations are found. Destinations that either have no lead times, or do not order the change-from pack will have a pack change recorded and will not be processed as a source. This assumes that if a destination does not order the pack its downstream locations do not either, because the pack would never be available at the source.
For each source/destination the appropriate start date (starting delivery date) and end dates are found using the raw ordering cycle (end date is ignored if the pack change is permanent).
The start date for a source/destination is the date that is:
The first delivery opportunity that orders from a source on or after the source's start date (the First Order Date in the case of the top level event source)
Before a defined end date (the Last Order Date in the case of the top level event source).
When the pack change is temporary the ordering pack is changed back on the next ATP day that orders from the source after the Last Order Date.
While a pack change can be recorded between a secondary source and destination it will not trigger any changes downstream of the destination. The destination must have a primary source participating in the pack change in order to cause additional changes downstream.
