EDI Solution

Starting to use EDI implies adapting your management and your billing, warehouse and accounting programs to a new language and coding that most of the ERP's on the market do not contemplate. Why? The main reason is that EDI is a form of relationship that takes into account both the sender and the receiver, while ERPs tend to focus solely and exclusively on organizing their client, not so much the relationship between the client and their business partners -clients and suppliers-.

Therefore, four changes must be taken into account:

First, it is necessary to generate an electronic document according to the United Nations standard UN / EDIFACT. Are there any other standards in EDI relationships? Yes, even the exchange of XML documents is becoming more and more common, but this is the most widespread.

To transform the information that comes out of your ERP, EDI Service is necessary, either a software or an EDI station that links with our internal computing and translates the information to the standard at the same time that it connects with your advanced EDI electronic mailbox. This adaptation and structuring to electronic language must be governed standards. Why the UN / EDIFACT? Because UN / EDIFACT is used as the "Esperanto language" of commerce, administration and transport.

Second, to know that the referred product is exactly the one that is sent and with the agreed characteristics, it is necessary to uniquely identify it, both for the sender and for the receiver, and for this purpose, the EAN Codes are used in EDI. Do you know where they are? On any product with a barcode.

Once the products and our company have been identified globally, we will need a communication network or channel through which to get the messages to the recipient. In the EDI environment, Value Added Networks (RVA) or VAN Networks are mostly used.

And finally, start sending and receiving. Your company will exchange purchasing orders, delivery notes (desadv), invoices (invoic) ... whose information can be consulted through an online access to your EDI service or through your ERP (integration) avoiding changing your company work procedures and their way of working in order to adapt and participate in one of the largest business communities in the world.

EDI in the 21st century

The EDI concept has evolved from its initial context, based on the EDIFACT standard and value-added networks, to a more open one where the use of new formats, documents, standards and protocols are compatible. Having an EDI service or software will not only allow you to work under this concept, but it has also been transformed to offer a global service for the electronic exchange of documents where all participants are connected regardless of the technology or standard used.

The use of EDI is extended to many industries but it has a special penetration in the sectors of retail trade (supermarkets, large stores, distributors, etc ...), Automotive (vehicle manufacturers, components, dealers, etc ... ), Health (Hospitals, health centers, clinics, pharmaceuticals, etc ...) and Transportation.
If your company does business with companies in any of these sectors, you are probably already working with EDI and can find a way to improve your
communication.

How is EDI used in messages between supplier and customer: orders, delivery notes, confirmations of receipt of merchandise or invoices?

Although all sectors that use the same documents may be that there is ever the existence of mandatory maritime orders and, in others, where the order of receipt of optional maritime merchandise. Similarly, some documents have different information with the sector or type of exchange (replacement of fresh, fish ...).
In any case, when a large area requests a supplier, for example, the replacement of
milk; When a Hospital requests a surgical material supplier to send new materials; or when a vehicle manufacturer requests a new tire from its supplier, all of them coincide in sending the invoice.
EDI cycle 1 The logic is based on the customer, following the example of the vehicle manufacturer, placing an order for merchandise (ORDERS), detailing the number of tires that can be
to buy. This order will indicate the quantity requested, the models, the characteristics, etc. The supplier of the goods and tires will respond with a delivery note (DESADV) describing the products shipped. The delivery note can contain information at two levels, the basic and the logistics, where the organization of the material is indicated in detail, pallets, boxes, etc. The factory, after receiving the tires, will send a confirmation of receipt of goods (RECADV) which is essential since it indicates the discrepancies, if any (for example, receive 80 tires instead of 100 or if the model of 4 of them is not the requested one). After verification of the supplier, the sales invoice (INVOIC) with the corresponding corrections.

The third actor: Transporter / Logistics Operator

EDI cycle 2 An EDI project not only allows you to manage the relationship between the supplier and the customer. Usually a transport or logistics company participates in this relationship that sends the physical merchandise to the customer's logistics center. In addition to the aforementioned documents, in the logistics environment the dispatch notice (DESADV), the dispatch instruction (INSDES), dispatch situation (OSTRPT), transport situation are also used.

(IFTSTA), forecast of needs or consumption, delivery scheduling, delivery response program (DELFOR), etc. This exchange of information in real time enables better calculations to optimize time, space and human and financial resources.

The majority of logistics operators, due to the condition of their clients and the amount of goods they transport, work with EDI.

When your company is about to send your clients a significant volume of their invoices, delivery notes or any other document, the need to optimize that shipment increases. To do this, the first logical step is to group all the documents to be sent from your ERP in the same "file" and thus not have to open and close the connection every time a document is sent with each of your clients.

This "file" is called "remittance of documents" and once received in your SERES service, it triggers a set of supervision tasks, among which the following stand out:

• Rules document review of its authenticity and integrity: We confirm that the sender is who he claims to be and we ensure that he identifiers of the receiver are correct. Error example: Send an invoice to a customer with the wrong NIF.
• Legal rules review: We apply the rules that are required by law. Example: The invoice has an indicated number.
• Semantic and syntactic review of document information: We confirm that the invoice information is correctly created.
  Example: The invoice amount in euros corresponds to a number with decimals.
• Recipient's business rules review: We confirm if there is any requirement from your client to accept your document. Example: Invoices to Spanish Public Administrations must include the code dir3.

What happens if any of the reviews fail

For a more agile, quick and easy management, your "remittance" is divided into parts or exchanges, according to its recipients and to the document. In this way, SERES offers you a "Remittance Report" where you can find out in detail for each client the documents that have passed all the filters and those that haven't.

In this way, the management of a remittance should focus on the cases to be supervised and where its solution is related to the previous reviews:

• Review of document authenticity and integrity: An incorrect nif has been indicated with an "X" in the block of numbers, for example "A5845X54". Change the data in your ERP.
• Review of legal rules: The invoice number must be indicated in your ERP.
  Semantic and syntactic revision of document information: A quantity has been indicated with letters. For example, the amount "€ 1000" when it should be "1000.00".
• Recipient's business rules review: If the invoice is to the Madrid City Council, the invoice must contain the DIR3 code that unequivocally identifies the Organic Units and Registry Offices of the AAPP. The solution requires identifying the DIR3 data from your systems.

Once the special situations have been solved, it will only be necessary to resend the documents that, only if passing all the rules, will now be sent to your clients.

When we take the step to the electronic exchange of documents, we become aware of additional information, which doesn't come in the exchange on paper, this is necessary so that the recipient can, in an automatic way, prepare his environment for the incoming merchandise, until the bill to be paid ...

Today we are going to talk about the location of information that all EDI messages contain and are necessary for the document both globally and internally in the companies.

Directions from the global point of view

A document to be sent and received by an entity must have an address. To do this, the entity must be uniquely identified. Thus, for instance, people in Spain have their physical address in Madrid at "Paseo de las Doce Estrellas 2. 28042 Madrid" and a different one in Barcelona. Both physically locate a business. Both use the "tax number (NIF)" as in Spain for their global identification. Each company has its own regardless of the number of offices it has.

In the EDI environment the global company identifier is a unique EAN code for each company.

Making a comparison with the previous example, the EAN code of the entity would be like its "tax number". The physical address (street, avenue, promenade ...) is not so important in an electronic document.

Directions from the internal point of view

Once the message has reached the recipient's "Global Electronic Mailbox", internal addresses start taking more importance. Like those that define where the document information should be treated within the company.

In the EDI environment, the internal identifiers of each company are also EAN codes. Unique in the world for each unit, department, manager, delegation, etc.

In the case of a delivery note, the EAN merchandise code delivery (warehouse, center, building, aisle, floor, etc.), who has placed the order (store, office, etc.) is usually indicated in the document.

On the invoice, it's usually indicated who is the invoicer and who is billed, who pays and who collects.

These EAN codes allow the document to be redirected to the means necessary for its processing. The warehouse manager who prepares for the receipt of the merchandise must receive the information from the praise to prepare for its receipt and collation. Similarly, the recipient of the invoice will need that matching information to post it and the treasurer to pay it. All these participants must be identified and known by both the sender and the receiver of the message.

How is it managed from a business point of view?

Any company that benefits from EDI must have its administrative structure. In other words, a document with all possible EAN codes in your daily management.

This EDI structure can be very simple, for small companies, or very complex. This complexity is often alleviated by creating logical EAN code unions. In this way, only a limited set of logic codes need to be handled.

Administrative Structure Example

Center A: Code A (who is billed) and code B (who pays)

Center B: Code B (who is billed) and code B (who pays)

Center C: Code C (who is billed) and code B (who pays)

Center D: Code C (who is billed) and code D (who pays)

In this example of four centers, three share a treasury department (Code B), center C or D shares an accounting department. In this case, the chances are reduced from 64 to 4.

EDI user companies notify changes or opening of new operational points in GENRAL messages.

In an automated environment, the issuer and receiver of the document are usually informed of this information that allows from an order to a delivery note to an invoice almost all of the information on global and internal addresses.

A bit of technicalities: NAD segment

EDI messages contain a sequence of information segments, which may be mandatory requirement or conditional inclusion, may be formed by simple or compound data (when they are formed once by other simple data) and may or may not be encoded (values ​​taking from an associated, previously known, or attached list).

The Directory of Segments or NAD Segments contain the destination information for sending the message, that is, the definition of the company, name, code, address and NIF, in addition to including department, processing unit, or whatever required depending on the internal structure of the recipient. This is essential for the message to be received and accepted by the department and assigned for the agility of the management process.

NAD Segments include both buyer and seller information. That is, all the Operational Points involved in communication.

One of the great pillars on which EDI is based is the definition and use of unique identifiers. They receive various names, such as: EAN Codes, Operational Points, GLN ... Whose most primitive essence is that the customer (issuer) who requests merchandise from a supplier (receiver) knows, without a doubt, what we are talking about.

Within EDI we can differentiate several types of identifiers:

Product or service identifiers

It's globally accepted that a barcode is a distinctive element of any product. This same set of bars conceals a number (usually 13 digits) that, in addition to being read by a supermarket cashier's reader, allows it to be identified in an unambiguous way around the world.

The first key here does not lie so much in the use of these codes, which is already very widespread, but in the way in which your company organizes its products by assigning them their corresponding codes, in addition, if coming from another "not so advanced" environment we migrate internal product codes with their global equivalents.

The second key is to inform your customers of those codes. In this case, the EDI PRICAT document has a lot to say, since its content does not provide information on the codes alone, but on additional information on the characteristics of its products.

Company identifiers, departments, units ...

Every document exchanged must contain at least the sender and the receiver.

As with product identifiers, names do not usually allow a clear relationship between the use of abbreviations, acronyms, accents, etc.). In this case, for company identifiers, the range of possibilities is much wider, from the same EAN, a VAT number, national codes, DUNS, and a long list of codes that in their relationship identify a company unambiguously.

But the reality indicates that it is not necessary to identify the sender or receiver of the message, internally exchanged document requires showing other units within the company. In the example of an EDI delivery note (DESADV) it's necessary to indicate that the merchandise has been delivered, in an invoice, we need to indicate who asks to whom for the payment, who receives the merchandise, and to whom it's billed and even the what's the payment about.

Organize the "administrative structures", list of units, centers, departments, etc. It is vital for your management, your client or supplier.

Organize your identifiers and code conversions

When a company has to organize the identifiers it sees the situation that you already have defined but based on your own internal codes. The conversion of these codes is essential for a correct electronic exchange of documents and also for the correct automation of the process and integration of the data in your IT management systems (ERP).

Many of the benefits that EDI services provide are hidden from most of its user companies. This month's council wants to show you how to take advantage of a feature of our technology to securely exchange your documents electronically, and specifically your issued electronic invoices.

It has always been said that the best financing for a company is through the sale of its products and services. As a provider for a large amount of clients, the collection of your invoices is often complex and implies that your company has to resort to other forms of financing.

SERES EDI services allow you to have complete traceability of the status of your exchanged documents. In the case of issued invoices, your company will know if your client agrees with their content, where they are in the processing process and even know when they are going to pay. In a paper invoice management environment, your company has no record of the date on which the calculation of the payment term begins and, therefore, provides less credibility when negotiating its collection and less knowledge of the future status of your treasury.

It's not within EDI capacities to be able to change your payment term, although knowing that your electronic invoices will be established and accepted in just seconds, your company has greater capacity in its periodic negotiation with your client to access "discounts for prompt payment" in a few seconds.  Additionally, and perhaps occasionally, you can take advantage of this situation to more consistently negotiate the progression of an invoice. Something that will surely alleviate your working capital in an extreme situation.

Another form of financing is through factoring, either with your clients or with a financing entity, bank or not. The electronic invoice allows you to more quickly communicate the documents related to your operations. Presenting the relationship of EDI documents between your client and your company, the purchase order, delivery note and the invoice, will provide you with a proof of greater confidence with your credit institution for the financing of your working capital.