---
title: Checking a purchase order
description: How FlowOS reads a client's purchase order, compares it with the quotation it accepts, and how an Office Head decides it.
sidebar:
  label: Checking a PO
  order: 8
---

## What this process achieves

A client's purchase order arrives as an email. FlowOS reads it, compares it with
the quotation it accepts, and shows every difference on the email in the inbox.
Nothing is decided for the client: a difference is shown, a person settles it,
and an Office Head records whether the order is accepted. Raising the sales
order stays in the ERP for now.

```mermaid
flowchart TD
  mail["Client email typed as a purchase order"] --> linked{"Linked to an enquiry?"}
  linked -- no --> linkit["Needs Review: link it first"]
  linked -- yes --> read["FlowOS reads the documents and the email text"]
  read --> found{"Found a purchase order?"}
  found -- "nothing like one" --> nopo["Needs Review: no purchase order found"]
  found -- "could not read a file" --> unread["Needs Review: purchase order unreadable"]
  found -- yes --> save{"Saved how?"}
  save -- "same content as one held" --> dup["Duplicate: nothing saved, later client changes held"]
  save -- "same number as an earlier order" --> amend["Amendment: the earlier order is Amended"]
  save -- otherwise --> created["New order"]
  amend --> check
  created --> check["Compared with the quotation it accepts"]
  check --> rows["Rows: Mismatch, Open, Not stated, Not in quote, Not ordered, Fewer units, Matched"]
  rows --> settle["A person settles or re-matches the rows"]
  settle --> head["Office Head records a decision"]
  head --> accept(["Accept"])
  head --> dev(["Accept with deviations"])
  head --> amendreq(["Ask for amendment"])
```

## When FlowOS reads a purchase order

FlowOS reads an email typed as a purchase order once it is linked to an
enquiry. It reads the attached documents, scans and pictures, and the email's
own text. For the position of each column it also reads the first 40 pages of up
to five PDFs, each at most 10 MB. A file we issued ourselves, and a repeat of a
file already read, is passed over.

A line's amount the reading left out is taken from its row. An order discount
printed on a line of its own is kept when the amount it prints, or else the
taxable total, bears it out, and not when it hangs on payment. A discount read
from a row that names no discount, such as a packing row or a sub-total, is
dropped. Packing or freight counts as included
only when the PO's words say so. A term that says its answer "will be advised"
and gives no figure is open.

Mail delivered to a mailbox outside the allow-list is not read until Flowtech
records its zero-retention agreement.

The PO check sits in the action column of the email. Until it has something to
show, it says one of these:

| The panel says | It means |
| --- | --- |
| FlowOS hasn't read this email for a purchase order yet. | The email is waiting. **Check again** fetches the answer again |
| FlowOS found no purchase order in this email. | Nothing in it looks like one. The email waits in Needs Review as `no_purchase_order_found` |
| FlowOS couldn't read a purchase order from this email. | A file that may be a purchase order could not be read. The email waits in Needs Review as `purchase_order_unreadable`, and the files are listed under "Files FlowOS couldn't read" with the reason |
| Viewing the PO check needs permission to view sales orders. | The signed-in person lacks `sales-order:view` |

An older PO that arrives after its amendment is saved in the chain behind it,
and the amendment stays the one that counts. A PO that has been amended,
cancelled or short-closed takes no decision.

## Which quotation it is compared with

A PO is compared with one issued version of the quotation it accepts (R113).
FlowOS picks it in this order:

1. The version a person chose.
2. Otherwise the best match among the versions the email is linked to or the PO
   cites, or, when there are none, among every version issued before the PO
   arrived. The best match pairs the most lines, then has the fewest
   differences in the model number, then the most quantities agreeing. Of
   revisions of one quotation that match equally, the newest wins.

The header shows the version and how it was found under **Compared with**
and **Matched by**. A later issued revision is named, such as "R2 issued
later", and is not compared. When two quotations fit equally the panel says
"Two quotations fit equally" and a person picks one. With no issued quotation
the panel says "No FlowOS quotation". With a PO that has no lines it says "Not
compared".

## Reading the check

The check opens on **PO vs Quote**. A summary line counts the rows by what they
mean for the order, for example "2 to resolve · 1 open · 14 matched", beside
the note "Proposed rules, pending Flowtech". Rows are grouped as **Lines**,
**Parties and tax**, **Terms** and **Order**, differences first. Matched rows
are folded behind one button.

Each row carries a verdict:

| Verdict | Meaning |
| --- | --- |
| **Mismatch** | The PO states something different from the quotation |
| **Open** | FlowOS cannot tell, and a person must answer |
| **Not stated** | The PO is silent. This is not a difference (R114) |
| **Not in quote** | The PO states something the quotation does not hold, such as a line never quoted |
| **Not ordered** | A quoted line the PO leaves out |
| **Fewer units** | A quoted line the PO orders in a smaller quantity |
| **Matched** | Same on both |

A row holds up the order when it is open, a mismatch, or a line the quotation
never held. Some exceptions apply: a mismatch on the order total, or on a line
whose only difference is the tail of the HSN code, does not hold it up, nor does
a party value or a term the quotation lacks, such as credit days, deemed
acceptance, the subject line or other terms. **Not ordered**, **Fewer units**,
**Not stated** and a match never hold it up (R114). The header says "N to resolve", "N to answer", or
"Nothing holds up the order". Which rows hold it up is a proposal, pending
Flowtech's confirmation.

An order code that cannot be compared with the quoted one, such as another
maker's, is an **Open** row reading **Order Code is not ours**, with both codes.
Our own code, with or without the maker's head, is never one, and pairing the
line by hand answers it.

**PO arithmetic** checks each line and the taxable total. The total may carry on
top the charges the PO states, or those the quotation bills, such as packing at
3%. A charge the PO says is included does not count.

**Source** opens the quotation and the PO document side by side, from the
header or from one row.

## Re-matching

A person with `sales-order:edit` can correct how the PO pairs with the
quotation, from a row's ⋯ menu or from the header:

- **Pair with another quoted line** pairs a PO line with a quoted line.
- **Mark not quoted** says the PO line is not on the quotation.
- **Let FlowOS pair it** hands a line back to FlowOS.
- **Change** beside **Compared with** chooses the version to compare with. With
  nothing compared, **Pick the quotation** sits beside **Quotation** instead.

These are saved, and the check is worked out again at once. Choosing a new
version clears the pairs made by hand against the old one. Any re-match or
change of version reloads the check and drops the corrections made on the page
that were not yet saved.

A PO that was amended, cancelled or short-closed shows no re-match, and says so
under the header facts.

## Settling and correcting

The same ⋯ menu settles a row: **Request updated PO**, **Correct quote**, **Accept as is**
(Office Head or Admin) or **Not a real difference**; an open row is **Answered**.
**Edit PO value** corrects what FlowOS read, and **Undo my changes** takes a
correction or settlement back.

These are not saved. The page says "Not saved — kept until you reload", and they
are gone after a reload. They help the person reading the check, and settling
every row that holds up the order is what opens **SO Generation**; the decision
below is what is recorded.

## Deciding

An Office Head or Admin, with `sales-order:approve`, records one decision for
the whole PO, with **Record decision** (R116). It sits under **SO Generation**;
a PO with no check has no tabs, and is decided from the bar under its facts:

- **Accept**
- **Accept with deviations**
- **Ask for amendment**

A note is needed for every decision except **Accept** on a PO that has a
check. A later decision replaces the earlier one. The decision is kept with the
check it was taken on. If the check has since moved, for example after a
re-match or because the PO was read again, the decision line shows **Check
changed since**.

**SO Generation** is locked while any row holds up an undecided order. It
opens once every row that holds up the order is settled, or once a decision is
recorded, and the decision shows at the top on every reload.

## Several POs in one email

An email with several purchase orders shows one check for each, each decided on
its own. A relink moves the email's POs to the enquiry it is moved to. A PO
already decided keeps its decision and reads "Check changed since".

## Deemed acceptance

Some POs state that the order is deemed accepted if Flowtech does not answer
within a number of days. FlowOS shows the date as **Deemed accepted on**
beside the header's counts, red once the date has passed (R115). No alert is
sent.

## Source

Rules [R113](/business/business-rules/taking-the-order#r113--a-purchase-order-is-compared-with-the-quotation-version-it-accepts), [R114](/business/business-rules/taking-the-order#r114--what-a-purchase-order-does-not-state-is-not-a-difference),
[R115](/business/business-rules/taking-the-order#r115--a-purchase-order-that-states-deemed-acceptance-shows-the-date) and [R116](/business/business-rules/taking-the-order#r116--an-office-heads-decision-on-a-purchase-order-is-recorded-with-the-check-it-was-taken-on). Part of
step 12 of [Enquiry to quotation](/business/workflows/enquiry-to-quotation). Where
a mail is linked first: [Linking mail after a quotation](/business/workflows/linking-mail-after-a-quotation).