Pilot an exception queue for EPC purchasing

Select one project and a defined group of purchase packages, such as mechanical equipment or MEP materials. Include the relevant purchase requests, PO lines, delivery schedules, receipts and technical-document references. Record which suppliers and sites are included and how closed or cancelled lines are treated.

The procurement head owns the queue’s business rules. Package engineers own technical decisions, stores owns receipt evidence and finance owns invoice or commitment reconciliation. A technical owner monitors source freshness and failed interfaces.

Useful first exceptions include a receipt without a matched PO line, an overdue supplier acknowledgement, a required document still under review and a delivery forecast beyond the agreed need date. Each rule needs an explicit definition. “Late” might refer to supplier commitment or project need; show which one triggered the case.

Preserve source timestamps and show when each source was last read successfully. The queue should not convert “no update received” into “no problem exists”. If the DMS export fails, technical-release status should be visibly stale.

Also check whether the joined records describe the same point in time. A revised PO loaded at noon and a receipt extract from yesterday can create a temporary apparent shortage. Show each source's cutoff and flag an incomplete refresh. Reconcile again when the batch finishes before treating that difference as a confirmed business exception.

ERPNext’s purchasing and receipt documentation illustrate distinct records that an integration may need to join. Actual fields, API permissions and status mappings must be verified in the installed systems.

Illustrative example: a PO line contains 40 valves. Receipt R-108 records 36 delivered, with 34 released and two held under the project’s inspection workflow. The interface receives R-108, processes it, then loses its acknowledgement. A retry sends the same receipt again.

The pilot should still show 36 delivered, not 72. It should also preserve the difference between delivered and released quantities. A stable source receipt ID and version allow the receiver to recognise the repeated event.

Now send a legitimate second receipt of four valves under a different receipt ID. Delivered quantity should become 40. Matching on supplier, date and quantity alone is not sufficient to distinguish a replay from another delivery.

If R-108 is later corrected, retain the version relationship and recalculate the exception from the accepted source state. Do not append the revised quantity as another receipt. AWS’s guidance on idempotent retries explains the request-identity principle behind safe repeat processing.

Each case should contain the affected package and record, reason, quantity or date exposure, source links, responsible role, next action and due date. A missing receipt acknowledgement belongs to stores. A returned technical submittal belongs to the package team. A broken export belongs to integration support.

Allow an owner to acknowledge a case, record investigation notes and attach resolution evidence. Acknowledgement means someone has taken responsibility; resolution means the triggering condition has been cleared or an authorised exception accepted. When the source system changes, re-evaluate the case and reopen it if the problem recurs. Completing an integration task cannot release a technical hold.

Prioritise cases by the decision they threaten. A missing certificate for material needed tomorrow may deserve attention before a larger order needed next month. Show the affected need date, usable quantity and relevant commitment value, with the package owner confirming the consequence. Avoid a single severity score whose assumptions no buyer can explain.

Group repeated alerts for the same unresolved condition. A hundred reminders about one blocked PO are not a hundred exceptions resolved. Preserve an escalation path for ageing cases and make responsibility changes explicit when staff move between projects.

Notifications should respect source permissions. A buyer may need to know that technical review is pending without receiving a confidential design attachment. Sending a summary should not grant access that the DMS would deny.

Choose a representative set of open and recently closed packages. Record the time spent assembling exception lists, the number of unmatched receipts, age of unresolved cases, repeated follow-ups and correction effort. Keep a fixed definition of an exception across baseline and pilot.

During the trial, measure both new and carried-forward cases. Report median resolution time by reason, along with older unresolved items. A lower median can conceal a growing backlog of difficult cases. Record false alerts and cases discovered outside the queue; those indicate rule or coverage problems.

Agree targets after the baseline. The queue must reproduce source quantities, avoid duplicate receipt effects and preserve approval authority. A genuine source discrepancy is a case for the business owner, not evidence that the pilot failed. A quantity difference introduced by the integration fails the control gate. Time savings are measured outcomes, not a promise based on installing a connector.

Use synthetic tests first, then an authorised live sample in parallel with the existing follow-up process. If future write-back is proposed, specify transaction type, target approval, duplicate protection and reconciliation separately. Passing a read-only pilot does not establish that automatic receipt posting is safe.

Stop expansion if the queue cannot be reconciled to its sources, a repeated event changes a balance, access leaks or an approval is bypassed. Pause the affected feed, retain logs and return users to the authoritative reports. Mark the queue’s cutoff so it cannot be mistaken for a current view. Keep ordinary purchasing disputes assigned in the queue; their existence alone is not a reason to stop an accurate feed.

The technical owner repairs and retests the cause; procurement and the affected function reconcile the results before resumption. Keep a list of any actions taken from incorrect alerts so the business team can review their consequences.

1. Select the package group and define a few meaningful exception rules.
2. Agree sources, owners and the baseline inclusion rules.
3. Pass duplicate, revision, stale-data and access tests.
4. Run a live queue alongside the existing process and review missed cases.
5. Expand only the rules and interfaces whose results the owners accept.

To discuss a procurement pilot, describe one blocked purchase and where its trail breaks between engineering, purchasing, stores and finance. Include the package type and systems involved.