MuleSoft Accelerator for Consumer Goods

Enable a single view of your sales orders by simplifying connectivity between ERP, CRM, Loyalty Management Cloud, Data Cloud and POS system

Overview
- Description
- Glossary
- Solution overview
- Assumptions and constraints
- High-level architecture
- Activity diagram
- Processing logic
- Successful outcome
See also
- Downloadable assets

The Sales Order Sync use case enables retail developers to create and update sales orders across disparate systems. Simplify connectivity between POS,ERP, CRM, Loyalty Management Cloud and Data Cloud with pre-built APIs, connectors, and implementation templates. This solution streamlines manual processes and eliminates duplication.

Retailers can connect sales orders to help calculate the total lifetime value of a customer across multiple channels. Syncing sales orders also helps retailers provide better service experiences.

Description

The sales order sync use case enables retail developers to create and update sales orders across relevant applications, regardless of which application the order is created in and where it is fulfilled.

The sales order sync achieves the following goals:

• Support the creation of sales orders across relevant applications, inclusive of Global Data Management System (Salesforce), POS, Loyalty Management Cloud, Oracle EBS and SAP S/4 HANA.
  • Support the creation of Global ID and ID attribution.
• Orchestrate controlled updates across designated applications.
• Link sales orders with customers and products using global identifiers.

Glossary

Solution overview

1. Capture new sales orders published from POS.
2. Capture sales order updates made in SAP S/4HANA.

3. Sales order creation and updates will be captured in Global Data Management (Salesforce).

   • All updates will be reflected in Salesforce first to establish the ID graph.
   • Orders will be associated with the global customer ID in Salesforce.

4. New or updated orders will be synchronized with the same downstream systems.

   • Global identifier from Salesforce will be recorded in the other systems.

5. The global identifier will be recorded back to the system that published the update, if it was not provided.

6. CIM entities supported (system agnostic): SalesOrder, SalesOrderProduct* (you can have multiple products for a given order), Customer, Individual.

7. Primary criteria used to match an existing sales order in other systems, in order of priority:

   • Global identifier.
   • External identifier specific to target system.

8. If the customer profile could not be found, or if not given with the order at all, the order will be associated with a predetermined generic customer profile. This profile must be identified and/or created ahead of time (see below).

9. In target systems, a new order will be created if not matched to an existing one.
10. Update errors will be reported in the logs and sent to the appropriate dead-letter queue only; no conflict resolution support will be implemented.

Assumptions and constraints

The following will be used to guide or constrain the solution design at a high level:

• The Cloud Information Model (CIM) will be used as the canonical model for all business types; see the CIM usage guidelines in that asset.
• Global identifiers will be maintained in Salesforce. Wherever possible, these will be assigned as external identifiers in target systems.
• References to the global IDs will be reflected in downstream systems using custom properties to avoid conflicts with the usage of other external identifiers.

High-level architecture

Activity diagram

Processing logic

The primary handling and orchestration of sales orders will be implemented in the Orders Process API. This process can be described as follows:

Global Data Management updates

1. If a customer profile was given with the sales order, find a matching entry in Salesforce. If a single match is found, associate the global customer profile with the order.
2. If no match is found, or if a customer profile was not given, associate the order with the predefined generic customer profile.

3. Find a matching sales order entry in Salesforce. The lookup will be done by attempting to match on the following criteria, in sequential order, returning once a match has been found:

   • Global Identifier (if provided)
   • External Identifier (of source system)

4. If a single match is found:

   • Retrieve the existing sales order
   • Apply the incoming updates and save them back to Salesforce
   • If not matched on external identifier, associate it with the sales order
   • Invoke APIs to update the downstream systems (see below)
   • Associate missing external identifiers back to Salesforce

5. If no match was found:

   • Create a new sales order in Salesforce
   • Associate external identifier of source system with the sales order
   • Invoke System APIs to update the downstream systems (see below)
   • Associate new external identifiers back to Salesforce

Downstream system updates

The replication of sales order updates to downstream systems follows a similar process as for Salesforce. The following steps apply to all downstream systems:

1. Assign the customer identifier(s) specific to the target system to the downstream order details

   • External ids should include Salesforce and the system(s) specific to the downstream API being invoked

2. Find a matching sales order in the target. The lookup will be similar as for Salesforce but using the following criteria, also in order by priority:

   • Primary identifier in target system (if one has been associated)
   • Global identifier from Salesforce

3. If a single match is found:

   • Retrieve the existing sales order and apply the incoming updates
   • If not matched on global identifier, associate it with the entity
   • Save the updates back to the target system

4. If no match was found:

   • Create a new entity in the target system
   • Associate the global identifier with the new entity
   • Report the system identifier of the new entity to the parent process

Successful outcome

After successfully completing the update processing for all target systems, the following conditions will be met:

1. Salesforce holds a record of the sales order, associated with a customer (may be the generic one)
2. All target systems will hold at least some minimal representation of the same
3. The entity created/updated in each system will reference the global identifier from Salesforce
4. Salesforce holds a list of all external identifiers associated with the sales order
5. A 360-degree view of the order can be constructed by first retrieving the global copy from Salesforce, and then from all associated downstream systems

---

back to top

Sales order create sync from POS

Overview

This use case records new orders published from POS via an event listener.

Before you begin

The Getting Started with MuleSoft Accelerators guide provides general information on getting started with the accelerator components. This includes instructions on setting up your local workstation for configuring and deploying the applications.

Workflow

1. The use case is triggered when a sales order is created in POS.
2. The PredictSpring Event Listener converts the sales order data to the CIM format and places it in a queue.

3. The Orders Process API consumes the message from the queue and orchestrates the following by invoking the appropriate system APIs for each system:

   • Create or update the sales order in Salesforce with an associated global ID.
   • Create or update the sales order in SAP S/4HANA with an external ID that links to the global ID in Salesforce.
   • Create or update the sales order in Oracle EBS with an external ID that links to the global ID in Salesforce.
   • Create or update the sales order in Loyalty Management Cloud with an external ID that links to the global ID in Salesforce.
   • Create or update the sales order in Data Cloud with an external ID that links to the global ID in Salesforce.
   • Update the sales order in Salesforce with a list of external IDs that link the order to its corresponding profiles in SAP S/4HANA, Oracle EBS, Loyalty Management Cloud and Data Cloud.

Systems involved

• POS
• Salesforce
• SAP S/4HANA
• Oracle EBS
• Loyalty Management Cloud
• Data Cloud

Setup instructions

Generic customer profile

As mentioned above, the Orders Process API will associate any anonymous orders with a predefined generic customer profile. The preferred way to set this up is to create a new customer directly in the preferred system (e.g., Salesforce) for this purpose and have it automatically sync to all downstream systems that are configured as part of Use case 1 - Customer profile sync. The Salesforce identifier must then be referenced in the appropriate configuration property of the API.

Salesforce configuration

Follow the Salesforce Customization Guide to create custom fields and enable Person Accounts.

SAP S/4HANA configuration

Follow the setup instructions in the SAP S/4HANA Setup Guide.

---

back to top

Downloadable assets

Accelerator System APIs

• RCG Loyalty Management Cloud System API| API Specification | Implementation Template
• RCG Data Cloud System API | API Specification | Implementation Template
• SAP S/4HANA Orders System API | API Specification | Implementation Template
• RCG Oracle EBS Order System API | API Specification | Implementation Template
• Accelerator Salesforce Global Order System API | API Specification | Implementation Template
• Accelerator Salesforce Global Party System API | API Specification | Implementation Template

Accelerator Process APIs

• Accelerator SalesOrders Process API | API Specification | Implementation Template
• Accelerator Customers Process API | API Specification | Implementation Template

Accelerator Listeners

• RCG SAP Event Listener | Implementation Template
• RCG POS Event Listener | Implementation Template