BC Hub - Order
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.
GEDI Profiles
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.
Item References
The standard configuration relies on Item References in the buying party BC towards the Vendors Item No.
Order
Purchase Order - Release Control
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.
Purchase Order - Export
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.
Sales Order - Import
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'.
Sales Order - Import Control
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'.
Sales Order - Export Acknowledge
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.
Purchase Order - Import Acknowledge
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'.
Confirmation
The purpose of the Order Confirmation is usually to confirm estimated information such as item no, quantities, or dates.
Sales Order - Release Control
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.
Sales Order - Export Confirmation
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.
Purchase Order - Import Confirmation
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)'.
Purchase Order - Confirmation Control
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)'.
Purchase Order - Confirmation Email
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.
Advanced Ship Notice
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).
Posted Sales Shipment - Export ASN
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.
Purchase Order - Import ASN
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.
Purchase Order - ASN Control
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)'.
Purchase Order - ASN Email
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.
Invoice
Posted Sales Invoice - Export
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.
Purchase Invoice - Import
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.
Purchase Invoice - Import Control
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'.
Purchase Invoice - Release 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.
F.A.Q.
Can we send an update for a purchase order already sent?
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.
Which line-item types can be sent via the integration?
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.
What changes can a vendor do to an order?
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.
Can the integration support a drop-shipment scenario?
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.
Can the vendor send an updated confirmation?
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.
Can the vendor send multiple shipments for the same order?
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.
Can the vendor send multiple invoices for the same order?
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.
Last updated
