Order to Cash
The ORDER-TO-CASH 'GEDI Setup' contains configurations for common sales processes via EDI.
Sales Order - Import - 'SO01-IMP'
Sales Order gets imported into BC as long as a correct customer could be found. Normally this is matched via a GLN or directly via your customer number if it was contained in the integration.
Context is saved in 'GEDI fields' on both the sales order header and sales order lines. This can be used later in the exports to reference the external party order information. E.g. their order lines numbers, their originally ordered quantity etc. The context can also be used later to compare differences between what was ordered and what is now on the order. E.g. 5 pieces was ordered, but we can only sell them 4 pieces, the difference being -1 piece.
If no customer could be found, order will remain in the GEDI Message Queue with an error, and an email error will be sent to you for your action.
If an item no. couldn't be found, the line will still be imported with a description of the item no. in integration as well as how many was ordered. This could for example happen if GTIN/EAN references are not updated. To solve this, the reference can be added, then the item no. can be manually matched on the order line to continue the order.
Initially after import the sales order will have GEDI status 'EDI Imported'.
It is optional in the mapping to send out an email advice to you after order is imported. (Message Code EMA-01-RQ, by default inactivated)
It is optional in the mapping to send out an Order Acknowledgement after order is imported. (Message Code SO-04-RQ, by default inactivated)
Sales Order - Import Control - 'SO03-IN-CTRL'
After importing the order, a control will check if mandatory fields are filled in or not. If missing fields are found, an email error is sent to you for your action.
In the template, the only field being controlled is that all lines have item no. matched. But it easy to configure it to check for whatever additional fields on the header or on the lines makes sense for your integration. E.g. a requested delivery date on the header or a price on a line.
Sales Order Acknowledgement - Export - 'SO05-ACK'
If you activated the Order Acknowledgement, it will be queued directly after importing the sales order. The purpose of this message is to let the other party know that you have successfully imported the order, and what your order number is for the transaction. Usually, it is only used for a technical handshake that the transmission was successful end-to-end. It is not to be confused with an Order Confirmation.
Usually, the Order Acknowledgement doesn't contain any line information, it is just a header.
Sales Order Release Control
!!NOT IN SETUP YET!!
Sales Order Confirmation - Export
After the first release of the sales order an order confirmation sent via the integration. The purpose of the Order Confirmation is usually to confirm estimated information such as item no, quantities, or dates. Order Confirmations can be vastly different from case to case, both structurally and the information contained. Therefore multiple types are contained in the template;
Order Confirmation with or without deviation is a common type used in for example EDIFACT / ESAP20 integrations. In this type only order lines that contains deviation should be included in the integration, therefore it is easy for the customer to see where changes are. This is the pre-configured type in this template. In this type we use 3 GEDI mapping documents;
SO12-CONF-CTRL -> Controls the sales order lines if any deviations are found.
SO21-CONF-OK -> If no deviations found, this mapping is used to generate an export with no lines and only a header.
SO31-CONF-DEV -> If deviations found, this mapping is used to generate an export with only the lines containing a deviation.
Order Confirmation all lines always are another common type used. In this type it is up to the customer to check all lines to see where deviations might exist, if any exists. This type can be activated by changing the 'GEDI Message Setup'. The GEDI Mapping used for this type is SO21-CONF-ALL
In the template it is best to release the sales order prior to posting the shipment or invoice. If you would invoice a sales order from open status, the sales order no longer exist when the export is processed in the GEDI Message Queue.
Usually Order Confirmations are not updated with new estimated information. It is instead followed up by a Despatch Advice, after the goods are picked, containing the actual items, quantities, or dates. Therefore the ability to send updates are not contained in the template (but can be configured together with GEDI).
Sometimes an Order Acknowledgment (ACK) or an Order Confirmation can be called an Order Response (ORDRSP). In this case it is advised to understand which of the two purposes the message should have, to use the correct GEDI configuration.
Sales Shipment Despatch Advice - Export
After a sales shipment is posted towards the order, a Despatch Advice is sent via the integration.
A Despatch Advice (DESADV) can sometimes also be called an Advanced Shipping Notice (ASN).
The Purpose of the Despatch Advice is usually to give actual information to the customer after the goods are packed. Despatch Advice can be vastly different from case to case, both structurally and the information contained. They can be divided into;
A Simple Despatch Advice (Without Package level) is a common type used when the customer doesn't have scanning capabilities in their warehouse process, or otherwise doesn't support an automated inbound process. In this case, all lines are sent, but no information is sent regarding which lines or quantities are packed together or on how many packages. This is the pre-configured type in this template. The GEDI mapping document used for this type is 'SD03-SIMPLE'.
An Advanced Despatch Advice (With package level) is a common type used when the customer have more complex capabilities for their inbound process. In this case, the lines and quantities are divided into the packages they are packed in. Usually, each package has a unique identifier that also can be scanned by the customer warehouse (SSCC).
The standard BC process doesn't contain this package level of complexity. Usually, other BC apps are used to build the package level, which we can export information from. GEDI can offer a manual alternative interface to build the package level in BC. Sometimes, tracking information can be used to build the package level.
Sales Order Post Invoice Control - SI01-CTRL
When trying to post invoice on a sales order, a control will check if mandatory fields are filled in or not. If any mandatory fields are missing, the posting will be stopped, and a pop-up error will be displayed. After filling in the mandatory field, you can manually try to post the invoice again,
In the template, the only field being controlled is External document no. on header level. But it easy to configure it to check for whatever additional fields on the header or on the lines makes sense for your integration. E.g. some invoice reference or similar.
Posted Sales Invoice - Export
After a Sales Invoice is posted towards the order, an Invoice is sent via the integration. Invoices can be divided into multiple types;
Order Invoice (1 order - 1 invoice), is the most common type used in integration when an invoice is created from a sales order, referencing the order on the header level. The GEDI Mapping Document used for this type is 'SI03-BGIR'.
Batch Invoice (multiple orders - 1 invoice), is also sometimes used in integrations when a weekly or monthly invoice is used. In this case usually posted shipment rows are gathered on a periodic basis and send in a batch. The invoice header in this case doesn't have any relation to a specific order, instead each line on the invoice contains the necessary order references. This type is not contained in this template, but GEDI can offer it separately.
Other Invoice types can exist but is rare in an order-to-cash process. Such as service fee invoices or similar. If you want to send an integration invoice without relationship to a sales order at all, it's better to start from the Advanced Invoice template instead.
Sales Credit Post Control - SC01-CTRL
When trying to post a credit memo, a control will check if mandatory fields are filled in or not. If any mandatory fields are missing, the posting will be stopped, and a pop-up error will be displayed. After filling in the mandatory field, you can manually try to post the invoice again,
In the template, the only field being controlled is External document no. on header level. But it easy to configure it to check for whatever additional fields on the header or on the lines makes sense for your integration. E.g. some invoice reference or similar.
Posted Sales Credit Memo - Export - SC03-BGIR
After a Sales Credit Memo is posted, a credit is sent via the integration. Credit memos via integration is usually per order basis or per return basis, batch credit memos are rare and not included in this template.
GEDI Conversion List
There is multiple GEDI Conversion List that should be configured for this template.
CURRENCY
The Currency GEDI conversion document should contain your BC currency codes in Code Value 1 and the standard international Currency codes in Code Value 2. There should also be 1 row with your standard currency in Code Value 2, and Code Value 1 being empty. The reason for this is that empty currency code in BC means it is your standard currency, but this behavior doesn't exist in standard integration praxis.
There is a function to automatically fill in this table, you find it in the menu under 'Copy' and then 'Currencies'.
UNIT-STD
It is common for integration to define UOM. Different EDI formats use differents sets of UOM codes and GEDI have standard UOM codes that are converted into the different EDI formats, from case to case. Therefore the BC codes needs to be converted into the GEDI UOM codes.
There is a function to automatically copy your BC codes into the table, leaving only the part to choose the GEDI UOM codes for each. you find this function in the menu under 'Copy' and then 'Currencies'.
GEDI-Profile
The GEDI-Profile in the template is named 'EDI', but this is a placeholder name. When configuring it is best practice to rename the GEDI-Profile into a code for the external party you integrate with. E.g. the vendor's name or the VAN/HUB name etc.
Sender and Receiver
The Sender and Receiver party roles in integrations is the highest level of identifications, contained usually in what is called the envelope. Usually when integrating with a VAN or a HUB the Sender and Receiver identifiers are used to sort the message into the correct formats and into the correct organisations.
On the GEDI-profile the column 'Partner GLN' can be used to identify the Receiver party. The 'Company GLN' column can be used to identify you, the sender party. It doesn't have to be a GLN in all integration, but that is the most common type of identifier used.
Other party roles might exist as well, such as the Buyer, Supplier, Delivery party, or Invoice receiver. These roles vary a lot and needs to be configured from case to case. sometimes the Buyer might correspond to your customer in BC, sometimes it might be the Delivery Party.
Last updated
