| EANCOM® 2002 S3, Edition 2016 | Part I |
|
|
The EANCOM® messages can be divided into the following categories:
The messages available in the EANCOM® standard cover the functions required to carry out a complete trade transaction: messages which enable the trade transaction to take place, (e.g., price catalogue, purchase order, invoice, etc.); messages used to instruct transport services to move the goods; and messages used in settlement of the trade transactions through the banking system. The flows and trading partners catered for in EANCOM® can be represented as follows:
The Party Information message is the first message exchanged between trading partners at the beginning of a commercial relationship. It is used to provide location information and the related operational, administrative, commercial and financial data to the trading partner, (e.g., name and address, contact persons, financial accounts, etc.). The message will be exchanged again if there are any changes or updates to such information at a later stage of the trading relationship, so that the partner's master data files are maintained and kept current.
The Party Information message can also be used by the trading partners to feed a central catalogue of addresses, making the information available to all interested parties.
The Product Inquiry message enables a buyer to inquire on a product or group of products from a master product catalogue according to criteria defined in the message. The buyer may specify in the message the attributes of a product or group of products for which he is interested in receiving additional information. This will allow a manufacturer and/or supplier to send the buyer only information for those products in which the buyer is specifically interested, rather than the entire product catalogue.
The Product Inquiry message may request information in order to select a specific group or family of products from a supplier's entire product catalogue, (e.g., a buyer requesting from a supplier of medical equipment all product information related to sterilised products), select a product or group of products according to attributes or product characteristics as defined by the sender in the message, (e.g., a retailer requesting a clothing manufacturer to send product information for all blue, white or striped men's shirts, sizes medium to extra-large), or determine the availability, lead-time and/or general commercial/sales conditions for a specific product.
The Product Inquiry message may be responded to by a Price/Sales Catalogue and/or Product Data message, depending on the business requirements expressed in the message.
The Product Data message is similar message to the Price/Sales Catalogue message in that it is used to exchange product related information between trading partners. The fundamental difference between the messages is that the Product Data message is used to provide technical and functional data related to products, (e.g., the technical specifications of an electrical product, the ingredients of a cake, etc.), and does not include any commercial terms and conditions. Data exchanged in the Product Data message normally does not change very frequently.
GS1 advises to implement the Price/Sales Catalogue message since it offers more functionality. However, some users have already implemented the Product Data message and have no business reason to replace it.
The Price/Sales Catalogue message is sent by the supplier to his customers. The message is used as a catalogue or list of all of the supplier's products or as an advanced warning to particular changes in the product line. The catalogue would include descriptive, logistical, and financial information about each product. However, the catalogue may also be used to provide technical and functional data related to products, (e.g., the technical specifications of an electrical product, the ingredients of a cake, etc.) as done in the Product Data message.
The message might indicate only general information about the products, valid for all customers or provide a single customer with specific product information such as special pricing conditions. Additionally, the message can be sent from a buyer to a seller to specify special requirements such as buyer labelling or packaging requirements.
The message will be re-sent when there are any changes, deletions or additions to the supplier's products.
The Price/Sales Catalogue message can also be used by suppliers to feed a central catalogue of products, making the information available to all interested parties.
2.4.1.1. Request for Quotation (REQOTE)
The Request for Quotation message is transmitted by the customer to his supplier to request a quotation for the supply of goods or services. The request for quotation may be used to solicit the supplier's payment terms and conditions, and also to specify the required quantities, dates and delivery locations. The message will refer to the location and product codes exchanged previously in the Party Information and Price/Sales Catalogue Messages.
The Quotation message is transmitted by the supplier to his customer in response to a previously received request for quotation for the supply of goods or services. The quotation should provide details on all aspects previously requested by his customer. The information sent in a quotation may directly lead to a Purchase Order being placed by the customer.
2.4.1.3. Contractual Conditions (CNTCND)
The message is exchanged between trading parties, providing the contractual conditions of a previously negotiated contract in order to enable the automatic validation of orders and the verification of invoices prior to payment.
This message is typically used in the case where a general contract has been established between parties, against which goods will be ordered over a period of time on an order-by-order basis. The contract will have been previously negotiated and accepted. This message only contains the information which can be used to automatically approve the transmission of an order or the correctness of an invoice.
2.4.2.1. Purchase Order (ORDERS)
The Purchase Order message is transmitted by the customer to his supplier to order goods or services and to specify the relevant quantities, dates and locations of delivery. The message may refer to an earlier Quotation received from the supplier for the ordered goods or services. The message will refer to the location and product codes exchanged previously in the Party Information and Price/Sales Catalogue Messages. It is intended to be used for the day-to-day ordering transaction with, as a general rule, one Purchase Order per delivery, per location. However, it is possible to request deliveries at several locations and on different dates.
2.4.2.2. Purchase Order Response (ORDRSP)
The Purchase Order Response is sent by the supplier to his customer in relation to one or more goods items or services to acknowledge the receipt of the Purchase Order, to confirm its acceptance, to propose any amendments, or to notify non-acceptance of all or part of the Purchase Order. The Purchase Order Response may also be used to respond to a Purchase Order Change Request Message. A buyer's Purchase Order may be responded to by one or more response messages according to business practice.
2.4.2.3. Purchase Order Change Request (ORDCHG)
The Purchase Order Change Request is sent by the customer to the supplier to specify the details concerning modifications to a previously sent Purchase Order. The customer may request to change or cancel one or more goods items or services.
The exact information flow with regard to the Purchase Order, the Purchase Order Response and the Purchase Order Change Request messages can vary. The procedures to be followed by the trading partners should be specified in the Interchange Agreement. An example of procedural difference might be not having the supplier send a Purchase Order Response message if there are no modifications to be made to the original order.
2.4.2.4. Order Status Enquiry (OSTENQ)
The Order Status Enquiry message may be sent from a buyer to a supplier to request information on the current status of a previously sent order(s). The message may be used to request status information for a previously transmitted Purchase Order message.
2.4.2.5. Order Status Report (OSTRPT)
The Order Status Report message may be used by a supplier to report the status of an order. This message may be sent as a reply to an Order Status Enquiry sent by a buyer or buyer's agent or a report sent at regular intervals as agreed by the parties. The message may be used to report status information for a previously transmitted Purchase Order message.
2.4.3.1. Cargo/Goods Handling and Movement (HANMOV)
The Cargo/Goods Handling and Movement message is sent by a party (e.g., buyer or supplier) to a warehouse, distribution centre, or logistics service provider, identifying handling services on products held but not owned by the message recipient, and, where required, the movement of specified goods, limited to warehouses within the jurisdiction of the distribution centre or logistics service provider.
This message addresses the indirect flow of goods between supplier and buyer through a warehouse, distribution centre or logistics service provider and caters for the following functions: the preparation of goods for shipment, the picking of goods according to instructions, the packing or unpacking of goods, the marking and labelling on the packages of goods, and instructions regarding the movement of goods between warehouses.
2.4.3.2. Instruction to Despatch (INSDES)
The Instruction to Despatch message is a message from a party (e.g., buyer or supplier) to another party (e.g., Logistic Service Provider or LSP) who has control over ordered goods, providing instructions to despatch or collect a consignment according to conditions specified in the message. The message may be used to identify the delivery location(s), identify the date(s) on which delivery should take place, indicate that the despatch is subject to cash on delivery, etc.
Because the third party service provider is outside the normal buyer-to-supplier order process, the Instruction to Despatch message may be used by the supplier or buyer to inform the third party service provider of information stated in the purchase order which is required for the effective despatch of the goods, (e.g., terms of delivery, transport equipment required for the delivery), to enable the logistic service provider to produce a despatch advice on behalf of the buyer or supplier.
2.4.3.3. Firm Booking (IFTMBF)
The Firm Booking message is a message from a party booking forwarding and/or transport services for a consignment to the party providing those services, containing conditions under which the sender of the messages requires the services to take place. A firm booking message is a commitment from the consignor to the carrier or forwarder to avail himself of certain services, and is used for planning or operational purposes by the carrier or forwarder.
2.4.3.4. Booking Confirmation (IFTMBC)
The Booking Confirmation message is sent from a carrier or forwarder to the consignor booking services, providing confirmation of a booking for a specified consignment. A confirmation may indicate that the booking of a consignment is accepted, pending, conditionally accepted or rejected. The message can be used whenever a confirmation of the booking of a consignment is deemed necessary as an answer to a firm booking message for a specific consignment.
2.4.3.5. Transport Instruction (IFTMIN)
The Transport Instruction is sent by a customer to his supplier of transport services (who may or may not be the supplier of the goods), requesting the transportation of a single consignment of goods to a specified delivery point or points. The instruction may be for one or several goods items which may be specially packaged for transport purposes. Identification of transport packaging may be achieved through the use of the Serial Shipping Container Codes (SSCC).
2.4.3.6. Forwarding and Consolidation Summary (IFCSUM)
The Forwarding and Consolidation Summary message is a message from the party issuing either an instruction or a booking regarding forwarding/transport services for multiple consignments (the equivalent of multiple Transport Instruction messages) under conditions agreed, to the party arranging the forwarding and/or transport services.
The message results in a transport contract for multiple consignments and is primarily meant for administrative purposes. It will be the message from shipper to carrier or forwarder containing the final details of the consignments for which services are provided.
2.4.3.7. Transport Status (IFTSTA)
The Transport Status message allows for the exchange of information regarding the status of the physical movement of consignments or goods at any point (in time or place) within the full transport chain. The message may be sent as the result of a request or requests for information regarding a consignment or consignments, on a scheduled basis at predetermined times, on the occurrence of a selected event or events, or on the occurrence of an exceptional event as agreed by the partners involved.
2.4.3.8. Arrival Notice (IFTMAN)
The Arrival Notice message is sent from the party providing forwarding and/or transport services to the party indicated in the contract (e.g., the consignor), giving notice and details of the arrival of a consignment. The message may also be used to provide proof of delivery information. One arrival notice message should always correspond to one consignment.
2.4.3.9. Despatch Advice (DESADV)
The Despatch Advice is a message specifying details for the goods despatched under conditions agreed between the buyer and the seller, with the function of advising the consignee of the detailed contents of a consignment. The message relates to a single despatch point and a single or multiple destination points, and it may cover a number of different items, packages or orders. The message allows the consignee to know what materials were despatched and when, allowing the consignee to prepare for receipt of the goods and to cross-check the delivery with the order.
The Despatch Advice may be sent for either the despatch of a delivery consignment of goods or the despatch of a return consignment of goods. Identification of transport packaging may be achieved through the use of the Serial Shipping Container Codes (SSCC).
2.4.3.10. Receiving Advice (RECADV)
The Receiving Advice is a message specifying details for the goods received under conditions agreed between the buyer and the seller, with the function of advising the consignor of the received contents of a consignment. The message relates to a single receiving point and a single despatch point and it may cover a number of different items, packages or orders. The message allows the consignor to know what materials were received/not received against the original order and what materials were accepted/not accepted. This information allows the consignor to prepare an invoice for the customer.
2.4.3.11. Announcement for Returns (RETANN)
The Announcement for Returns message is used by a party to announce to the other party details of goods for return due to specified reasons (e.g. returns for repair, returns because of damage, etc.). The message may be used by the message sender to request credit for goods, or the replacement of goods from the message recipient due to a problem with the goods (e.g., goods received in bad condition, goods received but not ordered, unsold goods which have exceeded their expiry date, etc.) discovered after the delivery process has been completed (i.e., the goods have been received and checked at case level and a Receiving Advice has been issued).
2.4.3.12. Instructions for Returns (RETINS)
The Instructions for Returns message is the means by which a party informs another party whether and how goods shall be returned. The sender of an instruction for returns message will normally have previously been informed by the recipient of the intention to return goods by means of the Announcement for Returns message.
The Instruction for Returns message may be used to inform a party if the sender refuses, or does not require, return of the goods. Where the message sender does not require the return of goods, the message may indicate what action the message recipient should carry out (e.g., disposal, destroy). Where the message sender refuses the return of goods, the reason for the refusal may be provided.
The Invoice message is sent by the supplier to the customer claiming payment for goods or services supplied under conditions agreed by the seller and the buyer. This same message with correct data qualification also covers the functions of pro-forma invoice, debit and credit note. The seller may invoice for one or more transactions referring to goods and services related to one or more order, delivery instruction, call off, etc. The invoice may contain references to payment terms, transport details and additional information for customs or statistical purposes in the case of cross-border transaction.
The Tax Control message may be sent by the supplier to the customer summarising the tax related information for an invoice or batch of invoices. Generally, it accompanies the actual invoice or batch of invoices. The message may also be sent by either party to third parties, auditors, and tax authorities in summary form to detail the tax information over a period of time.
2.4.4.3. Remittance Advice (REMADV)
The Remittance Advice is a communication between buyer and seller which provides detailed accounting information relative to a payment, or other form of financial settlement, on a specified date for the provision of goods and/or services as detailed in the advice. The message may be initiated by either the buyer or seller. The Remittance Advice is a notice of payment to be made, both national and international, covering one or more transactions. Each Remittance Advice is calculated in only one currency and relates to only one settlement date. References to payment orders may be included.
2.4.4.4. Multiple Payment Order (PAYMUL)
A Multiple Payment Order is sent by the Ordering Customer (normally the Buyer in EANCOM®) to its bank, to instruct the bank to debit one or more accounts it services for the Ordering Customer, and to arrange for the payment of specified amounts to several Beneficiaries (normally the Supplier in EANCOM®) in settlement of the referenced business transaction(s). The Multiple Payment Order may cover the financial settlement of one or more commercial trade transactions such as invoices, credit notes, debit notes, etc.
2.4.4.5. Commercial Account Summary (COACSU)
The Commercial Account Summary message enables the transmission of commercial data concerning payments made and outstanding items on an account over a period of time. The message may be exchanged by trading partners or may be sent by parties to their authorised agents (e.g., accountants).
2.4.4.6. Commercial Dispute (COMDIS)
The Commercial Dispute message is a notice of commercial dispute against one or more INVOIC messages (e.g., commercial invoice, credit note, etc.), which is usually raised by the buyer to notify the supplier that something was found to be wrong with an INVOIC message which detailed goods delivered or the services rendered (e.g., incorrect price, incorrect product identification, no proof of delivery, etc.).
The buyer may use the message to supply the following information; non-acceptance of an Invoice message containing errors, with a mandatory indication of error(s) providing the reason for non-acceptance and an indication of the corrections to be made, or, acceptance of an Invoice message containing errors and, if necessary, an indication of error(s) and an indication of the corrections to be made.
The Delivery Schedule is a message from a customer to his supplier providing product requirements for short term delivery instructions and/or long term product/service forecasts for planning purposes. The message can be used to authorise the commitment of labour and material resources. The message may provide schedules in two manners by location, or by product. The message may also be sent by a supplier to a buyer in response to a previously transmitted delivery schedule.
In its simplest form, a location delivery schedule allows the user to specify one location and multiple products which are/will be required for that location. The simple product schedule allows the identification of one product which is/will be required in multiple locations.
The Sales Data Report message, sent from a seller to his supplier, headquarters, distribution centre or third party such as a marketing institute, enables the transmission of sales data in a way that the recipient can process automatically. The message transmitting sales data by location in terms of product(s) identification, quantity sold, price, and promotions applicable can be used for production planning or statistical purposes. It should not be used to replace business transactions such as orders or delivery schedules.
The Sales Forecast Report message, sent from a seller to his supplier, headquarters, distribution centre or third party, enables the transmission of sales forecast data in a way that enables the recipient to process it automatically. The message transmitting sales forecast data by location in terms of product identification, forecasted quantities and promotions applicable can be used for production planning purposes. It should not be used to replace business transactions such as orders or delivery schedules.
The Inventory Report is a message between interested parties, specifying information related to planned or targeted inventories. All goods, services and locations detailed in the inventory report will have been previously identified in the Party Information and Price/Sales Catalogue Messages. Different classes of inventories may be identified which may also be financially valued. Quantities may relate to model or target quantities, minimum/maximum levels, reordering levels and held stocks.
The Syntax and Service Report Message is used by the receiver of an EANCOM® message to acknowledge receipt of and/or detail any errors contained in an interchange. This message is used to report on the syntax level of a message and is not used to report on the business data contained.
The Syntax and Service Report may be carried out by a third party, (i.e., a value added network), operating on behalf of the trading parties.
This message is send from the party who received an original message, to the party who issued the original message, to acknowledge to the message issuer the receipt of the original message by the recipient's application and to acknowledge errors made during the processing within the application.
The message should be generated by the application software - NOT by EDI-translator software - and must NOT be used to acknowledge the receipt of an interchange (see Syntax and Service Report).
The Multiple Debit Advice message is sent by a Bank to its customer (normally the Buyer in EANCOM®) to report amounts which have been (or will be) debited from the customer's account in settlement of a referenced business transaction(s). A Multiple Debit Advice message may cover the financial settlement of one or more commercial trade transactions, such as invoices, credit notes, debit notes, etc.
The Multiple Credit Advice message is sent by a Bank to its customer (normally the Supplier in EANCOM®) to report amounts which have been (or will be) credited to the customer's account in settlement of a referenced business transaction(s). A Multiple Credit Advice message may cover the financial settlement of one or more commercial trade transactions, such as invoices, credit notes, debit notes etc.
The Banking Status message is sent by a bank to its customer (usually the Buyer in EANCOM®), providing status information regarding a previously sent financial message. The Banking Status message may cover the response given to any previously sent message, such as a commercial or payment instruction, a request for information, etc. This message provides a means to report on errors and inconsistencies found in the original message at application level. It is not intended to report on syntactical errors or to provide a non-repudiation response.
A Financial Cancellation message is sent by the Ordering Customer (usually the Buyer in EANCOM®) to the Ordered Bank to request cancellation of a previously sent financial message(s), or one or many orders contained within a previously sent financial message(s). A Financial Cancellation message must always be responded to by a Banking Status message.
The Financial Statement message is sent by a financial institution to provide for a customer a statement of booked items confirming entries on the customer's account.
A Direct Debit is sent by the Creditor to the Creditor's Bank instructing the latter to claim specified amount(s) from the Debtor(s) and to credit the amount(s) to an account specified in the message, which the Creditor's Bank services for the Creditor in settlement of the referenced transaction(s).
A Metered Services Consumption Report is a communication between trading parties, or their agents, providing consumption and where required associated technical information at a location(s) for a product(s) or service(s) where the supply is recorded using a meter(s). The Metered Services Consumption Report may be used to provide consumption information which may directly relate to other business functions, (e.g., invoicing or process control).
A message to enable the transmission of the results of tests performed to satisfy a specified product requirement. The content includes, but is not limited to, test data and measurements, statistical information, and the testing methods employed.
This message will be used for the administration of each exchange of an external object. For example, an external object may be a photograph, a video, a film, a CAD file. The message will give additional information about the object and it will refer to the message, and if necessary to the line number to which it is related.
The General Message may be used to send required data for which there is no specific standard message. It was designed primarily to facilitate early transmission testing between new EDI partners or to transmit text (preferably structured or coded) to supplement or further clarify previously transmitted EDI standard messages.
|
