Reference · built on requestOperator by FibricInventory & supply

Lead-Time Drift

Compares promised and actual supplier lead times from PO dates, ASNs and receipts, then proposes lead-time updates when they drift.

Request accessPricing ↗

About

The lead time on a vendor record is a promise. The receipts are the record. Lead-Time Drift measures the gap between them. It reads each purchase order's order date and expected receipt date, the receipts posted against it, the advance ship notices and carrier tracking where you have them, and the lead time field the item or vendor carries today.

For each vendor and item it computes the days from order to receipt over a window, and where that figure has moved away from the value on file it proposes an update. Where ship notices and tracking exist, it shows whether the days were lost before dispatch or in transit. A buyer approves each change, and the old value stays in the receipt.

This is a reference listing. It documents what Fibric would read from Lead-Time Drift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Purchase orders with orderDate, and lines with expectedReceiptDate and receivedQuantity, in Business Central
  • Business Central purchase receipts, read-only, with postingDate and the orderNumber they were posted against
  • NetSuite purchase orders, the item receipts transformed from them, and the item's Lead Time field per location
  • NetSuite inbound shipment records and WMS receiving, such as ShipHero purchase order lines with quantity_received
  • Carrier tracking events and ETAs on inbound freight through project44 or FourKites
  • Katana purchase order rows with arrival_date and received_date

Proposed actions

  • Target capability: propose a new Lead Time on a NetSuite item record when the measured value has moved off the one on file
  • Target capability: propose a new lead time for a vendor and item in Business Central, with the receipts it was measured from
  • Target capability: propose a note to the buyer when the days were lost in transit rather than before the vendor shipped
  • Target capability: propose a review flag on a vendor whose promised dates and actual receipts keep diverging

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Measure lead time from receipts, not the promise

    Business Central purchase orders and purchase receipts give the days each vendor and item took over the window. Where that differs from the value on file, an update is proposed for the buyer.

    With Microsoft Dynamics 365 Business Central, NetSuite

  • Separate dispatch delay from transit delay

    project44 tracking on inbound freight against NetSuite inbound shipments shows whether the vendor shipped late or the carrier ran late. The buyer sees which before deciding.

    With project44, NetSuite

  • Watch receiving dates at the 3PL

    ShipHero purchase order lines record quantity_received as goods arrive. Those dates against the Katana expected_arrival_date show which suppliers land late at the warehouse.

    With ShipHero, Katana Cloud Inventory

Requirements

  • Purchase orders with order dates and expected receipt dates, in Business Central, NetSuite, or Katana
  • Receipts posted against those orders, so the actual lead time can be measured
  • A lead time field per item or vendor for the proposal to update
  • A buyer or planner named to approve each update
Authentication
Read access to purchase orders and receipts in your ERP with item update rights for the lead time field, plus a WMS API key and a project44 or FourKites account where inbound tracking is used.

Limits

  • Lead time is measured from order date to receipt posting date. Days the goods sat on the dock before receiving are counted.
  • A vendor with too few receipts in the window gets a note, not a proposed value.
  • Business Central's API v2.0 does not expose the vendor or item lead time field. Updates there need a custom API page.
  • Ship notices and tracking narrow down where the days went. Without them, the proposal shows the total only.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Lead-Time Drift ↗

Questions and answers

What does the buyer approve for a lead-time change?
A single change: the lead time on file, the measured value, the receipts it came from, and the window used. The buyer can accept, set a different value, or decline. Nothing on the item or vendor record changes until then.
Which dates are compared?
Order date to receipt posting date for the actual lead time. The expected receipt date on the order for the promise. Where a ship notice or tracking exists, ship date and delivery date split the total into the vendor's portion and the carrier's.
What is kept after an update?
A receipt per proposal: vendor, item, old and new lead time, the receipts measured, the window, who approved it, and the date. The old value stays in the receipt so it can be restored.
Ask about Lead-Time Drift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy