Even though everyone is talking about digitalisation at the moment - it’s by no means a new idea. The exchange of structured electronic business data by EDI (Electronic Data Interchange) has been taking place for decades. EDI is used to transfer business-related data electronically between IT systems without any human intervention and optimises business processes – in various company departments and beyond the confines of individual companies.
In order processing, for example, linking in with EDI partners avoids entry errors, automatically initiates downstream processes and cuts delivery times. In accounting, electronic processing minimises the amount of work involved in data input, cuts document processing times and increases transparency. All in all, companies benefit from reduced transfer, processing and response times.
In order for data to be exchanged smoothly, two IT systems need to be able to communicate with one another. And for this communication to run smoothly between one machine and the next, a series of cross-system standards has been produced. Similar to an electronic form of Esperanto, the sender’s data is put into a generally understood “language”, which is then translated in turn into a format which can be read by the receiver.
Recognised standards – see Esperanto - include, for example, the globally used EDIFACT (Electronic Data Interchange for Accounting, Commerce and Transport) with its industry-specific subsets as well as ANSI, SWIFT or ZUGFeRD. Above and beyond this, SAP has developed its own interface for exchanging business data with the SAP ERP system: IDoc format.
EDI messages can be processed by systems in companies – without any manual intervention by the administrator. Anyone who works with EDI messages on a daily basis will however know that errors can occur even here. As soon as the agreed standards and structures are not followed to the letter, the electronic data interchange may run into problems. Users inexperienced in standard EDI solutions face the huge problem of finding the cause of error in the highly cryptic data. The IT department usually has to be contacted, making things even more complicated.
tangro has developed its own EDI converter, which maps the EDI messages in a format legible for tangro. Incoming EDI data is then stored as a tangro document. This prevents incorrect data from being transferred to SAP, where due to errors it could not be processed any further and would therefore halt the process as the data wouldn't be in a legible form. In any case, tangro automatically generates a PDF, which is displayed on the monitor in parallel with the document data.
Even an EDI novice can visually check this screen and see at a glance where which data is missing and/or where there are discrepancies. This process is just as simple as with a document scanned using OCR. For the benefit of the user, tangro makes no distinction here. A feature, which incidentally is reflected in the billing model: no matter whether the customer uses OCR or EDI, there are no additional costs.
The EDI converter processes invoices as well as order data and supports all key standard formats, including EDIFACT and XML-based formats such as ZUGFeRD, XRechnung and EbInterface. The software can be flexibly adapted to existing business processes and maps company-specific rules and requirements. For example, the converter automatically adds to the received message additional information, such as source of supply or company code, information which is needed for fully automatic further processing.
Error-free documents can therefore be posted without the administrator having to intervene - as is commonplace with EDI. What’s more, rules can be specified to prevent background posting if this is expressly not wanted. If necessary, the converter also automatically initiates a workflow, to forward documents, e.g. to the right agent or the right organizational unit.