Sign in
< Back to Top

Prerequisites for D365 SCM

The following prerequisites should be met before configuring and using this Accelerator.

  1. D365SCM accelerator projects should be checked out using the template wizard project. Please follow these initial Setup steps before continuing.
  2. Once the projects are checked out using the wizard, ensure that B2BCloudAdminEmail global variable is updated to either the customer's email id or test@cleo.com. This ensures that no tickets are created in the Cleo Support Zendesk queue.

  3. D365 ERP instances should be configured with certain customizations to D365 SCM entities and fields. The customization package should be deployed in the customer's Dynamics instance as described in the steps to install D365 SCM Package in Customer's D365 instance. Complete this before proceeding to the next step.
  4. In the D365 SCM ERP instance, perform these steps:
    1. Turn on Create error file in Data Management Framework parameters.

    2. Refresh the Entity list.

    3. Create data projects in D365 SCM.  
    4. Create the required Connector Project in the CIC Studio Workspace before running the Cloud Connector wizard setup. The connector name should be: com.cleo.cic.connector.d365scm and should contain these entities:
      • Salesorderheadersv2
      • Salesorderlines
      • Cicsalesorderconfirms
      • Datamanagementdefinitiongroupdetails
      • Cicsalesorders
      • Cicoutboundshipmentheaderentity
      • Cicsalesinvoices
      • Datamanagementdefinitiongroups
      • Salesorderheaders
      • Shippingcarriers

        Prereq_D365ScmSelectEntities.png

    Notes:

    • Item Number - Any Product ID field (PO107/PO109/PO111/PO113/PO115/PO117/PO119/PO121/PO123/PO125) preceded by the Qualifier “VN / MG / VC / UP” will be considered as an item number which is already present in D365 SCM and mapped to the field - SALESORDERHEADERV2ENTITY/SALESORDERLINEV2ENTITY/ITEMNUMBER.
    • For Ship Notice (X12 856) (generated using D365 SCM Advanced Warehouse module), only SOI hierarchical structure is supported currently. ASN items should be enabled with advanced warehouse module configuration in Dynamics 365 SCM.
    • For Ship Notice (X12 856) (generated using Warehouse Shipping advice (945 sent by 3PL trading partner), only SOPI hierarchical structure is supported currently.
    • For 3PL ASNs generated from 3PL Warehouse 945 EDI documents, it is assumed that the ASN is sent on behalf of the Seller (D365SCM  ERP owner) and the same information is reflected on ISA, GS enveloper level sender details in X12 856.
    • For Warehouse shipping orders, data in D365 SCM is taken from sales order entity data itself. There is no dedicated entity for warehouse shipping orders in D365 SCM.
    • Customer for inventory is identified based on warehouse id. Each warehouse id is expected to be assigned to only one customer id. Partner reference table should not contain multiple records for the same warehouse id.  
    • The partner table should be populated with appropriate warehouse and customer id records before running inventory synchronization. See Reference Table Configuration to learn how to update the table.
    • This customer reference table process inserts only the customer account ids that are not present in the table already. If the customer account id for a given user is already present in the REFTABLES"."D365_SCM_Partners", then the existing record is treated as duplicate and skipped for the update.
    • Inventory data from D365 SCM supports full push mechanism instead of incremental pushes. This means the entire item data from the system is synced to EDI TP files instead of just the modified data. 
    • In order to differentiate between buying trading partner entities and warehouse trading partner entities, trading partner projects should be uniquely configured for buying trading partners and warehouse trading partners. See Trading Partner Project Configuration (using the Wizard) for more info.
    • 870 Order status report uses sales order composite entity (DMF framework).
      1. Customers can pull orders based on filters that suit their use case. The 870 Accelerator is not restricted to using a particular filter for pulling order reports
      2. Since the orders are pulled based on customer use cases and filters, no special custom field/ flag has been introduced for checking duplicate order report processing
    • “CICGROCERYSTATUS” flag is set to “YES” in 875, This flag is used to distinguish normal POs 850 from Grocery POs 875s. 
      1. CICStatus” flag is updated as “PENDING”, This is used to limit duplicate order processing. After being processed, the order status is updated to COMPLETED (status is updated to FAILED in case of failure.)
      2. Grocery orders are merged as one XML payload and submitted to D365 SCM in a batch using Data management framework APIs.
    • Payment orders or 820s are imported in Dynamics as unit XML message files and are not imported as batch files.  820 implementation also uses data management framework APIs
    •  Purchase order changes(860s) at the sales order header and detail level are updated in SCM with help of OData APIs. The order changes are processed one at a time and are not imported as batch files  
    • 880s: Grocery status flag set in 875 as YES during 875 processing. This flag is used to distinguish normal POs 850 from Grocery POs 875s. Grocery Invoices are filtered in SCM using CICGroceryStatus=YES and CICStatus =PENDING. After being processed, the invoice status is updated to COMPLETED (status is updated to FAILED in case of failure). Grocery invoices are exported in D365 SCM with help of data management framework APIs
    • The Change Order status flag is set in the 860 as YES during 860 processing. This flag is used to distinguish normal POs (850) from Order changes (860s). Purchase Order changes are filtered in D365 SCM using CICOrderChangeStatus=YES and CICStatus =PENDING. After being processed, the Order CICStatus is updated to COMPLETED. The status is updated to FAILED in case of failure. Purchase Order Changes are exported in D365 SCM with help of data management framework APIs.
    • 812 Credit/Debit adjustments are recorded in D365 SCM as Sales Order Return documents. These documents can be later financially adjusted manually by the customer's financial audit team. 812 documents are imported into D365 as unit XML message files and not as batch files. 812 implementation uses data management framework APIs. 812 DMF framework uses a custom composite entity and no custom fields.

Related articles

Comments

0 comments

Please sign in to leave a comment.