01 Parsing air freight reports and auto filling 1C

Air freight paperwork arrives in batches: waybills, flight reports, accompanying documents for a period. A single batch contains hundreds of files, and they arrive in whatever form the counterparty sent them: some as text based PDFs, some as Excel or CSV spreadsheets, some as plain text documents. There is no single format and there won't be one: every source has its own structure and its own set of columns.

A person sorted through all of it. They would open a document, find the waybill and flight number, the date, the route, the counterparty, the weight and number of pieces, the amounts, rates, and fees, and transfer them into Excel, and from there into the accounting system. One batch took a full working day, sometimes more.

A skilled employee's entire working day went into retyping numbers from one file into another.

The problem here isn't only speed. Transferring hundreds of values by hand guarantees typos, and an error in a weight or a fee amount doesn't surface right away, it surfaces later in the reporting, when tracing its source is already expensive.

A desktop application in Python. The user loads the entire archive into it at once, with no need to unpack or sort files by hand. The application scans the contents, identifies the type of each document, and parses it with the handler built for that type: a text based PDF, a spreadsheet, and a plain text document are three different tasks, and one universal method can't solve all three.

The documents yield exactly what the project set out to extract: waybill and flight numbers, dates, routes and counterparties, weight, piece count and cargo volume, amounts, rates, and fees. The data is then consolidated into a single structure regardless of the form it arrived in, and fills Excel files in the format the client uses.

Load the archive, get back filled files and a ready made export. Manual parsing disappeared from the process entirely.

Desktop rather than a web application was a deliberate choice. The documents sit on employees' own machines and contain commercial shipping data; uploading them to a server for the sake of a convenient browser button would have created a problem that didn't exist before. The application runs where the files already are.

A filled Excel file on its own only closed half the task: the data still had to make its way into the accounting system. So the application prepares an export file in the format that 1C picks up on its own side, and the accounting system gets filled without anyone transferring values by hand.

This is exactly why the case results show zero data entry errors. It isn't about employees being careful: as long as data is retyped by hand, typos are just a matter of time and volume. Once the chain from source document to the accounting record is no longer interrupted by manual entry, there is physically nowhere left for an error to happen.

Processing a batch that used to take a full working day now takes minutes. Converted to a monthly figure, the department freed up roughly a hundred hours, and this isn't "we sped up the process," it's freed up time for skilled people who used to spend it retyping numbers.

It's worth stating separately what the project did not do: it did not replace employees, and it was never meant to. It removed one operation from their work that repeated every day in exactly the same form. Exactly the kind of case automation exists for.