Deviations, tolerances and field decisions
The core logic behind every comparison
This is the core logic of the agent. It defines what counts as a deviation, which fields may be written back, how tolerances suppress noise, and which decisions you can record.
What a deviation is
A field deviates when the confirmed value differs from the ordered value: a later delivery date, a higher price, a reduced quantity, changed payment terms, and so on. Deviations are what the agent surfaces for review. Fields that match need no attention.
Field capability
Every field carries a capability that governs whether and how it can be synced to the ERP.
- Read and write, also called syncable. The confirmed value can be written back to the purchase order. Dates, prices, quantities, and terms are typically syncable.
- Informational. A note or remark with no data change. It can only be acknowledged, never written.
- Key field. An identity field such as the purchase order number or the material number. View only, never written.
Tolerances
Each syncable field can carry a tolerance, made up of a sign and a value. Supported signs are plus or minus, plus, minus, greater than, less than, equals, greater than or equal, and less than or equal. A deviation that sits inside its tolerance is treated as a match and can be auto accepted when the process rule Auto confirm when everything matches within tolerance is active.
Tolerance fields are user definable. You can add your own fields to the tolerance table in the configuration.
Decisions per field
For each deviating field one decision is recorded, either by you or by the agent within policy. The recorded label makes the action auditable.
| Decision | Meaning | Written to the purchase order |
|---|---|---|
| Accept | Take the supplier confirmed value. Logged as Manually accepted. | Yes, the confirmed value |
| Reject | The deviation is unacceptable. The field goes into the supplier rejection email. Logged as Manually rejected. | No |
| Use PO value or Ignore | Keep the ordered value and disregard the confirmed value. Logged as Manually used PO value. | Yes, the ordered value |
| Edit | Override with a value you enter by hand, for example a negotiated date. Logged as Manually edited. | Yes, the edited value |
| Acknowledge | For informational fields. Noted, no data change. | No |
Every decision shows a clear logged state with an Undo, so you can always revert.
Empty confirmed values
A confirmation may legitimately leave a field empty because the supplier did not restate it. An empty confirmed field is valid and can be accepted as is, governed by the process rule Treat empty OC values as acceptable.
When no confirmation has been received at all, the fields read Awaiting confirmation and nothing can be marked as matched.