I agree Utilizamos cookies para mejorar la experiencia de navegación del usuario y para estudiar cómo se utiliza nuestro sitio web. Si navega por nuestro sitio web, estará aceptando el uso de las cookies en las condiciones establecidas en la presente política de cookies. Esta política puede ser actualizada, por lo que le invitamos a revisarla de forma regular.
¡HI! If you want to propose us a project, send a mail to email@example.com
By Francisco González, Data transformations expert
Nowadays, an absolutely necessary condition for the sustained growth of a commercial company is how easy it exchanges information electronically with customers and suppliers. It is unthinkable today that a company that receives 100 orders and generates 100 invoices a day, takes orders over the phone or sends 100 envelopes by ordinary mail to their customers. As the business grows, the amount of staff resources required to handle such a lot of manual work increases proportionately.
Even if the order data arrives in an email’s body or the invoices are sent in PDF format, this does not represent a considerable improvement, since the receiver still needs to enter the data by hand in his system. First ones to put a stop sign at this situation were the big retail chains (Makro, Alcampo, El Corte Inglés, etc ...), who can’t undertake the work of typing the 1,000 invoices of providers that they receive every day.
An alternative for these large companies would be to scan them in mass by using an automated OCR system, but it is not so easy to find unequivocally the data necessary to carry out, at least, the accounting data. An additional difficulty is that each provider has its own document design, so incorporating a new vendor requires the additional work of creating a new recognition template. In short: it saves work, but the business is not scalable.
For these reasons, it is possible to observe a constant growth, promoted mainly by these retail chains, of the exchange of electronic documents, also called EDI. Unlike PDF files or emails, documents exchanged by EDI (orders, delivery notes, invoices, stock levels, price lists, etc...) contain structured data in such a way that they can be read perfectly by a computer system and to be imported in a target database automatically. The reduction of personal, of errors produced by the introduction of manual data and the time elapsed between dispatching and receiving is huge, which leads to an extremely cost reduction of purchasing management.
This saving is so significant, that these large retailers force their suppliers to send data through EDI. To accomplish this, they define one or two document formats (EDIFACT, XML, CSV, etc ...) and some communication channels (email, FTP, AS2, VANs, etc...) to which their suppliers have to fit. The big ones take advantage of their condition as client to press the small ones for their own benefit.
Once the internal problem of the big chains seems to be solved, what happens to their suppliers? These are usually small or medium businesses and do not usually have enough technical capacity to generate any type of EDI document that their customers ask for. This implies, as least, to lose competitive advantage over the competition (the customer will always choose the supplier that produces the lowest cost) and, in other cases, it means losing the customer completely. A supplier who disconnects from its distribution chain is doomed to failure.
Sometimes the problem of implementing a new customer’s EDI format is very unreasonable: a direct mapping of data from the ERP’s system database to the output format (e.g. EDIFACT invoice) is done by programming. This solution is usually difficult to maintain and is not scalable at all, since you have to repeat almost all the code again to achieve the next client’s new format. The time for implementation and tests usually surpasses by far the initial plans. Due to the high total cost of this approach, it does not seem to be a reasonable solution.
The same ERP manufacturer can provide some specific EDI formats, but can’t cover all the existing in the market. In addition, this type of data interface functions isn’t a central task of such applications and always involve an annoying but necessary job to satisfy the requests of their clients.
The best solution for them is to acquire a software (e.g. TransdatiX) that integrates easily with their ERP, provides preconfigured modules for transforming documents into the target formats of the large chains and facilitates the sending and receiving of these files. Another feature of such software would be the type of use, which can be through local installation, in the cloud or pay per service.
Just as mechanical traction motors need perfect coupling between gears to function optimally, the supplier's production chain must be synchronously linked to the customer's supply chain. Sometimes the difference between success and failure of a business relationship is very small and depends on the fluidity of the data between them, which couples their chains. This requires something relatively small: a link.