Supported use cases
Every path a confirmation can take, and where it ends up
The agent behaviour is documented as a numbered set of paths. Each path describes a real situation that can arrive with a confirmation, what the agent does with it, and the resulting thread status.
Comparison and write back paths
| No. | Path | What happens | Outcome |
|---|---|---|---|
| 1 | All match, auto confirmed | No deviations. The agent compares every field, auto confirms, and updates the purchase order end to end. | Confirmed |
| 2 | Within tolerance | A small price, quantity, or date difference sits inside the configured tolerance and is auto accepted and auto confirmed. | Confirmed |
| 3 | Manual accept | A real deviation above tolerance, for example a price increase of 6.3 percent. The buyer accepts and the confirmed value is written to the order. | Confirmed |
| 4 | Manual mixed or ignore | Keep the ordered value on a deviating field instead of the confirmed value. Recorded and logged to the audit trail. | Confirmed |
| 5 | Manual edit of a value | The buyer overrides both the ordered and the confirmed value with a value entered by hand, for example a negotiated date. | Confirmed |
| 6 | Review only with customer provided information | An informational remark or attachment with no data change. Acknowledge only, nothing is written. | Confirmed |
| 7 | Reject and supplier loop | An unacceptable deviation is rejected, a correction email goes to the supplier, the thread waits for a corrected confirmation, and the comparison runs again. | Awaiting |
| 8 | Updated confirmation without a rejection | The supplier sends a newer confirmation that supersedes the earlier one. Only the changed fields reopen for review. | Confirmed |
| 9 | Partial confirmation | The supplier confirmed only part of a quantity and has not committed the rest. Accept the confirmed pieces, then remind, keep open, or cancel the remainder. | Partially confirmed |
| 10 | Split delivery and schedule lines | One position is confirmed as several partial deliveries on different dates. Each is modelled as a schedule line and only the deviating dates need a decision. | Confirmed |
| 11 | Quantity deviation without a split | A short quantity where the remainder is declined, or an over delivery where more is confirmed than ordered. | Confirmed |
| 12 | Additional costs on the confirmation | The confirmation carries a charge that is not on the order, such as packaging, freight, or a minimum quantity surcharge. Create it as a new line item, use the ordered value, or reject it per item. | Confirmed |
| 13 | One to many consolidation | One ordered position is confirmed as several confirmation lines. They are grouped back to the single position and the totals are reconciled. | Confirmed |
| 14 | Many to one set match | Several ordered items are confirmed as one set position. The set level decision applies across all members. | Confirmed |
| 15 | Position surcharge as a sub item | A surcharge tied to a specific position. It is resolved like a line field and included in that position on update. | Confirmed |
| 16 | Close without update | The buyer deliberately closes the thread with an audit reason and without updating the order. | Closed |
| 17 | Cancelled position | A position is cancelled. The buyer acknowledges and the position is removed from the expected quantity on update. | Cancelled |
| 18 | Deletion flag on a position | A position carries a deletion flag, which is distinct from a cancellation. The buyer reviews and confirms. | Confirmed |
| 19 | Supplier declines a position | The supplier explicitly declines to deliver a position. The buyer decides whether to cancel it or keep it open. When cancelled, the delivery complete indicator is set. | Cancelled |
| 20 | Cancellation after sync | A change arrives after the thread was already updated. The thread reopens and allows a follow up update. | Reopened |
| 21 | Purchase order changed after comparison | The order was edited in the ERP after the comparison. The comparison is stale and blocked until it is run again. | Reopened |
| 22 | Overdue with reminders and escalation | A confirmation is overdue past the SLA. The agent sends automatic reminders and applies the escalation rules. | Awaiting |
| 23 | Header deviations | Header level deviations such as payment terms, Incoterms, and sometimes ERP code mapping. Resolved like line fields and written to the header on update. | Confirmed |
| 24 | Substitute article | The supplier confirms a different article for a position. Old and new are shown side by side and on accept the substitute is mapped onto the position. | Confirmed |
| 25 | Call off contract as sync target | Accepted values are written into a call off or framework contract instead of a standalone order. A contract badge appears in the top bar. | Confirmed |
| 26 | No confirmation received yet | The order was sent but nothing has come back. The thread stays open and the agent keeps watching for the incoming confirmation. | Awaiting |
Inbound inbox and email scenarios
| Scenario | What happens | Outcome |
|---|---|---|
| Unmatched, then assign a purchase order | A confirmation could not be matched automatically. The buyer assigns the correct order manually and the normal comparison begins. | Enters a comparison path |
| Unmatched, then dismiss | The confirmation is not relevant, for example not your order, a duplicate, or a test mail. The buyer dismisses it with a reason. | Dismissed |
| Email and inbox end to end | One inbound mail referencing several orders, the email view inside the thread, the rejection draft and composer, and send, reply, and forward with history. | Not applicable |