Miscellaneous

The BWA format comes from the German book industry. It’s a messaging standard comprising a total of four different messages:

• Order
• Delivery note
• Acknowledgment
• Title master data

The underlying format is a somewhat adventurous mixture of CSV and fixed record. Fortunately, this format is now considered outdated. For some time now, the German Publishers and Booksellers Association (Börsenverein des deutschen Buchhandels) – or more specifically, its “Working Group on Processes, Streamlining and Organisation” –

has recommended using the EDIFACT subset EANCOM instead, since this simply offers more options.

Nonetheless, here is an order record in BWA format to serve as an illustration of its structure:

Not exactly clear, is it? But as we said, the BWA standard is now considered outdated, and EANCOM is recommended instead.

So much for the messaging standards. Now we will turn our attention to the – let’s say – more idiosyncratic formats.

Let’s get one thing clear from the start: Excel is not a data interchange format within the meaning of EDI! Regrettably, that doesn’t stop some people from using it as one. :-(Excel generally means manually completed forms, which regularly exhibit small or even large discrepancies and are likely unsuitable for fully automated processing. Some particularly imaginative peers will even send out Excel files containing internal links to other Excel files. These will inevitably be stored on C:\somewhere\nowhere, and won’t be sent out along with the file linking to them.

Our top tip is to avoid any data interchange in Excel format! Excel can export files to CSV and re-import them too, which is better than trying to communicate directly via Excel. After all, we are talking about automated processes here, and not about some employee looking at an Excel file on a screen and manually copying its contents into their system. If this is unavoidable then OK – you will just have to bite the bullet. Modern converters can read or output Excel files too. But you (and your partner) will have to live with the fact that you won’t be able to rely on seamless, fully automatic processing of a kind that is (strictly speaking) required for EDI, and which is perfectly possible if you use standard formats.

The same goes for PDF as for Excel: It’s designed for people to look at on a screen, or to print out. It isn’t intended for use in EDI processes, and it is not suitable for such processes either. Only in rare cases where PDF files have been produced fully automatically and with a reliably uniform structure is it possible to process them automatically to a limited degree. If this isn’t the case, all you can do is apply a form of OCR-like pre-processing to convert what the human user sees into a somewhat machine-readable form.

PDF is a fantastic invention and is also used (often in conjunction with electronic signatures) to archive invoices and similar documents in a way that protects them from being manipulated. But it’s completely unsuitable for EDI.