BisEdiHistory table - Insert process and customizations

The insert process in the BisEdiHistory table is a critical part of EDI processing. It ensures correct account and document flow identification. This topic explains how the insert method designed and how you can extend it with customizations.

BisEdiHistory insert method

The purpose of the BisEdiHistory insert method is:

• Ensure that the correct customer, vendor, or warehouse is linked to an EDI transaction.

• Determine whether the correct document flow is implemented.

Replaceable methods

For the BisEdiHistory insert method, the account determination logic is separated into individual replaceable methods. With these methods, you can implement custom logic while ignoring the default functionality.

Each replaceable method determines the appropriate account for EDI processing. These replaceable methods are used:

Custom insert method

You can override the standard logic by implementing your own conditions.

To implement an extension on a replaceable method, use the chain of command (call 'next()').

The following example shows how you can replace inbound customer logic:

[ExtensionOf(TableStr(BisEdiHistory))]
internal final class BistestEdihistory_extension
{
    public BisEdiTmpDocumentFlowLine OnSetInboundCustomer()
    {
        boolean myCondition = false;
        if (!myCondition)
        {
            // Execute the standard logic if the custom condition is not met
            BisEdiTmpDocumentFlowLine returnValue = next OnsetInboundCustomer();
            return returnvalue;
        }
        // Implement custom logic and return BisEdiTmpDocumentFlowLine
        return null;
    }
}

Customize message type

You can extend the BisEdiMessageType enumerator with a custom message type. If you do so, develop the custom message type logic for customized EDI processing.

To develop the custom message type logic, use these methods to determine the correct document flow:

The following example shows how you can customize the message type logic:

protected BisEdiTmpDocumentFlowLine CustomInboundDocumentFlow()
 			{
 			    return null;
 			    // Implement custom logic
 			}

Document flows logic

In EDI Studio, document flows are used to define for which account code, account, document flow type, and direction, an EDI relation exists. When you receive an EDI message, only if a document flow exists for such a relation, the related message can be run.

On the message mapping, for the BisEdiHistory record, you must define the value for these fields:

• Direction (Direction): Inbound or Outbound.

• Document flow type (MessageType): Several options are available, for example, Order, Invoice, or Picking.

When you run an EDI-related message, the default logic determines the applicable account code (AccountType) based on the defined direction (Direction) and document flow type (MessageType), applying this logic:

Override default document flow logic

You can override the default logic. To do so, on the message mapping, to the BisEdiHistory record, add the FlowForAccountCode field. You can use this field to define the applicable account code (AccountType), skipping the default logic to determine the account code.

The FlowForAccountCode field has these values:

If you use a pre-defined account code, only document flows with this account code are considered.

Customize document flow logic

You can extend the BisEdiFlowAccountType enumerator with a custom account code. If you do so, develop the custom account code logic for customized document flow determination.

To develop the custom account code logic, use these methods to determine the applicable document flow:

• CustomInboundForAccountType()

• CustomOutboundForAccountType()

The following example shows how you can customize the document flow logic:

protected BisEdiTmpDocumentFlowLine CustomInboundForAccountType()
 			{
 			    return null;
 			    // Implement custom logic
 			}