Lead Time Calculations

Currently in oracle there are three dates which are used to correctly calculate delivery due dates to
the end user.

The below table explains what they are, where they live in oracle and who is the responsible business
owner.

Oracle Field Definition Oracle Table Business Unit

Owner
Pre-Processing Number of days to allow for Purchase Item Master Inventory
Order creation and approval
Processing Supplier lead time (this is auto populated Item Master & Procurement
from the supplier lead time in the BPA) BPA
Post Processing Number of days for the items to be Item Master Inventory
processed through the warehouse (receipt,
pick, despatch)

Currently, we are only using the processing date for all our reporting (both for the customer and within
PSCM) to identify when a product is due in or has fallen into backorder.

Promise Date

The promise date is used in all our reporting (for LHN’s and PSCM) to identify, when a product is due
in. At the time of PO creation, the promise date is defaulted to: PO creation date + processing time.

Example: if a PO was created on the 04/08/2021 and the processing time was 3 days, the promise
date would be 07/08/2021.

During the PO follow up process conducted by Purchasing, this date may change to reflect the new
promise date as advised by the supplier. *Refer to Open Po follow up process*.

Recommendation for Promise Date calculations for Supplier Orders:

No changes are recommended for Promise Date calculations – leave as is.

Field Current Calculations

Promise Date Requisitions raised Direct from Supplier (DFS)

Purchase Order creation date + processing

Requisitions raised from DC and Bulk

Purchase Order creation date + processing

Recommendation for Oracle Lead Time Business Rules

It is recommended that Inventory introduce and maintain the pre and post processing fields for all
stocked items based on the below business rule.
By having these two fields populated and maintained, we can then include these processing days in
our calculations for our DIFOT reports to accurately represent a realistic delivery date to the customer.

Field Definitions Recommendation

Pre- Time to allow from Purchase Order creation to 1 day
Processing supplier entering the order in their system.
Post Number of days for the warehouse team to receipt 2 days
Processing and put-away stock.

Need by Date

The Need by Date is generated when the requisition is created and before the requisition is converted
into a Purchase Order/Sales Order. The Need by Date cannot be used to track performance as this
can be overridden by the requisitioner. Although it cannot be used to track performance, it is still
important for the default calculation to be correctly represented.

Oracle Field Current Logic Recommendation

Need by Auto populated on the PO by the below
Date system logic Requisitions created through I-Proc

Requisitions created through I-Proc Source from DC: need by date

Source from DC: need by date is system
date + 3 working days
Source from Bulk: need by date is system
date + 3 working days
Source Supplier: Need by date is system
date + processing
Imprest order (order created by IMS
scanning)
Source from DC: need by date is system
date + 2 working days
Source from Bulk: need by date is system
date + 1 working days
Source Supplier: Need by date is system
date + 3 working days
Recommended order Report
Need by date is Sysdate + 4 working days
(weekend are not counted as working
days)
is system date + 3 working days for
country
Source from DC: need by date
is system date + 2 working days for
metro
Source from Bulk: need by date is
system date + 3 working days
Source Supplier: Need by date is
system date + processing
Imprest order (order created by IMS
scanning)
Source from DC: need by date
is system date + 3 working days for
country
Source from DC: need by date
is system date + 2 working days for
metro
Source from Bulk: need by date is
system date + 1 working days
Source Supplier: Need by date is
system date + processing

Recommended order Report

Need by date = PO creation date +

processing (supplier lead time)
 (weekend are not counted as working
days)

Re-Order Report Logic

The calculation used in the re-order report for demand planning and reordering calculations needs to
be amended to include: Pre-Processing + Processing + Post Processing

If a supplier lead time is missing, the default processing time should be 5 days.

The minimum processing lead time from supplier should not be less than 2 days. This will need to be
applied to procurement business rules when they enter the processing time in the system.

Min and Max Configuration

Inventory calculations for min and max levels does not currently consider lead time, unless supplier
lead time is more than 10 day.

It is recommended to change the min and max calculations to consider lead times for all products.

The same logic should also be applied to imprest par levels.

This Lead Time will be the combination of Pre-Processing + Processing + Post Processing.

Reporting

Sharp reports will need to be reviewed to ensure new logic is applied. Some sharp reports may no
longer apply and will need to be removed There may also be a need to create new sharp reports.

Open Po Follow Up Process

Nothing should impact the current Open PO Follow up Process. This remains the same.
It currently looks at creation date to promise date to identify a past due purchase order.

LHN Backorder Process and Report

A new Sharp Report is being proposed specifically for the LHN’s.

This report can include pre and post calculations so that the LHNs’ are provided with an accurate
delivery date rather than just seeing the supplier delivery date. This report can also exclude
terminology used internally by PSCM such as promise date, need by date etc, which will limit
confusion.

In this report a separate tab can also be added to further help the LHN’s understand the “fictious
date” being used by Procurement in their open PO follow up process.

Should the business need to change or amend delivery expectations to the LHN’s, this can easily be
done by amending formulas on a report, so they have visibility of the delay, rather than manipulating
our source data in oracle.

Delivery in Full on Time (DIFOT) Reports

There will be two DIFOT reports for Supply Chain which will need to be created to measure KPI’s

 Supplier – Source from Supplier

 Customer – Source from Inventory

Supplier DIFOT

To measure the supplier performance for supply chain we need to consider, the actual supplier
delivery time, plus the processing time required for Inventory to receipt the goods in.

Recommended calculation:

‘Receipt Date - Post Processing’ is = or < than the ‘Creation Date + Pre-Processing + Supplier Lead Time’

 26 – 2 = 24 18+1+5 = 24 24 equals 24 so the KPI has been hit.

Example of report below:

PO Processing Need by Promised Pre Post Receipt KPI

Creation (Supplier Date Date Processing Processing Date
Date Lead Time) (PO (PO (supplier (time to
Creation + creation + time to receipt and
Processing Processing receive ad put-away)
) ) enter the
order)
18/08/20 5 23/08/2021 23/08/2021 1 day 2 days 26/08/2021 YES
21
(Po (=Need by
Creation + Date)
5 days)

The 24/08/2021 is the date when theoretically goods have arrived to the warehouse. This date must
be equal or smaller than the expected delivery timeframes from supplier (creation date + pre-
processing + supplier lead time).

We have allowed 1 day for pre-processing lead time to cover the cases where our orders are not
submitted to suppliers within their cut-off times.

Note: DIFOT can only be measured for once an item has been received. If not received it’s a purchasing KPI.

Customer DIFOT

To measure the delivery performance from an Inventory to a customer for imprest items, it needs to
be measured differently based on whether it is coming from a DC or a Bulk Store.

Currently, sales orders do not have a lead time or promise date.

Recommended calculation for lead time and promise date:

Source Lead Time Promise Date

Type
DC 2 days for metro – 48h Order Creation Date + lead time
3 days for country – 72h

Bulk Store 1 day Order Creation Date + lead time

The KPI will be measured on whether we have delivered the goods within the agreed KPI.
Recommended Calculation:

‘Receipt Date’ = or < than ‘Creation Date + Lead Time + Pre-Processing

 DC - 21 18+2+1 = 21 21 equals 21 so the KPI has been hit

 Bulk - 20 18+1+1 = 20 20 equals 20 so the KPI has been hit

Example of report below for Metro:

Source Order Internal Need by Promised Pre Receipt KPI

Type Creation Lead Time Date Date Processing Date
Date (Order (Order (time to
Creation + Creation + release
Lead Time) Lead Time) sales order
to
warehouse
)
DC 18/08/2021 2 20/08/2021 20/08/2021 1 day 21/08/2021 YES

(Order (=Need by
Creation + Date)
2 days)
Bulk 18/08/2021 1 19/08/2021 19/08/2021 1 day 20/08/2021 YES

(Order (=Need by
Creation + Date)
1 day)

We have allowed 1 day for pre-processing lead time to cover the cases where sales orders are not
released to the warehouse until 24 hours later.

Note: DIFOT can only be measured for once an item has been received.

Things from PSCM to consider:

Procurement

 Supplier lead times will need to be populated for all catalogued items, not just stocked items,
otherwise they won’t be able to measure Direct from Supplier (DFS) orders correctly through
reporting
 Lead times from suppliers must include Warehouse to Warehouse, not just pick pack and
despatch otherwise DIFOT will all be inaccurate.
 The minimum processing lead time from supplier should not be less than 2 days. This will
need to be applied to procurement business rules when they enter the processing time in the
system.

Data Requirements

 How do we load the pre and post processing data in oracle – based on the 1000 items for
BFM this took 8 hours.
 How do we manage data updates as part of ongoing BAU processing as this is not in the
CMS?
 What exemption reports can be designed for missing data
o Example, a stocked item with missing pre and post processing data
Corporate Systems Support (CSS)

 Processing time of request

 Approval that recommended calculations can be done

Inventory and HSS

 Review and analyse current inventory and par levels to align to min and max/par level
calculations.