EDX - Electronic Data eXchange#
EDX - Electronic Data eXchange stands for the document exchange module of KUMAVISION 365. EDI documents are sent in different formats, e.g. EDIFACT, VDA, OpenTrans etc.. A converter handles the conversion from the external format to the EDX internal XML format.
EDX then processes the converted messages and imports them into Microsoft Dynamics 365 Business Central. Required message acknowledgements are automatically sent within the internal document exchange. In the case of external EDI (electronic data interchange), message acknowledgement must be coordinated with the EDI service provider.
Incoming messages are validated by the EDX module. This means that the message content is loaded into the EDX document and checked for correctness, discrepancies and completeness. The user can manually correct the data in the EDX document and subsequently create the associated Business Central document.
For incoming messages, mapping is often required between the external item units and those stored in Business Central. For this purpose, the EDX module provides appropriate mapping tables.
The following diagram should clarify which task EDX takes over in the electronic document exchange:
|1st communication||In this area the communication of the data exchange parties takes place.
For the transmission different protocols are used. The transmission protocols are usually specified by the data sender. Automotive, for example, uses the OFTP2 protocol. The trade sector tends to use X.400 or AS2.
It is not always necessary to use a service provider for document exchange. For X.400 transmission, for example, FileWork from Telekom can be used. However, if the OFTP½ protocol is required, then it makes sense to delegate the task of document exchange to a service provider
|Message converter||The incoming messages are converted from the source format to the EDX target format using a converter. For example, EDIFACT messages are converted to EDX in-house format. For outgoing messages, the message is converted from the EDX in-house format to the respective target format.|
|EDX Inhouse Format||The Inhouse Format maps the documents of the Business Central business processes in a defined format. EDX uses the XML format for this purpose. The documents are described in the "KUMAVISION EDI Guideline".|
|4. EDX Business Logic||In this area the previously converted documents are transferred into intermediate documents. With the "Business Logic" all relevant process steps are served, which are necessary for the examination of the document, creation as well as processing of the Business Central document. If it is possible by the document, an automation of the business process takes place.|
The EDX module enables internal as well as external document exchange. Microsoft Dynamics 365 Business Central1 documents can be exchanged within a group of companies as well as with external EDI partners.
Internal document exchange#
If there is a hierarchical company structure with several companies, then the document exchange can be implemented with the EDX module. Here, the documents of the individual companies can be exchanged among each other.
Prerequisites for the internal document exchange:
Main company and companies are in one database
In this case, the internal document exchange can be set up directly with the wizard.
Main company and companies are in separate databases
In this case, document exchange must be set up manually.
There is a common network structure and all participants can access a shared network path.
The following figure shows the document flow between customer and supplier in conjunction with the EDX module:
Main Company = Customer
Company = Supplier
External document exchange#
If documents are sent to an external partner (EDI) this is described below as external document exchange.
The external document exchange contains message types that have been developed for use with EDI service providers. The EDI service provider receives the EDX messages, transforms them into the target format and transmits the messages to the recipient.
It is not mandatory to use an EDI service provider. Depending on the requirements, the transformation and transmission can also be implemented as an in-house solution with appropriate middleware.
The following documents are already available in XML format after installation:
- Order outgoing
- Order change outgoing
- Order confirmation incoming
- Incoming purchase delivery
- Incoming purchase invoice
- Purchasing complaint outgoing
- Sales order received
- Sales order change received
- Order confirmation outgoing
- Sales quotation outgoing
- Delivery bill outgoing
- Sales invoice outgoing
- Sales credit note outgoing
- Sales complaint outgoing
The module has numerous configuration and customization options, which will be explained in more detail in the following sections. The first part of the documentation covers all topics concerning administration and configuration. The second part describes the operation of the data exchange.
Via the installation of the EDX Apps, different authorization sets are automatically integrated in your Business Central application. Assigning these permission sets to your users or user groups ensures that the respective users have access to the connection and can execute the functions depending on the assigned set.
|EDX ALL||Permissions to read the EDX setup.
This role must be assigned to the users.
|EDX SETUP||Permissions to read, write, modify as well as delete records for all EDX tables.
This permission set allows EDX setup as well as access to all EDX objects.
This role must be assigned to the Microsoft Dynamics 365 Business Central1 Administrator as well as the task queue user.
|EDX SALES||Permissions to read, write as well as modify records related to the sales business process.
This role must be assigned to the sales users.
|EDX PURCHASE||Permissions to read, write as well as modify records which are related to the business process purchasing.
This role must be assigned to users from the purchasing area.
The EDX Role Center represents the central work platform for the entire EDX module. All necessary information regarding documents (incoming/outgoing), items (incoming/outgoing) and configurations are displayed with corresponding stacks in the role center.
Incoming and outgoing documents are displayed as links in the Purchasing, Sales and Logistics overviews, indicating the number of each. Clicking on the link opens the relevant document or an overview of the documents. It is therefore possible to navigate from the role center to all EDX relevant documents.
Furthermore, all settings as well as error entries and system messages are displayed in additional overviews.
In the EDX Setup, settings can be made that are valid for the entire module. The EDX Setup can be called up via the Facilities and extensions > Service connections > KVSEDX Setup start page.
In the register Interface directory the directories for documents, test as well as the productive have to be defined.
Further entries are not necessary for the time being, since these are made with the EDX Setup Wizard. Further information can be found in the section of the same name.
For completeness, all fields of the EDX setup are explained in more detail below.
|Test environment||This flag controls whether the messages are processed in the subdirectory for the production or test database.
see "Inforegister interface-directory"
|database name||name of the current SQL database|
Inforegister interface directory#
|Document directory (UNC)||Base directory for electronic document exchange.
The path must refer to a network share and be written according to UNC notation. Example: \server name\EDX
|Subdirectory Test Environment||Subdirectory for Test Environment.|
|Subdirectory productive environment||Subdirectory for productive environment.|
Inforegister Azure Storage#
|Storage Account Name||Name of the created Azure storage account.
See Azure Environment: All Resources-> Storage Account
|Shared Access Key||Access key for the storage account
After selecting the storage account in the Azure environment, the access key (key1) can be retrieved and copied to the Shared Access Key field.
|Container||Name of the blob container in the storage account.|
|Azure subdirectory Prod||Subdirectory for productive data.|
|Azure subdirectory Test||Subdirectory for test data.|
|Activated||When activated, the Azure Storage interface is registered as a service connection and can be used.|
|File Share||Name of the Azure file share.|
The Azure service connection is registered when the setup dialog is closed. Before the Azure Connection Test action can be executed, the setup dialog must be closed and reopened.
After that, the Azure Connection Test action can be executed.
Depending on the setup, either the connection to the Azure Storage Container or to the Azure File Share can be tested.
The following actions are performed during the test:
- Create Readme.txt file in the container.
- List files in the container
- Read in file "Readme.txt
- Delete file "Readme.txt".
Information register partner#
|Extension Vendor EDX Partner Code
Extension Customer EDX Partner Code
|Within the EDX module the EDI partners are created based on a customer or vendor. The partner codes are composed of the respective Microsoft Dynamics 365 Business Central1 vendor or customer number and the extension specified here
Creating an EDX partner based on vendor 1000. The EDX partner is managed as V1000.
The extension codes are freely selectable. Both extension codes must be filled in
All incoming EDX documents are first stored in EDX intermediate tables. For these EDX documents number series are necessary. If the EDX module is used exclusively for outgoing documents, then the specification of number series is not necessary.
|EDX Order Number||Incoming order from customer.|
|EDX Order Change Number||Incoming order change from customer.|
|EDX Purchase delivery number||Incoming sales delivery from supplier.|
|EDX Purchase Invoice Number||Incoming sales invoice from vendor.|
|EDX Order Confirmation Number||Incoming order confirmation from supplier.|
Information register web service#
|Log incoming web service data||Specifies logging of incoming web service calls. Logging takes place in the EDX inbox.|
|Log outbound web service data||Specifies logging of outbound web service calls. Logging takes place in the EDX outbound.|
Inforegister error handling#
|The parameter "Time period until e-mail is sent" can be used to control the time period for which the errors are collected. Only after this time span has expired, the mail dispatch of all occurred errors takes place.|
|Error mail address||Mail address to which error messages are sent. Only error messages are sent, which occur within the server processing.
The following list shows a few examples of when error mails are sent automatically:
An error occurs when reading an XML file.
Possible error causes:
- General errors within the XML file (Wellformed)
- The XML file does not match the expected schema
An error occurred during automatic further processing "Receiving a sales order".
Possible causes of error:
- Within the sales order, a reference is made to a Business Central master data record (e.g. article number, article unit) which does not exist.
- When the sales order is created, queries are made which must be confirmed by the user (e.g. credit limit). These queries are not allowed in a background process.
An error occurs when sending an XML file.
Possible error causes:
- No permission to write the outbound directory.
In the error mail, a link to call the related Business Central Page is provided. For further information, please refer to the section "Setting up e-mail dispatch".
|Disable XML Byte Order Mark||This switch can be used to control whether the XML message to be output should contain the byte order mark.|
|The date formula in the "Archive outputs/inputs that are older" fields can be used to specify the date from which EDX inputs/outputs will be moved to the archive. Only outgoing items for which no transmission error has occurred will be moved to the archive.
Outgoing items with transmission errors can be manually moved to the archive using the Archive outgoing items with transmission errors action.
For inbound items, only completed acknowledgement messages are moved to the archive. The archiving of other input messages, such as EDX sales orders is controlled via the respective EDX document.
Inforegister BC Configuration#
|Task queue items in seconds interval||As soon as the switch is active, all EDX task queue items except for the parameters "Reorganization" and "Send Mail" will be executed in seconds interval.|
Inforegister Facility Overview#
The fields on the Setup Overview info tab give an overview of which items are already set up in EDX.
EDX Setup Wizard#
To make the setup of the connection as comfortable as possible for users, a setup wizard has been developed to guide you through the individual steps. This setup wizard can be called up via the EDX Setup menu ribbon (More Options > Action > Setup > EDX Setup Wizard).
Furthermore, the EDX Setup Wizard can also be started via the "Supported Setup".
The EDX setup wizard is started.
During the first EDX configuration, the "Communication" function should be started.
With the selection "Communication" the parameters for the file transfer (OnPrem) as well as the parameters for the Azure Storage can be entered.
The General selection is used to create the message types as well as number series for incoming messages.
If you want to send purchase orders, delivery bills or invoices to another client, then select the Internal document exchange function. For more information, see the "Internal document exchange" setup section.
EDX Document types#
When installed, the EDX module already has some message types which can be used for internal and external document exchange.
The EDX message types are created with the action "EDX Setup Wizard" within the EDX setup.
You can view the "EDX message types" using the call of the same name via the user search. The individual fields are explained in more detail below:
|Document||Name of the EDX message.|
|Description||Description of the EDX message.|
|Document Direction||Inbound/Outbound Message.|
|GS1 Business Message Standard||Indicates if this is a GS1 Business Message Standard message.|
|Intercompany Role||Role of the document within the intercompany message exchange (customer/vendor).|
|Processing order||Default value for the processing order.
This ensures that a purchase order confirmation is processed before the purchase delivery.
|Field setting active||Default value for the field setting.
If the message supports the field setting, then the field setting can be called after the message has been assigned to an EDX partner.
|Collective mail allowed||Default value for collective mail.See "Processing".|
|Include PDF allowed||Indicates to include the associated Business Central PDF document as a base64 string in the message.|
|Message Encoding||Sets the message encoding.|
|Web Service Function||The EDX message can be accessed via SOAP web service.|
|Webservice Function Name||Name of the associated webservice function.|
Distribution of EDX document types#
All EDX message types have a prefix with which an area assignment can be made.
The areas are subdivided as follows:
|IC||Internal message exchange.|
|CC||External message exchange.
Documents reconciled with Clearing Center.
These messages are used from EDX version >= 10 for external message exchange.
See also KUMA EDI Guideline.
|BASE CUSTOMER||Base Customer Export||Outgoing|
|BASE ITEM||Basic Item Export||Outgoing|
|BASE VENDOR||Basic Vendor Export||Outgoing|
|CC PURCHASE ORDER||Send Purchase Order (CC)||Outgoing|
|CC PURCHASE ORDER CHANGE||Send Purchase Order Change (CC)||Outbound|
|CC PURCHASE RETURN ORDER||Send Purchase Order Complaint (CC)||Outgoing|
|CC PURCHASE RETURN ORDER CHG||Send purchase complaint change (CC)||Outgoing|
|CC PURCHASE INVOICE||Receive Purchase Invoice (CC)||Outgoing|
|CC PURCHASE RECEIPT||Purchase delivery received (CC)||Incoming|
|CC PURCHASE ORDER CONF||Purchase order confirmation received (CC)||Incoming|
|CC SALES INVOICE||Send sales invoice (CC)||Outgoing|
|CC SALES ORDER||Receive Sales Order (CC)||Incoming|
|CC SALES ORDER CHG||Receive sales order change (CC)||Incoming|
|CC SALES ORDER CONF||Send order confirmation (CC)||Outgoing|
|CC SALES SHIPMENT||Send sales shipment (CC)||Outgoing|
|CC DESPATCH ADVISE||Send sales delivery (CC)
This message can only be used in conjunction with "KUMAVISION shipment processing". The message contains the assigned load carriers and their hierarchy.
|CC SALES CR.MEMO||Send sales credit (CC)||Outgoing|
|CC SALES RETURN ORDER||Send sales complaint (CC)||Outgoing|
|CC SALES RETURN ORDER CHG||Send sales complaint change (CC)||Outgoing|
|CC SERVICE INVOICE||Send Service Invoice (CC)||Outgoing|
|CC SERVICE CR.MEMO||Send Service Credit Note (CC)||Outgoing|
|CONFIRMATION RECEIVE||Receipt Confirmation||Outgoing|
|CONFIRMATION SEND||Send Receipt Confirmation||Outgoing|
|GS1 APP REC ACK IMP||Receive Acknowledgement||Incoming|
|GS1 APP REC ACK IMP||Send Receipt Acknowledgement||Outgoing|
|IC PURCHASE INVOICE||Receive Invoice (IC)||Incoming|
|IC PURCHASE ORDER||Send purchase order to vendor (IC)||Outgoing|
|IC PURCHASE ORDER CHG||Send purchase order change (IC)||Outgoing|
|IC PURCHASE ORDER CONF||Receive purchase order confirmation (IC)||Outgoing|
|IC PURCHASE SHIPMENT||Receive Purchase Delivery (IC)||Incoming|
|IC SALES INVOICE||Send Sales Invoice (IC)||Outgoing|
|IC SALES ORDER||Receive sales order (IC)||Incoming|
|IC SALES ORDER CHG||Receive Sales Change (IC)||Incoming|
|IC SALES ORDER CONF||Send Order Confirmation (IC)||Outgoing|
|IC SALES SHIPMENT||Send Sales Delivery (IC)||Outgoing|
|IC SALES DELFOR||Receive delivery schedule (FACTORY only)||Outgoing|
In order to be able to exchange documents, one or more partners must first be defined in the EDX module. These partners can be created based on existing accounts payable or accounts receivable.
EDX partners are managed under a code that consists of the respective Business Central vendor or customer number and a defined prefix.
Before creating the EDX partner, the field "Our account number" must be defined in the vendor/customer.
Example of "Our Account Number":
Vendor Role: For customer 1000, 61000 is entered in the "Our Account Number" field.
Role of Customer: For vendor 61000, 1000 is entered in the "Our account number" field.
Partner type debtor#
A new EDX partner is created directly from the partner overview. To do this, first call up the "EDX partner" via the user search.
With the action "Create customer" a new EDX partner is created on the basis of a customer.
For the EDIFACT UNB segment to be created, the fields: GLN, Data sender as well as Recipient Id. can be used for the EDIFACT UNB segment to be created.
The fields data sender and recipient ID are not subject to a format check. Accordingly an ODETTE-Id, DUNS-No etc. can be entered.
For the transmission of XInvoices to an EDI service provider the "Routing Id." is required. see "Coordination Office for IT Standards".
Basically all above mentioned fields have to be coordinated with the EDI service provider. The fields are transmitted within the CC messages invoice, credit bill as well as delivery bill in the element "Routing".
A unit mapping is necessary to change the customer's unit code to your own unit code.
A customer orders 5 PCS, the unit code in Microsoft Dynamics 365 Business Central1 is Piece. In this case, a mapping must be created for the translation from PCS to Piece.
The unit mapping is accessed from the "EDX Partner Overview" via the ribbon.
It is not necessary to store a unit mapping for each EDX partner and article. As a rule, the unit "PCS" must be converted to the Business Central unit "Piece" for all EDX partners and articles.
The following sequence is used to determine the unit mapping:
- mapping with EDX partner, article and reference code search.
- mapping with article and reference code search
- search mapping with EDX partner and reference code
- mapping with reference code search
Unit mapping is used with the following documents:
- Sales orders
- Sales order changes
- Purchase order confirmations
- Purchasing deliveries
- Purchasing invoices
For outgoing documents, unit mapping is only performed in the "Clearing Center Messages".
- born sales delivery
- born sales invoice
- purchase order
- order confirmation
In EDX additions/deductions mapping, additions and deductions can be assigned to articles, resources, G/L accounts and fields in the document header.
- G/L account for surcharge advertising costs
- Item as freight costs
- Amount incl. VAT field from the sales header as an insurance surcharge.
Only fields from the sales header can be used. Amounts and percentages can be specified. These two fields are disabled for lines surcharges/discounts. The field "Position" is filled automatically and is only an information for the user.
The addition and deduction codes are selected from a separate table.
The surcharge/deduction mapping is only used for external outgoing document dispatch with Clearing Center. This includes the following documents:
- Order Confirmation
- Posted sales invoice
- Posted sales credit memo
Service GTIN Mapping#
With the "EDX Service GTIN Mapping" resources, G/L accounts etc. can be provided with a GTIN. The stored GTIN is sent within the service invoice as well as credit note.
EDX Occupancy device#
Different message types can be defined for each EDX partner. With the "EDX message setup" the documents are assigned to the EDX partner as well as configured.
Via "New" an EDX message is assigned to a previously created EDX partner. In the following, the fields of the EDX message card will be explained in more detail.
|Partner No.||Selection of EDX partner.
Only active EDX partners can be selected.
|EDX Message||Selection of the EDX Message.
By default, the following messages are included:
- Order outgoing
- Order confirmation incoming
- Order change outgoing
- Sales order incoming
- Sales order change incoming
- Order confirmation outgoing
- Delivery bill outgoing
- Sales invoice outgoing
|EDX Message Description||A freely selectable description can be entered here. This is for information only|
|EDX Message Direction||Indicates the direction of the message (incoming or outgoing).|
|EDX transmission from||Microsoft Dynamics 365 Business Central1 documents are received or sent from the date specified here.|
|Receipt Confirmation Check||Receipt confirmation check can be used to control whether a message confirmation should be requested.
Sending a purchase order with receipt confirmation check.
Upon receipt of the purchase order on the receiving end, a receipt confirmation is sent to the message sender. The EDX status within the purchase order will automatically change to "Recipient Received". After the Business Centrals sales order is created at the recipient's end, another acknowledgement is sent. The EDX status within the order automatically changes to "Recipient accepted".
If the recipient rejects the EDX sales order, then an acknowledgement is also sent. The EDX status in the sent order will change to "EDX Rejected".
Acknowledgement check should be enabled on outgoing as well as incoming message.
Outgoing acknowledgement messages e.g. for receiving an EDX sales order will now be sent via EDX outgoing.
The "Source record" field now always refers to the associated document. The acknowledgement check is now supported by all EDX messages, sales deliveries, sales invoices as well as sales credit notes.
In case of external EDI, the acknowledgement messages may have to be coordinated with the EDI service provider.
|Test Indicator||Identifies the incoming or outgoing messages as a test message
See section Productive/Test Database.
|EDX transfer type||Intercompany
If both clients are in one database, then the transfer type "Intercompany" can be used.
The EDX Intercompany setup must be done via the EDX setup wizard.
API V2.0 Intercompany
Prerequisite: see section "OAuth Setup".
If both clients are in different SaaS databases, then the transfer type "API V2.0 Intercompany" can be selected. EDX Intercompany setup must be done through EDX setup wizard.
Prerequisite: set up an Azure storage and container. See section "Inforegister Azure Forwarding"
All messages are stored or retrieved on the specified Azure Storage container.
This transfer type can be used in the following scenario:
Messages are to be stored on an FTP or SFTP server for the interface operator.
An Azure Logic App must be created in the customer project.
Within the Azure Logic App, the Azure Connector "FTP" is used for message transfer.
The Azure Logic App is not part of the EDX module.
Prerequisite: set up an Azure storage and fileshare.
All messages are stored on or retrieved from the specified Azure fileshare.
This transfer method can be used in the following scenario:
Messages are to be stored in the file system of the interface operator. A Powershell script is provided to the interface operator for the Azure fileshare that has been set up. With this script the interface operator can integrate the Azure fileshare as a network drive into his infrastructure.
The transmission type can be extended in the customer project.
Extension of the transmission type is useful if the interface operator provides e.g. web services for message reception.
Messages from the interface operator to Microsoft Dynamics 365 Business Central1 can be sent to the "EDX API Inbound".
Inforegister Azure / File Transfer#
|EDX file path||Input/output path for files.
In this field either an absolute or dynamic path can be entered. The dynamic path is stored with the placeholder %ROOT_DIR%.
This placeholder is exchanged at runtime for the base directory from the EDX setup.
Thus, when moving a directory share, it is sufficient to change the new directory in the "Directory Documents (UNC)" field within the EDX setup.
In the above example, %ROOT_DIR% is exchanged for
Once the "Test Environment" switch is enabled, the following directory applies to %ROOT_DIR%
The same rules apply to the placeholder %AZURE_CONTAINER%
In this case, the Azure container set up is used.
Inforegister Azure Forwarding#
The forwarding parameters are sent to an Azure Logic App or Power Automate.
The Azure Logic App is not part of EDX. A corresponding "Azure Logic App" or "Power Automate" must be created in the customer project to process the parameters listed below. For the creation of the "Azure Logic App" the template "EDX_Outbound_Message" can be used.
When using the forwarding parameters, the GS1 messages "GS1 APP REC ACK IMP" as well as "GS1 APP REC ACK EXP" must be assigned to the EDX partner.
|Forwarding type||This parameter can be used within the Logic App to decide which Azure Connector is used.|
|Forwarding ID||Determines the EDI party.|
|Forwarding Destination||Determines the destination of the message.|
CC Invoice message is to be forwarded to EDI service provider EDI1 via SFTP. The message is to be placed on the destination FTP server in the /inbound directory.
Specify the following forwarding parameters:
FTP information register#
No longer supported.
For FTP as well as SFTP transfer, an Azure Storage in connection with an Azure Logic App is required.
|Recipient Email Address||Email address of the message recipient.|
|Email Subject||Indicates the subject of the e-mail.|
|Email Text (HTML)||Indicates the text of the e-mail.|
Information register processing#
In this info register the processing parameters for the incoming as well as outgoing messages are defined.
|Automatic processing||EDX incoming document:
The received EDX document is automatically checked. If there are no errors during the check, the Business Central document is created.
If an error occurs during the review or creation of the Business Central document, an error email is automatically sent.
This feature is currently available for EDX sales orders.
See section: "Automatic processing"
EDX Outbound Document:
So far, the following outbound documents can be sent automatically:
- Sales delivery
- Sales invoice
- Sales credit memo
- Purchase order
- Purchase order changes
See section: "Automatic processing".
|Processing order||Specifies the processing order of incoming messages.|
|Do not add transmission ID||If this option is enabled, the "EDX Transmission ID" element is not transferred to the XML file.
The EDX module basically assumes that the "TransmissionID" element is present in the incoming XML document. This element, for example, is used for document navigation within EDX.
If the incoming XML document does not contain the TransmissionID, then this is automatically added as the first element.
The setting of this switch should only be changed if described in the respective application documentation (customer project).
|Invoice ignore zero||Invoices with a value of 0 € will not be transferred if this option is enabled.
The setting of this switch should only be changed if it is described in the respective application documentation (customer project).
|Ignore zero credit notes||Credit notes with a value of 0 € will not be transferred if this option is enabled.|
|Automatic archiving||Determines that the associated EDX receipt is archived after EDX receipt processing.|
|Direct Purchase Invoice||Disabled:
When processing an incoming purchase invoice, the purchase delivery information is expected. Based on the purchase delivery number, the associated purchase order is determined.
The purchase delivery as well as the purchase order are then used for plausibility checks.
The EDX purchase invoice data is transferred directly to an unposted purchase invoice. Plausibility checks are performed with regard to the "purchase from vendor" as well as the articles.
This option is not available with EDX Intercompany.
|Include the associated PDF document||In the case of outgoing messages for the Clearing Center, the associated PDF document can be included directly in the message. The PDF document is transmitted as a base64 encoded string.
If the created Business Central documents (sales delivery bill, sales invoice as well as sales credit bill) should not be sent immediately when posting, then a document collection can be activated with this option.
This option is currently used by the EDX documents: Sales Delivery (CC), Sales Invoice (CC), Sales Credit Memo (CC) supported.
The time for sending the document can be set by the processing time window.
|Next list number||When sending collective shipments, a list number is usually required. In the "Next list number" field, the list number can be specified which will be used for the next transmission.
Sales deliveries can be transmitted as collective consignments. There is no provision for assigning a list number.
In general, a forwarding order number must be transmitted within the delivery note message. This is currently not supported by the EDX CC delivery note message.
|BC Release document||This setting controls that a scanned document is automatically released after creation.|
|BC Post Document||Determines whether an incoming EDX document should be posted or not.|
|Use Posting Date||Specifies which date should be used for incoming EDX vouchers.
The following options are available:
- Posting date
- Current date
- Work date
- Incoming document date
|Use article references||Since in the rarest cases there is a consolidated article master between the partners, it is necessary to ensure a reliable assignment of the article numbers. The setting "Use article references" controls a check of the transmitted article number, as well as the transmitted reference number. The article/reference number check is based on the Microsoft Dynamics 365 Business Central1 article master > References.
When using this function, the following requirements are necessary:
- The partner must necessarily transmit the GTIN or reference number.
- The article references of the partner must be maintained in the article master.
When transmitting a GTIN, the Microsoft Dynamics 365 Business Central1 article is determined based on the GTIN field in the article master. If no matching article is found, then a search is performed using the article references with type "Barcode". With the article reference search the reported article unit is used.
If also this search should lead to no result, then the search takes place on the basis the article references with type "debtor" and/or "creditor". The reported article reference number from the message is used.
|Use article unit mapping||This setting controls an automatic mapping of the article units.
The EDX partner transmits for any article the article unit "PCS" which is managed in Microsoft Dynamics 365 Business Central1 as "Piece". If the corresponding mapping table is maintained and the "Article Unit Mapping" setting is maintained, the unit will be changed accordingly upon receipt.
|EDX Automatic Archiving||If an EDX document is processed, this setting can be used to control that the corresponding incoming item is archived.|
|Processing Time Window||For outgoing documents, the processing time window controls when the document is sent. For incoming documents, the processing time window controls the review and creation time.
Example for outgoing sales invoices:
Sales invoices are to be collected by Saturday and sent at 10:00 p.m.
In this case, the "Execute Saturday" option is enabled in the processing time window. All other days will be disabled. The start time is set to 22:00 and the end time is set to 23:00. The earliest start date will be calculated automatically. Once the specified time window is reached, all invoices that have not yet been sent will be sent.
Incoming sales order example:
Sales orders should be processed automatically at 22:00 every day. In this case, every day will be activated in the processing time window. The start time is set to 22:00 and the end time is set to 23:00.
Once the specified time window is reached, all unprocessed EDX sales orders will be checked and created as Microsoft Dynamics 365 Microsoft Dynamics 365 Business Central1 order.
Info tab Advanced#
|Partner Type||Indicates whether the displayed EDX partner is a customer or vendor.|
|Partner BC No.||Displays the Microsoft Dynamics 365 Business Central1 customer or vendor no. depending on the "Partner type" field.|
|Message Type||Displays the Microsoft Dynamics 365 Business Central1 message type associated with the EDX document setup.|
|Document Table No.||Displays the Microsoft Dynamics 365 Business Central1 Table No. associated with the EDX Document Setup.|
|Indicates the XML port or code unit responsible for message processing.|
|Message Encoding||Specifies the message encoding. This parameter has no effect on EDX standard messages. Within project specific messages this parameter can be used for the message encoding.|
|Webservice Function||Specifies the message for use within internal webservice functions.|
|Webservice Function Name||Sets the name of the internal webservice function.|
|Azure File Share||These parameters can be used to override the Azure file share parameters from the EDX setup.
1. In the EDX setup, the Azure storage account "PartnerA" and the file share "Transfer" is set up. No different parameters are entered on the selected message.
In this case, the message transfer is to the Azure storage account "PartnerA" / "Transfer".
2. As described in point 1, the Azure storage account as well as the fileshare is set up in the EDX setup.
For the selected message, the Azure storage account "PartnerB" and the fileshare "Interface" are specified via the parameters.
In this case, the message transfer will be to the Azure storage account "PartnerB" / "Interface".
|AZURE_FILESHARE_ACCOUNT_NAME||storage account name|
|AZURE_FILESHARE_ACCESS_KEY||Storage account access key|
|AZURE_FILESHARE_DIR_PROD||Directory for Prod. environment|
|AZURE_FILESHARE_DIR_TEST||directory for test environment|
Function "Field settings document check "#
The function "Field settings for document check" in the ribbon defines which fields of the EDX document are checked or transferred to the Microsoft Dynamics 365 Business Central1 document.
|Validation Order||According to the defined validation order, the data from the EDX intermediate document will be transferred to the Microsoft Dynamics 365 Business Central1 document.|
|Use default values||With the option "Use default values" fields within the EDX document can be predefined, which are not included in the message for example.|
|Default value||It can be set, e.g. for the due date in the sales header, that this field is always initialized with the work date. Within the default value, constant values or placeholders can be used. When using a constant, care must be taken to enter the value according to XML format.
So a fixed date must be entered in the format YYYY-MM-DD. For decimal values, the period must be used as a separator. The XML format was chosen to avoid translation errors of different languages. If staff set the date: 01/15/2023 as default value and then English speaking staff check the message, the default date cannot be converted.
The default values will be initialized when EDX document is checked.
List of wildcards:
%WORKDATE = Work date
%TIME = Current time
%TODAY = Current date
%COMPANYNAME = Client name
@Fieldname = Reference to another field in the current table
|Create field content||This flag controls whether the field content from the EDX document should be checked as well as transferred to the Microsoft Dynamics 365 Business Central1 document
Set up task queue item#
Automated message sending/receiving is done by setting up the task queue items. These are created using the EDX setup wizard. See "EDX Setup".
Process distribution within the task queue items#
The following task queue items are created using the EDX Wizard: CodeUnit: 5487951 EDX Job Queue
|INBOUND_TRANSMISSION||Read data according to the specified transfer type (e.g. file transfer) and make it available in "EDX Inbox".|
|INBOUND_TO_EDX_DOCUMENT||Process all EDX input items with status "Unprocessed".|
|INBOUND_POST_EDX_DOCUMENT||Check all created EDX documents (sales order, purchase order confirmation, etc.) that have been configured with the "Automatic processing" flag and create the corresponding Microsoft Dynamics 365 Business Central1 document if necessary.|
|OUTBOUND_SEND_NAV_DOCUMENT||All created Microsoft Dynamics 365 Business Central1 documents (sales delivery, sales invoice, etc.), which are configured with the "Automatic processing" flag, are transferred to the "EDX outbox".|
|OUTBOUND_TRANSMISSION||Send all EDX outgoing items with status "Unprocessed" according to the defined transmission type.|
|SEND_MAIL||Send processing errors by mail.|
|REORGANIZATION||Archive the EDX outputs. Time of archiving is defined in EDX Setup.|
For the creation of an EDIFACT message, further GLNs are required in addition to the GLN (Global Location Number) in the customer. With EDIFACT the message recipient is transmitted in the UNB segment. The GLN of the message recipient can differ from the GLN of the customer.
According to EDIFACT GLN's are mapped in the following segments:
|UNB||Interchange Header (Message Sender/Receiver).
If the "Invoice to Customer" belongs to a federation, then GLN of the federation customer, otherwise GLN of the "Invoice to Customer".
Special case: The message receiver requires a GLN, which does not belong to the above master data. In this case the GLN of the EDX partner is used.
|NAD||Name and address data||SU = Supplier
BY = Buyer
DP = Delivery address
IV = Invoice address
The GLN's are entered in the following Microsoft Dynamics 365 Business Central1 master data:
Message receiver (UNB)#
The GLN for the message recipient/sender (UNB) is entered directly at the EDX partner in the "GLN" field.
Debtor (NAD segment)#
The GLN for the customer (NAD segment) is entered directly on the customer card in the "GLN" field in the "Invoicing" info tab.
Delivery to address (NAD segment)#
The GLN for the delivery to address (NAD segment) is entered directly on the customer card > delivery to addresses in the field "GLN" in the info tab "General".
The transmission of the above mentioned GLN's is supported by the XMLPorts for EDI service providers (prefix CC).
Set up e-mail dispatch#
As described in the previous sections, EDX sends mails automatically if, for example, an error has occurred during processing.
The following items must be set up for sending mails:
SMTP mail setup#
An SMTP account must be set up via "E-mail accounts". With the action "New" the setup wizard is displayed. Then "SMTP" is selected. After completing the SMTP setup, the scenario "EDX" must be assigned to the created account.
BC Administration (Management Console)#
Mail is usually sent using the Microsoft Dynamics 365 Business Central1 instance JOBQUEUE01. Since this is a process without client service, it is necessary that the base URL is entered.
In the field "Windows Client Base URL" the URL of a Microsoft Dynamics 365 Business Central1 instance must be entered, where the option "Enable Client Services" is activated.
This base URL is then used, for example, for the PageLinks within the error mail.
Internal document exchange#
Set up with the EDX Setup Wizard#
The internal document exchange can be set up completely via the EDX Setup Wizard if both clients are present in one database.
Before starting the wizard, the EDX setup must be set up in both clients. Further information can be found under "EDX Setup".
Afterwards, the action "EDX Setup Wizard" can be started in the EDX Setup.
The setup for the internal document exchange can now be started with the action "EDX Setup Wizard".
After starting the wizard, the following parameters must be set:
- Set the function of the wizard to "internal document exchange".
- Set the role of the current client.
- Selection of the communication interface.
- Use purchase price as sales price.
The price will be transferred from the sent purchase order to the sales order. (See Field Control)
- Selection of the client with which messages are to be exchanged.
- Assignment of customer as well as vendor according to the clients.
After executing the "Finish" action, the matching of the "Our account number" field between the customer and vendor takes place. In both clients, the required EDX partners and the related intercompany documents are assigned.
If the clients exist in different databases, then the setup must be done manually.
The following messages have to be set up on the client side:
|partner no.||EDX document||EDX document direction||EDX document description||partner type||partner BC no.||EDX transmission type|
|V10000||IC PURCHASE ORDER CHG||Outgoing||Send order change||Vendor||10000||File transfer|
|V10000||IC PURCHASE ORDER CONF||Outgoing||Receive order confirmation||Vendor||10000||File transfer|
|V10000||IC PURCHASE ORDER||Outgoing||Send order||Vendor||10000||File transfer|
|V10000||IC PURCHASE SHIPMENT||Outgoing||Receive purchase delivery||Vendor||10000||File transfer|
|V10000||IC PURCHASE INVOICE||Incoming||Receiving purchase invoice||vendor||10000||file transmission|
|V10000||CONFIRMATION RECEIVE||Incoming||Acknowledgement Received||Vendor||10000||File Transmission|
The following messages are to be set up on the vendor side:
|Partner No.||EDX Document||EDX Document Direction||EDX Document Description||Partner Type||Partner BC No.||EDX Transfer Type|
|C10000||IC SALES ORDER CONF||Outgoing||Sending order confirmation||Customer||10000||File transmission|
|C10000||CONFIRMATION SEND||Outgoing||Message acknowledgement||Customer||10000||File transfer|
|C10000||IC SALES ORDER Incoming||Receipt of sales orders||Customer||10000||File transfer|
|C10000||IC SALES ORDER CHG||Incoming||Receive order change||customer||10000||File transfer|
|C10000||IC SALES SHIPMENT||Outgoing||Send Sales Delivery||Customer||10000||File Transfer|
|C10000||IC SALES INVOICE||Outgoing||Send Sales Invoice||Customer||10000||File Transfer|
When setting up the intercompany documents manually, the EDX file paths must be configured manually.
In doing so, the outgoing message is configured first. The corresponding path must be stored temporarily. Afterwards the incoming message can be configured. Here, the path from the previously configured outgoing message must be used.
The message recipient and sender can thus communicate via the same directory.
Using the example "IC PURCHASE ORDER", the following steps must be carried out. The EDX basic setup must already have been carried out and partners must have been created. This procedure must be carried out for all incoming messages:
- Open client "Customer".
- Create EDX message setup for document "IC PURCHASE ORDER" and save path temporarily.
- Switch to the "Supplier" client.
- Create EDX message setup for document "IC SALES ORDER" and use the path of the outgoing document.
If the intercompany setup is to be done via different SaaS databases, then the OAuth setup must be performed in both databases. For this purpose, the action "OAuth connections" is called in the EDX setup. Within the OAuth setup, the new connection is started with the action "New->Microsoft Dynamics 365 Business Central1 Connection". The setup wizard requires the following parameters from the Azure App registry:
- Tenant Id
- Client Id
- Environment name
Shipping order / load carrier#
For the use of the outgoing message "CC DESPATCH ADVISE" (DESADV) the setup of the shipping orders including the load carriers is required.
The general information for setting up the shipping orders and load carriers can be found in the corresponding section "Shipping processing". In the following, you will only find notes on the relevant settings for the outbound message mentioned above.
Setup storage location#
In order for an assignment of the load carriers/packages in the shipping order to take place, the option "Shipping order" must be selected in the "Shipping processing" field in the storage location or must remain free.
Shipping order setup#
Via the menu item "Shipping and Load Carrier Setup" you set up your shipping orders. If you want to send load carriers with information on the NVE/SSCC, the fields "Company ID" must be filled with the base number (GLN) of the company, as well as "Load carrier ID numbers" with a number series. Instead of storing the number series here in general, these can also be stored specifically for individual load carriers. In addition, the option "Create check digit for carrier ID" must be activated so that the check digit specified by GS1 can be calculated and added for the NVE/SSCC.
In the field "Company ID" a reserve digit (see GS1 specification) must be prefixed before the base number, so that a correct NVE/SSCC can be generated.
In order for a NVE/SSCC to be generated automatically, the option "Assign load carrier ID on order release" must also be activated.
The NVE/SSCC has a total length of 18 digits (see GS1 specification). Therefore, the combination of company ID with reserve digit, number series of the load carrier and check digit must be exactly 18 digits long. If this is not the case when a shipping order is released and the "Assign load carrier ID on order release" option is activated, a corresponding note appears.
Load carrier setup#
The required load carriers can be set up via the menu item "Load carrier". If load carriers including NVE/SSCC are to be transferred, the option "ID mandatory" should be set here. If no number series is stored in the "Load carrier ID number" field in the shipping order or if a different number is to be used for the respective load carrier, a previously created number series can be selected here.
Please note the information on the NVE/SSCC from the "Shipping order setup" section.
The outgoing message "CC DESPATCH ADVISE" is generated from a booked dispatch order with EDX partner.
So that a valid DESADV file can be created and, if necessary, processed further by an EDI converter, the following requirements must still be met when creating shipping orders:
- the shipping order must refer to a booked sales delivery, otherwise no valid EDX partner can be transferred to the booked shipping order.
- each line with packaging materials/cargo carriers must be assigned to at least one delivery line.
Incoming documents are first temporarily stored in EDX documents.
Data flow of an incoming document#
The incoming message is first read into the EDX inbox. The system creates an EDX inbox item and saves the message in the item.
Then the EDX intermediate document is created from the EDX inbound item. Within the EDX intermediate document, users can intervene and correct data. Furthermore, users can reject the EDX intermediate document if necessary or create a Microsoft Dynamics 365 Business Central1 document from it.
EDX input items#
All incoming documents are first stored in the EDX Inbox table. When the business process for this document is completely finished, the item is automatically transferred to the transferred to the "EDX Inbox Archive".
|EDX Status||Indicates the current status.
The document has been transferred to the EDX module and an EDX Inbound item has been formed. The item has not yet been sent.
An error occurred while processing the item.
The "Error" field displays the number of errors that occurred.
Using the look-up of the "Error" field, the associated error items can be retrieved.
EDX Document Created
An EDX intermediate document was created from the incoming item.
BC Document Created
A Microsoft Dynamics 365 Business Central1 document was created from the EDX intermediate document created. The associated EDX inbound item has now been completed and will be moved to the "EDX Inbound Archive".
|EDX Message||If there are system messages for this item, they can be retrieved via the look-up.|
|EDX Error||If there are processing errors for this item, they can be retrieved via the Look-Up button.|
|Action "Display file"||This action displays the document contained in the item.|
|Action "Manual Processing"||If an error has occurred during automatic inbound processing and this error has been corrected in the meantime, then the inbound item can be processed again using the action "Manual Processing". See section "EDX Edit and Reprocess Incoming Items".|
|Action "Archive processing errors||The following conditions must be met for the action to archive an incoming item:
- The incoming item has a valid "Transfer GUID"
- An archiving period is entered in the EDX setup, section "Reorganization"
EDX Edit and reprocess incoming items#
The "View file" function can be used to download the XML message of the selected EDX input item and edit it if necessary. The "Save files" function downloads the XML message from all selected input items and saves it in a selected folder.
Currently this action "Save file" is not available in the WebClient (.NET Framework).
The file must be stored with the action "Show file" and then save.
If an EDX inbox item runs into an error, for example because a field length in the EDX intermediate document is exceeded or the XML structure is incorrect, the XML message can be downloaded from the EDX inbox, edited and uploaded again for new processing.
Using the "Upload message" function, the XML message can be uploaded again to the document directory on the server.
After the successful upload, the message will be processed again.
The new EDX input item does not appear immediately after calling the function, but only when the message has been retrieved again from the task queue.
Manual processing of an EDX document#
For the processing of EDX documents, a basic distinction is made between two cases.
Incoming EDX document, the Microsoft Dynamics 365 Business Central1 document has not yet been created.
A sales order is received. The corresponding Microsoft Dynamics 365 Business Central1 document has not yet been created. If the incoming EDX document is created, it results in a new Microsoft Dynamics 365 Business Central1 sales order.
Incoming EDX document, the Microsoft Dynamics 365 Business Central1 document already exists.
An incoming EDX order confirmation relates to an existing Microsoft Dynamics 365 Business Central1 purchase order.
Before a Microsoft Dynamics 365 Business Central1 document can be created from an incoming EDX intermediate document, the incoming EDX document must first be checked. After a successful check, the EDX document receives the status "Ready for creation". All EDX documents with this status can be transferred to a corresponding Microsoft Dynamics 365 Business Central1 document.
EDX Intermediate document#
The EDX intermediate documents contain partly identical fields as the Microsoft Dynamics 365 Business Central1 documents (see EDX sales order). Specific EDX fields and associated functionality are described below.
. If there are any system messages or errors specific to this document, they can be retrieved via the Look-Up.
|Unprocessed||The EDX document was created automatically. No further processing steps have been performed yet.|
|Error||An error occurred during the processing of the document.|
|Ready to create||The EDX document has been checked and can be created.|
|BC voucher created||A Microsoft Dynamics 365 Business Central1 voucher has been created from the EDX voucher already created. This item is now done and will be moved to the "EDX Incoming Archive".|
|Unmatched data||An existing Microsoft Dynamics 365 Business Central1 document already exists for the incoming EDX document.|
|Rejected||The incoming document has been rejected.|
|Manual processing||If it is not possible to create an incoming EDX document as a Microsoft Dynamics 365 Business Central1 document, it will be given the status "Manual processing".|
|Archived||EDX documents that have already been archived.|
|Deleted||EDX vouchers that have been deleted by users.|
EDX Voucher Check#
During the verification, the system performs a validation of the data. In the process, the field contents are checked. The check of the field contents is based on the settings made in the message setup.
If errors are determined, the EDX document receives the status "Error". The number of errors that occurred is indicated in the "Error" field on the document header or lines. You can open related error items using the Look-Up button.
If errors are detected, then they can be corrected directly in the EDX document. Each field change in the EDX document is logged. By means of Lookup on the field "EDX Note" these changes can be called up.
After manual correction in the EDX document, the action "Check" must be executed again. After all errors have been corrected, the Microsoft Dynamics 365 Business Central1 document can be created using the "Create" action.
Processing of EDX documents with status "Inconsistent data"#
During the check, the data of the EDX document is compared with the data of the Microsoft Dynamics 365 Business Central1 document. This is the case, for example, with an incoming order change.
To avoid having to manually compare the existing Microsoft Dynamics 365 Business Central1 sales order with the EDX order change, EDX checks the discrepancies and displays them clearly.
If any discrepancies are found, the EDX status is set to "Inconsistent Data". Clicking on the lookup field "EDX Error" will display all discrepancies.
An order change for an item with a quantity increase from 20 pieces to 30 pieces has been received.
The EDX status is set to "Inconsistent Data."
By clicking on the EDX error number (line), a dialog is displayed in which the discrepancies are shown.
The selection "Apply changes" determines whether the displayed change is to be applied to the Microsoft Dynamics 365 Business Central1 document. The column "Value EDX" shows the currently transferred value. The column "Value BC" shows the current value of the Microsoft Dynamics 365 Business Central1 document.
Once it has been determined which changes are to be adopted, the "Accept changes" action must be executed.
Delete EDX document#
Deleting an EDX document depends on the status. If the EDX status contains one of the following values, deletion is not possible:
- BC Document created
- Manual processing
If the document is not in this status, the EDX document can be deleted with the action "Delete EDX document".
After executing the action "Delete EDX document", a dialog box appears with a note that a deletion reason must be specified and whether you actually want to delete the document. This query must be confirmed with "Yes".
Subsequently, the reasons that led to the deletion of the message can be entered.
Create EDX document#
The "Create" action transfers the EDX intermediate document to the associated Microsoft Dynamics 365 Business Central1 document.
Reject EDX document#
It is possible to reject incoming EDX documents.
The rejection is sent to the message sender if the "Receipt confirmation check" field has been activated in the EDX message setup.
Rejection reasons must be recorded before completing the action.
EDX document with "Manual processing" status#
EDX documents with the status "manual processing" indicate that the EDX document cannot be created or confirmed as a Microsoft Dynamics 365 Business Central1 document. This may be due to the following reasons:
- The existing document has already been delivered
- Reservations exist
- A unique assignment of the document is not possible
- A unique assignment of the lines is not possible
- There are discrepancies that cannot be processed automatically
Since these EDX documents cannot be processed by the system, further processing must be done by the user.
The EDX document is closed by archiving it.
Within the "EDX Message Setup" the "Automatic Processing" can be activated. The received document will be checked automatically. If there are no errors during the check, the Microsoft Dynamics 365 Business Central1 document is created.
Up to now, incoming sales orders are processed automatically.
Outgoing EDX documents are not transferred to an EDX intermediate document. When the EDX message is created, an EDX outgoing item is created directly.
Each outgoing document contains information which is required for the transmission. This information is displayed in the "EDX" info tab.
The fields of the info tab that are required for the transmission are explained in more detail below:
The document has been recognized as an EDX document by the document device. Transmission of the document is possible.
No document facility exists for the document. Transmission is not possible.
|EDX Status||Indicates the current status:
The document has been transferred to the EDX module and can be sent.
The EDX outgoing item has already been created.
The EDX outgoing item has been sent.
The receiver can use a message acknowledgement to signal that the message has arrived in the target system.
An error occurred during processing. This can be looked up in the EDX system error log.
Documents with the status "Ignored" will not be sent.
The status "Ignored" will be set automatically if the following conditions are met:
If a sales invoice that has not yet been sent is cancelled, then both documents (invoice/credit note) will be set to the status "Ignored".
If a sales delivery that has not yet been shipped is cancelled by a complaint, then the status of the sales delivery is set to "Ignored".
Sales delivery, invoice as well as credit memo.
In the sales order it can be defined that certain documents should not be sent during the next posting.
If a posting number for delivery bill or invoice is reserved via the sales order and the sales order is deleted without using this posting number, then according to Microsoft Dynamics 365 Business Central1 standard a posted document is created with the note "deleted document". These documents will not be transferred.
Send EDX document manually#
Manual document dispatch takes place directly from the associated Microsoft Dynamics 365 Business Central1 document with the action "Send EDX document".
EDX output items#
All sent documents are first saved in the "EDX Outbox" overview. When the process is complete, the system automatically transfers the item to the EDX Outbox Archive overview.
|Unprocessed||The document has been transferred to the EDX module. This item has not been sent yet|
|Error||An error occurred while processing the item. Please refer to the "Error Log" field for details. If the error occurred due to insufficient file permissions, then the EDX document can be processed again after correcting the permissions. To do this, select the "Reprocess" action.|
|Sent||The item has been sent to the partner. With the columns "Messages" as well as "Error" information about the outgoing item can be retrieved.|
|Display file||This action displays the document contained in the item.|
|Display BC Document||This action displays the Microsoft Dynamics 365 Business Central1 document contained in the item.|
|Display archived BC document||Displays the archived document.|
So far, the following outgoing documents can be sent automatically:
- Sales delivery
The dispatch takes place when posting.
- Sales invoice
The dispatch takes place when posting.
- Purchase order
Shipment takes place upon release.
- Purchase order changes
Shipping occurs when released. If the purchase order is released and has been previously sent via EDX, then the automatic dispatch of an order change takes place. There is currently no check for quantity or date change.
Automatic dispatch of Microsoft Dynamics 365 Business Central1 documents can be controlled within the EDX message facility.
The following conditions apply to the EDX message facility:
- The EDX partner must be of type "Customer" or "Vendor".
- The EDX "Transfer Date From" must be greater than or equal to the Work Date.
The following conditions apply to Microsoft Dynamics 365 Business Central1 documents: delivery bill, invoice as well as purchase order:
- The "EDX Partner" field has a value.
- The document date is greater than or equal to the "EDX Transmission from".
- The "EDX Status" is "Unprocessed".
The following condition applies to the Microsoft Dynamics 365 Business Central1 delivery bill:
- The "Sale to Customer" field must match the "BC Partner No." from the EDX message setup.
The following condition applies to the Microsoft Dynamics 365 Business Central1 Invoice:
- The "Invoice to customer" field must match the "BC Partner No." from the EDX message setup.
Reset EDX status#
With the action "Reset EDX status" documents can be sent again.
Enhancements in "Internal document exchange#
Purchasing deliveries without goods receipt#
In the case of purchasing deliveries, it was previously always assumed that the storage location used was posted by goods receipt. The processing of purchase deliveries has been changed so that now also storage locations without goods receipt can be used. In this case, the field "Quantity current delivery" is initialized with the reported delivery quantity in the respective order line.
The document must be posted by the user.
Purchase deliveries with batch / serial number#
Batch/serial numbers are supported for purchase deliveries.
The batch/serial number to be delivered is entered in the sales order. The batch is then transferred to the recipient with the posted sales delivery.
The transmitted batches/serial numbers can be retrieved in the "EDX Purchase Delivery" with the line menu.
After checking/creating the EDX purchase delivery, the item tracking data is transferred to the purchase order.
After posting the purchase order, the item/batch is available in the storage location.
Additions/deductions in "internal document exchange"#
Surcharges/discounts can now be used in internal document exchange. The prerequisite is that the "Sales price without VAT" field is activated in the field control for the sales order received. Otherwise, the order line will be created without a sales price.
Item variants in "internal document exchange"#
The item variants are supported in the internal document exchange.
Order date in "internal document exchange#
When sending the order, the "planned goods receipt date" is transmitted from the purchase order. The further processing looks as follows:
|Send Purchase Order||"Scheduled Goods Receipt Date"||Send Date|
|Receive Sales Order||"Desired Delivery Date"||Validate "Planned Goods Receipt Date" from Purchase Order in "Desired Delivery Date" field.
The validation automatically calculates the "Planned Delivery Date", "Planned Goods Issue Date" and "Goods Issue Date" fields in the sales order.
|Send order confirmation||"Committed delivery date" as well as
"Planned delivery date"
|Receive Purchase Confirmation||"Committed Goods Receipt Date"
"Planned Goods Receipt Date"
|Validate "Committed Delivery Date" from Order Confirmation to "Committed Goods Receipt Date" of Purchase Order
"Validate Planned Delivery Date" from Order Confirmation to "Planned Goods Receipt Date" of Purchase Order
|Send order change||"Planned date of receipt of goods"||Send date|
|Receive order change||"Desired delivery date"||As for "Receive sales order"|
During internal document exchange, the "remarks" are transferred from the Microsoft Dynamics 365 Business Central1 order, header as well as line. On receipt, the remarks are stored in the EDX sales order.
Likewise, remarks can be reported back with the EDX Purchase Order Confirmation. In this case, remarks are stored in the EDX Purchase Order Confirmation.
Received remarks are not transferred to the Microsoft Dynamics 365 Business Central1 sales order or to the Microsoft Dynamics 365 Business Central1 purchase order. Otherwise, it would no longer be possible to distinguish between remarks entered by the user and remarks from the other party.
Receive delivery schedules#
In the internal document exchange, previously sent purchase orders/framework orders can be received as delivery schedules. The setup for sending purchase orders can be done as described above. On the receiver side the message "IC SALES DELFOR" is set up.
When a delivery schedule is received, a delivery schedule and a scheduling agreement are created for each purchase order/article.
This functionality is only available within KUMAVISION factory365.
When sending a purchase order with reference to a sales order (direct delivery) the data of the sales order will be transmitted as well.
On receipt, the data of the direct delivery is transferred to the EDX intermediate document for sales orders.
Further processing of this data must be implemented in the customer project.
Productive -/Test database#
When copying the production database to the test database, overlaps may occur in the interface directory area. Furthermore, it should be ensured that test messages do not get into the productive system.
The steps required to secure the production database are explained in more detail in the following sections.
Before the copy#
Before copying the production database to the test database, all task queue items (all clients) should be set to "Wait".
After copying the production database to the test database#
When the production database is copied to the test database, there is usually an overlap of the interface directories. The document directories in the production and test database are identical. This can lead to the fact that current EDI documents are not imported into the productive but into the test database.
For this case a security query was integrated, which is displayed when opening the test database.
If the query is answered with "Current database is the test database", the option "Test environment" is automatically activated in the EDX setup.
All clients with active EDX setup should be opened once after copying the database. Furthermore, the interface directories must be copied from the "Prod." subdirectory to "Test".
EDX voucher setup (FTP)#
FTP transfer is no longer supported. An Azure storage is required. The test and production path must be defined for this storage.
Task queue items#
Task queue items can now be reactivated in both databases.
The "Test Indicator" is used to identify incoming and outgoing messages during the EDI test phase. For EDIFACT messages this indicator is contained in the UNB segment (Interchange Header). The message recipient can use this indicator to control whether the message is transferred to the production or test system.
However, this "Test Indicator" is not available in all message formats (VDA, OpenTrans etc.).
In the EDX message setup it can be set whether the message (order, delivery bill, invoice etc.) is a test message.
Effect of the test indicator on processing in Microsoft Dynamics 365 Business Central1:
|Document received in BC:
Sales order change
Purchase order confirmation
|If the test indicator is enabled within the incoming message or in the message setup, then the EDX document will be marked as a test document.
This allows the test to be enabled for messages even if the original message (e.g. VDA) does not support the test indicator.
EDX documents with the test indicator enabled will only be processed automatically if the "Test Environment" option is enabled in EDX Setup at the same time. Otherwise, an error will be generated and sent by mail.
|Document sent from BC||The test indicator from the message setup is transferred to the outgoing document.|
Receiving a sales order with test indicator
. The test indicator is transferred from the Microsoft Dynamics 365 Business Central1 sales order to the delivery as well as invoice. This means that if a Microsoft Dynamics 365 Business Central1 sales order was received as a test message, then the outgoing delivery/invoice messages will also be marked as a test message.
Azure FileSync can be used to exchange files between networks. The synchronization between source and target directory can take up to several minutes.
If time-critical messages have to be exchanged, which is the case, for example, when messages are provided for a label printer, then the switch should be made to the "Azure Fileshare" file transfer.
EDX master data export can be used to export the following master data:
Subtables: Item variants, Item units as well as Item references.
The setup is done with the EDX setup.
At the beginning, the necessary setups are done via the setup wizard. This setup wizard can be called up via the EDX Setup menu ribbon ("More options" > "Action" > "Setup" > "EDX setup wizard"). The EDX setup wizard is started. Via the selection "General" the required document types as well as number series are created.
EDX Document types#
After setup via the setup wizard, the following document types are available:
|BASE CUSTOMER||Basis debtor export||Based on|
|BASE ITEM||Base article export||Based on|
|BASE VENDOR||Base Vendor Export||Based on|
Setting up the document types#
For each EDX partner different voucher types can be defined. With the "EDX voucher setup" the previously created voucher types are assigned to the EDX partner as well as configured.
The "Field settings for document verification" function in the EDX document setup card ribbon allows you to configure which fields are to be exported from the associated master data table.
|Table name||Specifies the table name for which the master data is to be transferred. For example, "Article" or a sub-table of the article, such as "Article variant".|
|Field name||Specifies the respective field name for which the master data is to be transferred.|
|Validation sequence||The validation order sets the element order in the XML output message.|
|Default value||This option is not available for the master data export|
|Create field content||Specify which fields will be exported.|
Master data export#
The master data export takes place automatically as soon as a change is made to the master data record. Here, only field changes that were specified in the field settings are monitored.
The article description has been changed for an article. After the data record has been saved, the export takes place.
The output file contains the following elements:
Currently, only the calculated field "Stock" is provided. Calculated fields of the debtor or creditor are not provided by this AddOn, but can be implemented in the project.
Bulk data export#
At the beginning of a project, a function is usually needed to export all records of a table.
This can be controlled via the "Collective item" option within the document setup.
As soon as you activate the switch, all records of the table will be exported during the next data export. Afterwards, the "Collective export" option will be deactivated automatically.
EDX OpenTrans 1.0#
With the EDX AddOn OpenTrans 1.0 the following OpenTrans messages are provided:
- DISPATCHNOTIFICATION (shipping notification)
- INVOICE (Invoice)
- ORDER (sell order)
- ORDERRESPONSE (order confirmation)
The setup is done with the EDX setup.
At the beginning, the necessary setups are done via the setup wizard. This setup wizard can be called up via the EDX Setup ("More options" > "Action" > "Setup" > "EDX setup wizard") menu ribbon. The EDX Setup Wizard is started. Via the selection "General" the required message types as well as number series are created.
EDX Document types#
After setup via the setup wizard, the following message types are available:
|BASE CUSTOMER||Base Customer Export||Outgoing|
|BASE ITEM||Basic Article Export||Outgoing|
|BASE VENDOR||Basic Vendor Export||Outgoing|
Setting up the document types#
The message types listed above are then assigned to an EDX partner.
The field setting is only available for the OpenTrans message "OT1.0 SALES ORDER". See "Document check field setting".
The processing of OpenTrans 1.0 messages is done in EDX standard. Incoming sales orders are provided as "EDX sales order". The order confirmation can be created via the associated Microsoft Dynamics 365 Business Central1 sales order. The sales delivery as well as sales invoice can be sent manually or automatically.