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:

Method	Description
OnSetInboundCustomer()	Returns BisEdiTmpDocumentFlowLine for inbound customer processing.
OnSetOutboundCustomer()	Returns BisEdiTmpDocumentFlowLine for outbound customer processing.
OnSetInboundVendor()	Returns BisEdiTmpDocumentFlowLine for inbound vendor processing.
OnSetOutboundVendor()	Returns BisEdiTmpDocumentFlowLine for outbound vendor processing.
OnSetInboundWarehouse()	Returns BisEdiTmpDocumentFlowLine for inbound warehouse processing.
OnSetOutboundWarehouse()	Returns BisEdiTmpDocumentFlowLine for outbound warehouse processing.

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:

Method	Description
CustomInboundDocumentFlow()	Returns BisEdiTmpDocumentFlowLine for inbound messages.
CustomOutboundDocumentFlow()	Returns BisEdiTmpDocumentFlowLine for outbound messages.

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:

Direction	MessageType	AccountType
Inbound	Order	Customer
	DeliveryForecast
	Confirmation	Vendor
	Acknowledge
	Delivery
	Invoice
	InvoiceStdOnly
	PriceList
	PurchaseInquiry
	Picking	Warehouse
	WarehouseDelivery
	Return
	InventoryCount
	TransferReceipt
	TransferShipment
Outbound	Order	Vendor
	ProductReceipt
	PurchaseInquiry
	Confirmation	Customer
	Delivery
	Invoice
	InvoiceStdOnly
	PriceList
	ProjInvoice
	InventoryCount
	Picking	Warehouse
	WarehouseDelivery
	TransferShipment
	Return

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:

Account Code	Description
Default	The default logic to determine the account code (AccountType) is applied.
Customer	The account code 'Customer' is used for the message.
Vendor	The account code 'Vendor' is used for the message.
Warehouse	The account code 'Warehouse' is used for the message.

f 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 }

See also

• BisEdiHistory table - Setting field values and mapping IDs