Introduction

In the 'GEDI Profile' page view in Business Central you will find 'GEDI Profiles'. A 'GEDI Profile' is the key to which processes you want to activate in the Standard App, and what exact GEDI configurations will be used.

A 'GEDI Profile' often refers to a 'CIP Connection', but not always. The 'CIP Connection' can be used for a "1 to 1 connection" for example between the Business Central company and one specific customer. Or it can be a "1 to many connection" to a Value Added Network (VAN) where the Business Central company reach multiple recipients/senders. 'GEDI Profiles' used only for Standard App internal functions don't need a 'CIP Connection'. Sometimes a 'GEDI profile' both use a 'CIP connection' and Standard App internal functions.

Parties such as customers or vendors, that the Business Central company is going to integrate with, needs to have a 'GEDI Profile' set in the card details. That 'GEDI Profile' will then be inherited down to each transaction related to that party, for example orders and invoices.

Sometimes within the same 'CIP Connections', there are different variations that is needed to support different scenarios. In this case multiple 'GEDI Profiles' can be configured against the same 'CIP Connection', but they will have different 'GEDI Message Setups'. For example when you have more than one method of delivering invoices or if the EDI-Invoices needs a variation in the content depending on the recipients. One of the most common scenario is the need of different banking details for different recipients within the same VAN 'CIP Connection'.

GEDI Profile concepts

'GEDI Profiles' can be divided into some different concepts;

• CIP Connection Profiles: Profiles with a 'CIP Connection' allows the CIP to read and write 'GEDI Messages' to that 'GEDI Profile'. This is the standard scenario for EDI.

• Internal profiles: Profiles without a 'CIP connection' can be used for Business Central internal functions.

  For example, a PDF Invoice 'GEDI Profile' automates standard Business Central e-mail sending with PDF. In this case there is no need to integrate with the CIP.

• CIP Generic profile: The 'GEDI Profile' 'INTERNAL' is a default profile to be used with the CIP for integrating general functions. The 'CIP Connection' ID for this profile is always 'GEDI-INTERNAL'. The 'GEDI Profile' 'INTERNAL' is for example used when downloading 'GEDI Setups' from the CIP.

Introduction

In the 'GEDI Mapping List' page view in Business Central you will find 'GEDI Mapping Documents'. A 'GEDI Mapping Document', or short 'GEDI Mapping', is a definition of tables and fields in Business Central that should be exported from, imported to or be controlled. Along with rules and filters to be applied.

The 'GEDI Mapping' is structured in a table and processed from top to bottom row. There are many different types of rules that can be used, and new rules are often added upon release of new Standard App versions. This allows for a very powerful and flexible framework that can be used for much more than just EDI.

Mapping Concepts

'GEDI Mappings' can be divided into some different concepts;

• Import: Moving data from 'GEDI Messages' into tables and fields in Business Central.

• Export: Moving data from tables and fields in Business Central to 'GEDI Messages'.

• Control: There are different types of controls. For example controlling if fields in Business Central contains certain values or if they are empty etc.

  • Can be used as a pop-up error at certain events, for example release of Order or other Posting events.

  • Can be used to create comments in Business Central.

  • Can be used as "If this then that" rules to generate new 'GEDI messages'. The result can for example be triggering an error message to be sent by e-mail or a record to be updated with a 'GEDI status'.

• Send PDF: Generate PDF mails with the Standard Business Central functionality, using the automization logic from the Standard App.

  For example, when Invoice is posted, then the Invoice PDF will be automatically e-mailed to the customer as per configuration.

• Internal functions: Running only internal functions, such as updating a status, creating a 'GEDI Message Log' or running a Code Unit.

Classes and Properties

As previously mentioned, the CIP integrates with the Standard App via an internal JSON format. In the Standard App the JSON format is structured by 'GEDI Class names' and 'GEDI property names'.

• 'GEDI Class names' correspond to a Message Document type, for example 'ORDER' or 'INVOICE' etc.

• 'GEDI Property names' correspond to a field or 'tag' as it's often called in EDI, for example 'OrderNumber' or 'InvoiceNumber'

When creating import mappings or export mappings, one of the main purposes is to define the rules for which Business Central tables and fields shall correspond to which 'GEDI Class Name' and 'GEDI Property Name' in the internal format.

Introduction

In the 'GEDI Setup Catalog' page view in Business Central you will find 'GEDI Setups'. A 'GEDI Setup' is an XML file containing a complete GEDI configuration package of the Standard App. Using the 'GEDI setups' is a powerful and efficient way to import and export GEDI configurations on company level in Business Central.

Some standard 'GEDI Setups' are uploaded to the CIP and can be downloaded directly via the interface. Other 'GEDI Setups' are xml files that are created from other Business Central environments and can be uploaded into the App manually.

It is possible to save current GEDI configurations in the App as a new 'GEDI Setup', for backup purposes or for moving the GEDI configurations between different Business Central companies. This means that moving a setup from a test environment to a production environment can be done smoothly using 'GEDI Setups'.

It is possible to completely delete all GEDI configurations in a Business Central company if you want to start anew. Doing that will automatically create a back up.

Modular and Complete Setups

'GEDI Setups' can be either modular or complete GEDI configurations, depending on how they were designed. When importing 'GEDI Setups' after each other any new configurations will be added on top, and if any conflicts should occur the latest setup imported will overwrite existing GEDI configuration.

Modular 'GEDI Setups' are usually those that are uploaded to the CIP, and includes Prepacked setups and template setups. The Modular 'GEDI Setups' more strictly follow standard practices to make them compatible with each other.

A Complete 'GEDI Setup' are usually a copy of a Business Central Company GEDI configurations.

GEDI Setup concepts

'GEDI Setups' can be divided into some different concepts;

• Prepacked: Usually modular, and should work "out of the box". Almost no additional GEDI configurations should be needed to start using the 'GEDI Setup' in production. These are in general terms easier to document, as every installation is more or less the same.

  'Freemium' and 'Basic Invoice' are examples of Prepacked 'GEDI Setups'.

• Template: Usually modular, and contains a lot of GEDI configurations were most of it is expected to be relevant. Some templates are closer to prepacked, and some are more generic. These are harder to document, as every installation will have different needs for additional GEDI configurations.

  'Advanced Invoice' and 'Order-to-Cash' are examples of Template 'GEDI Setups'.

• Addon: Usually modular, lightweight 'GEDI Setups' dependent on other 'GEDI Setups'. Used for commonly added features that are not included in the main 'GEDI Setup'.

• Demo: Usually complete, and contains GEDI configurations to easily setup a demonstration of a function. These are not meant to be installed in Production environments, and should only be used in sandboxes or other test environments.

• Company Copy: Always complete, intended to move all GEDI configurations from one company to another or to be used as a backup.

Introduction

In the 'GEDI Message Codes' page view in Business Central you will find 'GEDI Message Codes'. A 'GEDI Message Code', is a definition of a specific function that a 'GEDI Message' will execute. Each unique function has a corresponding unique 'GEDI Message Code'. For example Importing an EDI order is one 'GEDI Message Code', exporting an EDI Invoice is another.

Often 'GEDI Message Codes' comes in a pair of two; one request and one execution. The request is created in the 'GEDI Message Queue' triggered by an event in Business Central. When that request is later processed, the function is actually executed. For example, information is extracted and inserted as 'GEDI message lines' or a control process is executed. After execution, a second 'GEDI Message' on another 'GEDI Message Code' is created for the result. This way the event that puts 'GEDI Messages' in the 'GEDI Message Queue' are separated from the execution of the actual function. This allows batch processing via a Job Queue running in the background, instead of delaying the user experience.

For each 'GEDI Message Code', you can define a 'GEDI Status' that will be created. This will then update the processed record with the latest status.

On the 'GEDI Message code' you can define a number of days in the field "Delete in Queue Days Back" deciding how long 'GEDI Messages' should be saved in the 'GEDI Message Queue'. A Job Queue Entry will handle the deletion of entries past due.

Directions

A 'GEDI Message Code' can be configured in different Directions. This determines the main function of the 'GEDI Message Code'. The directions are;

• Down: For importing data from a 'GEDI Message'. Usually originating from the CIP.

  For example, an EDI order is written to 'GEDI Message' from CIP and should be imported as a Sales order.

• Internal: For requests to create another 'GEDI Message' with another 'GEDI Message Code'.

  For example, an invoice is being posted and the invoice request message is added to the 'GEDI Message Queue'.

• Up: For exporting data to a 'GEDI Message'. Usually because the CIP should receive it.

  For example, when invoice data is exported to 'GEDI Message' to later be read by the CIP.

• Control: For controlling data in Business Central. Usually checking if required fields are missing data.

  For example, an EDI order is imported and a control checks if there is article number match on all order lines.

• Up Auto Finished: For a function that should be automatically marked as finished, to prevent the CIP from reading the 'GEDI Message'.

  For example, a PDF invoice being sent out via Business Central e-mail functionality.

• Posted: For exporting data to a 'GEDI Message' and directly posting it up to the CIP via xml port instead of letting the CIP read the 'GEDI Message'. Usually this is only used when the CIP is not allowed to have a web service integration with Business Central. As the CIP in this case has no way of sending back information such as status updates to Business Central.

  For example, an EDI Invoice is sent via Basic Invoice Setup, which doesn't require a web service. Statuses for the EDI Invoice is only stored and found in the CIP portal, as they are not sent back to Business Central.

Introduction

In the 'GEDI Message Queue' page view in Business Central you will find 'GEDI Messages'. A 'GEDI Message', is something that will be or has been processed within the Standard App.

There are different types of 'GEDI Messages', for example exports, imports, control functions, emails, status updates and much more. The exact function of each 'GEDI Message' is defined by a 'GEDI Message Code'.

In the 'GEDI Message Queue' page view it is possible to manually process, reprocess or run 'GEDI Messages' for testing purpose.

'GEDI Messages' can be automatically deleted by a Job Queue Entry. This clean up is making sure that the 'GEDI Message Queue' doesn't store too much data. This is to make sure that we don't have negative impact on performance over time.

'CIP Work Items' are read or written to the Standard App as 'GEDI Messages' holding a unique 'Work Item' ID. The 'CIP Work Item' ID acts as a link between the two layers; Business Central and the CIP.

Introduction

In the 'GEDI Message Selection' page view in Business Central you will find a overview of all 'GEDI Message Selections'. A 'GEDI Message Selection', is a definition of which events in Business Central should trigger which 'GEDI Message Codes' to be created as 'GEDI Messages'.

The events are also categorized in subpages, as can be seen on the picture bellow. In general, the main 'GEDI Message Selection' overview is better to use for review, and the exact subpage is better for editing.

A 'GEDI Messages' will only be created if the 'GEDI Profile' that runs the event, is allowed to use the 'GEDI Message Code' as defined in the 'GEDI Message Setup'. For example, multiple 'GEDI Message Codes' could be defined on the same event, but depending on the 'GEDI Profile' running the event, only some or all of the 'GEDI Message Codes' will actually trigger 'GEDI Messages'.

Active and Passive Events

Some events are Active and some are Passive;

• Active events: Events that are tracked when they happen, and then creates the 'GEDI Message' with the 'GEDI Message Code'. Usually this is standard Business Central events.

  For example, Posting of a Invoice, Release of an Order etc.

• Passive events: Only to define which job queue Categories should run which 'GEDI Message codes' in the 'GEDI Message Queue'. The actual 'GEDI Message' is created by another source than the event itself.

  For example, the CIP created a incoming sales order, a 'GEDI Mapping Document' created a status update.

Processing Methods

There are two different options to configure how the 'GEDI Message' should be processed; by a Job Queue Entry or "immediate". Most events will only work with either of the two options, and this is predefined.

• Job Queue Processing: Configured by selecting a 'Job Queue Category Code' that should process the 'GEDI Message Code'. This is the most common method and is used for almost all export, import and other actions that can be processed in the background.

  For example, the event "S.Invoice" happens after a Sales Invoice has been posted. The 'GEDI Message Code' for the Sales Invoice export request will be created in the 'GEDI Message Queue'. And the actual execution of the export will be done later by the Job Queue Entry with the corresponding Category Code.

• Immediate Processing: Configured by checking the "Manual Immediate Run" checkbox. Usually this means that the 'GEDI Message Code' defined is a control that will be processed directly. Either in the interface or in the background. This processing method is for example used for pop-up controls or for export of temporary data.

  For example, the event "C.S.Invoice" happens when a Sales order is requested to be posted for invoicing. This enables the control 'GEDI Message Code' to either allow or rollback the posting event. In the control, certain fields that are required for allowing the posting can be defined. If requirements are not met the posting event will be rolled back.

Introduction

In the 'GEDI Status Ledger Entries' page view in Business Central you will find a overview of all 'GEDI Status Ledger Entries'. A 'GEDI Status Ledger Entry' or short 'GEDI Status', contains information that should be displayed on a record for the end user. A 'GEDI Status' is always connected to a 'GEDI Status Code'.

On a a lot of records you will find a field called 'GEDI Status'. In this field you can see the latest Status Description of 'GEDI Statuses' connected to this record.

This allows the end user to get a quick overview of what the latest status for a record is. If the 'GEDI Status' field is empty, it usually means that this record did not trigger any GEDI processes.

Introduction

In the 'GEDI Conversion List' page view in Business Central you will find 'GEDI Conversion Documents'. A 'GEDI Conversion Document', or short 'GEDI Conversion', is a table were you can input values to be converted and used in 'GEDI Mappings' or in Code Units.

This means that code identifiers inside Business Central can be different from the code identifiers in the EDI.

Conversion Concepts

In general you can divide 'GEDI Conversions' into some different concepts;

• Identifier: Convert internal Business Central identifiers to or from standard EDI codes used by the 'CIP translators'.

  For example, maybe in Business Central a unit of measure is "BX" but the corresponding EDI standard code is "BOX". Then a 'GEDI Conversion' is used to convert the values.

• Add Info: Can be used to add information that has no field in Business Central.

  For example, A customer has a fixed invoice reference they require in EDI. Then a 'GEDI Conversion' could be used to convert the customer nr into the fixed invoice reference and include in the EDI message.

• Logical: Can be used to convert fields in Business Central to a integer. The integer can then be used in 'GEDI Mapping' rules or in the 'CIP Translator' to flag certain scenarios.

  For example, some order rows are articles and some are not. If we convert ARTICLES to 1, RESOURCES to 0 and G/L ACCOUNTS to 0; then we can tell the 'CIP Translator' that some rows are item related (1) and some rows are are not (0).

Introduction

In the 'GEDI Status Codes' page view in Business Central you will find 'GEDI Status Codes'. A 'GEDI Status Code', is a definition of which status texts that can be configured. The 'GEDI Status Code' is connected to a 'GEDI Message Code'. When a 'GEDI Message' is created or executed, depending on the configuration, a 'GEDI Status' will be created.

The status codes description can be changed or translated as needed, without any impact on the configuration.

Status concepts

'GEDI Status Codes' can be divided into some different concepts.

• Direct: Is created when a 'GEDI Message' is created.

  For example, an Invoice is posted and directly gets the status "EDI Requested". This is before the 'GEDI Message' request is executed.

• Processed: Is created when the 'GEDI Message' is executed. This is connected to a 'GEDI Message Log' that is created during the execution.

  For example, the above invoice 'GEDI Message' request is now executed and is waiting for the CIP to read the information. The 'GEDI Status' is now set to "EDI Sending".

• CIP: Is created when the CIP writes a 'GEDI Message' when a new status in the CIP has been reached. This is connected to a 'GEDI Message Log' that is created during the execution.

  For example, the above invoice is now translated by the CIP and sent to the receiver as EDI. Then CIP writes back a "sent" 'GEDI Message'. When this "sent" 'GEDI Message' is executed, the invoice 'GEDI Status' will be "EDI Sent"

• Control: Is created when a Control mapping is executed and the outcome of the control will be either True or False. Then two different Statuses can be connected to this.

  For Example, a sales order is imported via EDI and now a control is checking if all article numbers from the customer can be matched against the item list in Business Central. If the outcome is that all article numbers match, then the 'GEDI Status' "OK Control" is created. If the outcome is that not all article numbers match, then the 'GEDI Status' "Error in Control" is created.

Status Color Schemes

All statuses can be configured to be visualized based on a color scheme. Some transactions has a GEDI list page view, for example 'GEDI Posted Sales Invoices'. In these list pages the 'GEDI Status' field will be presented by the color scheme defined.

The Status color Schemes are;

• Standard, in black. Used when there is only one outcome.

  For example, "EDI Requested" when the invoice was posted.

• Ambiguous, in yellow. Used when the outcome is not yet known.

  For example, "EDI Sending" when the EDI invoice is executed, but the CIP has not yet written down the next status.

• Favorable, in green. Used when the outcome is positive.

  For example, "EDI Sent" when the invoice was sent to receiver by the CIP.

• Unfavorable, in red. Used when the outcome is negative.

  For example, "Error in Control" when the order control found article numbers that didn't match.

Introduction

In the 'GEDI Class Setup' page view in Business Central you will find 'GEDI Class Setups'. A 'GEDI Class Setup', is a definition of which 'GEDI Message Code' should be used by the CIP when writing 'GEDI Messages' to the 'GEDI Message Queue'. This is defined per 'GEDI Class name' used for the header of the 'Message Document Type'.

For example, the CIP wants to write a new Order 'Message Document Type' into the 'GEDI Message Queue'. ORDER is the header 'GEDI Class name' for Order 'Message Document Type'. ORDER can then be defined in the 'GEDI Class Setup' with 'GEDI Message Code' "SO-01-IM". The CIP can now create a 'GEDI Message' with 'GEDI Message Code' "SO-01-IM".

It is possible for the CIP translator to have rules for fallback or override 'GEDI Message Code' as well.

In 'Reference Property names' field it is possible to determine which 'GEDI Property name' should be used as the 'Message ID' for the 'GEDI Message' that the CIP creates.

Introduction

In the 'GEDI Message Line' page view in Business Central you will find 'GEDI Message Lines'. 'GEDI Message Lines', holds the information that is contained within a 'GEDI Message'. The information is structured by 'GEDI Class name' and 'GEDI Property name'.

• 'GEDI Class names' correspond to a Message Document type, for example 'ORDER' or 'INVOICE' etc.

• 'GEDI Property names' correspond to a field or 'tag' as it's often called in EDI, for example 'OrderNumber' or 'InvoiceNumber'

'GEDI Mappings' can import or export information to 'GEDI Message Lines'.

The CIP reads or writes information to 'GEDI Message Lines'.

Value types

Each 'GEDI Message Line' and each corresponding 'GEDI Property name' has a specific value type. This makes sure that information is always imported and exported correctly. Each value type has it's own column in the 'GEDI Message Line' table. The value types are;

• Text value - "Customer Name"

• Code value - "PIECE"

• Integer value - "100"

• Decimal value - "100,00"

• Date value - "2021-10-29"

• Time value - "10:15:00"

• DateTime value - "2021-10-29 10:15"

• Boolean value - Checkbox for "TRUE" or "FALSE"

• Big integer value - "12147483647"

The value type defined in the 'GEDI Mapping' shall correspond to the value type of the 'GEDI Property name', or the data won't be correctly transferred.

Levels

'GEDI Message Lines', 'GEDI Class names' and 'GEDI Property name' all have a corresponding level. Levels allow for different 'GEDI Class names' to together build up one 'Message Document Type'. The level can be found in a field in the 'GEDI Message Line'

For example, 'Message Document Type' 'Order' consists of two levels and 'GEDI Class names':

• Level 1: 'ORDER' 'GEDI Class name', corresponds to the order header.

• Level 2: 'ORDERLINE' 'GEDI Class name', corresponds to the order lines.

Some 'Message Document Types' and 'GEDI Class names' may have repeatable levels. To structure this information there is a field 'Level Line No' on each 'GEDI Message Line'.

For example, many 'ORDERLINE' 'GEDI Class names' can be contained in the same Order.

• First 'ORDERLINE' section has 'Level'=2, and 'Level Line No'=1

• Second 'ORDERLINE' section also has 'Level'=2, but 'Level Line No'=2

• etc for each additional line.

Some 'Message Document Types' are more complex than others. For example, the Despatch Advice has three levels and 'GEDI Class names'. The Despatch Advice header can hold multiple containers and each container can hold multiple order lines.

• Level 1: DESPATCHADVICE - Despatch Advice header information

• Level 2: DESPATCHADVICELOGISTICUNIT - Despatch Advice container information

• Level 3: DESPATCHADVICELOGISTICUNITLINE - Despatch Advice article line information

Introduction

In the 'GEDI Message Setup' page view in Business Central you will find 'GEDI Message Setups'. A 'GEDI Message Setup', is a definition of how three main parameters; 'GEDI Profile', 'GEDI Message Code' and 'GEDI Mapping Document' are all tied together and build the process that is connected to each 'GEDI Profile'.

For each 'GEDI Message Setup' there is a check box for "Not Create Automatically". If this is checked, the normal events defined by 'GEDI Message Selection' will be disabled for the combination of 'GEDI Message Code' and 'GEDI Profile'. This can be useful when it's better to have a 'GEDI Mapping Document' create the 'GEDI Message Code' instead of the normal event. For example, when a control is to decide wheather a 'GEDI Message' should be created or not.

Golden EDI Standard App

The Golden EDI Standard App for Business Central has functions for importing, exporting and controlling data in a configurable framework without coding needed. Many standard functionalities are ready to use "out of the box".

Golden EDI is used to transfer data between Business Central and external parties, other applications or intercompanies.

Golden EDI is a 2-layered solution for EDI; The Standard App handles processes inside Business Central, the Cloud Integration Platform (CIP) handles the communication between sender and receiver. A Work Item Id for each transaction is the link between the two layers.

Golden EDI can also be used to transfer data between different tables inside the same Business Central company. This can be useful when Business Central is integrated with other applications or for Partner Apps where populating custom tables with certain data is needed.

A few examples of integration flows where Golden EDI can be used:

E-Invoices via Value Added Network (VAN)

Order to Cash (Sales Order Import to Invoice Export)

Webshop integration with 3PL integration

Intercompany Sales to Purhase

Intercompany Masterdata update

Introduction

Before we go into the details of the Standard App for Business Central, we will go through some basics on how the Cloud Integration Platform (CIP) manages communications with other parties.

The CIP is an online cloud solution on Microsoft Azure.

CIP Connections

In the CIP, connections between different parties are configured. The CIP Connection holds information about which Business Central company it should connect to, and what other party it should integrate with.

It can be a direct connection, for example between your Business Central company and 1 of your customers. Or it can be a connection to a Value Added Network (VAN), were multiple parties can be integrated through the same connection.

The connection also holds information on which communication protocol that should be used to communicate with the other party. For example FTP, API, AS2 etc.

Communication with the Business Central company is usually via Web Service SOAP, but could also be via other means.

Each CIP connection has a Connection ID and a API key, this is linked in the Standard App to a 'GEDI Profile'. More on the 'GEDI profile' later.

CIP Translators

Communication between the Standard App and the CIP is always done via a internal JSON format.

A CIP Translator is a code script to convert between the internal JSON format and the format that the other party can handle, for example PEPPOL, EDIFACT, X12, XML etc.

In the CIP translator it is defined which direction it converts (incoming/outgoing), which format it converts to and from (PEPPOL, EDIFCAT etc) and which Message Document Type it converts (Order, Invoice, DespatchAdvice etc).

There are general translators that follow the standards for the format, and there can be specific translators that is custom made for parties with more specific demands and setups.

In the CIP Connection it is defined which directions, document types and translators that are allowed to be used for that CIP Connection.

CIP Work Items

A transaction in the CIP is called a Work Item, usually this is an incoming EDI file from an other party or it is an outgoing message from the Standard App. It is then processed and converted as part of several steps.

When the CIP reads or writes Work Items to and from the Standard App, the Work Item ID is updated and viewable inside Business Central.

References

For more details about the CIP, see bellow page on Core Concepts for Cloud Integration Platform.

Introduction

'GEDI Messages' is usually configured to be automatically processed by 'Job Queue Entries'. 'Job Queue Entries' are configured to call on specific Code Units and 'Job Queue Category Codes'.

'Job Queue Category Codes' are then configured against an event and 'GEDI Message Code' in the 'GEDI Message Selection'.

There are some standard 'Job Queue Entries' that many 'GEDI Setups' relies on, for example the 'Job Queue Category Code' 'GEDIQUEUE'. Additional 'Job Queue Categories' can be configured if certain 'GEDI Messages' should be processed on other time interval than 'GEDIQUEUE'.

The CIP has the possiblity to track if the 'Job Queue Entries' are still running as expected. This functionality is called a 'GEDI Heartbeat'. If the 'Job Queue Entry' for some reason should stop running, the CIP can send out notifications about 'GEDI Heartbeat' failure.

There can also be other GEDI related Code Units that 'Job Queue Entries' could call upon. For example, when configuring an automatic master data sync, a 'Job Queue Entry' defines how often the sync should run.

GEDIDELETE

Another 'Job Queue Entry' that should be configured in most Standard App installations is the 'Job Queue Category Code' 'GEDIDELETE'. 'GEDIDELETE' is a clean up job that deletes old 'GEDI Messages' depending on a setting in the 'GEDI Message Code'. This job is most often run once a day making sure that 'GEDI Messages' doesn't store too much information over time.

Introduction

In the 'GEDI Message Log' page view in Business Central you will find an overview of all 'GEDI Message Logs'. A 'GEDI Message Log', contains information about when 'GEDI Message' has been processed. Also some other context information regarding the processing is saved in the 'GEDI Message Log'.

Not all processed 'GEDI Messages' will create a 'GEDI Message Log'. How and when a 'GEDI Message Log' is created is determined by the 'GEDI Mapping' rules.

Creating a 'GEDI Message Log' connected to a record will allow for the 'GEDI Status' to be updated after processing. Therefore it is recomended to create a 'GEDI Message Log' for the 'GEDI Mappings' where a 'GEDI Status' update is relevant.

Duplicate protection

One of the purposes of the 'GEDI Message Log' is to track which key references are already used by other 'GEDI Messages'. It is very common in a EDI process that updates are not allowed against the same key reference. This is prevented by setting the 'GEDI mapping' to "not allow updates", and by creating a 'GEDI Message Log' on the key reference.

For example, you have received the same sales order twice from a customer by mistake. The first time the order gets imported and the customer purchase order number is stored into External Document Number field and saved as a 'GEDI Message Log'. The second time you receive an order with that same customer purchase order number, the import will be stopped automatically and an error e-mail sent out.

Processing protection

Another purpose of the 'GEDI Message Log' is to track if a request is executed or not. This can be useful to prevent certain events to create a second request before the first is executed.

For example, a sales order is released and the event creates a request for an order confirmation to be processed. If the user want to reopen the sales order again, they have to wait for the first order confirmation to be executed, before reopening the order is allowed. This is to make sure that the sent order confirmation correspond to the sales order at the time it was released.

The processing protection can be disabled in the corresponding 'GEDI Mapping Document'.