Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The ORDER-TO-CASH 'GEDI Setup' contains configurations for common sales processes via EDI.
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)
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.
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.
!!NOT IN SETUP YET!!
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.
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.
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.
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.
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.
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.
There is multiple GEDI Conversion List that should be configured for this template.
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'.
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'.
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.
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.
It is also common that Credit Memos are handled outside of the integration, via PDF email. In this case you can automate that with the help of our template
The UNIT-STD GEDI conversion document should contain your BC UOM codes in Code Value 1 and the in Code Value 2.
EP-PURCHASE-TO-PAY 'GEDI Setup' contains configurations for common Purchase processes via EDI. Extended Platform is Required, to validate the information coming back from the Vendor.
Released 'Purchase Order' Export (Original / Not Order Change)
'Purchase Order' Confirmation Import (All lines always variations)
'Posted Purchase Reciepts' Import (Simple / Not SSCC level variation)
Order, Confirmation, and DespatchAdvice are configured as 3 different document types in extended Platform, all linked together to easily overview what information was sent and received.
A process is built around finding and highlighting changes from the Vendor when comparising Order to Confirmations and DespatchAdvices. Changes from the confirmation can be accepted and then the order can be updated with corresponding information. DespatchAdvices can be used to create Posted Purhcase Reciepts.
The 'GEDI Mapping' is primarily built to support EDIFACT D96A. It is also close to compatible with similar EDI formats such as PEPPOL BIS 3.0 or other EDIFACT versions, and can be used with minimal adjustment for those formats as well.
The BC-HUB 'GEDI Setup' contains configurations for simple trading scenarios between two different BC parties, which may be in completly different tenants/environments. Since both parties are uses BC and the GEDI app, no translation to external formats is needed.
The configuration contains two template GEDI Profiles;
SALES-HUB, which should be used for the selling party BC customer card. Default Customer No should be set on the GEDI Profile.
PURCH-HUB, which should be used for the buying party BC vendor card. Default Vendor No should be set on the GEDI Profile.
Each GEDI Profile is connected to one specific CIP Connection resulting in a direct party-to-party communication. This means every time you want to add additional BC Hub parties, you need to create a new GEDI Profile for that Party from one of the templates above and buy an additional CIP connection for that new party.
The standard configuration relies on Item References in the buying party BC towards the Vendors Item No.
When trying to release a purchase order, a control will check that mandatory fields are filled in. If any mandatory fields are empty, the releasing will be stopped, and a pop-up error will be displayed. After filling in the mandatory field, you can manually try to release the order again. This function uses GEDI Message Code 'PO-01-CT' and GEDI Mapping 'HB01-PO01-RLS-CTRL'.
In the template, the only field being controlled is Item Reference No. on Item lines. But it easy to configure the control to check for any additional fields on header or lines, that may be relevant for the specific setup.
After the first release of the purchase order, it is exported out via the integration using the GEDI message codes 'PO-02-RQ'/'PO-03-EX' and the GEDI mapping 'HB01-PO03-EXP'. Item Reference is included for every item line.
During this process, the GEDI status will move through;
EDI Requested - when order is released.
EDI Sending - when export was generated in the GEDI Message Queue.
EDI Sent - when export was uploaded to the cloud and processed.
Potentially, the order could get GEDI status 'Error in Export', 'Error from Cloud' or 'Error in Message' if an error occurred during the 3 steps above.
The order is received and imported as a Sales Order using the GEDI Message Code 'SO-01-IM' and the GEDI Mapping 'HB02-SO01-IMP'.
The Sell-to customer is identified using the Default Customer No from the GEDI-Profile.
The item no is identified using the Item Reference information in the incoming message. If the item can't be identified for any of the order lines, the order will be imported anyway, and information on the line will let the user know of the incorrect information.
GEDI context information from the purchase order is saved in different GEDI fields on the sales order, for example GEDI Position No field is used to hold the Purchase Order Lino no.
The GEDI Status at this point is 'Imported'.
Directly after importing the sales order, a control to validate the import is performed using the GEDI Message Codes 'SO-02-CR' / 'SO-03-CT' and the GEDI Mapping 'HB02-SO03-IMP-CTRL'.
The control included in the standard scenario, will validate that all items could be identified and that the Price and Line amount from the buying party correspond to the Sales line.
If any errors are found, the control will update the GEDI Status to 'Error in Control' and send out a email containing the error comments.
If no errors are found, the control will update the GEDI Status to "OK Control'.
Directly after importing the Sales Order, an Acknowledge will be sent back to the buying party, using Message Codes 'SO-04-RQ' / 'SO-05-EX' and the GEDI Mapping 'HB02-SO05-ACK-EXP'. The purpose of the acknowledge is to communicate that the order is imported.
In the background GEDI Statuses containing '(ACK)' will be created, but under normal circumstances not showed on the Sales Order.
The Acknowledge is received and updates the Purchase Order using the GEDI Message Code 'PO-10-IM' and GEDI Mapping 'HB03-PO10-ACK-IMP'. The Vendor Order No field is updated as well as the GEDI status to 'Acknowledged'.
The purpose of the Order Confirmation is usually to confirm estimated information such as item no, quantities, or dates.
When trying to release a sales order, a control will check that mandatory fields are filled in. If any mandatory fields are empty, the releasing will be stopped, and a pop-up error will be displayed. After filling in the mandatory field, you can manually try to release the order again. This function used GEDI Message Code 'SO-10-CT' and GEDI Mapping 'HB04-SO10-RLS-CTRL'.
In the template, the fields being controlled is External Document No on the header and Item No and GEDI Position No on the lines. But it easy to configure the control to check for any additional fields on header or lines, that may be relevant for the specific setup.
If both parties agree to extend the standard scenario with the ability for the vendor to add lines, the GEDI Position fields should be removed from the control.
After the first release of the sales order, a confirmation is sent out via the integration using the GEDI message codes 'SO-20-RQ'/'SO-21-EX' and the GEDI mapping 'HB04-SO21-CFM-EXP'.
During this process, the GEDI status will move through;
Requested (CFM) - when order is released.
Sending (CFM) - when export was generated in the GEDI Message Queue.
Sent (CFM) - when export was uploaded to the cloud and processed.
Potentially, the order could get GEDI status 'Error in Export', 'Error from Cloud' or 'Error in Message' if an error occurred during the 3 steps above.
The confirmation is received and updates the purchase Order using the GEDI Message Code 'PO-20-IM' and the GEDI Mapping 'HB05-PO20-CFM-IMP'.
On the Purchase header, Vendor Order No and Promised Receipt Date fields is updated.
On the Purchase Line, Promised/Planned Receipt Date is directly updated, but otherwise most information from the vendor is saved in GEDI fields for comparison, the data is not directly changed. It can be extended to give the vendor more freedom to update specific fields.
The GEDI Status at this point is 'Confirmed (IMP)'.
Directly after importing the confirmation, a control to validate the import is performed using the GEDI Message Codes 'PO-21-CR' / 'PO-22-CT' and the GEDI Mapping 'HB05-PO22-CFM-CTRL'.
The control in the standard scenario will compare fields on the Purchase Order and the GEDI fields imported from the vendor. The information compared is; Quantity, Price, Amount Including VAT, Item Reference, Unit of Measure and Planned Receipt Date.
Any deviations are saved in the purchase order / order comments section.
If the control finds deviations, it will update the GEDI Status to 'Confirmed (DEV)'
If the control finds no deviations, it will update the GEDI status to 'Confirmed (OK)'.
After the Confirmation Control, an email advice will be sent out using the GEDI Message Codes 'PO-23-RQ' / 'PO-24-EX' and the GEDI Mapping 'HB05-PO24-CFM-EMA'. The email contains the information that the purchase order has now been confirmed with references. If the confirmation contained deviations, information about the deviations will be included in the confirmation email.
Order Confirmations are not updated with new estimated information, instead it is followed up by a Advanced Ship Notice (ASN), upon shipment of the goods. It contains the actual information; items, quantities, or dates picked by the warehouse. Another common name for this is Despatch Advice (DESADV).
After a posted sales shipment is created, a ASN is sent out via the integration using the GEDI message codes 'SD-02-RQ'/'SD-03-EX' and the GEDI mapping 'HB06-SD03-ASN-EXP'.
During this process, the Posted Sales Shipment GEDI status will move through;
EDI Requested - when order is released.
EDI Sending - when export was generated in the GEDI Message Queue.
EDI Sent - when export was uploaded to the cloud and processed.
Potentially, the GEDI status could be 'Error in Export', 'Error from Cloud' or 'Error in Message' if an error occurred during the 3 steps above.
The ASN is received and updates the purchase Order using the GEDI Message Code 'PD-01-IM' and the GEDI Mapping 'HB07-PD01-ASN-IMP'.
On the Purchase header, Vendor Shipment No and Promised Receipt Date fields is updated.
On the Purchase Line, Promised/Planned Receipt Date and Qty. To Receive is directly updated, but otherwise most information from the vendor is saved in GEDI fields for comparison, the data is not directly changed. It can be extended to give the vendor more freedom to update specific fields.
The GEDI Status at this point is 'Ship Adviced (IMP)'.
Please see F.A.Q bellow about multiple shipments for the same order.
Directly after importing the ASN, a control to validate the import is performed using the GEDI Message Codes 'PD-02-CR' / 'PD-03-CT' and the GEDI Mapping 'HB07-PD03-ASN-CTRL'.
The control in the standard scenario will compare fields on the Purchase Order and the GEDI fields imported from the vendor. The information compared is; Quantity, Item Reference, Unit of Measure and Planned Receipt Date.
Any deviations are saved in the purchase order / order comments section.
If the control finds deviations, it will update the GEDI Status to 'Ship Adviced (DEV)'
If the control finds no deviations, it will update the GEDI status to 'Ship Adviced (OK)'.
After the ASN Control, an email advice will be sent out using the GEDI Message Codes 'PD-04-RQ' / 'PD-05-EX' and the GEDI Mapping 'HB07-PD05-ASN-EMA'. The email contains the information that the purchase order has now been confirmed with references. If the confirmation contained deviations, information about the deviations will be included in the confirmation email.
After a posted sales invoice is created, it is sent out via the integration using the GEDI message codes 'SI-02-RQ'/'SI-03-EX' and the GEDI mapping 'HB08-SI03-INV-EXP'.
During this process, the Posted Sales Invoice GEDI status will move through;
EDI Requested - when order is released.
EDI Sending - when export was generated in the GEDI Message Queue.
EDI Sent - when export was uploaded to the cloud and processed.
Potentially, the GEDI status could be 'Error in Export', 'Error from Cloud' or 'Error in Message' if an error occurred during the 3 steps above.
The Invoice is received and imported as a separate Purchase Invoice using GEDI Message Code 'PI-01-IM' and the GEDI Mapping 'HB09-PI01-INV-IMP'.
The purchase header is imported with all the information from the vendor invoice. In the background an 'incoming document' is created containing the invoice sums. A PDF copy of the invoice is also attached to the purchase invoice.
The lines from the invoice is imported, and if they refer to an item line that existed on the purchase order the standard function 'Get receipt Lines' will activate to link the imported lines with the posted purchase receipt lines. For this function to automate directly, it is important that the receipt is posted at this stage.
The GEDI Status at this point is 'Imported'.
Please see F.A.Q bellow about multiple invoices for the same order.
Directly after importing the Invoice, a control to validate the import is performed using the GEDI Message Codes 'PÍ-02-CR' / 'PI-03-CT' and the GEDI Mapping 'HB09-PI03-INV-CTRL'.
The control in the standard scenario will compare fields on the Purchase Order and the GEDI fields imported from the vendor. The information compared is; Price and Amount Including VAT. It will also control that Item No, Quantity and linked receipt line exist for all item type lines.
Any deviations are saved in the purchase invoice / comments section.
If the control finds deviations, it will update the GEDI Status to 'Error in Control'
If the control finds no deviations, it will update the GEDI status to 'OK Control'.
When trying to release a purchase invoice, two controls will run one after the other;
GEDI Message code 'PI-11-CT' using GEDI mapping 'HB09-PI11-INV-CTRL'. The purpose of this control is trying to re-run the function 'Get Receipt Lines' for relevant lines.
GEDI Message code PI-13-CT using GEDI Mapping 'HB09-PI13-INV-CTRL'. The purpose of this control is to revert the release if mandatory fields is missing.
!!Fix so that get receipt lines codeunit easily can be run again after import!!
If the invoice is received before the receipt is posted, it will try to re-run the 'Get Receipt Lines' function every time you try to release the purchase invoice. If the function still can't find the receipt lines, the release will be stopped, and the purchase invoice will stay open.
It is important to not forcefully post the invoice, by various workarounds, if the receipt lines are not linked! The consequence being both that you will have double inventory and a purchase order that will never get invoiced correctly.
You can't send purchase order updates in the standard scenario. Sending updates can be very problematic depending on if the other party already started to act on your first version of the order, and quickly can turn into a situation where both parties are sending incorrect information in both directions, causing errors. It is best practice in any integration to keep away from updates. It's usually better then to agree on a manual fall-back routine or simply creating a new order.
Only 'Item' and 'comment' type lines can be sent in the standard scenario. It can however be extended to include other types, but then both parties need to agree on a setup that needs to be configured. Other types don't have item references, so in this case a GEDI conversion list needs to be maintained.
The vendor can change the quantity or the dates on the lines that was created via the integration. The customer will be notified in both the order confirmation and the ASN if such changes occur. If a line can't be delivered at all, it should be set to quantity 0, rather than deleting the line. Otherwise, the integration can't advice the change. Replacing an item, changing the unit of measure, the variant, or adding a new line can't be managed in the standard scenario. To support this type of changes the setup needs additional configuration which should be agreed upon by both parties.
Adding admin fees, freight fees or similar can't be added by the vendor in the standard scenario. It can be extended, if so it is best to add it to the invoicing process and not the confirmation/ASN.
A Purchase Order with drop-shipment line can be sent via the integration as any other Purchase order. However, it will be problematic for the vendor to change the quantity since this is very restricted by the drop-shipment functionality in the buying party BC. The configuration can also be extended with posting the receipt for drop-shipment lines from the ASN.
The standard practice in trading integration is to send one confirmation with your best estimate and then it's followed up by the actual information in the ASN, and this is what the standard scenario is built around. It can however be extended with a button on the sales order to manually trigger an updated confirmation.
In the buying party BC, there is no standard functionality to hold multiple incoming ASN before they are posted. As such, the integration uses fields on the purchase order to save the information from only the latest ASN. The integration can support a simple back-order scenario, were the first delivery gets advised, received, and posted, and then we receive the second advice, receive it, and post it. If you have the requirement of keeping track of multiple parallel ASNs, the buying party should uppgrade to the 'Purchase to Pay' configuration including our Extended Platform App.
It is preferable if the vendor doesn't partially invoice. However, multiple purchase invoices can be imported in parallel. But since they utilize the function to 'Get receipt Lines' it is best to use the same process as for the shipments, not sending multiple invoices for the same order in parallel. If you have the requirement of keeping track of multiple parallel Invoices, the buyer party should uppgrade to the 'Purchase to pay' configuration including our Extended Platform App.
PDF-CIP 'GEDI Setup' contains configurations for using CIP as the email sending system. Useful when you for some reason don't want Business Central to send out the email. Included documents;
Posted Sales Invoice
Posted Sales Credit Note
Issued Reminder
Sending email SMTP can in the CIP be configured to be either Golden EDI (noreply@goldenedi.com) or your own SMTP server.
ADV-INVOICE 'GEDI Setup' contains configurations for sending Posted Sales Invoices and Posted Sales Credit Notes as 'E-invoices' via VAN (Value Added Network).
Used primarily for Advanced Invoice product that combines the ADV-INVOICE 'GEDI Setup' with a VAN CIP Connection and defined prices for service.
The invoices can be sent including the PDF Invoice as an additional attachment next to the EDI. Other PDF attachments can also be configured to be sent; in this case the CIP will merge the PDF Invoice with PDF attachment so only 1 file is sent to the VAN.
Delivery instructions can be sent to the VAN, if the Invoice should be redistributed as either;
E-Invoice - The receiver will get a digital invoice.
Print/Postal Service - The receiver will get a postal mail. (Not all countries supported)
PDF/E-Mail Service - The receiver will get an e-mail.
3 different GEDI Profiles are included, which decides how the invoice should be paid. All bank account information is by default taken from 'Company Information' page in Business Central.
ADV-BGIR - Bankgiro payment (A Swedish domestic payment system).
ADV-BBAN - Bank Account payment (Standard domestic Bank Account number + Swift Code).
ADV-IBAN - International Bank Account payment (Standard IBAN number + Swift Code).
The 'GEDI Mapping' is primarily built to support Svefaktura 1.0 Format. It is also close to compatible with similar Invoice EDI formats such as PEPPOL BIS 3.0 or EDIFACT D96A, and can be used with minimal adjustment for those formats as well.
The OnGoing Warehouse 'GEDI Setup' contains configurations for simple warehouse scenarios between a BC company and a Goods Owner in Ongoing Warehouse. It is suitable for both internal warehouses, as well as external once (3PL).
'GEDI Extended Platform' (EP) app is required for this setup. It is primarily utilized for comparing outgoing and incoming information to/from the warehouse. It can also act as a staging area for decision making before the information is imported or posted into BC. Documents created in Extended Platform are called 'Intermediate Documents'.
In GEDI Warehouse terminology, information sent to the warehouse is called an 'instruction', and information sent back from the warehouse is called a 'Result'. When looking at the goods flow, goods coming into the warehouse is called 'Inbound', and goods going out from the warehouse is called 'Outbound'.
The integration on OnGoing Side is based on their SOAP API, which GEDI has a customised Communication Provider for in the CIP.
On BC side the GEDI processes utilize a mix of Generic Classes/Properties for internal processes, and customised 'OnGoing' Classes/Properties for the external processes. Thus, the internal processes use terminology close to BC naming convention, and the external processes uses terminology close to Ongoings naming convention.
Some GEDI Mapping Documents are prepared for additional scenarios that can be easily configured via 'Skip lines'.
To start setting up an OnGoing integration, you first need to get the API details from Ongoing towards your Goods Owner. To register a new API connection in OnGoing, go to the 'API for Goods Owners' page via the 'Administration' tab. Select your goods owner and then fill in the details to create a new API user.
After the API user is created, you should receive an email with the API details needed to create a GEDI connection in the CIP.
Create a new CIP connection and choose the Communication provider 'OnGoing V2'. After this, go to the Edit/View of the communication provider, and in the first segment, enter the API details from OnGoing.
When sending information to OnGoing, this doesn't need to be configured on the Communication Provider, but for all information coming back from OnGoing, you need to activate each process and configure the details. If needed, most processes can be combined with filter on a start date, and the standard 5 min queue time can be changed to another interval. It is also possible to add a delay of the messages if you, for some reason, want to manipulate the timing between different processes. For Order processes, you have some additional settings.
Status From / To; this is a filter to only fetch orders in certain statuses. Normally, you only want to fetch an order after it's 'done'.
Include ArticleItems; Enabling this flag changes the behavior of the result lines, so that OnGoing ArticleItems details can be fetched. Enabling it will lead to many more result lines being created in BC. If the ArticleItems details are not needed, such as Serial No, Batch No, Package No, Return Cause etc., it is advised to not enable this option.
The GEDI setup comes prepacked with one OnGoing GEDI Profile (OGW-1). One GEDI Profile contains only one OnGoing Goods Owner (via one CIP Connection), and normally corresponds to one BC Location Code.
The GEDI conversion Document 'GEDILIGHT' must be filled in with the relation between the Location Code (in Code Value 1) and the GEDI Profile (in Code Value 2). Multiple processes rely on the setup in this document to find the correct GEDI profile.
It is advised to rename the GEDI Profile to make it logical for your context, for example into the name of your 3PL party or your location code.
If you have multiple Location Codes and Goods Owners in OnGoing, additional GEDI Profiles can be created with the following steps.
Create a new CIP Connection for the new Goods Owner
Create a new GEDI Profile with a suitable code, and add the CIP connection.
Go to GEDI Message Setup, and copy the original GEDI Profiles lines into the new GEDI Profile.
Go to GEDI Conversion Document 'GEDILIGHT' and add a new lines for the new Location Code to the new GEDI Profile.
Sometimes when you have multiple GEDI setups installed, the same order needs to interact with multiple GEDI Profiles, e.g. you might have both an E-invoice scenario and a Warehouse scenario for the sames Sales Order. In these scenarios, only one GEDI profile can exist on the sales order or purchase order at a time, and that will be the main GEDI profile that is also set on the customer cards and vendor cards. Normally, the Customer/Vendor scenario will take priority and the warehouse scenario will not be the GEDI Profile on the order. To activate the warehouse scenarios for a Customer/Vendor GEDI profile, some GEDI Message setup Lines can be added to create a 'combination' GEDI Profile.
Many of the Warehouse standard processes utilises Intermediate documents in EP. The Page 'GEDI Workspace 1' can be used to view all these documents and it divides them into different stack icons depending on their type and status. Stack icons related to processes irrelevant for a specific project can be hidden via setup.
Not all statuses of all Intermediate Header types are visible as stack icons. When you select a Stack icon, and open the corresponding list, you can remove the status filter to see all documents of the same type.
Items in BC can be synchronised to OnGoing. GEDI utilises BC standard 'Workflows' as the trigger for this process. If the workflow is triggered, this function uses GEDI Message Code 'MAR-11-RQ'/'MAR-12-EX'.
In OnGoing, this creates an Article via the API function ProcessArticle.
To configure the workflow, the event 'An item record is changed' is utilised. You can add your own conditions to filter out items you don't want to synchronize. See below screenshots for detailed configuration template.
The BC standard workflow for items only triggers when the Item table (27) is updated, not the related tables, such as Unit Of Measures, or Item References.
After the first time a sales order is released, an intermediate document will be created with type '1' and description 'SOOI - S.Order Outbound Instruction'. This chain of events starts with the GEDI Message Code 'IM01-02-RQ'. Once the intermediate document is created, it is automatically released in Extended Platform and triggers the GEDI Message Code 'IM01-12-RQ'.
This intermediate document statuses will move through;
Open - When the instruction document is created.
Released - When the instruction is sent to the warehouse.
Posted - When applied results are posted and the instruction quantity is fully shipped.
Archived - When the instruction is no longer relevant and can be hidden from the Workspace stack icon. In this status the instruction can also be deleted.
In OnGoing, this creates an Outbound Order with Order Type = 'Sales Order' (Order Type Code = SOOI), via the API function ProcessOrder. In the order header, Intermediate Document number can be found in the field 'Goods Owner Order ID'. The order header field 'Free text 1' is also used by the integration to save context needed for the result later.
In OnGoing, after the goods are picked and the correct status is fullfilled, the CIP will fetch a Result message via API function GetOrdersByQuery, using GEDI Message Code IM02-01-IM. This will create an Intermediate document with type '2' and description 'SOOR - S.Order Outbound Result'. Once the intermediate document is created, it automatically will try to 'Post' it (IM02-11-RQ/IM02-12-IN). If deviations compared to the instruction is found, the posting will be stopped. If the posting doesn't go thru an email advice will be sent out (IM00-21-RQ/IM00-22-EX). If the posting is successful, a standard Posted Sales Shipment with the quantities from the result will be created. The intermediate document can be reposted manually if it for some reason failed.
If Item tracking is needed, then you can enable the API communication provider option 'include ArticleItems'.
This intermediate document statuses will move through;
Open - When the result document is created.
Posted - When the result is posted and the corresponding Posted Sales Shipment is created.
Archieved - When the result is no longer relevant and can be hidden from the workspace stack icon. In this status the result can also be deleted.
There are multiple ways of managing a Sales Return Scenario in OnGoing;
Outbound Order with returned lines. In this scenario, the return must be initiated in OnGoing. It is not possible to send an 'instruction' from BC. This is the most common scenario, and the only one currently included in the standard processes.
Inbound Return Order. In this scenario, an instruction can be sent to OnGoing before the return arrives, but it must be correctly linked to an Outbound Order, oyherwise OnGoing will give an error. This scenario is currently not included in the standard.
Inbound Purchase Order with Order Type Sales Return. In this scenario, an instruction can be sent to OnGoing before the return arrives, but all the fields in OnGoing will be according to their purchase naming convention. The order can't be linked to an Outbound Order in OnGoing. An Order Type 'Sales Return' can be used to easily sort these from standard purchase orders. This scenario is currently not included in the standard.
In OnGoing, after the goods are return and the correct status is fullfilled, the CIP will fetch a Result message via API function GetOrdersByQuery, using GEDI Message Code SRA-01-IM. This will create a Sales Return Order in BC, and if the corresponding Posted Sales Invoice is found, it will connect the Sales Return Order to that Invoice.
Directly after importing the sales return order, a control to validate the import is performed using the GEDI Message Codes 'SRA-03-CT'.
If no errors are found, the control will create the Posted Return Receipt.
Item tracking from OnGoing can't be managed via direct import as a Sales Return Order. The reason for this is that if you enable 'Include ArticleItems' on a return, then duplicated lines can be created. An intermediate document is required to sort out and disable these duplicated lines.
After the first time a sales order is released, an intermediate document will be created with type '3' and description 'POII - P.Order Inbound Instruction'. This chain of events starts with the GEDI Message Code 'IM03-02-RQ'. Once the intermediate document is created, it is automatically released in Extended Platform and triggers the GEDI Message Code 'IM03-12-RQ'.
This intermediate document statuses will move through;
Open - When the instruction document is created.
Released - When the instruction is sent to the warehouse.
Posted - When applied results are posted and the instruction quantity is fully received.
Archived - When the instruction is no longer relevant and can be hidden from the Workspace stack icon. In this status the instruction can also be deleted.
In OnGoing, this creates an Inbound Purchase Order with Order Type = 'Purchase Order' (Order Type Code = POII), via the API function ProcessInOrder. In the order header, Intermediate Document number can be found in the field 'Goods Owner Reference'. The order header field 'Info Free Text 1 is also used by the integration to save context needed for the result later.
In OnGoing, after the goods are received and the correct status is fullfilled, the CIP will fetch a Result message via API function GetInOrdersByQuery, using GEDI Message Code IM04-01-IM. This will create an Intermediate document with type '4' and description 'POIR - P.Order Inbound Result'. Once the intermediate document is created, it automatically will try to 'Post' it (IM04-11-RQ/IM04-12-IN). If the posting doesn't go thru an email advice will be sent out (IM00-21-RQ/IM00-22-EX). If the posting is successful, a standard Posted Purchase Receipt with the quantities from the result will be created. The intermediate document can the reposted manually if it for some reason failed.
If Item tracking is needed, then you can enable the API communication provider option 'include ArticleItems'.
This intermediate document statuses will move through;
Open - When the result document is created.
Posted - When the result is posted and the corresponding Posted Purchase Receipt is created.
Archieved - When the result is no longer relevant and can be hidden from the workspace stack icon. In this status the result can also be deleted.
From a warehouse point of view, the transfer order is two different warehouse activities for two different warehouses. There is an outbound side (Transfer-from Code) and an inbound side (Transfer-to Code). The GEDI process represents this by creating the corresponding two activities as two completely different processes, one for outbound and one for inbound.
The GEDI Conversion Document 'GEDILIGHT' is used to identify which Location Code that is connected to which GEDI Profile. The Transfer order itself doesn't have a GEDI profile. The individual location codes could have a mix of multiple OnGoing integrations, or other Warehouse integrations, so each location code is handled separately.
This means that when a Transfer Order is released, there are four possible outcomes;
Once the GEDI profile for the Location has been identified and the processes have started, the outbound side acts towards the warehouse like a sales order, and the inbound side acts towards the warehouse like a purchase order.
After the first time a transfer order is released, and if the GEDI profile for the Transfer-from Code could be linked, an intermediate document will be created with type '5' and description 'TOOI - T.Order Outbound Instruction'. This chain of events is starts with the GEDI Message Code 'IM05-02-RQ'. Once the intermediate document is created, it is automatically released in Extended Platform and triggers the GEDI Message Code 'IM05-12-RQ'.
This intermediate document statuses will move through;
Open - When the instruction document is created.
Released - When the instruction is sent to the warehouse.
Posted - When applied results are posted and the instruction quantity is fully shipped.
Archived - When the instruction is no longer relevant and can be hidden from the Workspace stack icon. In this status the instruction can also be deleted.
In OnGoing, this creates an Outbound Order with Order Type = 'Transfer Order' (Order Type Code = TOOI), via the API function ProcessOrder. In the order header, Intermediate Document number can be found in the field 'Goods Owner Order ID'. The order header field 'Free text 1' is also used by the integration to save context needed for the result later.
In OnGoing, after the goods are picked and the correct status is fullfilled, the CIP will fetch a Result message via API function GetOrdersByQuery, using GEDI Message Code IM06-01-IM. This will create an Intermediate document with type '6' and description 'TOOR - T.Order Outbound Result'. Once the intermediate document is created, it automatically will try to 'Post' it (IM06-11-RQ/IM06-12-IN). If deviations compared to the instruction is found, the posting will be stopped. If the posting doesn't go thru an email advice will be sent out (IM00-21-RQ/IM00-22-EX). If the posting is successful, a standard Posted Transfer Shipment with the quantities from the result will be created. The intermediate document can be reposted manually if it for some reason failed.
If Item tracking is needed, then you can enable the API communication provider option 'include ArticleItems'. However a PTE will be needed, as the standard codeunit doesn't support this.
This intermediate document statuses will move through;
Open - When the result document is created.
Posted - When the result is posted and the corresponding Posted Transfer Shipment is created.
Archieved - When the result is no longer relevant and can be hidden from the workspace stack icon. In this status the result can also be deleted.
After the first time a Transfer order is released, and if the GEDI profile for the Transfer-to Code could be linked, an intermediate document will be created with type '7' and description 'TOII - T.Order Inbound Instruction'. This chain of events starts with the GEDI Message Code 'IM07-02-RQ'. Once the intermediate document is created, it is automatically released in Extended Platform and triggers the GEDI Message Code 'IM07-12-RQ'.
This intermediate document statuses will move through;
Open - When the instruction document is created.
Released - When the instruction is sent to the warehouse.
Posted - When applied results are posted and the instruction quantity is fully received.
Archived - When the instruction is no longer relevant and can be hidden from the Workspace stack icon. In this status the instruction can also be deleted.
In OnGoing, this creates an Inbound Purchase Order with Order Type = 'Transfer Order' (Order Type Code = TOII), via the API function ProcessInOrder. In the order header, Intermediate Document number can be found in the field 'Goods Owner Reference'. The order header field 'Info Free Text 1 is also used by the integration to save context needed for the result later.
In OnGoing, after the goods are received and the correct status is fullfilled, the CIP will fetch a Result message via API function GetInOrdersByQuery, using GEDI Message Code IM08-01-IM. This will create an Intermediate document with type '8' and description 'TOOR - T.Order Inbound Result'. Once the intermediate document is created, it automatically will try to 'Post' it (IM08-11-RQ/IM08-12-IN). If deviations compared to the instruction is found, the posting will be stopped. If the posting doesn't go thru an email advice will be sent out (IM00-21-RQ/IM00-22-EX). If the posting is successful, a standard Posted Transfer Receipt with the quantities from the result will be created. The intermediate document can be reposted manually if it for some reason failed.
If Item tracking is needed, then you can enable the API communication provider option 'include ArticleItems'. However a PTE will be needed as the standard codeunit doesn't support this.
This intermediate document statuses will move through;
Open - When the result document is created.
Posted - When the result is posted and the corresponding Posted Transfer Receipt is created.
Archieved - When the result is no longer relevant and can be hidden from the workspace stack icon. In this status the result can also be deleted.
Inventory Adjustments from OnGoing can be synchronised to BC. The CIP will fetch the inventory adjustment via the API function GetInventoryChanges, using GEDI Message Code IM09-01-IM. This will create an intermediate document with type '9' and description 'IJAR - Item Journal Adjustment Result'. Once the intermediate document is created, it automatically will try to 'Post' it (IM09-11-RQ/IM09-12-IN).
When posting an inventory adjustment, the Item Journals in BC are used for this. The Import mapping is configured in standard to expect an Item Journal batch with the same name as the GEDI profile. So that would be 'OGW-1' in standard, or the name you have renamed your GEDI profile to. If you have multiple GEDI profiles and warehouse integrations, it's advised that each has its own batch name. When creating the Item Journal Batch, there must be a 'Posting No. Series' assigned. For the 'No Series', the intermediate document number automatically is used, and this setup isn't needed in the setup for the batch.
It is common that an implementation doesn't use all the standard processes. In this case it is advised to inactivate and hide the processes that's not used.
To inactivate the processes sending instructions to OnGoing, then the flag in 'Not Create Automatically' in the 'GEDI Message Setup' can be filled in. This will disable the standard 'GEDI Message Selection' events.
For processes related to results coming from OnGoing, this is configured in the CIP on the communication provider.
For Item synchronization, simply just don't setup, or turn off, the workflow for "An item record is changed' to avoid activating the process.
After the processes are inactivated, it is also advised that the stack icons on the 'GEDI Workspace 1' are hidden, so that the interface becomes clearer for the end user. To accomplish this, go to the corresponding 'GEDI Intermediate Document Setup', and in the 'Cue Lines' section, uncheck the 'Cue Visible' boolean.
Several of the processes below uses the GEDI Message Selection 'Send Partner Information' to trigger them. This means that a job queue entry for codeunit 70618584 is required. If you want different recurrences for different GEDI profiles, the 'Parameter String' can optionally be used to filter it on GEDI profile. It is adviced to set the recurrence of this job queue entry to run after standard operating hours.
'Send Partner Information' job queue starts a process to batch move the statuses of intermediate headers to the status 'Archived'. The purpose of this is to keep the stack icons in the GEDI workspace to a reasonable count. The GEDI Message Code that starts the process is IM00-30-RQ.
The standard mapping filter is set to archive intermediate headers with status 'posted' after 30 days after creation. The filter is set per document and from status. Instructions are normally archived from status 3, and results are normally archived from status 2. There is a GEDI conversion document, 'ARCHIVE-STATUS', that determines what status number each document type archives to.
'Send Partner information' job queue starts a process to delete old intermediate headers and lines. The purpose of this is to avoid building up to much data in the intermediate tables. The GEDI Message Code used for this process is IM00-41-CT.
There is also a manual trigger on the GEDI Intermediate Document setup to do this per document type, in this case the GEDI Message Code IM00-43-CT is used. If you use the manual process, additional filters can be used; 'Creation Date filter' / 'Expire Date filter'.
Two main parameters decides which documents that are deleted and not; 'Document duration' and if the status has 'Delete Allowed'. The duration is calculated from the creation date of each intermediate header, and for the process to work, the duration must be defined on each document type.
'Send Partner information' job queue starts a process to send out an email report with the status of the workspace. The GEDI Message Code that starts this process is IM00-50-RQ.
If you want to hide some of the stack icon in the above email because the processes that is not relevant for you, you need to go into the corresponding GEDI Mapping document and change it accordingly.
Sometimes posting errors in the GEDI workspace can fetch the error message on the intermediate header itself, instead of finding it in the GEDI Message Queue. This is usually the case when the source of the error is some kind of integration mismatch, instead of a general posting error. E.g. the integration have the wrong line number, or the item tracking is incorrect etc. In this case a 'Warehouse Workspace Error' email using GEDI Message Code 'IM00-21-RQ' is sent out.
in the standard process, all orders with relevant GEDI-Profiles will be created as intermediate documents in the GEDI workspace, and from there be sent to the warehouse. A technique to stop certain orders from being sent to the warehouse is simply to use a warehouse irrelevant GEDI-profile, or remove the GEDI-profile, depending on your configuration.
In the export of the order to intermediate document, you can also easily make a filter to exclude certain lines, if you at least have 1 line that is relevant for the warehouse.
In a more advanced scenario, were orders sometimes got relevant lines and sometimes not, a GEDI control mapping is needed to try to sort out your different scenarios. For example, G/L account lines or drop-shipment lines might not be relevant for the warehouse. In more complex scenarios it can sometimes be required to have series with multiple control mappings to achieve the logic that you want to configure.
Whenever you want to split an order into multiple instructions to the warehouse, it can be beneficial to work with inventory pick and inventory put-away. If for example the lines have different dates, some warehouses are only intrested in the lines they can work with in a near future.
Currently reason codes or variants are not supported in the standard posting codeunit of inventory adjustment.
A PTE is required solve this.
The standard scenario doesn't include item tracking in the instruction to the warehouse. E.g. to give them instructions on exactly which batches to pick. However, it is possible to rebuild the export mapping to Extended Platform to look at reservations instead of order lines. It is also possible to rebuild it in a way that take reservations from lines where they exist, and line information on lines that doesn't have reservations.
Currently there is no known solution for mixing the two on the same line. E.g. one line has a partial reservation, but the 'unreserved' quantity should still be sent to the warehouse for the same line. In this case you would need to split the line, to have one line fully reserved and one line fully unreserved.
Reservations in standard BC is used to hold item tracking information before it is posted, therefor it will always exist as reservations in the instruction part of the process.
In OnGoing, like BC, item tracking information doesn't exist on the line level, but on a sub line level. In OnGoing this level is called OrderLineArticleItem.
If 'Include ArticleItems' is disabled, then this sub line level information is simply ignored in the API, and only result with the simple line information is fetched via the API. This means for example, that you will get a summarized picked quantity per line. Usually this means that in the GEDI Workspace one instruction line will have one result line per picking time.
If you enable 'Include ArticleItems' however, then the line level in OnGoing will mostly be ignored, and the detailed information in OrderLineArticleItem will be the basis for the lines instead. This means that one instruction line can now have multiple lines result per picking time, as per how OnGoing have split the line. OnGoing will for example split the line for different tracking information (Serial/Lot No/Package ID). But it could also split the lines for other internal warehouse reasons as well. The result in the GEDI workspace is that you get much more detailed information and many more result lines to track.
In the standard scenario you can only have one location holding inventory quantities in BC per one GoodsOwner holding inventory quantities in OnGoing. Otherwise, it will be complicated to track and reconcile the inventory.
Theoretically, one could divide a GoodsOwner into several statuses of the inventory and connect different BC locations to different OnGoing statuses. For example, to create a separate BC location code for quarantine inventory. But this scenario is currently not well supported and would need to be custom built to work.
OnGoing doesn't use units of measures in the same way that BC does. In OnGoing only the base unit of measure for the stock keeping can be used on the line level. Consequently, this leads to different scenarios;
Always use the base unit of measure on the BC orders sent to OnGoing. This will limit your process, but works without further configuration in the standard scenario.
Make a conversion in the integration between BC and OnGoing. This will get the correct quantity, but OnGoing will still not know what the expected unit of measure is, without further configuration. There is also a significant risk of running into issues with decimals and fractions that doesn't round correctly.
Maintain different items in OnGoing for each unit of measure. This will make the inventory hard to reconcile, unless you don't add additional functions in OnGoing to convert inventory between the different unit of measures. Item identifier could be used to setup different OnGoing Item No. per Item-UOM in BC.
Like unit of measures above, OnGoing also doesn't use variants in the same way that BC does. However, the solution here is simpler, as a variant doesn't need to convert between different values. Each variant can have its own inventory, and thus can be created as its own item in OnGoing. Item identifier could be used to setup different OnGoing Item No. per Item-Variant in BC.
The standard scenario for item synchronisation will not create variants of the main item, this needs to be configured separately.
In any order related integration, it is best practice to not work with updates. Updates can become a complex issue if the receiving system doesn't agree on a change, leading to desynchronisation between the systems. Were possible, design your business processes around this instead.
In the standard scenario, orders (Sales/Purchase/Transfer) will never send an updated instruction to OnGoing after the one sent from the initial release. If this is needed, additional events to send an update is needed in BC, usually a manual update button provided via a PTE. When sending an update to OnGoing, it can for several reasons be rejected, leading to desynchronisation. For example, most OnGoing environments doesn't allow updates at all in certain statuses. Flow test your update scenarios with extra care, to understand what is allowed or not, and when. If an update scenario is configured, it will, compared to the initial instruction, use other GEDI Message Codes and GEDI Mapping documents in the internal process to intermediate document.
If you work with Inventory Picks/Put-away, a new inventory pick/put-away could be generated in BC with the un-posted quantity to achieve a new partial order in OnGoing, and then the old inventory pick in OnGoing can be closed manually if needed.
It is not advised to work with several partial orders in OnGoing for one order in BC, unless you don't use the inventory pick/put-away to split an order into several instructions.
You can run a Item masterdata sync between 2 companies in Business Central using Golden EDI Standard App in both companies, and CIP Connections between them.
The Sending company (Master), should use 'GEDI Setup' 'IC ITEM MD SENDING'. Including tables;
Item Card export (per item and complete list)
Item Units of Measure export (per item and complete list)
Item Attributes export (per item and complete list)
Item references export (per item and complete list)
Item dimensions export (per item and complete list)
Sales Price list export (per item and complete list)
The Receiving company (Replica), should use 'GEDI Setup' 'IC ITEM MD RECEIVING'. Including tables;
Item Card import (per item and complete list)
Item Units of Measure import (per item and complete list)
Item Attributes import (per item and complete list)
Item references import (per item and complete list)
Item dimensions import (per item and complete list)
Purchase Price list import (per item and complete list)
In Business Central there is a standard workflow to listen to changes to the item card. in this 'GEDI Setup' we use this as a trigger to send out item card export from the sending company.
When the item card later has been imported in the receiving company, it sends back an acknowledge to sending company. When the acknowledge then is imported in the sending company, this is the trigger to send out all the underlying tables (for example, Attributes, References etc.)
Additional to the workflow, a job queue entry can be created to send out all information as often as defined. Usually in the night as exporting/importing all item information at the same time can be performance heavy.
In the underlying tables (for example, Attributes, References etc) it is only the relation to the item that is synced, not the definitions themselves. For example, if you create a completely new Unit of Measure, this is not synced; If you add your new Unit of Measure to a item, this relationship can be synced.
Transfer-from Code | Transfer-to Code | Outbound | Inbound |
---|---|---|---|
Location 1 have GEDI Profile 1
Location 2 have GEDI Profile 2
Process starts to warehouse 1
Process starts to warehouse 2
Location 2 have GEDI Profile 2
Location 3 doesn't have GEDI Profile
Process starts to warehouse 2
Process doesn't start
Location 4 doesn't have GEDI Profile
Location 1 have GEDI Profile 1
Process doesn't start
Process starts to warehouse 1
Location 3 doesn't have GEDI Profile
Location 4 doesn't have GEDI Profile
Process doesn't start
Process doesn't start
The purpose of the BASE 'GEDI Setup' is to establish a baseline of configuration that can be shared between almost all other 'GEDI Setups'. Here you will find for example configurations for standard statuses and e-mails that can be sent out.
The Base is not meant to be installed in Production Environments, as it is contained in almost all other 'GEDI Setups' that needs it. The Base is only meant as a resource for creating new Template 'GEDI Setups' from beginning.
Version 3.0.0 contains the following configurations;
E-mail Advice (For example, a new incoming EDI Advice)
E-mail Error (For example, a message could not be imported/exported in 'GEDI Message Queue'
Standard Statuses
PRINT-EXTERN-PARTNER 'GEDI Setup' contains configurations for sending a PDF with print and Postal instructions to a VAN partner. The EDI message itself only contains these instructions and almost no other information regarding the document is sent. Included documents;
Posted Sales Invoice
Posted Sales Credit Notes
Issued Reminder
Issued Finance Charge Memo
Usually added on top of Advanced Invoice for additional Printing alternatives.