What it does
Work orders from partner programmes arrive as PDFs and land in a folder. Every fifteen minutes a scheduled job takes each new one, reads it with a vision model, and creates what the office would otherwise type: the customer if they are not already on file, the equipment, a case, a task for the technician, and the sales order with its dates, notes, addresses and lines. Then the PDF moves to a processed folder.
- Work order PDFsent by a partner programme
- Every 15 minutesa scheduled run picks up new files
- Read by a modelnames, dates, address, lines
- Customer on file?yes four more records · no new customer
- New customercreated only when nothing matches
- Four more recordsequipment, case, task, sales order
- ProcessedPDF moved, linked to the order
The new build runs in the sandbox on documents the old tool already handled, and every field is compared before it goes near production.
Why rebuild it
The tool that did this came as a compiled vendor bundle. We could not read it or change it, so every fix lived around it, cleaning up orders after they had been created. When it started creating duplicate customers, records with no document behind them and wrong issue dates, I wrote the failures up for the vendor with examples, corrected the dates it had got wrong in one mass update, and proposed building our own.
How it is being checked
The new version runs in the sandbox on work orders the old tool already processed, so every document comes with the records it produced. Each output is compared field by field, and the differences go to my lead before anyone talks about production.
Systems inside it
- A vision model reads each work order PDF
- Five records from one document, matched before anything is created
- Every field compared with the old output before launch
- Failure report and clean up of what the old tool created