OnGoing Warehouse (EP)
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'.
CIP Connection and API Communication Provider settings
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.
GEDI Profiles and Location Codes
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.
Multiple Locations / Goods Owners
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.
Mixing Warehouse Processes with GEDI Profiles for customers
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.
Warehouse Processes
Intermediate documents
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
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.
Sales Order
Outbound Instruction to warehouse (SOOI - S.Order Outbound Instruction)
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.
Outbound Result from warehouse (SOOR - S.Order Outbound Result)
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.
Sales Return Order
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.
Outbound Order with returned lines - direct import to Sales Return Order
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.
Purchase Order
Inbound Instruction to Warehouse (POII - P.Order Inbound Instruction)
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.
Inbound Result from Warehouse (POIR - P.Order Inbound Result)
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.
Transfer Order
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;
| 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 |
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.
Outbound Instruction to Warehouse (TOOI - T.Order Outbound Instruction)
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.
Outbound Result from Warehouse (TOOR - T.Order Outbound Result)
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.
Inbound Instruction to Warehouse (TOII - T.Order Inbound Instruction)
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.
Inbound Result from Warehouse (TOIR - T.Order Inbound Result)
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
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.
Inactivating and hiding processes
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.
Other Processes
Send Partner Information - Job Queue Entry
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.
Archive Intermediate Document
'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.
Deleting old Intermediate Document
'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.
Warehouse Report - Workspace 1
'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.
Warehouse Workspace Error
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.
F.A.Q.
General Warehouse
Can I filter which order and which order lines that are sent to which warehouse?
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.
What are common reasons to activate inventory pick and inventory put-away on the location codes used in a warehouse integration?
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.
Can I add reason code or variants to the inventory adjustment?
Currently reason codes or variants are not supported in the standard posting codeunit of inventory adjustment.
A PTE is required solve this.
Can I advise item tracking information in the instruction to the warehouse?
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.
Ongoing
What happens when i enable the 'Include ArticleItems' on the order results in the communication provider?
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.
Can I have multiple Location codes in BC integrating with one GoodsOwner in OnGoing?
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.
Can I use different unit of measures for the same item when integrating with Ongoing?
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.
Can I use item variants when integrating with Ongoing?
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.
Can I send an update to an order to Ongoing?
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.
Last updated
