Reconcile customer-held stock with consignment sales reports

Setup requirements

1. Distinguish event reports from cumulative snapshots; repeated cumulative totals cannot be treated as new sales.

2. Require owner, consignee location and item identities; identical SKUs at two customers remain separate.

3. Invoice coverage does not prove payment, and physical movement does not establish ownership transfer without the owner’s rule.

4. Agree this bounded synthetic scope and confirm a real unresolved need before any implementation pilot. The written design does not authorize executing it.

Inputs and access

1. Name

   opening_custody.json

   Source or owner

   Inventory owner

   Scope

   Synthetic owner/customer/location/item/lot balances at a frozen start time.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

2. Name

   movement_events.json

   Source or owner

   Warehouse owner

   Scope

   Synthetic outbound consignments, customer-to-owner returns and confirmed transfers with unique movement IDs.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

3. Name

   sellthrough_reports.txt

   Source or owner

   Consignment account owner

   Scope

   Synthetic report IDs, periods, sale event IDs or explicit cumulative-report basis, quantities and return corrections.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

4. Name

   invoice_coverage.json

   Source or owner

   Billing owner

   Scope

   Synthetic invoice line IDs and exact sell-through event allocations, including cancellations. Include stable invoice_allocation_id, invoice_id, invoice_line_id and sale_event_id; duplicate and cancelled allocations remain typed.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

5. Name

   custody_rules.json

   Source or owner

   Operations owner

   Scope

   Approved cutoff, ownership scope, event basis, stocktake comparison and treatment of corrected reports.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

Human approval boundaries

1. Before a pilot, the accountable owner approves exact synthetic/minimized copies, processing environment, retention and allowed recipients.

2. Owner validates identity mappings, authority, status definitions and all unresolved evidence.

3. Any source mutation, account access, upload, external communication, commercial commitment, payment or changed permission requires separate appropriate authorization.

The problem

Goods held by a customer are not necessarily sold. Delayed or repeated sell-through reports can leave physical custody, reported sales and invoicing out of step.

Suggested task

Reconcile opening custody, transfers, returns and uniquely identified sell-through events within owner/location/item scope.

What you could produce

A custody roll-forward and sale-to-invoice coverage matrix, with duplicates, unexplained differences and missing confirmations.

Why an agent / simpler alternative

An agent can interpret inconsistent consignee reports and explain event-versus-snapshot conflicts. Quantity roll-forwards and allocation checks are deterministic. Use native location/sales reports when they already preserve the required ownership and event links.

When this work comes up

Role

Consignment operations coordinator

Trigger

A periodic consignee report arrives before a stock and invoice review.

Human approval

Owner reviews scope, rules, identities and findings; operating decisions remain separately authorized.

Finished output

A custody roll-forward and sale-to-invoice coverage matrix, with duplicates, unexplained differences and missing confirmations.

Proposed evaluation scope — no pilot authorized

Scope

Two consignee locations, at most 10 items and one reporting period with at most 100 movement/sale events.

Limit origin

Original editorial evaluation bound, not a verified tool limit.

Overflow action

Stop and request owner-approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Source facts describe human friction; O*NET describes duties; shared official documentation supports file primitives. The six-step workflow, safeguards, numerical fixture and outputs are original proposed designs.

Proposed steps

1. 1

   Freeze opening balances, cutoff and report completeness; identify all custody scopes.

   Output: Scope and event-basis manifest.

   Expected output: Scope and event-basis manifest.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner approves exact inputs and rule scope before any pilot.

2. 2

   Extract transfer, return and sell-through observations with IDs, dates and original report versions.

   Output: Typed custody events.

   Expected output: Typed custody events.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

3. 3

   Resolve duplicate or superseding report references under owner rules, retaining each raw appearance and unresolved event.

   Output: Unique accepted-event candidates and exceptions.

   Expected output: Unique accepted-event candidates and exceptions.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

4. 4

   Roll forward custody by exact scope and compare with any owner-supplied stocktake; conserve transferred units and expose unexplained differences.

   Output: Custody quantity bridge.

   Expected output: Custody quantity bridge.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

5. 5

   Join accepted sell-through events to existing invoice allocations and show uncovered or multiply covered quantities separately from stock balances.

   Output: Sale-to-invoice coverage.

   Expected output: Sale-to-invoice coverage.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner reviews draft findings; no operational action authorized.

6. 6

   Prepare independent review tables and questions; do not create invoices or change warehouse configuration or stock.

   Output: Consignment review packet.

   Expected output: Consignment review packet.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner accepts the review artifact; any live change or communication needs separate approval.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Reconcile opening custody, transfers, returns and uniquely identified sell-through events within owner/location/item scope. Follow the six-step design. Preserve exact identities, source citations and uncertainty; make calculations inspectable. Write only separate review drafts to {approved_output_folder}. Do not guess missing facts, alter sources, access accounts, send, upload, buy, post, settle, make personnel decisions or claim the fixture passed.

Expected output schema — proposed

Primary key

1. owner_id

2. consignee_id

3. location_id

4. item_id

5. lot_id

6. period_id

Columns

1. opening_units

2. inbound_units

3. returned_to_owner_units

4. unique_sold_units

5. closing_custody_units

6. observed_count

7. unexplained_difference

8. sale_event_ids

9. invoice_covered_units

10. uncovered_sold_units

11. source_spans

12. hold_reason

Record status

draft_review_only

Common provenance columns

1. input_snapshot_id

2. rule_version

3. source_document_id

4. source_row_or_span

5. reviewer_decision

Unknown value policy

Unknown numeric values remain null, never zero. Preserve raw rows and typed relation/allocation IDs; unresolved rows do not silently enter approved totals.

Linked tables

Sale to invoice allocations

Primary key

1. invoice_allocation_id

Columns

1. owner_id

2. consignee_id

3. location_id

4. item_id

5. sale_event_id

6. invoice_id

7. invoice_line_id

8. allocated_units

9. invoice_state

10. source_rows

11. hold_reason

Sale event control

Primary key

1. owner_id

2. consignee_id

3. sale_event_id

Columns

1. accepted_sold_units

2. total_invoice_allocated_units

3. uncovered_units

4. overcovered_units

5. invoice_allocation_ids

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

Opening

50

Inbound

20

Returned

5

Unique sales

18

Invoiced sales

10

Expected

Closing custody

47

Uncovered sold units

8

Duplicate report effect

0

Invoice creation

No

Limits

1. Original proposed and untested design; no source documents this complete agent workflow.

2. A reported problem is not proof of prevalence, willingness to pay, harm magnitude or current demand.

3. Historical product reports require current-installation checks; a current capability document only establishes general primitives.

4. Native reports or a deterministic script may be simpler. Exports, identity mappings, context size, privacy controls and actual tool compatibility remain untested.

5. Numerical fixtures are synthetic and have not been executed. Owner review is necessary; no time saving, cost saving or revenue outcome is asserted.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

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

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

2. Name

   Claude

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

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

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

Failure modes

1. A repeat cumulative report is counted as another sale.

2. Two consignees or owners sharing an item code are netted together.

3. Unbilled sold units are mistaken for units still physically held.

Recovery and troubleshooting

1. Signal

   A repeat cumulative report is counted as another sale.

   Recovery

   Preserve report version links and hold ambiguous event/cumulative basis for account-owner review.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

2. Signal

   Two consignees or owners sharing an item code are netted together.

   Recovery

   Partition every balance and allocation by owner, location and item identity.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

3. Signal

   Unbilled sold units are mistaken for units still physically held.

   Recovery

   Keep custody and invoice coverage as separate linked tables, recomputing each from its own event basis.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

Unexecuted validation plan

Sample setup

Scope A starts with 50 units, receives 20, returns 5 to owner and reports 18 uniquely identified sold units. The same report arrives twice. Invoice lines cover 10 of those 18 sold units. A separate consignee B holds the same SKU. A late correction lacks a superseded report ID.

Acceptance checks

1. A closes at 47 units:50+20-5-18. The duplicate report does not reduce custody twice.

2. Uncovered sold quantity is 8 and is not added back to physical custody.

3. B is never netted with A.

4. The late correction stays unresolved until its replacement or additive meaning is approved.

5. Each invoice allocation links to sale event IDs and cannot exceed their accepted units.

6. No invoice, inventory adjustment, ownership decision or payment conclusion is made.

7. Every conclusion traces to approved source rows or an explicitly labelled owner rule; rerunning the same frozen input must not change identities or totals.

8. All source copies remain unchanged. Any duplicate, missing key, stale snapshot or conflicting authority is held visibly.

9. A second invoice allocation of 9 against the same 18-unit sale, alongside the existing 10, must show overcoverage 1 and hold both competing allocations; no invoice identity or allocation row is hidden.

Stop conditions

1. Input scope, required identity or calculation policy is missing.

2. Unexpected real sensitive/personal data is supplied before handling approval.

3. The requested output would require live account access, external upload/send, accounting posting, purchase, access change or irreversible action.

Executed

No

Fixture status

Designed only; no acceptance fixture or workflow executed.

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan access, model usage, tool runtime and storage costs unknown.

2. Export preparation, evidence cleanup, review and correction effort unmeasured.

3. No native integration, paid service, new account or software installation assumed.

4. Case-specific effort is unknown: source extraction, identity repair, owner-rule preparation, fixture design and review may dominate model cost.

Caveat

No measured time saving, current demand, ROI or price claim. Compare the simpler remedy first.

Canadian adaptation — proposed

Verify local privacy and organizational record-handling requirements before any real-data pilot; preserve original currency, business calendars and time zones. No Canadian deployment or compliance claim.