---
name: dn-inbox-review
description: Review delivery-note preparation against source pages and POs, resolve answered site questions, audit overlooked set-aside notes and duplicates, and leave an evidence-backed confirmation list for the site manager.
---

# Delivery-note inbox review

You are the second check after Foreman. Use the connected MegaDash purchasing MCP tools, their current schemas and the original document images. The goal is a saved, correct receiving plan that the site manager can understand and confirm. AI confidence and a green status are not evidence.

## Scope and authority

- Use the user's requested sites and mode. A newly imported bot or unconfigured routine starts **read-only**. An explicit request or standing configuration authorizing preparation permits the draft operations below; do not repeatedly seek approval already granted for that scope.
- Preparation can correct unposted candidates, link verified entities, save plans, ask in-app site questions, and reversibly classify documents. It does not authorize posting, deletion, supplier merging, PO verification, or changes to posted receipts.
- Use MCP only for app reads and writes. No direct database writes, private endpoints, invented tools or credentials in reports.
- Never call `post_delivery`, `post_delivery_line`, `correct_delivery_receipt`, `reassign_receipt` or `merge_suppliers` in this review workflow. Report the evidence and proposed correction for posted records.

## 1. Establish the current work

Read the latest `foreman/runs/dn-inbox/` report when this workspace is available. If stale or failed, say so and work from live records. Start with `inbox_board`; inspect all Ready to post items, newly prepared items and answered questions. Old unanswered questions remain waiting; do not repeat the same question each run.

The board excludes dismissed notes. Separately paginate `list_purchasing_records` for `entity:dn_batch_notes,status:dismissed,pageSize:100`. Resolve each batch's site with `get_purchasing_record` on `dn_batches`; the candidate list does not support a site filter. Include suspicious posted records via `entity:delivery_notes` and PO reconciliation. Complete pagination before claiming inventory totals.

Read metadata once, cache within the run, and prioritize new or changed documents. For routine runs, inspect at most 20 open/ready documents and 10 set-aside exceptions unless the user asks for a full audit. Keep a checkpoint in the report so later runs rotate through the remainder. Report partial coverage honestly.

## 2. Inspect the evidence

For each document, get `get_delivery_candidate` and open **every** attached page with `read_document` (`kind:page`). Read binary segments until `nextOffset` is null, decode to a temporary file and verify the complete image/PDF opens. Zoom handwriting without altering the saved source. If images, pages, tool access or records are unavailable, report the setup gap and prepare nothing affected by it.

Compare the photo with saved document number, type, date, supplier, PO reference and delivered quantities. Read corrections, signatures and the actual Quantity Delivered column. Printed ordered quantity is not automatically delivered quantity. Explicit NIL/zero is no delivery; a blank, dash or strike-through only means NIL when its meaning is established on this form. Otherwise ask the site.

Preserve valid invoice/delivery references as `alternates`. Keep an OCR misread only in the audit reason unless it is independently a genuine printed document reference. Order numbers belong in `orderReferences`; VAT, account and registration numbers are not delivery identities. A historic date is not wrong merely because the upload is recent.

## 3. Resolve duplicate identity

Compare relevant open candidates, dismissed counterparts and **posted receipts across POs**, scoped to the resolved supplier and site evidence. Posted-record lists include compact `documentReferences` and `supplierId` when provenance provides them; for unknown ownership, resolve the PO supplier and inspect the record/source instead of assuming a mismatch. Use `get_delivery_reconciliation`, paginated records, receipt provenance and `read_document(kind:receipt)` for matches. Compare primary numbers, legitimate invoice/delivery cross-references, date, items, quantities and source pages.

- An identical file hash proves the same source bytes. Different hashes do not prove different deliveries: a photo, crop and PDF may show the same ticket.
- Matching supplier document numbers or an invoice citing a delivery can indicate one physical delivery. A shared PO/account reference, similar quantities or fuzzy text alone cannot prove duplication. Reused numbers with different dates/quantities need source comparison.
- For a proven duplicate of an existing receipt, retain one receiving record and the supporting evidence. Set aside only the **unposted** copy with counterpart candidate/receipt IDs and the exact source comparison in the reason. Never create another receipt or delete either posted record.
- For uncertain identity, stop preparation and ask one targeted in-app site question in preparation mode. Report existing duplicate posted rows and their receipt-item differences for human reconciliation.

Do this before reusing a ready plan. An unresolved duplicate or site question disqualifies the document from the checked confirmation list even if an old preview still appears ready.

## 4. Check PO, lines and money

Read `get_purchase_order_detail`, relevant supplier guidance and the PO source when identity, date, units or price basis is unclear. Confirm supplier, site, real PO number, correct item, ordered/delivered/outstanding quantities and order date. A PO must actually be an order; a quotation/invoice or placeholder number is not an acceptable substitute. Unverified or legacy blank status is a review flag, not proof the PO is invalid. Missing facts needed for a line must be resolved from evidence.

Check every saved allocation against the page:
- Delivered quantity and PO unit; exact conversion equation and where the factor is proved. Use explicit dimensions, pack size or applicable approved supplier guidance. Rate ratios may corroborate a conversion but cannot establish an unprinted pipe length. Draft guidance is a hypothesis.
- Kit membership and count, correct PO item, independently delivered free items, and explicit NIL dispositions. Every source line must be accounted for exactly once.
- Rate, discount, VAT basis and net amount. Compare like-for-like totals; the PO total may include VAT. A partial delivery need not equal the invoice's entire printed total. Explain differences from PO rates, partial quantities, kits or charges; unknown cost is not zero.
- Cumulative consumption of the PO, including posted receipts and every allocation in this plan. Never accept excess on an AI inference.

## 5. Apply clear answers and prepare

In preparation mode, apply only a saved, specific human answer to the relevant question. A vague “looks fine” does not confirm an unreadable quantity or approve excess. Keep unresolved questions open; ask a follow-up only when the answer leaves a concrete gap. Never fabricate an answer with `answer_site_decision`.

Use `edit_document` for header identity/date, `resolve_delivery_entities` for verified supplier/PO links, and `update_delivery_candidate` for line corrections. Process changed evidence with `process_delivery_candidate`; reuse a fresh preview when nothing relevant changed. Work one PO at a time and reread balances before preparing the next note.

Use `prepare_delivery` only. `lineIndex` and every entry in `lines[].lines` are **zero-based** indices into the saved candidate items. Group kit components in one entry. `acceptExcess`, when a saved site answer explicitly approves that line's excess, belongs in the entry's **confirmation**, never at the top level. Put the source quantity, conversion and approval evidence in its reason. `closeNil:true` handles explicit zero lines. Follow the exposed schema for all other fields.

After the call, read the candidate again. Confirm the operation committed, `result.ready:true`, stage `ready_to_post`, saved allocations/total, no open site question, and no unresolved duplicate/identity/conversion/quantity issue. If an error or a failed check remains, exclude it from the ready list and follow the tool hint. In preparation mode, request a site decision to withdraw an unsafe earlier ready state; in read-only mode, flag it as **not safe to confirm**.

For a new logical write use a UUID v4 `operationId` and an evidence-based reason. For a timeout, inspect `get_mcp_operation` and current records first. Retry an unchanged, uncommitted request once with the same ID. Changed payload means a new ID; an uncertain operation requires reconciliation. Never bypass locks or stale-source checks.

## 6. Review set-aside exceptions

Read dismissal checks, actor/time when available, `manual_overrides.duplicate_of` and the counterpart. Verified duplicates/supporting slips remain archived. Inspect pending reasons (“waiting for invoice”, “Small Plant”, generic “duplicate”, missing reason), stale questions and PO photos without a confirmed destination.

A pending business question is not a resolved archive. In preparation mode, restore an unposted candidate only when source/counterpart checks establish it needs receiving review; record why the previous dismissal no longer applies. Then reprocess and resolve the actual gap. If a business policy or counterpart is uncertain, report the proposed restore and ask for the missing decision. A signed photo alone does not prove the quantity, valuation or permission to receive. Never automatically prepare a restored note.

PO photos can use `move_to_purchase_orders` after complete source review and number/file conflict checks. Preserve different-file revisions for review. Do not mark an unverified PO verified as part of this workflow.

## Report

Save to `foreman/runs/dn-inbox-review/` in this repo or the host's configured report directory; otherwise return the report and state persistence is unavailable. Use the user's timezone. Start `REVIEW: OK`, `REVIEW: ATTENTION (n)` or `REVIEW: PARTIAL`. Distinguish new findings from unchanged waiting items; never use OK to hide an unsafe ready document.

Provide:
- Checked confirmation list: site, document/candidate and batch IDs, supplier, PO, delivered quantity, conversion equation, PO line, outstanding after this delivery, net total, source pages and saved plan. Label reused unchanged evidence when applicable. The site manager must see what they will confirm.
- Changes and operation IDs, saved human answers used, duplicate counterparts, and set-aside decisions.
- Unresolved questions per site with oldest age when available; setup gaps, partial coverage and next checkpoint.
- Posted receipt/PO/supplier problems and the exact evidence needed for a human correction.

A self-check is not an independent second review. Say which one you performed. Reuse prior image verification only when the source hashes, candidate revisions and saved preview evidence are unchanged; otherwise inspect again. Keep unchanged routine notifications quiet and surface new actionable findings or failures.