Why distribution and wholesale order desks still key orders by hand
Order desks key orders by hand because every customer sends a purchase order in its own layout, and the ERP only accepts what is typed into its screens. A distributor with a few hundred accounts gets a few hundred PO formats: system PDFs, spreadsheets, faxes with notes in the margin. A rep reads each one, finds the account, translates part numbers and types every line. That produces the errors customers notice first: the wrong ship-to, a transposed quantity, an order keyed twice. It is the gap data entry automation closes.
- Orders that arrive late in the day wait until tomorrow, and so does the shipment
- Customer part numbers live in a rep's memory or a spreadsheet beside the terminal
- A re-sent order with a new PO number slips past a check on the PO number alone
How order entry automation works, from inbox to confirmed order
Automate order entry from email and PDF
Customers keep sending POs as they do today. Orders arrive through a forwarding address on your order desk mailbox, an IMAP or Gmail inbox, an SFTP folder or an API upload: PDF, Excel, Word, scans and faxes.
Read the PO, header and lines
AI vision reads the PO the way a rep does: buyer, ship-to, PO number, and each line's part number, quantity and requested date. No templates per customer. A file holding several orders is split into one order each.
Find the account and the ship-to on your system
The agent looks up the customer and ship-to with your own host lookups, so it uses an account your ERP already holds. If it cannot tell which is meant, it holds the order and asks.
Turn customer part numbers into your item numbers
Each line's part number is matched to your item number through the cross-reference and item lookups on your screens. When a person maps a part once, that answer is remembered for the next order.
Key the sales order on the host
It signs on, opens order entry, fills the header and every line with the prompt windows and function keys your reps use, and reads each host message.
Approve, submit, confirm
By default a person approves the prepared order in the web console or from an email link before submission. Then the agent reads the order back from your system and logs the result.
Customer PO to sales order: what gets keyed and checked
legacy bridge keys the fields your order entry screens ask for, and checks each value before it is typed.
Customer and account
Found on your host, never invented from the PO letterhead.
Ship-to
Matched to a ship-to location the account already has.
Customer PO number
Keyed as printed, and kept with the order for the audit trail.
Items and quantities
Customer part numbers mapped to your item numbers; quantities and units read per line.
Requested dates
Per order or per line, checked against the date the PO arrived.
Pricing
As your host shows it; your price lists are never overridden. If the PO price must match, a difference holds the order.
- Line amounts and the PO total add up on the document itself
- Your order desk rules apply, written in plain English, not code
- Account, ship-to and items exist on your system before anything is typed
- The order is not one you already hold, whatever PO number it carries
Exceptions sales order processing automation has to handle
Unknown customer or ship-to
A new account or delivery address is not guessed. The order is held with the PO image and the lookup the agent ran, for a rep to set up or pick.
Unknown item
A part number your cross-reference does not know holds that order, naming the exact line. Once a person maps it, the next order with that part goes through.
Same order, new PO number
legacy bridge compares what the order says, customer, ship-to, items and quantities, so a copy re-sent under a new PO number is caught as a duplicate, not shipped twice.
Backorders and host messages
When your system answers a line with a backorder or other message, a person sees the host's own words and the screen. Nothing is submitted past an error.
Hand-written changes on a fax
A quantity crossed out and rewritten on a faxed order is flagged, never assumed. The order waits with the marked-up image for a person to decide.
Manual keying, OCR and RPA, or legacy bridge
Each usual alternative solves half the job: OCR stops at extracted data, and RPA bots replaying recorded clicks break when a screen changes. legacy bridge does both halves, with confirmation.
| Criterion | legacy bridge | OCR + RPA | Manual keying |
|---|---|---|---|
| New customer PO layouts | Read without templates | A template per layout | Read by a rep |
| Customer part numbers | Your host lookups, plus remembered fixes | A mapping table someone maintains | A rep's memory |
| Re-sent orders | Caught by content | Caught by PO number, if at all | Depends on who keyed the first one |
| Screen changes | Reads screens by meaning | Scripts break | Retraining |
| Proof it was entered | Read back from the host, every keystroke recorded | Bot log | None |
Order entry on AS/400 (IBM i) and other ERPs
legacy bridge runs in production on IBM i (AS/400, iSeries), including custom RPG and COBOL order entry programs and packaged ERPs on IBM i. Nothing is installed on the host and no program changes: it connects as a terminal emulator does, over TN5250, through a secure SSH tunnel if the system is not on the internet. See IBM i data entry automation.
The same engine speaks TN3270 for mainframe order systems, VT and HP 6530, and can drive a web portal or a desktop ERP over Citrix or RDP, scoped per workflow with the same controlled proof. It fits order desks in manufacturing and logistics. Buying rather than selling? See purchase order automation.
