Duplicate Mgt

EDI Update Message processing in combination with Duplicate Orders

Reason for the development

When an EDI message arrives and processes, it is checked whether the order already exists yes or no. If not, a new order will be created. If the order does exist, a request is made based on the current status whether the data can be updated. This is defined in the status template in the column "Data Integration Action".

The existing options are:

• Update: this means that the existing order may be overwritten with all new information. In the screenshot this is set up for status 05 to status 20. Please note: with this setting, the entire order is actually rebuilt and everything is overwritten, so this does not update specific fields but by default the entire order is rebuilt from the EDI message as if it were a new order.

• Error: This means that the existing order must NOT be overwritten and that the message must fall into an error. Idea behind this: the client sends an update message too late, the order has already been executed and can and may not be changed. In the screenshot this is set up for SHIPMENTon status 65-LADEN and above (and also status 01-CANCELLED) and on RECEIPT on status 40 and higher (and also status 01-CANCELLED

Different Customers has clients who can send changes by EDI in various moments in the process: Order header data (think of address change, desired delivery date / times, etc), Order Line data (change in numbers or article numbers) or Cash on delivery data.

It depends on the status AND the change provided by the client whether the changed data should be updated or not. Therefore, the current Update/Update or Error/Error setting is not sufficient in those situations.

Description of the solution

In order to properly determine what can and cannot be changed in a certain situation and to make a good comparison between the new data and the existing data, a solution has been built whereby in the cases that the changes may be updated under certain conditions, a duplicate order is created. After this duplicate order is created, functionality can be executed to determine whether the changes may be processed or not. 2 components have been developed:

• In the status template, an additional option has been added to the "Data Integration Action", called Duplicate. When this option is chosen, you can determine under "Duplicate Handling" that a new order must be created with the option to create it in a different order type. This option can therefore be used in addition to the Update/Update and Error/Error, so in certain statuses the entire original order may be overwritten (for example, for orders that have not yet been processed or are waiting for receipts), in certain statuses nothing may change at all (for example, result orders that have already been shipped or entries that have already been received completely), and in all other cases one chooses Duplicate. It is useful to give these duplicate orders a separate

numbering and the most practical thing is to link a separate status template to this order type.

• On the newly created duplicate orders, a function (via state transition or step, possibly in combination with a job queue entry that performs this automatically) can be executed that determines whether the changes can be made or not based on a Compare Scenario. In the situation that all changes are agreed, this will be done on the original order and the duplicate order can be put in a "Processed-Status". If the changes are not accepted, the duplicate order can be put in an "Error Status". Possibly in combination with the generation of an e-mail on this "Error Status" so that the responsible employee can be informed that this can be discussed with the client. Within these scenarios, order header, order line, order detail line and cash-on-delivery can be determined per field whether the change is allowed or not.

The starting point here is that only the fields that have been named are reviewed and/or processed, so all fields that have not been named are not assessed and are not processed in the existing order.

Provisioning in duplicate order creation status template

If you want to use the duplicate orders and the corresponding logic, the first step is to determine that duplicate orders must be created, including the new order type to be created.

To do this, choose "Duplicate" on the status template in the "Data Integration Action" column.

When this setup is done, a configuration must be made per line for the order type that is used in the creation for the duplicate order. To do this, select the status line and click [Status] [Duplicate Handling].

Subsequently, table filters can be used to determine which order type should be created. It is highly recommended to create the duplicate orders with a separate order type for the recognition and for using a separate status template.

In the column "table filter" you can enter a filter on the original order, for example based on the order type.

In the column "Order Type Code" you can setup the order type for the new duplicate order to be created.

The column "External Doc.No. Format" allows you to define how the external document number should be formulated on the duplicate order. If you choose "%1-%2" here, the external document number on the duplicate order is filled with the original external document number followed by a "-" and followed by an ascending sequence number. So with the first duplicate order a -1 arises, suppose there are more updates then that becomes -2,-3 etc.

Note: If the setup in the parameters of the message type contains that new documents should have a specific document status, for example 05-EDI, then the newly created duplicate order will also receive this status.

When the "Duplicate Handling" has been set up for all relevant statuses, duplicate orders are created based on this statuses when processing the EDI messages. The creation of the duplicate order does not immediately result in conditionally updating the changes. See the rest of this instruction.

Compare Scenarios in general

When a duplicate order is created, it will have to be compared with the original order. A setup can be made which fields should be taken in account and whether it is allowed to update these fields or not. As mentioned earlier, the starting point here is: fields that have been named are checked and updated if allowed. Fields that are not in the setup are neither checked nor updated.

The setup is available in the Compare Scenarios. You can work with 1 total Compare Scenario, but for readability and transparency it is recommended to create a separate Compare Scenario at least per document type (Receipt, Shipment etc).

In addition to naming the fields, the compare scenario also specifies which subsequent actions must be performed on the duplicate order and/or original order. The default logic is that when the Compare Scenario is executed, by definition, the fields that are named and allowed to update are also updated by default.

A Compare Scenario consists of 3 parts: General, Rules, Details.

Setup Compare Scenarios - General

On the Compare Scenario Card, the tab "General" captions the unique code of this scenario, a description and to which table this should be applied (for now it is only WMS Documents).

In the section "Original Document", functions can be performed on the original document. By clicking on the assist button you can set up one or more functions to be performed in that situation.

In the section "Duplicate Document", functions can be executed on the duplicate document after the compare scenario has been executed.

Function sets on Original Document:

• Before Processing Func. Set : The functions in this set up will always be executed on the original document. Practical example of a function that can be set up here: marking original document with indication "an update has been performed" on a certain attribute field then that could be done with this.

• Change Allowed Function Set : The functions in this set up are executed if all differences between the duplicate and the original are allowed to be updated and have therefore been updated on the original order. Practical example of a function that can be set up here: sending an update message to TMS with all new data from the updated original order.

• Change Not Allowed Function Set : The functions in this setup will run if 1 or more differences between the duplicate and the original are detected that are not allowed. Practical example of a function that can be set up here: changing the status of the original order because an update has arrived and the order does not need to be sent out/ picked up further until this has been fixed

• Mismatch Function Set : The functions in this set up are executed if there is data in the duplicate order that was not known in the original order. For example, an extra order line or a newly created Cash on Delivery line. Practical example of a function that can be set up here: Changing the status of the original order because an update has arrived and the order does not need to be sent out/ picked up further until this has been fixed

Function sets on Duplicate Document:

• Change Allowed Function Set : The functions in this set up are executed if all differences between the duplicate and the original are allowed to be update and have therefore been updated in the original order. Practical example of a function that can be configured here: changing the status of the duplicate order to status "UPDATE-PROCESSED".

• Change Not Allowed Function Set : The functions in this setup will run if 1 or more differences between the duplicate and the original are detected that are not allowed. Practical example of a function that can be configured here: changing the status of the duplicate order to status "UPDNOTALLOWED". On this status, the back office can create a tile that is periodically viewed or set to that status that an email is sent to the back office.

• Mismatch Function Set : The functions in this setup are executed if there is data in the duplicate order that was not known in the original order. For example, an extra order line or a newly created Cash on Delivery line. Practical example of a function that can be configured here: changing the status of the duplicate order to status "UPDATEMISMATCH". On this status, the back office can create a tile that is periodically viewed or set to that status that an email is sent to the back office.

Design Compare Scenarios - Detail

Within 1 scenario for multiple situations, it can be determined which fields may be updated or not. In the tab "Rules" it is possible to set up for which situation the institution applies, in the tab "Details" the fields are determined including whether it is allowed to be updated or not.

Situation Determination Rules WMS Document Header

In the tab "rules" the setup can be made for which situation the layout of the fields applies. For this, one always starts by recording a line with source table "WMS Document Header". The table filter can be used to set up which documents this applies to. A practical interpretation of this is filtering on 1 or more statuses.

When a line of source table "WMS Document Header" has been created, on the bottom of the page in the tab "Details" the setup can be done which fields may be updated and which may not. These are fields on the header of the order such as reference numbers, address details, delivery date, etc. The fields can be searched for and set up 1 by 1, or the [Add all fields] button can be chosen.

For each field, in the column "Change Allowed" you can choose

• "Allowed": If the data of this field in the duplicate order differs from the value on the original order, the original order value may be overwritten with this setting.

• "Not Allowed": If the data of this field in the duplicate order differs from the value on the original order, the original order value may not be overwritten with this setting. If 1 or more fields cannot be overwritten and the data deviates, this results in the data not being updated for the complete order. The functions from the "general" tab for "Change Not Allowed" are executed on the original and duplicate order.

Situation Determination Rules WMS Document Line

In addition to the data on the order header, it is also possible to set what is allowed to be updated for the order lines. For this, a line can be inserted directly below the line of "WMS Document Header" with "WMS Document Line" as the source table. Make sure that the line is indented (via action button "Indent"). This ensures that this rule is executed after and including the Order-Header-Filters of the "WMS Document Header" line above it.

In the table filter of the "WMS Document Line" you can define specific filters for rules, for example for lines that have not yet been booked (inbound) or assigned (result). It is possible to create multiple "WMS Document Line" lines within 1 "WMS Document Header" filter. The setup of the fields works in the same way as described in "WMS Document Header".

Situation determination Rules WMS Document detail rule

In addition to the data on the order header and order lines, it is also possible to set what is allowed to be updated for the detailed lines. This can be used in particular in the case of Receipts in the situation that the customer sends the carrier information in advance. For this, a line can be inserted directly below the line of "WMS Document Line" with the source table "WMS Document Line". Make sure that the line is indented 2 times (via action button "Indent"). This ensures that this rule is executed after and including the Order-Header Filters of the "WMS Document Header" and the "WMS Document Line" lines above it.

If there is a general setting for the detail lines, you can also keep the indentation the same as that of the document lines (i.e. 1 x indent) and then the filters of the parent "WMS Document Line" do not apply to those detail lines.

Situation determination Cash On Delivery Line

In addition to the data on the order header, it is also possible to determine what is allowed to be updated for the cash on delivery lines. For this, a line can be added under the "WMS Document Header" with the source table "Cash On Delivery Line". Make sure that the line is indented 1 x (via action button "Indent"). This ensures that this rule is executed after and including the Order-Header-Filters of the "WMS Document Header" line above it. The setup of the fields works in the same way as described in "WMS Document Header".

Provisioning Apply Compare Scenario to the duplicate order

To apply a compare scenario, a function in a function set can be called. This can be applied in a status transition or a step.

It is recommended not to have this carried out automatically immediately after or during processing the EDI order and the subsequent creation of the duplicate order. This ensures that the processing of the EDI message takes longer and if there is an incorrect setup in the

compare scenario, this can lead to EDI processing errors while there is nothing wrong in the message itself.

The most practical application is that a duplicate order is created, possibly followed by functions that are also applied to new orders, after which the duplicate order is placed in a "to be processed" or "to be checked" status. This is where the process of processing the EDI message stops.

The next step could be for the responsible employee to manually change the duplicate order in status or execute a step. Another option is to have a job queue entry automatically set the duplicate orders to a next status where the Compare Scenario is applied.

At the status transition or step, the function "EXEC COMPARESCENARIO" from Codeunit 11172877 (WMS Document Functions) must be provisioned. In the parameter of this function, the Compare Scenario to be executed can be specified.

Manual Processing: View differences if changes are not allowed

When a Compare Scenario is executed manually (manual continuation of status or execution of step function) and there are 1 or more fields that differ and whose update is not allowed, then after the execution of the functions for "Not Allowed" a comparison screen appears that shows which data is different, and by the use of colors green or red it is shown whether the change is allowed or not. Based on this, the user can check the changes and if needed consult the customer, and where necessary incorporate the changes into the original order. For example, after this has been completed, the duplicate order can be forwarded to a processed state.

Manual processing: Mismatch

If the manual processing leads to a mismatch, the system will tell the user via an error message which part of the order results in a mismatch. For example, when the duplicate order contains a cash on delivery line and the original order does not.

Tip

Step function on check status in case of processing via Job Queue Post

When the Compare Scenario execution is performed via a job queue entry, the result will be that the duplicate order will be in a processed status. The duplicate orders that have been processed properly do not need to be further examined. For the duplicate orders that cannot be processed (Update not allowed or Mismatch) manual intervention is needed.

In order to determine which data is different or for what reason the mismatch occurred, it is desirable to perform the Compare Scenario again. For this purpose, a step function could be created that performs the same as the status function or job queue entry. This step function can be linked to the specific statuses in the status template so that it is automatically displayed to the user in that status. To do this, click on "Number of linked steps" in the status template on the line of the relevant status

In a blank line, select the Step Code created to run Compare Scenario.

BBy executing the Step Function the compare view will be opened (for not allowed) or the error message will be displayed (in case of mismatch) and then the user can determine what to do.