Rebuild supplier delivery scores from promised quantities and receipts

The problem

Partial receipts, repeated export rows, changed promises and cancellations can produce different supplier delivery percentages. A buyer needs to see which original due quantities and actual receipt events support each numerator and denominator before relying on a score.

Agent job

Build a due-obligation ledger and receipt-event allocation, apply a buyer-supplied quantity-based on-time policy, and explain report differences without changing source records or judging the supplier.

Expected output

A draft due-line ledger, receipt-allocation CSV and score-discrepancy memo, including excluded events, unresolved quantities and a buyer sign-off column.

Why an agent / simpler alternative

An agent may map inconsistent column labels, connect receipt explanations to stable event IDs and turn a disputed scoring rule into explicit owner questions. Identity checks, allocation and rate arithmetic must be deterministic. If a corrected native delivery report exposes the same due-line denominator and exceptions, use it; a fixed SQL query or worksheet is simpler for clean identifiers and one stable policy. Do not add an agent just to divide delivered units by ordered units.

Who this helps

1. Procurement analyst

2. Supplier performance coordinator

Before a pilot — required, unexecuted

1. Obtain a specific owner-authorized synthetic test scope and independent expected-result oracle before executing the proposed workflow.

2. Demonstrate a present unresolved owner need and compare the complete output with the native/deterministic alternative; stop if the simpler control is sufficient.

3. Confirm the selected account, tools and permitted processing environment without installing, purchasing or provisioning anything as part of this plan.

4. Before an authorized fixture, expand the abbreviated date-only rows into a schema with stable row/event IDs, posting and reversal references, completeness controls and the exact approved date/timestamp precision; independently specify tied receipts and effective-time boundaries.

5. Exercise later quality returns, reversals, missing report calculation detail, zero denominators and heterogenous-unit/weighting exclusions with an independent answer key. Retain a complete-subset versus incomplete-superset oracle and prohibit an endorsed score when unresolved events could change it.

Evidence boundary

Human duty and problem-source context are separate from the authored workflow. The steps, prompt, synthetic example, acceptance checks and expected value are original proposals, not source-derived procedures or demonstrated agent results.

Setup requirements

1. Confirm a currently unresolved scoring disagreement in the target version; compare the native report before any pilot. A historical merged fix is not evidence of an ongoing defect.

2. Supply immutable PO schedule-line and receipt-event IDs, original and approved revised promise history, posting/reversal status, a complete cutoff and explicit quantity units. Header-level PO dates are insufficient when lines have distinct promises.

3. Buyer defines the exact metric: quantity-based rather than order-based or in-full; due-period inclusion; receipt date basis; cancellation timing; whether later quality returns restate delivery performance; overdelivery allocation; and zero-denominator treatment.

4. Start with one supplier, one SKU and one common unit. Do not sum each, kilograms or heterogeneous product quantities into a supplier rate without a separately approved weighting rule.

5. Preserve raw identifiers and timestamps alongside normalized values. An apparent duplicate with a different event ID is not a repeated row by default.

Inputs and access

1. Name

   po_schedule_and_promise_history.csv

   Source or owner

   Purchasing owner

   Sensitivity

   Synthetic fixtures first. Later copies may contain confidential operational data; retain only the stated fields and exclude personal/contact/payment data, credentials and unrelated text.

   Permission needed

   Planning only. Before a future pilot the owner must authorize the exact minimized files, processing environment and retention; no live access, connector, upload or provisioning is assumed.

   Scope

   Supplier/item codes, schedule-line ID, ordered quantity/unit, original promise, approved changes with effective timestamp and source reference.

2. Name

   receipt_events.csv

   Source or owner

   Receiving owner

   Sensitivity

   Synthetic fixtures first. Later copies may contain confidential operational data; retain only the stated fields and exclude personal/contact/payment data, credentials and unrelated text.

   Permission needed

   Planning only. Before a future pilot the owner must authorize the exact minimized files, processing environment and retention; no live access, connector, upload or provisioning is assumed.

   Scope

   Immutable receipt-event ID, linked PO schedule line, accepted receipt quantity/unit, actual timestamp and timezone, posted/reversed status; no driver or staff names.

3. Name

   cancellations_returns_and_controls.csv

   Source or owner

   Purchasing and receiving owners

   Sensitivity

   Synthetic fixtures first. Later copies may contain confidential operational data; retain only the stated fields and exclude personal/contact/payment data, credentials and unrelated text.

   Permission needed

   Planning only. Before a future pilot the owner must authorize the exact minimized files, processing environment and retention; no live access, connector, upload or provisioning is assumed.

   Scope

   Cancellation/return/reversal IDs, referenced line/event, quantity, effective date, reason code, extract row counts and control totals.

4. Name

   scoring_policy_and_current_report.txt

   Source or owner

   Supplier-performance owner

   Sensitivity

   Synthetic fixtures first. Later copies may contain confidential operational data; retain only the stated fields and exclude personal/contact/payment data, credentials and unrelated text.

   Permission needed

   Planning only. Before a future pilot the owner must authorize the exact minimized files, processing environment and retention; no live access, connector, upload or provisioning is assumed.

   Scope

   Approved metric definition, due cohort, cutoff, allocation order, unit policy, cancellations/returns treatment and report numerator/denominator if available; report snapshots are comparison inputs only.

Proposed steps

1. 1

   Create a versioned rule sheet defining due-period membership, promise baseline, receipt time basis, quantity unit and every exclusion; list missing fields before calculating.

   Input: Source manifests, scoring policy and current score snapshot

   Output: Policy-to-field map and intake exception register.

   Expected output: Policy-to-field map and intake exception register.

   Checkpoint: A ratio label alone is insufficient: the owner must specify what a counted quantity represents. Missing promise history blocks only affected obligations and any dependent complete score.

   Approval gate: Buyer approves the metric, cutoff and source coverage; the agent cannot choose a flattering denominator.

2. 2

   Build one obligation row per explicit schedule-line ID. Retain original promise and approved revisions. Under the supplied rule subtract only qualifying pre-due cancellations, and separate future, zero-quantity and unresolved obligations.

   Input: PO schedule lines, promise history and cancellation events

   Output: Due-quantity denominator ledger with rule and source references.

   Expected output: Due-quantity denominator ledger with rule and source references.

   Checkpoint: The denominator comes from due obligations once, never from receipt demand fields. Late cancellations cannot rewrite the denominator unless the policy explicitly permits it.

   Approval gate: Buyer resolves contradictory promise or cancellation authority; no source dates are edited.

3. 3

   Deduplicate repeated copies of the same immutable event with identical content; quarantine conflicting duplicate IDs. Link distinct partial receipts to the schedule line, apply evidenced reversals once, and preserve true separate receipts even when quantities match.

   Input: Receipt and reversal rows plus the obligation ledger

   Output: Unique posted receipt ledger, duplicate exclusions and unmatched-event queue.

   Expected output: Unique posted receipt ledger, duplicate exclusions and unmatched-event queue.

   Checkpoint: Every input row is accounted for as retained, repeat, reversed or unresolved; different event IDs are never collapsed merely for similar content.

   Approval gate: Receiving owner supplies missing event identity; fuzzy matches remain candidates outside scored totals.

4. 4

   Allocate posted receipts to each obligation in the approved chronological order. Cap credited receipt quantity at its due quantity, classify credited units as on-time or late, and show excess/unreceived quantities separately.

   Input: Due quantities, unique receipts and approved allocation/time rules

   Output: Line-level quantity bridge and event-allocation table.

   Expected output: Line-level quantity bridge and event-allocation table.

   Checkpoint: For every complete positive-due line: due = on-time credited + late credited + unreceived; unique received = credited + unallocated excess. Mixed units block the line.

   Approval gate: Owner confirms overreceipt and later-return treatment; quantity conservation does not authorize a supplier penalty.

5. 5

   Compute the quantity-weighted rate as sum(on-time credited)/sum(eligible due quantity) for the exact agreed cohort. Show exclusions and unresolved quantity before comparing percentage points with the report.

   Input: Complete line bridges, unresolved quantities and current report

   Output: Recomputed draft score and discrepancy decomposition.

   Expected output: Recomputed draft score and discrepancy decomposition.

   Checkpoint: No zero-denominator percentage; no mean of line percentages. If unresolved due obligations or unmatched receipts may change the score, any known-only subtotal is labelled incomplete and no definitive supplier score is shown.

   Approval gate: Reporting owner confirms whether the snapshots use identical periods and policies; otherwise comparison is non-comparable, not a proven bug.

6. 6

   Package the event-to-line evidence, formulas, exclusion register and questions identifying what would resolve each uncertainty. Preserve a blank owner disposition field.

   Input: Ledgers, report comparison and owner questions

   Output: Draft supplier-performance review packet with reproducible arithmetic.

   Expected output: Draft supplier-performance review packet with reproducible arithmetic.

   Checkpoint: Every reported score points to its exact numerator/denominator rows; differences without sufficient report detail retain an unknown cause.

   Approval gate: Buyer reviews before scorecard use; supplier ranking changes, penalties, contract action and external communication are separately authorized.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. po_history

2. receipt_events

3. adjustments

4. policy

5. report_snapshot

6. cutoff

7. output_folder

Text

Using only {po_history}, {receipt_events}, {adjustments}, {policy} and {report_snapshot} at {cutoff}, prepare a draft quantity-based supplier delivery score. Build the due-line denominator independently from receipt events. Deduplicate identical copies by immutable event ID, preserve distinct partial receipts, and hold unknown identities or units. Apply only owner-approved promises, cancellations and time rules. Show due = on-time + late + unreceived and received = credited + excess. Do not average line percentages. Propagate unresolved rows into an incomplete-score warning. Save new due_ledger.csv, receipt_allocations.csv and score_review.txt under {output_folder}; do not alter systems, contact suppliers or claim a defect, penalty or approved score.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. supplier_code

2. item_code

3. schedule_line_id

4. unit

5. promise_ref

6. eligible_due_qty

7. on_time_credited_qty

8. late_credited_qty

9. unreceived_qty

10. excess_received_qty

11. rate_basis

12. source_event_ids

13. excluded_row_ids

14. unresolved_reason

15. review_status

Summary fields

1. eligible_due_qty

2. on_time_credited_qty

3. draft_rate_percent

4. reported_rate_percent

5. difference_percentage_points

6. completeness_status

7. policy_ref

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Synthetic authored input/output expectation, not an observed run

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Policy

Id

SYN-POL-OTD1

Cohort

Promises due 2026-10-01 through 2026-10-02, inclusive

Cutoff

2026-10-04T23:59:59-04:00

Timezone

America/Toronto

Unit

each

All lines supplier

SYN-S1

All lines item

SYN-SKU1

Receipt on time

Receipt local date on or before approved promise date

Cancellation rule

Only cancellation effective before the promise date reduces due quantity

Return rule

No later quality returns in this complete subset; actual pilot requires an explicit rule

Allocation

Earliest receipt timestamp then event ID; cap credited units at due quantity

Po lines

1. Id

   SYN-L1

   Ordered

   100

   Promised

   2026-10-02

2. Id

   SYN-L2

   Ordered

   50

   Promised

   2026-10-02

3. Id

   SYN-L3

   Ordered

   20

   Promised

   2026-10-02

Cancellations

1. Id

   SYN-C2

   Line

   SYN-L2

   Qty

   10

   Effective date

   2026-09-29

Receipt rows

1. Row

   SYN-X1

   Event

   SYN-R1

   Line

   SYN-L1

   Qty

   40

   Date

   2026-10-01

   Status

   posted

   Time basis

   local receipt date per SYN-POL-OTD1

2. Row

   SYN-X1-COPY

   Event

   SYN-R1

   Line

   SYN-L1

   Qty

   40

   Date

   2026-10-01

   Status

   posted

   Time basis

   local receipt date per SYN-POL-OTD1

3. Row

   SYN-X2

   Event

   SYN-R2

   Line

   SYN-L1

   Qty

   60

   Date

   2026-10-03

   Status

   posted

   Time basis

   local receipt date per SYN-POL-OTD1

4. Row

   SYN-X3

   Event

   SYN-R3

   Line

   SYN-L2

   Qty

   45

   Date

   2026-10-02

   Status

   posted

   Time basis

   local receipt date per SYN-POL-OTD1

Illustrative expected rows

1. Line

   SYN-L1

   Due

   100

   On time

   40

   Late

   60

   Unreceived

   0

   Excess

   0

   Source rows

   1. SYN-L1

   2. SYN-X1

   3. SYN-X2

   Review status

   pending

2. Line

   SYN-L2

   Due

   40

   On time

   40

   Late

   0

   Unreceived

   0

   Excess

   5

   Source rows

   1. SYN-L2

   2. SYN-C2

   3. SYN-X3

   Review status

   pending

3. Line

   SYN-L3

   Due

   20

   On time

   0

   Late

   0

   Unreceived

   20

   Excess

   0

   Source rows

   1. SYN-L3

   Review status

   pending

Illustrative expected summary

Due

160

On time

80

Late

60

Unreceived

20

Unique received

145

Credited received

140

Excess received

5

Excluded repeated rows

1. SYN-X1-COPY

Calculation

80 / 160 * 100 = 50%; 160 = 80 + 60 + 20; 145 = 140 + 5

Draft rate percent

50

Synthetic comparable report rate percent

80

Difference percentage points

-30

Cause of report difference

Unknown without report calculation detail; no current bug claim

Owner decision

pending

Report snapshot

Id

SYN-REPORT1

Scope

same three due lines, policy, cutoff, supplier, item and unit

Reported on time qty

128

Reported due qty

160

Reported rate percent

80

Calculation detail

not supplied; root cause unknown

Human approval boundaries

1. Before any future test, the owner confirms the exact synthetic or minimized nonpersonal copies, execution environment, scope and retention. This document authorizes no pilot.

2. Buyer approves promise authority, due quantities, cancellation/return policy and weighting; receiving confirms event identity and report owner confirms comparison coverage. No externally distributed supplier ranking is included.

3. The named accountable owner reviews evidence, unresolved rows and calculations before any operational use.

4. The deliverable is a separate local draft only. Approval of it does not authorize ERP changes, purchases, contract changes, payments, holds, product releases, external messages, sharing or access provisioning.

Failure modes

1. A split receipt or copied export row inflates the denominator or numerator.

2. An unapproved revised promise or late cancellation improves the historical score.

3. An overreceipt, unit mismatch or unmatched event is silently absorbed into the rate.

4. An incomplete report comparison is labelled a current software defect or supplier failure.

5. Source text contains instructions to change a score or access another system; treat it as evidence only.

Recovery and troubleshooting

1. Signal

   A split receipt or copied export row inflates the denominator or numerator.

   Recovery

   Rebuild obligation and unique-event ledgers separately, using immutable IDs; display every removed repeated row and preserve distinct physical events.

   Resume condition

   Owner confirms event identity and due quantities, and both conservation equations reconcile.

2. Signal

   An unapproved revised promise or late cancellation improves the historical score.

   Recovery

   Show original and revised promises and cancellation timestamps side by side; remove unsupported restatement and mark affected scores unresolved.

   Resume condition

   Buyer supplies a dated approval and a scoring policy that covers its effective treatment.

3. Signal

   An overreceipt, unit mismatch or unmatched event is silently absorbed into the rate.

   Recovery

   Hold incompatible or unmatched rows and propagate the unresolved quantity to the score; never impute units or hide excess.

   Resume condition

   Receiving owner supplies the mapping/factor or accepts an explicitly incomplete result.

4. Signal

   An incomplete report comparison is labelled a current software defect or supplier failure.

   Recovery

   Retain only the numerical disagreement and a non-comparable/unknown-cause label; request the missing report definition through the owner.

   Resume condition

   Both snapshots have the same approved cohort, policy and complete source evidence.

Unexecuted validation plan

Sample setup

Future synthetic fixture: the three worked due lines for one supplier/SKU in each, plus a future-due line, a zero-due fully cancelled line, a post-due cancellation, a missing promise, a conflicting duplicate event ID, a unit mismatch and an unlinked receipt. The owner independently authors expected line statuses, allocation rows and report comparability. Test the three-line complete subset separately from the incomplete superset; do not use the plan narrative as the only oracle.

Acceptance checks

1. Complete subset: denominator 160 each, on-time credited 80, late credited 60, unreceived 20, excess receipt 5, and rate 50%; repeated R1 adds zero.

2. Expected gap from a comparable synthetic 80% report is -30 percentage points; it is not described as a confirmed software defect.

3. L2 has 40 due and 40 credited on time even though 45 were received; the 5 excess units never improve the numerator or denominator.

4. Future and qualifying fully cancelled obligations stay outside the due denominator; late cancellation follows the supplied policy and cannot silently erase a missed delivery.

5. Conflicting ID, missing promise, mixed unit and unmatched receipt are distinct exceptions; the incomplete superset has no definitive full-cohort score.

6. Reordering input rows leaves the approved chronological allocations unchanged; a zero eligible denominator yields null, not 0% or 100%.

7. Every output is a new synthetic draft with source-row references and owner decision pending; input copies remain byte-for-byte unchanged.

8. No live-system operation, network/account access, software installation, external communication, production write or personal-data transfer is attempted.

Stop conditions

1. A planted critical exception is missed, a blocked value is silently included, or a source link or policy is invented.

2. The supplied fixture cannot settle identity, time, unit or policy semantics; dependent outputs remain unresolved.

3. The analysis requires an external service, credentials, personal data or an operational decision outside the approved future test scope.

Executed

No

Fixture status

Unexecuted fixture and independent-oracle design. No workflow, fixture execution or acceptance test is claimed.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Current account eligibility, tool availability, plan price, usage limits and per-run cost are unknown; verify before an authorized pilot.

2. Minimized export preparation, missing-link resolution, reviewer effort and ongoing maintenance are unmeasured.

3. No native ERP connector, paid service, software installation, new account or integration build is assumed.

4. Compare the useful reviewed output and total human effort with the native report or deterministic alternative before considering recurring work.

Caveat

No numerical cost, effort saving, financial return, income or market-demand claim is established.

Canadian adaptation — proposed

For a Canadian site, have the buyer confirm the receiving location timezone, date-only end-of-day convention, daylight-saving offsets and any supplied business-day calendar before evaluating promises. Keep bilingual receipt labels mapped but preserve original codes. Do not aggregate kilograms, pounds and each without an item-specific factor; this fixture uses no currency or tax. Canadian deployment, availability and supplier-contract compliance are not established.

Limits

1. Original editorial plan, not a source-documented agent case. No workflow, fixture or acceptance test was executed.

2. Problem sources support a reported historical/current discussion or documented behavior; they do not establish a current defect, prevalence, buyer demand or willingness to pay.

3. Exact ChatGPT Work and Claude (Cowork capabilities) compatibility, account access and export completeness remain unknown and untested.

4. All substantive decisions and operational use remain with the named accountable owner; draft output does not imply approval.

5. Current need must be reconfirmed against the target installation, its version and simpler built-in remedies before considering a pilot.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Availability in canada

   Not assessed by this reference update.

   Required capabilities

   1. Read owner-supplied structured and text copies in the approved task workspace.

   2. Run inspectable deterministic joins, conservation checks and calculations using available tools.

   3. Create separate reviewable CSV and text files with source-row references.

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Selection basis

   Candidate from general documented primitives only; no ERP integration, account access or end-to-end compatibility is claimed.

2. Name

   Claude (Cowork capabilities)

   Current access note

   Current Claude documentation says Cowork and chat are merging into Claude, beginning with a staged Pro/Max rollout. Some accounts still show Cowork. Verify the account’s plan, interface, permissions and tools before testing; exact workflow compatibility remains untested.

   Setup caveat

   Use current help for actual runtime and permissions. Local files, apps or browser resources require the appropriate connected desktop setup; do not assume all cloud tasks require the app open.

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Availability in canada

   Not assessed by this reference update.

   Required capabilities

   1. Read owner-supplied structured and text copies in the approved task workspace.

   2. Run inspectable deterministic joins, conservation checks and calculations using available tools.

   3. Create separate reviewable CSV and text files with source-row references.

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Selection basis

   Candidate from general documented primitives only; no ERP integration, account access or end-to-end compatibility is claimed.