Also called the O2C cycle, Order-to-cash is how your business receives, processes, manages, and completes orders. It begins from the time an order takes place and includes each step of the delivery and payment process. In this case, MS Dynamics 365 Supply Chain Management (D365 SCM) represents our backend.
This particular Accelerator contains prebuilt Schemas, Rulesets, Business Processes, and other resources used for development, deployment/execution, and testing. This includes mapping tools specific to several business flows as part of this Accelerator. Finally, there are also resources necessary to display data on several Cockpit monitoring pages.
Supported Integration Flows
Pre-built Integration Flows:
- 850 (Sales Order): Integration flows in CIC are provided to receive X12 850 (Purchase Order) from the Trading partners and create the corresponding Sales Order in D365SCM.
- 855 (Sales Order Confirmation) and 856 (Advanced Shipment Notice): Once the Order is confirmed, and fulfilled using D365SCM Advanced Warehouse, the integration flow automatically retrieves details from D365 SCM and creates the respective outbound documents like X12 855 (PO Acknowledgement) and X12 856 (ASN).
- 810 (Invoice): Once the Invoice is created for the Order in the D365 SCM, Accelerator has the project to retrieve the Invoice from the D365 SCM which generates the X12 810 (Invoice) document. All the flows will also have the respective X12 997 (Func Ack) flow and outbound EDI validations included.
- 940(Warehouse Shipping Order), also known as Warehouse Shipping Order, is commonly sent by Sellers/Suppliers to third-party logistics providers. It acts as a formal request for shipment of goods from a remote Warehouse to the buyer’s location. CIC receives X12 850 (Sales Order) from the Trading partner and creates the corresponding Sales order in D365SCM. The same D365 SCM Sales order XML record is sent to CIC where X12 940 is generated and sent to the warehouse trading partner.
- 846(Inventory advice) outbound also known as Inventory Inquiry/Advice provides updates regarding Inventory Levels, Stock status & availability. This is a bi-directional transaction set and it can be sent by either the trading partner or the Customer. In the current phase of the accelerator, CIC receives inventory XML from customer D365 SCM ERP and creates the corresponding Inventory EDI X12 for a trading partner.
- 856 ASN (Shipment) 3PL: In a few cases, D365SCM customers don’t have the Advanced warehouse module, and a third-party trading partner is responsible for sending Warehouse shipping advice (EDI X12 945 v4010 version) to the seller (ERP owner). The same X12 945 data can be used to generate EDI X12 856 for the buyer or trading partner. In such scenarios, ASN data is not staged in D365SCM. Instead, Warehouse Shipping Advice (945 data) is used to create Advanced Ship Notice(856 data) NOTE - The existing accelerator does not process the Warehouse shipping advice data (EDI 945) in D365SCM. It just uses this data to convert it into ASN EDI 3PL. Above inbound configuration is a prerequisite for creating ASN using 3PL trading partner 945 information).
- EDI 870 (Order Status Report): This document type is sent by the vendor or supplier as a response to an EDI 869 Order Status Inquiry provided by a trading partner and reports the current status of the 850 Purchase Order in question. The 870 Order Status Report can be used to report on the status of the requirement forecast, the entire purchase order, and selected items, products, and services of a purchase order. CIC receives X12 850 (Sales Order) from the Trading partner and creates the corresponding Sales order in D365. The same D365 Sales Order XML record is pulled by CIC where the X12 870 is generated and sent to the trading partner.
EDI 875 (Grocery Products Purchase Order): This document type is used by Grocery wholesalers and retailers to place orders for finished goods from a supplier. EDI 875 Grocery Products Purchase Order and EDI 850 purchase order are similar. EDI 875 enables a grocer or retailer to order goods from a manufacturer, wholesaler, or other suppliers.
EDI 820 (Payment order/remittance): This document type is used to confirm payment details or advise the seller of any adjustments to the payment amount. Usually, an 820 is jointly sent along with the payment itself via electronic funds transfer.
EDI 860 (Sales order change): This document type, also known as a Purchase Order Change Request, is sent from a buyer to a seller when the buyer needs to make changes to their EDI 850 Purchase Order. The EDI 860 is used to update existing sales orders. It can be used to add, update, and delete line items, and modify some header-related information.
- EDI 880 (Grocery Products Invoice): This document type, also known as a Grocery Products Invoice, is sent by a grocery supplier to a buyer, such as a grocery store, to bill for goods or services.
- EDI 865 (Order change acknowledgment): This document type, also known as a Purchase Order Change Acknowledgement/Request, is a seller-initiated transaction set used to communicate with trading partners about an existing purchase order confirmation.
- EDI 812 (Credit/Debit Adjustments): This is a trader partner-generated request used to request adjustments made to a particular payment.
Integration Design Specification: This is a default mapping template for a Transaction between source and target ecosystem entities. The Integration Design Specification describes the transaction type, Data Flow direction, source data, target data, and relevant application version(s). It also includes applicable B2B/API elements and mapping rules. The template helps in documenting any changes to the template integration based on your specific requirements.
Multiple Trading Partner Onboarding: The design lets you onboard several Trading Partners at once using the Wizard.
Email notification for unknown Trading Partner: If the Inbound/Outbound payloads are received where no matching configurations are found, then an email notification will be generated.
EDI message validations:
- Duplicate Inbound messages The Accelerator has the logic to handle any duplicate EDI data that is retrieved from the Trading partner. If need be, this can be customized per partner or per doctype.
- Inbound/Outbound EDI Data validation Accelerator is enabled to catch any invalid EDI syntaxes in both Inbound and Outbound flow. The execution will be stopped if there are any syntax errors. The settings can be changed so that execution does not stop.
Error Handling and Ticket Creation: Accelerator ensures all the processing failures are logged as tickets and marked as Issues in the Cockpit.
Out-of-the-box Cockpit visibility: Accelerator is already enabled with the resources necessary to display data in several Cockpit monitoring pages.
- The Message Details view provides the life cycle of an Order until the Invoice has been generated. The Accelerator also uses charts to monitor various transactions.
- Dashboard > Chart transactions: Below are the screenshots of the charts from the dashboard for 850, 855, 856, 810, 812, 846, 940, 870, 875, 820, 860, 880 and 865. Details about the count of messages translated are displayed.
What is Not Supported
- The Accelerator currently supports X12 EDI Version 4010 only.
- For Ship Notice (X12 856) advanced warehouse module configuration in D365 SCM, only SOI hierarchical structure is supported currently.
- ASN items should be enabled with advanced warehouse module configuration in D365 SCM for non-3PL transaction sets.
- For Ship Notice (X12 856) generated using EDI 945 3PL document in D365 SCM, only SOPI hierarchical structure is currently supported.
- EDI document type Warehouse Shipping advice translation and processing are not in scope for the current release.
- The Accelerator supports only integration for the documents which are processed in CIC. You cannot use the Accelerator for the integration of non-CIC documents. For example, you cannot create an invoice, ASN, and confirmation record for an Order that was not processed by CIC.
- Inventory data from D365 SCM supports full push mechanism instead of incremental pushes. It means the entire item data from the system is synced to EDI TP files instead of just the modified data.
- Inventory data being pulled from D365 SCM contains entire product stock data from the ERP and doesn’t distinguish between EDI versus non-EDI data.
Detailed documentation is provided on the project structure and object-level details that are in the Accelerator. Please refer to the Workflow and Project Details for X12 O2C <> D365 SCM Accelerator document provided in
com.cleo._customer_.edid365scm project, under the docs folder.
Please sign in to leave a comment.