Two kinds of purchase order, one keying problem
A purchase order reaches a legacy ERP in one of two directions, and both end with someone retyping a document into a green screen.
Customer PO to sales order
A customer’s purchase order becomes your sales order. Most arrive as PDFs or spreadsheets from customers who will never send EDI. That flow has its own page: sales order entry automation.
Supplier purchase orders
Buyers often raise POs outside the ERP — a requisition form, a spreadsheet, a portal export. Someone keys each into purchasing so receiving, and later invoice processing, can work against it.
This page covers what both share: getting the PO into the host line by line, with the checks a careful clerk would make.
Why purchase order processing stalls at the item number
The hard part of purchase order processing is not reading the page; it is translating it. The customer orders “BRKT-4410-ZN” and your item master calls it 004410Z. The PO says $12.40 and your price list says $12.85. A nine-page PO carries a ship-to change on its last page. A buyer re-sends last week’s order under a new PO number because the first one “didn’t go through”.
Generic OCR captures the characters and leaves those questions to a person. An RPA bot types what it is given, wrong part number included. The clerk who knows the cross-references is the real system — and the bottleneck.
How PO entry automation works
PO entry automation takes one order from inbox to host in six steps.
Orders come in the way they do today
By email, SFTP folder or API — PDFs, scans, faxes, Word files or Excel order forms.
The whole PO is read as one order
AI vision reads the header and every line across all pages. A file holding several POs is split into one order each.
Item numbers are translated on the host
Each part number is looked up through the item or cross-reference screen your team already uses, and the host’s answer is taken. A person’s pick is remembered for the next PO.
Prices, quantities and dates are compared with the host
The PO price is compared with the host’s price, units and dates are checked for sense, and your plain-English rules decide what holds.
The order is prepared on your screens
Header, ship-to and each line across subfile pages, with function keys and paging handled as an operator would, reading the host’s messages at every step.
A person approves; the host confirms
By default someone approves the prepared order in the console or from an email link. The agent submits, reads the order back and logs every keystroke.
PO data entry into AS/400 (IBM i): fields and checks
PO data entry into AS/400 (IBM i) or any legacy ERP needs every line — and a check on each.
Header
- PO number and PO date
- Buyer, customer or supplier
- Payment terms and currency
Ship-to and dates
- Ship-to and bill-to addresses
- Requested and promised dates
- Shipping method
Lines
- Their part number and yours
- Description
- Quantity and unit of measure
- Unit price and extended amount
Checked before the order is keyed
- Part numbers resolved to your item numbers by the host’s own lookup
- Each line price compared with the price the host shows
- Extended amounts add up to the PO total
- Every page accounted for — no line silently dropped
- The order’s content compared with orders already received and on the host
- Rules you write in plain English, such as “hold any order for a discontinued item”
Exceptions, held where a person can decide
An exception is held with the exact line and the PO image — never guessed.
Unknown item number
When the host lookup finds no item, or several, the order waits with the part number and what the lookup showed. A person picks; the pick is remembered.
Price mismatch with the host
If the PO price differs from your host’s, the order is held with both, so someone decides before it surfaces at invoice time.
Multi-page POs
Every page is read into one order and checked against the total. An unreadable page holds the order instead of dropping lines.
A PO re-sent under a new number
legacy bridge compares what orders say — who, which items, how many, when — not just numbers. A repeat under a new PO number is caught as a duplicate, not keyed twice.
Purchase order automation compared
Purchase order automation is judged on the lines that go wrong.
| Criterion | legacy bridge | OCR + RPA | Manual keying |
|---|---|---|---|
| Their part numbers | Resolved through your host’s item lookup | A mapping table someone maintains | The clerk’s memory |
| Multi-page orders | One order, every line counted | Depends on the template | Slow; a page is easy to miss |
| Price check | Compared with the price on the host | Only if scripted | When someone notices |
| Re-sent POs | Caught by content, not just number | A number match at best | Rarely caught |
| Entry into the ERP | Keyed on your screens, then read back | A bot types what OCR gave it | Typed line by line |
| Human control | Approval before submission by default | Exceptions buried in bot logs | Full control, full effort |
More on bots versus agents in AI RPA, and on keying work in data entry automation.
Systems it works with
legacy bridge is in production on IBM i (AS/400, iSeries), including the order entry and purchasing screens of packaged ERPs and custom RPG or COBOL applications — common among manufacturers and distributors. It connects over TN5250 like a terminal emulator: nothing installed, no program changes.
The same engine speaks TN3270 for mainframe screens, VT and HP 6530, and drives web portals and Citrix or RDP desktops, scoped per workflow. The company behind it is part of scandiweb and certified ISO 9001, ISO/IEC 27001 and ISO/IEC 27017.
