Supplier Promise Schedule Revision Evidence

What does this Actor do?

Supplier Promise Schedule Revision Evidence turns an authorized order export and supplier promise-lot export into a reproducible selected revision report. It shows which split lots contribute to a declared schedule, which older lots are retained uncounted, and where quantity, date or identity evidence needs review.

Use it after a supplier revises a delivery schedule or before handing a split-delivery promise to another operations team. You explicitly identify the revision you want reviewed for each supplier and purchase order. Revision labels are opaque strings: the Actor never chooses a “latest” revision from alphabetical order, timestamps or row order.

Why use a revision and split-lot report?

A line can have several valid delivery promises with distinct promise IDs. Mixing an older schedule into those lots can inflate the apparent quantity. This Actor keeps the complete supplied evidence while calculating per-line quantities only for your selected revision. It separates confirmed, backordered and cancelled declarations, and divides active promises into on-time, late and undated quantities relative to the required date.

This is a batch tool available through the Apify API and integrations. It does not connect to suppliers or update your purchasing system. Connected ERP users may already have this workflow; it is useful when you have normalized exports that need an explicit, reviewable schedule artifact.

How to review a supplier promise schedule

1. Export authorized order lines and normalized promise lots. Preserve supplier, PO, line, SKU, unit, revision and promise identifiers as strings, including leading zeros.
2. Supply orderLines and promiseLots arrays, or use the mapped CSV alternative for either table. Delete the relevant array field when using a nonempty CSV field.
3. Supply selectedRevisions with one entry per exact supplier/PO and explicit coverage of complete or partial.
4. Run the Actor and inspect the order-line and promise-lot evidence alongside the findings.
5. Download full JSON, evidence CSV, findings CSV or standalone HTML. Keep the unresolved evidence with any handoff.

Input and quantity rules

Order lines contain rowId, supplierId, poId, lineId, sku, unit, orderedQuantity and requiredDeliveryDate. Promise lots contain the same exact identities, plus revisionId, promiseId, quantity, status and optional promisedDeliveryDate. Status is exactly confirmed, backordered or cancelled.

Quantities are positive decimal strings with at most 15 integer digits and six fractional digits. Dates are real YYYY-MM-DD calendar dates. The Actor uses exact decimal arithmetic and produces decimal strings; it never totals quantities across unlike units or invents a unit conversion.

CSV supports BOMs and quoted values. Required mapped headers must exist and be distinct. Duplicate or unmapped headers and irregular rows are rejected. A blank optional promise date means no supplied date. Every source row needs a unique rowId within its table; this does not make repeated business identities safe.

What does the output mean?

Field	Meaning
selectedRevisionId, coverage	Your declared scope for this supplier/PO
confirmedQuantity, backorderedQuantity	Active promise declarations in the selected supplied scope
cancelledQuantity	Separate cancellation declaration, never fulfillment
onTimeQuantity, lateQuantity, undatedQuantity	Active promise quantities relative to the required date
declaredQuantity	Confirmed + backordered + cancelled declarations
observedQuantityDelta	Supplied declaration quantity minus ordered quantity
unallocatedQuantity	Ordered minus declared quantity only for resolved, complete supplied scope
sourceRefs	Exact input table indexes and row references supporting the evidence

One dataset item contains the complete report, source evidence, rows and findings. The dataset can be downloaded in formats including JSON, CSV, HTML or Excel through Apify; the dedicated evidence CSV is the flat line-and-lot artifact. The dedicated HTML download is escaped, has no external scripts and should be opened locally.

How are partial and ambiguous schedules handled?

Partial coverage describes supplied lots only. The report leaves unallocatedQuantity unknown; it cannot establish what an omitted part of the schedule contains. Even when you declare complete coverage, a missing line stays unknown instead of becoming zero or cancelled.

Repeated order keys or selected-revision entries are unresolved even when identical. A duplicate promiseId within the same supplier/PO/revision, including across lines, is not counted. Incompatible SKU/unit evidence also prevents full-line totals. Valid individual selected lots remain visible when another lot makes the full line unresolved. Unselected revisions remain traceable as superseded_revision rows and contribute no quantity to the selected schedule.

Price, limits and recovery

The price is $0.25 per completed report, with platform usage included. There is one report-completed event and no positive dataset-item or startup event. Each new run is billable again; a same-run resurrection repairs missing exports without producing a second dataset item or report event when the prior report and charge are intact.

Input is limited to 4 MB and 2,000 combined order, promise and selector rows. Ambiguous source-reference fanout is capped at 20,000 occurrences. Full JSON must remain below 8 MB and each export below 9 MB before a report event can be charged. Split larger or heavily duplicated batches. Malformed input, insufficient budget and output-cap failure do not deliver a completed report event.

Boundaries and support

A promise is future supplied evidence. This report does not establish supplier approval, an accepted contract, shipment, delivery, fulfillment, purchasing authority or live ERP state. It does not compare prices, invoices or receipts, parse EDI/XML/PDF files, forecast demand or message a vendor. Normalize your records before use, and upload only opaque authorized identifiers; inputs and results are stored in your Apify run.

A balanced supplied declaration is not a business approval. Review flagged or incomplete records with their source references. Use the Issues tab for a reproducible synthetic example and the API tab for programmatic batch access.