direct-store-delivery integrating consumer goods mobile oracle customer experience … · 2018. 11....

Oracle Customer Experience CloudIntegrating Consumer Goods MobileDirect-Store-Delivery

Release 13 (update 18C)

Oracle Customer Experience CloudIntegrating Consumer Goods Mobile Direct-Store-Delivery

Release 13 (update 18C)Part Number F11234-01Copyright © 2011-2018, Oracle and/or its affiliates. All rights reserved.

Authors: Iqtidar Hussain, Meghna Neogi, Alekhya Sen Gupta

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected byintellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast,modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, ordecompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them tous in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then thefollowing notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulationand agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operatingsystem, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictionsapplicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use inany inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerousapplications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. OracleCorporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks orregistered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks ofAdvanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. OracleCorporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, andservices unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for anyloss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreementbetween you and Oracle.

The business names used in this documentation are fictitious, and are not intended to identify any real companies currently or previously in existence.


Contents

Preface i

1 About This Guide 1Audience and Scope ................................................................................................................................................ 1

Related Guides ......................................................................................................................................................... 1

2 Introduction 3Integration: Overview ................................................................................................................................................. 3

3 Integrating Routes 5Integrating Routes with Consumer Goods Direct-Store-Delivery Processes: Overview ............................................... 5

Configuring Integration Flows for Integrating Routes ................................................................................................. 5

Integration Tables and Key Fields for Integrating Routes ........................................................................................... 6

4 Integrating Route Inventory 9Integrating Route Inventory with Consumer Goods Direct-Store-Delivery Processes: Overview .................................. 9

Configuring Integration Flows for Route Inventory ................................................................................................... 10

Integration Tables and Key Fields for Route Integration ........................................................................................... 12

5 Integrating Orders 15Integrating Orders with Consumer Goods Direct-Store-Delivery Processes: Overview ............................................. 15

Configuring Integration Flows for Integrating Orders ................................................................................................ 16

Integration Tables and Key Fields for Integrating Orders ......................................................................................... 19

6 Integrating Shipments 25Integrating Shipments with Consumer Goods Direct-Store-Delivery Processes: Overview ........................................ 25

Configuring Integration Flows for Integrating Shipments .......................................................................................... 26

Integration Tables and Key Fields for Integrating Shipments .................................................................................... 27


7 Integrating Invoices 31Integrating Invoices with Consumer Goods Direct-Store-Delivery Processes: Overview ............................................ 31

Configuring Integration Flows for Integrating Invoices .............................................................................................. 31

Integration Tables and Key Fields for Integrating Invoices ....................................................................................... 32

8 Integrating Credit Lines 35Integrating Credit Lines with Consumer Goods Direct-Store-Delivery Processes: Overview ...................................... 35

Configuring Integration Flows for Integrating Credit Lines ........................................................................................ 36

Integration Tables and Key Fields for Integrating Credit Lines ................................................................................. 37

9 Integrating Payments 41Integrating Payments with Consumer Goods Direct-Store-Delivery Processes: Overview ......................................... 41

Understanding Payment Types for Integrating Payments ........................................................................................ 42

Configuring Integration Flows for Integrating Payments ........................................................................................... 43

Integration Tables and Key Fields for Integrating Payments ..................................................................................... 43

10 Integrating Store Credits 47Integrating Store Credits with Consumer Goods Direct-Store-Delivery Processes: Overview .................................... 47

Configuring Integration Flows for Integrating Store Credits ...................................................................................... 48

Integration Tables and Key Fields for Integrating Store Credits ................................................................................ 49

11 Integrating Empty Containers 53Integrating Empty Containers with Consumer Goods Direct-Store-Delivery Processes: Overview ............................. 53

Configuring Integration Flows for Integrating Empty Containers ............................................................................... 54

Integration Tables and Key Fields for Integrating Empty Containers ......................................................................... 55


Preface

i

PrefaceThis preface introduces information sources that can help you use the application.

Using Oracle Applications

Using Applications HelpUse help icons to access help in the application. If you don't see any help icons on your page, click your user imageor name in the global header and select Show Help Icons. Not all pages have help icons. You can also access OracleApplications Help.

Watch: This video tutorial shows you how to find help and use help features.

You can also read Using Applications Help.

Additional Resources

• Community: Use Oracle Cloud Customer Connect to get information from experts at Oracle, the partnercommunity, and other users.

• Guides and Videos: Go to the Oracle Help Center to find guides and videos.

• Training: Take courses on Oracle Cloud from Oracle University.

ConventionsThe following table explains the text conventions used in this guide.

Convention Meaning

boldface Boldface type indicates user interface elements, navigation paths, or values you enter or select.

monospace Monospace type indicates file, folder, and directory names, code examples, commands, and URLs.

> Greater than symbol separates elements in a navigation path.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website.

Videos included in this guide are provided as a media alternative for text-based help topics also available in this guide.

https://fusionhelp.oracle.com/

https://fusionhelp.oracle.com/

https://apex.oracle.com/pls/apex/f?p=44785:265:0::::P265_CONTENT_ID:10552

https://apex.oracle.com/pls/apex/f?p=44785:265:0::::P265_CONTENT_ID:10552

http://www.oracle.com/pls/topic/lookup?ctx=cloud&id=OACPR2531440

https://appsconnect.custhelp.com/

http://docs.oracle.com/

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=906

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc


Preface

ii

Contacting Oracle

Access to Oracle SupportOracle customers that have purchased support have access to electronic support through My Oracle Support. Forinformation, visit My Oracle Support or visit Accessible Oracle Support if you are hearing impaired.

Comments and SuggestionsPlease give us feedback about Oracle Applications Help and guides! You can send an e-mail to:[email protected].

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

mailto:[email protected]


Chapter 1About This Guide

1

1 About This Guide

Audience and ScopeThis guide provides information about how to integrate back end systems such as supply chain, accounting, or ordermanagement systems with the Direct-Store-Delivery processes in Oracle Customer Experience Cloud for Consumer Goodsmobile application.

This guide describes how the integrated applications work with consumer goods mobile and the configurations that you mustdo to support the integrated business processes.

Related GuidesRefer to the related guides listed in the following table to understand more about the integrations covered in this guide.

Title Description

Using Sales for Consumer Goods

Describes the business flows and functionality in retail execution and trade-promotion executionareas, and how you can perform your day-to-day operations in these areas.

Getting Started with Implementing Salesfor Consumer Goods

Describes how to set up and configure Oracle Sales Cloud for Consumer Goods either whileimplementing or after implementing Oracle Sales Cloud.

Using CX Retail Execution Mobile

Describes how to perform tasks related to retail execution and trade promotions management usingconsumer goods mobile application.

You can access these guides on Oracle Help Center on https://docs.oracle.com/en/.


Chapter 1About This Guide

2


Chapter 2Introduction

3

2 Introduction

Integration: OverviewThis topic provides information about the Direct-Store-Delivery (DSD) flows available for integration in Oracle CX RetailExecution Mobile.

DSD enables your sales team to deliver goods directly for your customers using CX Retail Execution Mobile. You can use thismobile application in connected or disconnected mode for anytime, anywhere access to key information about customers,orders, route inventories, promotions, and so on.

To use DSD processes you must integrate them with your back end systems such as supply chain, accounting, or ordermanagement systems. When fully integrated, you can perform, track, measure, and manage your transactions at each stageof the delivery process, starting from checking your appointments to completing your visits, for better business results.

The following consumer goods DSD flows are available for integration:

• Integrating Routes: Covers the integration of route assignments in consumer goods with a route planning andoptimization system.

• Integrating Route Inventory: Covers the integration of CX Retail Execution Mobile with a supply chain system tomanage route inventories.

• Integrating Orders: Covers the integration of CX Retail Execution Mobile with order management system to manageorder requests and order statuses.

• Integrating Shipments: Covers the integration of CX Retail Execution Mobile with a supply chain system to enableshipments.

• Integrating Invoices: Covers the integration of CX Retail Execution Mobile with Enterprise Resource Planning (ERP)accounting system for processing invoices.

• Integrating Credit Lines: Covers the integration of CX Retail Execution Mobile with an ERP accounting system tomanage credit lines and payments.

• Integrating Payments: Covers the integration of CX Retail Execution Mobile with an ERP accounting system tomanage payments.

• Integrating Store Credits: Covers the integration of CX Retail Execution Mobile with an ERP accounting system tomanage store credits.

• Integrating Empty Containers: Covers the integration of CX Retail Execution Mobile with an ERP system to manageempty containers.

The chapters in this guide describe each of these integrations in detail. To integrate your back end systems, you mustperform the configurations according to the instructions given in this guide.


Chapter 2Introduction

4


Chapter 3Integrating Routes

5

3 Integrating Routes

Integrating Routes with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers the integration of route assignments in CX Retail Execution Mobile with a route planning and optimizationsystem.

In CX Retail Execution Mobile, sales representatives must first check in to their assigned routes to carry out their activities forthe day. While the consumer goods application manages the route assignments, to perform route-based retail execution youmust integrate a route planning system to manage the account lineups and appointments for each such route assignment.

You can create or update route appointments using either consumer goods Web application or create theseprogrammatically in your route planning system.

The integrated route execution assigns the appointments to the sales representatives based on the route account lineup andtheir default route assignments. For example, a sales representative who is assigned route A, is assigned to the appointmentsfor the accounts on route A.

Here's how this integration works:

• The integrated system retrieves the default route assignments from consumer goods.

• Appointments for the route execution are created or updated based on the account lineups and the default routeassignments in consumer goods.

• The appointments for a route are assigned to the same sales representative who was assigned that route.

The following graphic shows the route scheduling integration flow.

Route Scheduling

Sales for Consumer Goods Integration

Route Execution

Default Assignments Route Assignments

Route Appointments

Route Account Line-ups



6

Configuring Integration Flows for Integrating RoutesThis topic covers the configurations that you must perform to enable the supported integration flows.

In the integrating system, configure the route-execution process to refresh or update the data, as applicable, each timeit runs. For example, the process must detect the changes to route assignments and assign the sales representativesaccordingly. You must run and complete the scheduling process for the next route execution before the mobile applicationstarts synchronizing data for the next route execution.

Integration Tables and Key Fields for Integrating RoutesThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store routeinformation:

• Route Allocation

• Activities

Route AllocationThe following table lists the key fields in the Route Allocation (__ORACO__RouteAllocation_c) staging table used for defaultroute assignments.

Key Fields API Names Description

Route

_ _ ORACO_ _Route_c

The route assigned by default to the salesrepresentatives.

Primary

_ _ ORACO_ _ SalesRepresentative_ c

The sales representative who is assigned theroute.

Resource

_ _ ORACO_ _Primary_c

Indicates whether the assigned resource isthe primary sales representative. Each route can have only one primary salesrepresentative. The primary route resourcemust also be the primary sales representativefor the route appointments.

ActivitiesThe following table lists the key fields in the Activity table used for appointments and tasks.



7

Key Fields API Names Description

Route

_ _ ORACO_ _Route_c

The route to which the appointment isassigned.

To import Activities from Oracle Sales Cloud, refer Oracle Sales Cloud Understanding File-Based Data Import and Exportguide on https://docs.oracle.com/cloud/latest/salescs_gs/docs.htm.



8


Chapter 4Integrating Route Inventory

9

4 Integrating Route Inventory

Integrating Route Inventory with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers the integration of CX Retail Execution Mobile with supply chain system to manage route inventories.

The CX Retail Execution Mobile captures and maintains the route-inventory transactions that occur during route execution.The supported inventory transactions are read-only in Oracle Sales Cloud and are of the following types:

• Restock for Shipment: Increases the route inventory with the quantity that is required for a shipment. It alsoprovides the sellable quantity of the transaction.

• Restock for Additional Inventory: Increases the route inventory with the quantity that is required due to reasonsother than shipment. It also provides the sellable quantity of the transaction.

• Delivery: Decreases the route inventory based on the quantity delivered in a shipment. It also provides the sellablequantity of the transaction.

• Damage: Changes the route inventory from sellable to unsellable. When the quantity of sellable inventory decreases,the quantity of the unsellable inventory is increased by the same amount.

• Loss: Decreases the route inventory based on the quantity of the inventory lost. It also provides the sellable quantityof the transaction.

• Recovery: Increases the route inventory based on the quantity of the inventory recovered. It also provides thesellable quantity of the transaction.

• Return: Increases the route inventory based on the quantity of the inventory returned. It also provides the sellablequantity of the transaction.

• Unload: This transaction decreases the route inventory based on the quantity of the inventory unloaded. It alsoprovides the sellable quantity of the transaction.

To update the inventory records periodically or after each route execution, you must use Supply Chain Management (SCM)system to process and refresh inventory position in the mobile application.

Depending on your business use case, you can first determine how you want to refresh your inventory records and thenconfigure your system accordingly.

Here's how this integration works when using the Maintaining Static Inventory Position method of calculating the inventorylevel:

1. The SCM system recalculates inventory using the Maintaining Static Inventory Position method and sends theupdated records to the consumer goods server.

2. The CX Retail Execution Mobile retrieves the refreshed inventory records from the consumer goods server to updatethe inventory position for the next route execution.

3. CX Retail Execution Mobile sends transaction records created during route execution to the consumer goods server.4. The consumer goods server prepares the transactions records and makes them available to the integrating SCM

system.



10

The following graphic shows the integration flow:

Route Inventory Integration

SCM

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail

Exec

utio

n M

obile

Starting Inventory

Staging Inventory Transactions Data

Calculating Inventory Position

Staging Inventory Data

Transactions

Transactions

Refreshed

In this integration, the mobile application calculates the inventory position as follows:

1. Reads the route-inventory level and the Last Processed Transaction Time Stamp from the Route Inventorystaging table.

2. Reads all transactions later than the Last Processed Transaction Time Stamp. See, Integration Tables and KeyFields.

3. Adds the transaction quantity of each transaction to the original product inventory level.

The inventory position thus calculated by the mobile application is temporary and is not sent to the consumer goods server.The inventory transactions that remove items are in the negative and those that add items are in the positive.

Configuring Integration Flows for Route InventoryThis topic covers the configurations that you must perform to enable the supported integration flows. It covers how you cantransfer data to or from Oracle Sales Cloud to the integrated application and the methods or strategies that you can use forupdating the route-inventory records.



11

Maintaining Static Inventory PositionIn the static inventory method, the mobile application uses the Route Inventory Transactions staging table to calculate theinventory position. This method is suitable when it's possible to ensure that the mobile device does not download partialinventory records.

Note: Before using this method, you must ensure that the mobile device and the integrating system are notperforming any read-write operation in the transactions table.

To maintain static inventory position:

1. Transfer all route inventory transactions from the Route Inventory Transactions table to the integrating system.2. The integrating system purges all route inventory and route inventory transactions and uploads the new route

inventory to the Route Inventory Transactions table.

For highly dynamic inventories, you must use the Maintaining Inventory Position Using Transactions method.

Maintaining Inventory Position Using TransactionsIn the transactions method, the mobile application uses only the Route Inventory Transactions table to calculate inventoryposition. This method is suitable where the inventory transactions between the mobile application and the back-officeinventory system happen throughout the day.

This integration method involves a bidirectional flow of transactions between the integrating system and the mobileapplication.

To maintain inventory position, the integrating system must insert the following transactions in the Route InventoryTransaction table:

• Restock for Shipment: Records the transfer of inventory from the distribution center to the route for delivery to aspecific customer.

• Restock for Additional Inventory: Records the transfer of inventory from the distribution center to the route incases where the inventory is not allocated to a specific customer.

• Unload: Records the transfer of inventory from the route to the distribution center.

Note: Transactions method does not use the Route Inventory table.

The mobile device calculates the inventory position by first totaling all restock transactions and then deducting from it all theunload transactions.

Maintaining Inventory Using Static Inventory Position and TransactionsYou can also maintain the inventory position by using a mix of static inventory method and the transactions method.

To maintain inventory using both Route Inventory and Route Inventory Transactions table:

1. Set up the route by initializing its Route Inventory staging table and clearing its Route Inventory Transaction stagingtable.

2. Insert the following transactions in the Route Inventory Transaction table:

a. Restock for Shipment: Records the transfer of inventory from the distribution center to the route for deliveryto a specific customer.



12

b. Restock for Additional Inventory: Records the transfer of inventory from the distribution center to the routein cases where the inventory is not allocated to a specific customer.

c. Unload: Records the transfer of inventory from the route to the distribution center.

Periodically reconcile the route inventory transactions into the Route Inventory staging table.

You can use the Static Inventory method to reconcile the transactions if the transactions can be downloaded, processed,and deleted. You must ensure that during this process the mobile application is not reading the information from the RouteInventory staging table.

In cases where the mobile application is simultaneously reading the Route Inventory staging table, you must configure theSupply Chain Management (SCM) system to do the following:

1. Read the current route inventory level for a product and note the Last Processed Transaction Time Stamp ofthose products.

2. Retrieve and process the route inventory transactions for products where the Creation Time Stamp is later thanthe Last Processed Transaction Time Stamp.

You must configure the inventory system to process the retrieved transactions by descending order of the CreationTime Stamp, which means that the most recent transaction is processed first. To prevent the inventory system fromprocessing in-progress transaction records based on the most recent Creation Time Stamp, you must do either ofthe following configurations in the inventory system:

◦ Induce delay in processing the transaction record having the most recent Creation Time Stamp.

◦ Process transaction records up to but not including the most recent Creation Time Stamp.

Update the Last Processed Transaction Time Stamp with the Creation Time Stamp of the last processedrecord after the inventory level is updated. You must ensure that the same operation updates both the fields.

You can configure the integrating system to reconcile the records multiple times in a day.

Integration Tables and Key Fields for Route IntegrationThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store route inventoryinformation:

• Route Inventory

• Route Inventory Transactions

Route InventoryThe following table lists the key fields in the Route Inventory (__ORACO__RouteInventory_c) staging table, which contains theinformation about the current inventory.

Key Fields API Name Description

Route ID Product

Id _ _ ORACO_ _Product_c

The user keys that uniquely identify eachinventory record.



13


Total Quantity

_ _ ORACO_ _ TotalQuantity_ c

The quantity of inventory in a route.

Sellable Quantity

_ _ ORACO_ _ SellableQuantity_ c

The sellable subset of the total quantity ofinventory in a vehicle.

Unsellable Quantity

_ _ ORACO_ _ UnsellableQuantity_ c

The unsellable subset of the total quantity ofinventory in a vehicle.

Last Processed Transaction Time Stamp

_ _ ORACO_ _ LastProcessedTimestamp_ c

The last creation time stamp from the RouteInventory Transaction table. This time stampis used for calculating the inventory positionfor the route. See, Configuring IntegrationFlows on how this time stamp is used forrefreshing inventory position.

Route Inventory TransactionsThe following table lists the key fields in the Route Inventory Transactions (__ORACO__RouteInvTransDSD_c) staging table,which contains the information about the inventory transactions.


Route ID

Id

A unique and incremental databasesequence ID generated by Oracle SalesCloud when a record is created.

Creating Time Stamp

_ _ ORACO_ _CreatedOn_c

The date when the inventory transactionrecord was created.

Route ID Product

_ _ ORACO_ _ TransferRouteID_ c _ _ ORACO_ _Product_c

The keys that uniquely identify each inventorytransaction. These correspond to a Route IDand the associated product.

Transaction Date Transaction Type Transaction Quantity

_ _ ORACO_ _ TransactionDate_ c _ _ ORACO_ _ TransactionType_ c _ _ ORACO_ _ TransactionQuantity_ c

These fields describe how the route inventoryhas changed.



14


Chapter 5Integrating Orders

15

5 Integrating Orders

Integrating Orders with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers the integration of CX Retail Execution Mobile with order management system. The consumer goodsapplication enables sales representatives to capture order requests. To process the order requests further through order tocash business processes, you must integrate an order management system with the consumer goods application.

When fully integrated, you can capture order requests and track order fulfillment that can happen either through direct deliveryor through the integrated shipment process. The integration enables you to track the status of orders based on revisions,returns, cancellations, and so on to address customer queries related to orders.

Here's how the order integration process works:

1. CX Retail Execution Mobile captures order requests and transfers the unprocessed requests to the staging table.2. The integrating system picks up the unprocessed requests and updates the status of each order based on the type

of request.3. CX Retail Execution Mobile picks up the order status.



16

The following graphic shows the order integration flow.

Order Integration

ERP

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail

Exec

utio

n M

obile

Order Capture andDirect Fulfillment

Order Request Staging Tables

Process OrderOrder Status

Updates

Unprocessed Requests

Unprocessed Requests

Order Status Updates

Order Status Staging Tables

The order integration also uses information from other integrations such as route inventory, invoicing, and shipments. Forspecifics about those integrations, see the relevant chapters in this guide.

Configuring Integration Flows for Integrating OrdersThis topic covers how the participating applications can work together to support the integration flows. You can use this topicto configure the integration system based on how the consumer goods application manages the order requests and how itupdates the values in the staging tables based on the request type.

Types of Order RequestsThis section covers the types of order requests, and covers how the consumer goods application updates the staging tablesbased on the type of request.

The integrating system can use the following values to identify the type of order request:

New Order



17

In the Order Request table, the new order request has Revision Number of 1.

Update Order

In the Order Request table, an update order request has Revision Number greater than 1 and the Update Requested setto True. Additionally, corresponding order request lines are also generated with the new revision number.

Cancellation Order

In the Order Request Table, a cancellation order request has Revision Number greater than 1 and the CancellationRequested set to True. Additionally, corresponding order request lines are also generated with new revision number.

Note: Cancellation can be done only for the entire order and not for individual line items.

Return Order

In the Order Request table, a new order request with Revision Number of 1 and Order Type of Return is generated.Additionally, the products to be returned are captured as its order line requests. These products may or may not be from thesame order.

Direct Order (Auto-Sales)

In the Order Request table, a new order request with Revision Number of 1 is generated. Use the Use Quantity Deliveredat Creation in the Order Line Request table to identify whether the sales representative has fulfilled the entire order requestfrom the route inventory.

Direct orders or auto-sales orders are created and delivered immediately by the sales representative during route execution.The products delivered are captured as its order line requests using the field Quantity Delivered at Creation in the OrderLine Request table.

The integrating system must generate shipments and mark them as delivered using the field Quantity Delivered atCreation. The shipment is already being closed using the Quantity Delivered at Creation, so the integration must handlethe transactions for inventory delivery such that it does not trigger a double decrement.

Processing Order RequestsThis section covers how the integrating system identifies and processes the unprocessed order requests.

To retrieve order requests, the integrating system must do the following:

1. Read the value of the Process Status field to distinguish between unprocessed and processed orders. Forunprocessed orders, the value of the Process Status field is Ready to process.

2. Set the value of Process Status to Processed after processing the orders.

Updating Order Status Based on RequestsThis section covers how the integrating system updates the status of an order along with other fields in the staging tables.

You must configure the integrating system to update the order status each time an action is taken on a request. Ensure thatthe fields in the Order Status and Order Line Status staging tables are populated from the corresponding Order Request andOrder Line Request staging tables. Additionally, the Order Line Status records must be properly linked to the parent OrderStatus records using the internal ID of the Order Status record.



18

The following table describes how the integration must set the order status based on the action taken on an order.

On This Action Order Status is Set To Here's How

Order is read by integrating system and it canbe fulfilled

Booked

• In the Order Status table, a recordmust be created where the value ofStatus and Last Request Status isBooked.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status andLast Request Status is Booked.

Order is read by the integrating system and itcannot be fulfilled

Booking Rejected

• In the Order Status table, a recordmust be created where the value ofStatus and Last Request Status isBooking Rejected.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status andLast Request Status is BookingRejected.

Some of the order lines are delivered

Partially Delivered

• In the Order Status table, a recordmust be created where the value ofStatus and Last Request Status isPartially Delivered.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status andLast Request Status is PartiallyDelivered.

Note: For each order

line not delivered, create

a new Order Line Status

record with the previous

status value.

All the order lines are delivered

Delivered

• In the Order Status table, a recordmust be created where the value ofStatus and Last Request Status isDelivered.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status andLast Request Status is Delivered.

An update to order is requested throughorder revision

Booked or Partially Delivered Note: In an order revision,

multiple order lines may haveupdates. The integration doesnot support partial updates orupdates to only some of theorder lines in the order. Either allthe updates in an order revisionmust be accepted or all must berejected.



19

On This Action Order Status is Set To Here's How

If the updated order can be fulfilled:

• In the Order Status table, a recordmust be created where the value ofStatus is either Booked or PartiallyDelivered, as applicable, and LastRequest Status is Updated.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status is eitherBooked or Partially Delivered, asapplicable, and Last Request Statusis Updated.

If the updated order cannot be fulfilled:

• In the Order Status table, a recordmust be created where the value ofStatus is either Booked or PartiallyDelivered, as applicable, andLast Request Status is UpdateRejected.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status is eitherBooked or Partially Delivered, asapplicable, and Last Request Statusis Update Rejected.

Order cancellation request

Canceled or Canceled Rejected If the order can be canceled:

• In the Order Status table, a recordmust be created where the value ofStatus and Last Request Status isCanceled.

• In the Order Line Status table, arecord must be created for each orderline where the value of Status andLast Request Status is Canceled.

If the order cannot be canceled:

• In the Order Status table, a recordmust be created where the valueof Status is either Booked orDelivered, as applicable, and LastRequest Status is CanceledRejected.

• In the Order Line Status table, arecord must be created for eachorder line where the value of Statusis either Booked or Delivered, asapplicable, and Last Request Statusis Canceled Rejected.



20

Integration Tables and Key Fields for Integrating OrdersThis topic covers the tables and the key fields that you must use or configure to support the integration.

The creation and fulfillment of an order requires data flow between multiple systems that may work offline or independent ofeach other. The integration uses the following staging tables to store the order information.

• DSD Order Request

• DSD Order Line Request

• DSD Order Status

• DSD Order Line Status

DSD Order RequestThe following table lists the key fields in the DSD Order Request (__ORACO__OrderDSD_c) staging table. This table capturesand stores information about the order requests from telesales and the mobile application. The integrating system must readfrom this table to identify and process the revisions in order.


Account

_ _ ORACO_ _Account_c

The account to which the order belongs.

Order Type

_ _ ORACO_ _OrderType_c

Differentiates the types of orders.

Source System Source System Number

_ _ ORACO_ _OrderSS_c _ _ ORACO_ _OrderSSN_c

A unique combination for identifying orders.

• Source System: A unique identifierissued by the mobile device. Thismust be unique across differentoriginating systems.

• Source System Number: A uniquenumber within each source system.

Note: Source System

and Source System

Number of an order is

the same across Order

Request records and

Order Line Request

records.

Revision Number

_ _ ORACO_ _OrderRN_c

Represents the revisions of an order. Thismust start from 1 (when creating an order)and then incremented by 1 (for subsequentrevisions).



21


Note: Revision Number is the sameacross the order request and its orderline request for each revision. Everyrevision of an order includes all of itsline items.

Process Status

_ _ ORACO_ _ ProcessStatus_ c

Differentiates between new or processedorders.

Cancellation Requested

_ _ ORACO_ _ CancelRequestFlag_ c

Captures cancellation request.

Update Requested

_ _ ORACO_ _ UpdateRequestFlag_ c

Captures update request.

Creation Time

_ _ ORACO_ _ CreationTime_ c

Captures the time when the order wascreated.

Order

_ _ ORACO_ _Order_c (_ _ ORACO_ _Order_Id_c)

The foreign key to Order Rollup record of theOrder Request table. The Order Rollup object is internal to OracleSales Cloud for displaying a consolidatedorder record on the Web UI.

DSD Order Line RequestThe following table lists the key fields in the DSD Order Line Request (__ORACO__OrderLineDSD_c) staging table, which storesorder lines provided by the captured order request. The integrating system must read from this table to identify and processthe revisions in order.


Source System Source System Number Revision Number

_ _ ORACO_ _ OrderLineSS_c _ _ ORACO_ _ OrderLineSSN_ c _ _ ORACO_ _ OrderLineRN_c

The source system, source system numberand revision number of the correspondingOrder Request.

• Source System: A unique identifierissued by the mobile device. Thismust be unique across differentoriginating systems.

• Source System Number: A uniquenumber within each source system.

Note: Source System

and Source System

Number of an order is

the same across Order

Request records and

Order Line Request

records.



22


• Represents the revisions of an Order.This must start from 1 (when creatingan order) and then incremented by 1(for subsequent revisions).

Note: Revision Number

is the same across the

Order Request and its

Order Line Request for

each revision. Every

revision of an order

includes all of its line items.

Line Number

_ _ ORACO_ _ OrderLineLN_c

Uniquely identifies an order line of an orderwhen used together with Source System,Source System Number, and RevisionNumber.

Product

_ _ ORACO_ _Product_c (_ _ ORACO_ _ Product_Id_c)

The product of the order line.

Quantity

_ _ ORACO_ _Quantity_c

The quantity of the products in the order line.

Quantity Delivered at Creating

_ _ ORACO_ _ QuantDelAtCreate_ c

The quantity already delivered while takingthe order. Can be used for partial deliveries.

Order


The foreign key to order request of the OrderLine table.

Order Line

_ _ ORACO_ _OrderLine_c (_ _ ORACO_ _ OrderLine_ Id_c)

The foreign key to order line rollup of theOrder Line table.

The integrating system can uniquely identify orders using a combination of fields in cases where mobile devices may havegenerated the orders. These fields enable distributed systems to operate in situations where the Order ID is unknown.

The following fields are covered in the Order Request and Order Line Request tables:

• Source System

• Source System Number

• Revision Number

• Line Number

Note: These fields do not replace or invalidate the use of ID fields. Oracle Sales Cloud enforces that the ID fieldsare available, unique, and automatically populated for all the objects.

If the integrating system posts multiple Order Status revisions (with corresponding lines) for the same order, Oracle SalesCloud uses the latest revision for calculating the final status.



23

DSD Order StatusThe following table lists the key fields in the DSD Order Status (__ORACO__OrderStatusDSD_c) staging table, which capturesorder status updates from the order management system.


Order


The corresponding order request.

Order - Source System

_ _ ORACO_ _OrderSS_c

The source system of the correspondingorder request.

Order - Source System Number

_ _ ORACO_ _OrderSSN_c

The source system number of thecorresponding order request.

Order - Revision Number


The revision number of the correspondingorder request.

Revision Number

_ _ ORACO_ _RefOrderRN_c

The revision number of the order status. Thismust start from 1 and then increment foreach subsequent order status of an order.

Last Request Status

_ _ ORACO_ _ LastRequestStatus_ c

The status of the corresponding orderrequest.

Status

_ _ ORACO_ _Status_c

The final status of the order.

DSD Order Line StatusThe following table lists the key fields in the DSD Order Line Status (__ORACO__OrderLStatusDSD_c) staging table, whichstores information about the order lines based on the status update of the orders.


Order Line

_ _ ORACO_ _OrderLine_c

The corresponding order line request.

Order Line - Source System

_ _ ORACO_ _ OrderLineSS_c

The source system of the correspondingorder line request.

Order Line - Source System Number

_ _ ORACO_ _ OrderLineSSN_ c

The source system number of thecorresponding order line request.

Order Line - Line Number

_ _ ORACO_ _ OrderLineNumber_ c

The line number of the corresponding orderline request.



24


Order Line - Revision Number

_ _ ORACO_ _ OrderLineRN_c

The revision number of the correspondingorder line request.

Order Status

_ _ ORACO_ _ OrderStatus_c

The parent order status of the order linestatus.

Revision Number

_ _ ORACO_ _ OrderLineStatusRN_ c

The revision number of the order line status.

Last Request Status

_ _ ORACO_ _ LastRequestStatus_ c

The status of the corresponding order linerequest.

Status

_ _ ORACO_ _Status_c

The final status of the order line.


Chapter 6Integrating Shipments

25

6 Integrating Shipments

Integrating Shipments with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers the integration of CX Retail Execution Mobile with a supply chain system to enable shipments.

The consumer goods application maintains the details about inventory transactions. For the mobile application to sendthe shipments out for delivery, you must integrate it with a supply chain system to get the shipment details. Depending onyour business use case, you must configure the Supply Chain Management (SCM) system to process the captured orderrequests.

For more information about how to configure the integrating SCM application to transfer data to the consumer goods server,see Configuring Integration Flows.

Here's how this integration flow works:

1. The integration uploads the shipment data to consumer goods server and the consumer goods mobile applicationpicks it up.

2. The consumer goods mobile application delivers the shipments and creates corresponding inventory transactions.3. The consumer goods mobile application uploads these inventory transactions to the staging tables of the consumer

goods server.4. The integration system picks up the inventory transactions and uploads them to SCM. The following graphic shows

the shipment integration flow.



26

The following graphic shows the shipment integration flow.

Shipment Integration

SCM

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail

Exec

utio

n M

obile

Inventory Transactions

Stage Inventory Transactions

Update Inventory

Stage Shipment Data

Shipment

Transactions

Ready to process

Download

Transactions

Prepare Shipment

Delivery

Configuring Integration Flows for Integrating ShipmentsThis topic covers the configurations that you must perform to enable the supported integration flows. It covers how you cantransfer data to or from Oracle Sales Cloud to the integrated application and how shipment details are transferred from SCMto CX Retail Execution Mobile.

Transferring Shipment Details from SCM to CX Retail Execution MobileThe CX Retail Execution Mobile can read-only complete shipment records. To identify or capture completed shipments, thevalue in the Process Status field is used.

The Process Status field is a static pick list on the shipments header record in SCM. After the shipment headers and allshipment lines are created, SCM must set this Process Status field to Ready to process.

To transfer shipments, SCM must do the following:

1. Create a shipment header with Process Status as NULL.2. Retrieve Shipment ID of the shipment header.3. Create all shipment lines using the Shipment ID.



27

4. Update the Process Status in the shipment header to Ready to process.

Note: Shipment and Shipment Lines must not be updated for shipment headers in Ready to processstatus.

Setting the Delivery Status of Shipment in SCMWhen you deliver shipments using CX Retail Execution Mobile, corresponding inventory transactions are generated for eachshipment. You must configure SCM to identify and track whether the shipments were delivered by using the correspondinginventory transactions.

Integration Tables and Key Fields for Integrating ShipmentsThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store shipmentinformation:

• DSD Shipment

• DSD Shipment Line

DSD ShipmentThe following table lists the key fields in the DSD Shipment (__ORACO__ShipmentDSD_c) staging table used for storing shipmentheader information.


Shipment Number

RecordName

A unique alphanumeric key in SCM thatidentifies a shipment.

Account

_ _ ORACO_ _Account_c (_ _ ORACO_ _ Account_Id_c)

The retailer account to which the shipment isdelivered. You must ensure that this field iscorrectly set.

Order Number


The order for which the shipment wascreated.

Shipment Date

_ _ ORACO_ _ ScheduledDate_ c

The shipment date provided by SCM.

Legal Entity

_ _ ORACO_ _ LegalEntity_c (_ _ ORACO_ _ LegalEntity_ Id_c)

The manufacturer legal entity for theshipment.

Source System


Uniquely identifies the source for theshipment. Oracle Sales Cloud uses this keyto track shipment.



28


Source System Number


The unique number within each sourcesystem for a shipment. Oracle Sales Clouduses this key to track shipment.

Created On


This field must be set to 0 (zero) to identifythe new records from SCM.

DSD Shipment LineThe following table lists the key field in the DSD Shipment Line (__ORACO__ShipmentLineDSD_c) staging table used forstoring shipment line information.


Shipment Line Number

RecordName

A globally unique alphanumeric stringprovided by SCM for each shipment line.

Line Number

_ _ ORACO_ _ ShipmentLineLN_ c

A numeric and unique line number within ashipment.

Shipment

_ _ ORACO_ _Shipment_c (_ _ ORACO_ _ Shipment_ Id_c)

The shipment header associated with theshipment line.

Account


The retailer account to which the shipmentis delivered. Same as the Account field inthe Shipment header. This field must be setcorrectly.

Product


The product being shipped.

Quantity


The quantity of the product being shipped.

Source System

_ _ ORACO_ _ ShipmentLineSS_ c

Uniquely identifies the source for theshipment. Oracle Sales Cloud uses this keyto track shipment.

Source System Number

_ _ ORACO_ _ ShipmentLineSSN_ c

The unique number within each sourcesystem for a shipment. Oracle Sales Clouduses this key to track shipment.

Line Number

_ _ ORACO_ _ ShipmentLineLN_ c

The unique numeric line number within ashipment. Oracle Sales Cloud uses this keyto track shipment.

Created On


This must be set to 0 (zero) to identify thenew records from SCM.



29




30


Chapter 7Integrating Invoices

31

7 Integrating Invoices

Integrating Invoices with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers the integration of CX Retail Execution Mobile with Enterprise Resource Planning (ERP) accounting systemfor processing invoices.

In CX Retail Execution Mobile, sales representatives can generate and print invoices for deliveries. To further manage andprocess these invoices for accounting purposes, you must integrate your back-office accounting system with CX RetailExecution Mobile.

Here's how this integration works:

1. CX Retail Execution Mobile generates and transfers invoices to the consumer goods server.2. The consumer goods server prepares the invoices for the integrated accounting system to pick them up.3. The accounting system further manages and maintains the invoice data.

The following graphic shows the integration process flow.

Invoice Integration

Inte

grat

ion

- ER

P Ac

coun

ting

Syst

emC

onsu

mer

G

oods

Ser

ver

CX

Ret

ail

Exec

utio

n M

obile

Invoice

Stage Invoice

Manage Invoices and

Payments

Transfer

Ready to process



32

Configuring Integration Flows for Integrating InvoicesThis topic covers the configurations that you must perform to enable the supported integration flows. It includes theinformation about how the accounting system picks up the invoices generated by the CX Retail Execution Mobile.

Processing Invoices Created by CX Retail Execution MobileThe Process Status field in each of the generated invoices indicates whether the invoice has been picked up by theintegrating system.

You must configure the integrating ERP system to perform the following:

1. Read all invoice records where the Process Status is Ready to process.2. Read all invoice lines of the Ready to process invoices.3. Set the Process Status of those invoices to Processed.

Integration Tables and Key Fields for Integrating InvoicesThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store invoiceinformation:

• DSD Invoice

• DSD Invoice Line

DSD InvoiceThe following table lists the key fields in the DSD Invoice (_ORACO__InvoiceDSD_c) staging table used for storing invoiceheader information.


Invoice Number

RecordName

A unique alphanumeric key that identifies theinvoices generated by the mobile application.

Account


The account associated with the invoice.

Shipment

_ _ ORACO_ _Shipment_c (_ _ ORACO_ _ Shipment_ Id_c)

The shipment associated with the invoice.

Process Status

_ _ ORACO_ _ ProcessStatus_ c Indicates whether the invoice is ready to be

processed. Accounting system must process



33


only those invoices where this field value isReady to process.

Order Source System


The source application of the orderassociated with the invoice. The OrderSource System is picked up from theshipment for which the invoice was created.

Order Source System Number


The source application number of the orderassociated with the invoice. The OrderSource System Number is picked up fromthe shipment for which the invoice wascreated.

Order Revision Number


The revision number of the order associatedwith the invoice.

Order Number

_ _ ORACO_ _ OrderNumber_c

The order number of the order associatedwith the invoice. This value is picked upfrom the shipment for which the invoice wascreated.

Legal Entity


The manufacturer legal entity for all productsin an invoice.


_ _ ORACO_ _InvoiceSS_c _ _ ORACO_ _InvoiceSSN_c

These are the unique user keys for an invoicerecord generated by the mobile application.

DSD Invoice LineThe following table lists the key fields in the DSD Invoice Line (_ORACO__InvoiceLineDSD_c) staging table used for storinginvoice lines in the invoice.


Invoice Line Number

RecordName

A unique alphanumeric key generated by themobile application.

Line Number

_ _ ORACO_ _ InvoiceLineLN_ c

A unique line number within an invoice andhas a numeric value.

Invoice

_ _ ORACO_ _Invoice_c (_ _ ORACO_ _ Invoice_Id_c)

The invoice header associated with theinvoice line.

Product


The product for which the invoice isgenerated.



34


Quantity


The quantity of the product invoiced.

Shipment Line

_ _ ORACO_ _ ShipmentLine_ c (_ _ ORACO_ _ ShipmentLine_ Id_c)

The shipment line associated with the invoiceline.

Order Line Source System

_ _ ORACO_ _ OrderLineSS_c

The source application of the order line thatis associated with the invoice line. The OrderLine Source System is picked up from theshipment line for which the invoice line wascreated. It must have the same value as theOrder Source System field in the invoiceheader.

Order Line Source System Number

_ _ ORACO_ _ OrderLineSSN_ c

The source application number of the orderline associated with the invoice line. TheOrder Line Source System is copied from theshipment line for which the invoice line wascreated. It must have the same value as theOrder - Source System Number field in theinvoice header.

Order Line Revision Number

_ _ ORACO_ _ OrderLineRN_c

The revision number of the order lineassociated with the invoice line.

Order Line Number

_ _ ORACO_ _ OrderLineNumber_ c

The number of the order line associated withthe invoice line. The order line is picked upfrom the shipment line for which the invoiceline was created.


_ _ ORACO_ _ InvoiceLineSS_ c _ _ ORACO_ _ InvoiceLineSSN_ c

The unique user keys for an invoice recordgenerated by the mobile application. Theymust have the same values as those in theinvoice header.


Chapter 8Integrating Credit Lines

35

8 Integrating Credit Lines

Integrating Credit Lines with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers how you can integrate CX Retail Execution Mobile with an Enterprise Resource Planning (ERP) accountingsystem to manage credit lines.

In CX Retail Execution Mobile, sales representatives can view the credit lines available to the customers and can create thepayment transactions against those credit lines. To further process these payment transactions and get updated credit linesafter processing the payments, you must integrate an ERP system with CX Retail Execution Mobile.

When integrated, you can use CX Retail Execution Mobile to see the usage of credit lines or credit notes available to eachcustomer. You can capture and manage payments done using these credit lines or credit notes against the invoices.

You can use credit lines to store records of type credit line and proof of purchase, and to check the authorization of proof ofpurchase. See: Integration Tables and Key Fields for the fields used for the type of record and the authorization of proof ofpurchase.

Here's how the integration flow works:

1. Integration system uploads the credit line information to the consumer goods server.2. CX Retail Execution Mobile captures payment transactions against these credit lines.3. The payment transaction records are transferred to the staging tables.4. The integrated system picks up these transaction records and updates the credit line information based on

payments.



36

The following graphic shows the credit line integration flow.

Credit Line Integration

ERP

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail

Exec

utio

n M

obile

Credit Line and Payments

Update Credit Line/ Credit Note

Credit Updates

Payment Transactions

Credit Staging Tables

Payment Staging Tables

Credit Updates


Configuring Integration Flows for Integrating Credit LinesThis topic covers how the integrating system can manage the balances in credit notes and credit lines. It also covers how youmust configure the integration to refresh the credit records in the integration tables periodically.

Note: If you do not use credit notes, you can skip the integration of credit note and integrate only credit line.

The credit line and credit note records that the CX Retail Execution Mobile uses are read-only. Although the credit balancesare updated in the mobile application to facilitate route execution, these balances are not sent to the consumer goods server.Only the payment transaction records are sent to the consumer goods server. Instead of using credit line balances, theintegrating system must use the captured payment transaction records to update the credit balances.

The integration system must do the following to maintain credit details:

• Add and update records for open credit lines and credit notes.

• Remove records for closed credit lines and credit notes.



37

Each credit note is linked to its parent credit line; therefore, when creating the credit note records in consumer goods, theintegration system must do the following:

• Create the parent credit line record first.

• Read the Internal ID of the credit line record and use it to create the child credit note records so that the records areproperly linked.

Integration Tables and Key Fields for Integrating CreditLinesThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store credit line andcredit note information:

• DSD Credit Line

• DSD Credit Note

DSD Credit LineThe following table lists the key fields in the DSD Credit Line (__ORACO__CreditLineDSD_c) staging table.


Credit Line Number

RecordName

Credit Line Number is issued by an externalERP data source.


_ _ ORACO_ _ CreditLineSS_ c _ _ ORACO_ _ CreditLineSSN_ c

The user keys for a credit line.

Account


The account for which the credit line wasapproved.

Credit Limit

_ _ ORACO_ _ CreditLimit_c

The maximum amount the customer can usewith this credit line.

Number of Notes Allowed

_ _ ORACO_ _ NoOfNotesAllowed_ c

The number of credit notes allowed with thecredit line.

Amount Used

_ _ ORACO_ _AmountUsed_c

The amount the customer has used with thiscredit line.

Notes in Use

_ _ ORACO_ _NotesInUse_c

The number of credit notes opened with thecredit line.

Available Credit

_ _ ORACO_ _ AvailableCredit_ c

The available amount the customer can usewith the credit line.



38


Balance Date

_ _ ORACO_ _ BalanceDate_c

The date on which the balance is updated.

Amount Due

_ _ ORACO_ _AmountDue_c

The amount due with the credit line.

Legal Entity


The legal entity for the credit line.

Type

Indicates the type of the credit line record.The type can be standard credit line or proofof purchase.

Approved From Date

The date from which the record is valid.

Approved To Date

The date up to which the record is valid.

DSD Credit NoteThe following table lists the key fields in the DSD Credit Note (__ORACO__CreditNoteDSD_c) staging table.


Note Number

RecordName

Note Number is issued by an external ERPdata source.

Account


The account for which the credit note wascreated.

Credit Line

_ _ ORACO_ _CreditLine_c (_ _ ORACO_ _ CreditLine_ Id_c)

The parent credit line.

Source System Source System Number Line Number

_ _ ORACO_ _ CreditNoteSS_ c _ _ ORACO_ _ CreditNoteSSN_ c _ _ ORACO_ _ CreditNoteLN_ c

The user keys for a credit note.

Order Number Order - Source System Number Order Source System Order - Revision Number

_ _ ORACO_ _ OrderNumber_c _ _ ORACO_ _OrderSSN_c _ _ ORACO_ _OrderSS_c _ _ ORACO_ _OrderRN_c

Identifies the order for which the credit notewas opened.

Issue Date _ _ ORACO_ _IssueDate_c The date when the credit note was opened.



39


Due Date

_ _ ORACO_ _DueDate_c

The date when the credit note is due.

Amount


The amount used with the credit note.

Balance

_ _ ORACO_ _Balance_c

The outstanding amount from the credit note.

Balance Date

_ _ ORACO_ _ BalanceDate_c

The date on which the balance is updated.

Legal Entity


The legal entity for the credit note.



40


Chapter 9Integrating Payments

41

9 Integrating Payments

Integrating Payments with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers how you can integrate CX Retail Execution Mobile with an Enterprise Resource Planning (ERP) accountingsystem to manage payment information.

In CX Retail Execution Mobile, sales representatives can create payment transactions against credit lines. To process thesepayment transactions further and to update the credit lines after processing the payments, you must integrate an ERP systemwith CX Retail Execution Mobile.

When integrated, you can use CX Retail Execution Mobile to capture payments and view updated credit lines or credit notesbased on those payments.


1. CX Retail Execution Mobile captures payment transactions against credit lines.2. The payment transaction records are transferred to the staging tables.3. Integration system processes the payment transactions and uploads the credit line information to the consumer

goods server.4. CX Retail Execution Mobile picks up the updated credit line information.



42

The following graphic shows the payments integration flow.

Credit Line Integration

ERP

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail

Exec

utio

n M

obile

Credit Line and Payments

Update Credit Line/ Credit Note

Credit Updates


Credit Staging Tables

Payment Staging Tables

Credit Updates


Understanding Payment Types for Integrating PaymentsThis integration supports the following types of payments:

• Cash: Payments made using physical currency.

• Check: Payments made using checks.

• Credit line: Payments made using credit lines. These credit lines are issued and managed by ERP, and are used topay for items up to a maximum credit limit for a fixed number of times. Customers must later pay for these creditlines using cash.

• Credit or Debit cards: Payments made using credit or debit cards. A credit card lets your customers pay for yourgoods and services by incurring a debt with a credit card provider.

• Electronic transfer: Payments made using Websites or portals.

• Proof of purchase: Payments made using proof of purchase. This proof of purchase has a unique number that mustbe captured in this integration.

• Coupon: Payments made using coupons. A coupon has a prepaid amount that customers can use.



43

You must also provide values associated with each type of payment to process each payment transaction. For example,if your customer uses checks for payments, you must capture the values for fields such as Bank Name, Bank AccountNumber, and Check Number. Similarly, the following additional fields must be provided for each payment type:

• Coupon: Coupon and Number of Coupons.

• Credit Line: Credit Line Number, Credit Line - Source System and Credit Line - Source System Number.

• Credit Card: Voucher Number.

• Electronic Transfer: Electronic Transfer Transaction Number.

• Proof of Purchase: Proof of Purchase Number and Purchase Order Number.

Configuring Integration Flows for Integrating PaymentsThis topic covers how the integrating system can manage the balance of payments in credit notes or credit lines. It alsocovers how you must configure the integration to refresh the payments in the integration tables periodically.

The credit line and credit note records that the CX Retail Execution Mobile uses are read-only. Although the credit balancesare updated in the mobile application to facilitate route execution, these balances are not sent to the consumer goods server.Only the payment transaction records are sent to the consumer goods server. Instead of using credit line balances, theintegrating system must use the captured payment transaction records to update the credit balances.

Processing PaymentsThe sales representatives who collect cash and checks must deliver those payments to the back-office system regardlessof the issues, if any, in other types of payment methods. For example, an issue with a coupon must not block uptake of apayment in cash.

The back-office system must process payments one by one, which means that the payment lines must be processedindividually over iterations. Only those payment lines where the Process Status is Ready to process must be processed bythe integrating ERP system. Optionally, corresponding payment headers can be processed as well.

After a payment line has been processed, the Process Status field must be set to Processed to prevent reprocessing ofthe payment line records.

Integration Tables and Key Fields for Integrating PaymentsThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store paymentinformation:

• Coupon

• DSD Payment

• DSD Payment Line



44

CouponThe following table lists the key fields in the Coupon (__ORACO__Coupon_c) table.


Coupon Name

RecordName

The unique name of the coupon.

Start Date

_ _ ORACO_ _StartDate_c

The date when the validity period of acoupon begins.

End Date

_ _ ORACO_ _EndDate_c

The date when the validity period of acoupon ends.

Coupon Value

_ _ ORACO_ _ CouponValue_c

The value of the coupon.

Currency Code

_ _ ORACO_ _Currency_c

The currency of the coupon.

DSD PaymentThe following table lists the key fields in the DSD Payment (__ORACO__PaymentDSD_c) table.


Payment Number

RecordName

Account


Payment Date

_ _ ORACO_ _ PaymentDate_c

Amount

_ _ ORACO_ _Amount_c


_ _ ORACO_ _PaymentSS_c _ _ ORACO_ _PaymentSSN_c

DSD Line PaymentThe following table lists the key fields in the DSD Payment Line (__ORACO__PaymentLineDSD_c) table.


Payment Line Number

RecordName

The globally unique alphanumeric stringgenerated in mobile for each payment line.



45


Account


The corresponding retailer account which hasthe made the payment.

Payment

_ _ ORACO_ _Payment_c

The payment header information.

Amount


The amount for each payment line.

Pay For

_ _ ORACO_ _PayFor_c

The payment type against which the paymentis made.

Pay For Credit Line

_ _ ORACO_ _ PayToCreditLine_ c

The value used when the payment is madeusing a credit line. You must enter the CreditLine Number, Credit Line - Source System,and Credit Line - Source System Number.

Pay For Credit Note

_ _ ORACO_ _ PayToCreditNote_ c

The value used when the payment is madeusing a credit note. You must enter the CreditNote Number, Credit Note - Source System,Credit Note - Source System Number, andCredit Note - Line Number.

Pay For Invoice

_ _ ORACO_ _ PayToInvoice_ c

The value used when the payment is madeusing an invoice. You must enter the InvoiceNumber, Invoice - Source System, andInvoice - Source System Number.

Type

_ _ ORACO__Type_c

The type of payment method for the paymentline.

Source System Source System Number Line Number

_ _ ORACO_ _PaymentSS_c _ _ ORACO_ _PaymentSSN_c _ _ ORACO_ _ PaymentLineLN_ c

The user keys for a payment.



46


Chapter 10Integrating Store Credits

47

10 Integrating Store Credits

Integrating Store Credits with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers how you can integrate CX Consumer Goods with an Enterprise Resource Planning (ERP) accounting systemto manage store credit information.

The sales representatives can use the mobile to capture the product returns when they visit retail stores. After these returnsare accepted, the retail store can get the credit for these returns and they can use it for paying the outstanding order invoices.

To refresh the store credit data based on the return and other sales transactions, you must integrate the mobile applicationwith an external ERP system.

The store credit transactions are read-only in consumer goods server and must be available to the integrating ERP system forfurther processing. You can define the processing logic by setting the profile option.

When integrated, you can use the mobile application to manage store credits based on sales and return orders.


1. The mobile application captures store credit transactions for each account. These transactions are sent to theintegrating ERP system for further processing based on the processing logic chosen.

2. Integrating system processes the store credit transactions and uploads the information to the consumer goodsserver.

3. The mobile application picks up the updated or refreshed store credit information. The following graphic shows thestore credit integration flow.



48

The following graphic shows the store credit integration flow.

Store Credit Integration

ERP

Inte

grat

ion

Con

sum

er G

oods

Se

rver

CX

Ret

ail E

xecu

tion

Mob

ile

Store Credit

Update Store Credit

Information

Sales/ReturnUpdates

Store Credit Transactions

Store Credit Staging Table

Store Credit Transaction

Table

Store Credit Updates

Sales/ReturnTransactions

Immediate Updates

Aggregated Transactions

Configuring Integration Flows for Integrating Store CreditsThis topic covers how you must configure the integration to refresh the store credit in the integration tables periodically.

Setting the Profile OptionThe integration supports two strategies for the mobile application to manage the store credits based on the profile optionenabled.

Profile Option Description

Immediate

Use this option if the store credits allocated to an account must be immediately available in themobile application for redemption when a product is returned.



49

Profile Option Description

When you use this option, the mobile application aggregates the transactions to create a localcopy of the store credits. The Enterprise Resource Planning (ERP) system does not validate thetransactions.

Back Office

Use this option if the store credits allotted to an account must be prevented from being redeemedimmediately using the mobile when a product is returned. When you use this option, the Enterprise Resource Planning (ERP) system validates the transactionsalong with the payment and order details before the store credits are generated for the account.These credits are a part of the download package and can be used by the account after they aresynced to mobile.

Processing Store CreditsHere's how the mobile application processes the store credit information for an account:

1. Reads the account's base store-credit and the Last Processed Transaction Time Stamp from the Store Creditstaging table.

2. Reads all transactions that are greater than the Last Processed Transaction Time Stamp.3. Adds or reduces the transaction quantity for each transaction from the original store credit value, as applicable.4. Generates a new record in store credit staging table with the final value. This new record has its Last Processed

Transaction Time set to the creation time of the most recent transaction for the account.

Integration Tables and Key Fields for Integrating StoreCreditsThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables for store creditinformation:

• Store Credits

• Store Credits Transaction Table

Store CreditsThe following table lists the key fields in the store credits (__ORACO__StoreCredit_c) table.


Store Credit Number

RecordName

The unique name for store credits.

Amount


The amount available as credit for theaccount.



50


Account


The account to which the store credit isallotted. This must be set by the integratingERP system.

Date

_ _ ORACO__Date_c

The date on which the store credit iscalculated and allotted. This must be set bythe integrating ERP system.

Legal Entity

_ _ ORACO_ LegalEntity_c

The legal entity for which the store credit isallotted.

Store Credit Transactions TableThe following table lists the key fields in the store credit transactions (__ORACO__StoreCreditTrans_c) table.


Store Credit Transaction Number

RecordName

The unique identifier for the store credittransaction.

Transaction Date

_ _ ORACO_ _ TransactionDate_ c

The date on which the transaction wasrecorded.

Transaction Amount

_ _ ORACO_ _ TransactionAmount_ c

The amount involved in the transaction.

Transaction Type

_ _ ORACO_ _ TransactionType_ c

The type of the transaction. This can be debitor credit.

Description

_ _ ORACO_ _ Description_c

The description of the transaction.

Store Credit

_ _ ORACO_ _ StoreCredit_c

The ID of the store credit related to thetransaction.

Account


The account where the credit transaction hashappened.

Order

_ _ ORACO_ _Order_c

The return order or sales order which createdthe transaction.


_ _ ORACO_ _ StoreCreditTransSS_ c _ _ ORACO_ _ StoreCreditTransSSN_ c

The unique user keys for store credits.

• Source System is the route number.• Source System Number is the unique

number generated in the mobileapplication for each route.

Order Source System


The source system of the order.



51


Order Source System Number


The source system number of the order.

Order Revision Number


The revision number of the order.

Order Number

_ _ ORACO_ _ OrderNumber_c

The number of the order.

Legal Entity

_ _ ORACO_ _ LegalEntity_c

The legal entity of the order for which thetransaction was performed.



52


Chapter 11Integrating Empty Containers

53

11 Integrating Empty Containers

Integrating Empty Containers with Consumer Goods Direct-Store-Delivery Processes: OverviewThis topic covers how you can integrate CX Consumer Goods with an ERP system to manage empty containers.

The sales representatives can manage empty containers using CX Consumer Goods Mobile in both offline and online mode.The empty containers refer to the returnable containers or material such as bottles or cartons that the retail stores must returnafter the delivery of the related products.

The mobile application captures the delivery or return of containers as transactions, and uses the integration with ERP torefresh or recalculate the balance of these containers before each route execution.

The transactions data is read-only in consumer goods server and determines whether or how the empty containers which arenot returned must be charged.

The transactions are of the following types:

1. Product Delivery: Increases the number of containers loaned to the customer based on the quantity delivered in ashipment to the customer. This does not include any containers purchased by the customer.

2. Return of Empty Containers: Decreases the number of containers loaned to a customer based on the number of theempty containers returned by the customer.

3. Return of Product: Decreases the number of containers with a customer based on the quantity of the productsreturned by the customer.


1. The ERP system recalculates the balance and sends the new balance records to the consumer goods server. See,Calculating Balance Using Transactions Method.

2. The CX Retail Execution Mobile retrieves the refreshed balance records from the consumer goods server.3. The CX Retail Execution Mobile sends transaction records created during route execution to the consumer goods

server.4. The consumer goods server prepares the transactions records and makes them available to the integrating ERP

system.



54

This graphic shows the empty container integration flow:

Empty Container Integration

Supp

ly C

hain

In

tegr

atio

nC

onsu

mer

Goo

ds

Serv

erC

X R

etai

l Ex

ecut

ion

Mob

ile

Container Balance and Charges

Recalculate Balance and Charges

Update

Route Execution

Container Balance

Container Transactions

Update

Container Records

Configuring Integration Flows for Integrating EmptyContainersThis topic contains information about how you can manage and configure the transactions related to empty containers. Itcovers how you can transfer data to or from Oracle Sales Cloud to the integrated application and the methods or strategiesthat you can use to update the container-class balance records.

The mobile application uses only the container-class transactions that are periodically purged using the table designed tosupport this operation.

Caution: If the transactions table is not used, you must configure the integration in a way that it does not purgethe transactions. This can affect the recalculation of the inventory level in the device.



55

Calculating Balance Using Transactions MethodHere's how the integration calculates the balance using the mobile transactions:

1. Reads the current balance for an account and container class combination and notes the Last TransactionProcessed Time Stamp of that container class.

2. Retrieves and processes the container class transactions for the account and the container class, where theCreation Time Stamp is later than the Last Transaction Processed Time Stamp.

You must configure the integration to process these retrieved transactions by descending order of the CreationTime Stamp so that the most recent transaction is processed first. To prevent the integration from processing in-progress transaction records based on the most recent Creation Time Stamp, you must do either of the followingconfigurations in the integrating system:

◦ Induce delay in processing the transaction record having the most recent Creation Time Stamp.

◦ Process transaction records up to but not including the most recent Creation Time Stamp.

3. After the container-class balance is updated, the Last Transaction Processed Time Stamp is replaced with theCreation Time Stamp of the last processed record. You must ensure that the same operation updates both thesefields.

You can configure the integrating system to reconcile the records multiple times in a day.

Integration Tables and Key Fields for Integrating EmptyContainersThis topic covers the tables and the key fields that you must use or configure to support the integration.

To facilitate the data flow between multiple systems, this integration uses the following staging tables to store containerinformation:

• Container Class Balance

• Container Class Transactions

Container Class BalanceThe following table lists the key fields in the Container Class Balance (__ORACO__ContainerClassBal_c) staging table thatcontains the information about the current number of empty containers that have not been returned by the customer at thestart of the day or as configured.


Account Container Class

_ _ ORACO_ _Account_c _ _ ORACO_ _ ContainerClass_ c

The fields that correspond to an accountand container class combination. Onecontainer class transaction corresponds to acombination of account and container class.

Current Balance

_ _ ORACO_ _ CurrentBalance_ c

The balance or the current count of theempty containers that have not beenreturned.



56


Balance Counted On

_ _ ORACO_ _ BalanceCountedOn_ c

The date and time when the containerbalance was last counted.

Last Transaction Processed Time Stamp

_ _ ORACO_ _ LastTxnProcessedTS_ c

The last creation Time Stamp from theContainer Class Transactions table.

Container Class TransactionsThe following table lists the key fields in the Container Class Transaction (__ORACO__ContainerClassTxn_c) table, whichcontains the transaction records of the containers.

Key Fields API Name Descriptions

Record ID

Id

A unique and incremental databasesequence ID generated by consumer goodsserver when a record is created.

Creation Date

CreationDate

The date when the transaction occurs.

Account Container Class

_ _ ORACO_ _Account_c _ _ ORACO_ _ ContainerClass_ c

The fields that correspond to an accountand container class combination. Onecontainer class transaction corresponds to acombination of account and container class.

Transaction Date Transaction Type Quantity

_ _ ORACO_ _ TransactionDate_ c _ _ ORACO_ _ TransactionType_ c _ _ ORACO_ _Quantity_c

A combination of fields that represent howthe container class balance has changed.

direct-store-delivery integrating consumer goods mobile oracle customer experience … · 2018. 11....

Documents