Customer Ordering

Order Management Sales and Returns

Customer Order sales and returns processed through an Order Management System (OMS) will look and behave much like regular sales in a store, but with some key differences pointed out below. It should be noted that for some of the RTLOG attributes, this could be either the POS or OMS sending these details, depending on whether the order is captured in the store or online, and whether the fulfillment of the order is based on store pickup or shipment from a store or other location.

Transactions related to customer will be processed through the RTLOG as transactions with the transaction type of Sale. Additional transaction item-level codes are used to indicate the specific actions that should be applied to the transaction when it is process by Merchandising, as noted below:

Item Status Codes

This status is used for customer orders related transactions. For customer orders, there are several different statuses used:

Order Initiate (code ORI) - used to indicate that an order for the item was taken and that tender was collected for the ordered item, thereby representing a financial liability since the item has not yet been fulfilled (delivered or picked up). If tender is not collected there is no need to communicate the order initiation to Sales Audit since the purpose of it is to communicate the financial liability through to the General Ledger.
Order Cancel (code ORC) - used to reverse the financial liability created through the order initiation in the case where an order resulting in a financial liability is canceled. If the Order Initiate code is not used cancellations do not need to be communicated to Sales Audit.
Order Complete (code ORD) - used to communicate that the order/line item fulfillment has been completed - delivered or picked up. The result is a completed sale which will also offset the financial liability created by the Order Initiate code, if used.

Adjustment/Appeasement (code ADJ) - used to communicate a price adjustment for the order/line item. When using this status type, it should be used for a transaction type of SALE, but at the item level the details in the file are a bit different from the other statuses above.

Table 6-1

TITEM
Sales Type	E
Quantity Sign	This should always be N for this type of transaction; appeasements cannot increase the original unit retail.
Quantity	Quantity of the item being adjusted
Unit Retail	The absolute value of the adjustment amount without tax.
Original Retail	Price the customer originally paid for a single unit. For example, if the selling price of the item is $250 and the customer received a $10 discount on the original sale, then this should be $240 (250-10).
Override Reason	Reason code from OMS (for OROMS it will always be "OMS")
Total IGTAX Amount	Absolute value of the total taxes for all IGTAX rows for this item.
IGTAX
IGTAX Code	This is always hardcoded to TOTAX in OMS integration
IGTAX Rate	This is always left blank in OMS integration
IGTAX Amount Sign	Should only be N for this type of transaction
IGTAX Amount	Absolute value of the tax on the extended adjustment retail (qty * unit retail).
TTEND
Tender Type Group	Value used to reimburse the customer
Tender Type ID	Value used to reimburse the customer
Tender Sign	Should only be N for this type of transaction
Tender Amount	Absolute value of the amount for which the customer was reimbursed.

When Sales Audit processes this transaction, it will audit it for the details above. Balancing for this new equation should be similar to other transactions and should be (quantity * unit retail) + tax = tender.

When exporting the details to Merchandising and Retail Insights for sales processing, it will do the following:

Create a negative sale transaction to reverse the original transaction processed. This sales transaction should be based on the original retail value.
Create a sale transaction based on the new retail price, which will be calculated as original retail - unit retail.

When Merchandising processes these transactions, it should process the first as a full reversal of the sale (not a return) - similar to when a sales audit sends a negative sale based on a revision. This means posting of sales, tax, markdown, and any other relevant transactions in tran data as negative values. Also, if the Account for the Sale setting for Merchandising is set to Order Location instead of Fulfillment Location, then the book transfer created originally will also be reversed by writing negative tran code 31/33 records. The second transaction should be posted as a normal sale.

Other notes:

TTAX, if included, should be a summary of the IGTAX lines on the transaction, including the ADJ line items. If IGTAX is not sent or used (as with a non-OROMS integration) then the ADJ line would still be expected to contribute a negative tax value to the overall tax calculation.
IDISC, TPYMT should never be included for this type of transaction.

To communicate the liability or the alleviation of the liability to the General Ledger, totals can be built using these status codes. For more on creating totals, see the Configuring Totals and Audit Rules section of this document.

Order Numbers

In addition to the above codes the Customer Order and Fulfillment Orders numbers are communicated to Sales Audit at the transaction/item level of the RTLOG. The Customer Order number represents the master order identifier that ties back to the order the customer created while the Fulfillment Order number represents each unique fulfillment order as defined by the fulfillment location and method. Sales Audit does not validate these numbers so they are only included for traceability and cross reference.

Fulfillment Location Type and Location

Sales and returns processed through an OMS and communicated to Sales Audit via the RTLOG will usually be fulfilled from multiple different stores and warehouses in a particular day. The fulfillment location type and location are used to communicate the location where the customer order was fulfilled, while the store in the file header will be the virtual store representing your ecommerce site. The fulfillment location type will be either store (ST), warehouse (WH), or supplier (SU) and the fulfillment location will contain the store, warehouse, or supplier ID where the fulfillment of the order occurred. If the fulfillment type is not present in the RTLOG, such as in the case of POS processed customer orders, the store in the header of the RTLOG file will be used as the fulfillment location for sales processing.

Sales Type

The RTLOG file contains an attribute for specifying the sales type of the item on the transaction. For orders processed through an order management system the sales type should be External Customer Order (code E). The In-Store Customer Order (code I) is used for orders taken and fulfilled within the store that do not involve an order management system for fulfillment, such as an order taken at the POS and picked up at the same store at a later date. Regular POS transactions will utilize the Regular Sales sales type (code R).

Warehouse Returns

Returns of customer orders processed at a warehouse are communicated to the OMS and then in turn, communicated to Sales Audit. Like customer order sales fulfilled from the warehouse, returns are processed through a virtual store location and communicated to Sales Audit in the RTLOG. The following RTLOG attributes are used to support this process:

Returns Warehouse - should contain the warehouse where the return occurred; this could be a physical or virtual warehouse.
Return Disposition - indicates whether the returned item can be returned to sellable stock or whether it should be set aside as non-sellable stock; this is optional.
No Inventory Return - indicates if there is no physical product returned, as would be the case if the customer was instructed to just dispose of the item instead of shipping it back to the warehouse. If a return is flagged as a no inventory the return will be processed into the warehouse and then subsequently be adjusted out of inventory.

Note:

Return disposition and no inventory returns are supported only for warehouse returns. Store returns sent from POS would always be returned into available inventory with any subsequent move to unavailable or write off occurring in the store inventory management solution, like Oracle Retail Store Inventory and Operations Cloud Service (SIOCS).

Transaction Filtering

Sales Audit has the ability to filter certain transactions to avoid double processing transactions in cases where the same transaction is communicated from both the OMS and POS systems. The transaction filter logic uses the following attributes in the RTLOG to determine which transaction to process and which to ignore:

RTLOG Originating System - valid values are OMS and POS. This is defined at the RTLOG file level as it represents the system from where the particular file originated.
Transaction Processing System - valid values are OMS and POS. This is defined at the RTLOG transaction header level so the value can be varied by transaction.

An example of how this filter could be used is for a customer order that is fulfilled through store pickup using POS. When the pickup occurs, POS will communicate the pickup transaction to Sales Audit, but you may not want to recognize this as a sale until this order is processed by the OMS, for example if OMS has the payment information related to the transaction. In this example the RTLOG Originating System for the pickup transaction from the POS will be "POS" and the Transaction Processing System on the transaction should be sent as "OMS". The transaction sent by the OMS should have the value "OMS" for both attributes. Sales Audit will filter the POS transaction because the originating system and processing system do not match and it will process the OMS transaction because they do.

Managing Customer Information

A system option controls whether Sales Audit is the system of record for customer information associated with customer orders or other POS transactions. If Sales Audit is the system of record, any information that the customer provided at the time the order was created or at the time the transaction occurred will be stored in the respective Sales Audit tables. If not, then Sales Audit will only store customer identifiers on the tables, and any required fields on the tables will contain generic default values (for example, XXXX). These customer identifiers may be used to request the customer information from a third-party order management system or customer system that holds the complete customer information.

Balancing Customer Order Transactions

When balancing transactions that contain line items using the item statuses Order Initiate (ORI), Order Complete (ORD), or Order Cancel (ORC), there are some differences from regular sales transactions, as the extended item retail value for items of this status will always be 0. The balancing equation used is as follows:

Balance = Tender - (Payment + Item Total + Tax Total)

The below images show an example of what this might look like in a transaction.

Layaway

Sales Audit's layaway functionality gives customers the option to pay for an item that is currently in stock at a store in installments, and then pick it up at a later date. When these types of transactions are processed in Sales Audit, there are two key things that occur - an inventory reservation transaction is sent to Merchandising to reserve the item (the item is moved to a Customer Order Reserved inventory bucket) if the system option for Inventory Reservation - For Layaway is Y. The payment information is also recorded for tracking the liability. When the item is eventually picked up, the reservation is released and the sale is processed. This functionality leverages item level statuses to indicate the updates that should be made. The statuses used are:

Layaway Initiate (LIN) - using this status indicates a new layaway is being initiated and triggers a reservation in Merchandising.
Layaway Complete (LCO) - using this status indicates the customer has completed the payment schedule for their item and has picked it up. This will process the sale for the item and release the reservation in Merchandising.
Layaway Cancel (LCA) - this indicates that the customer has changed their mind about the layaway item and that the reservation should be cancelled and their payments have been reimbursed.

The below example illustrates how these statuses are used, as well as how interim payments between initiation and pickup would be handled.

The customer goes to the store and ask for a layaway of Item A that costs $500 and pays a deposit of $200.
- Transaction Type = SALE
- Sub-Transaction Type = Initiate Layaway (LAYINT)
- Payment = $200
- Item Status = Layaway Initiate (LIN)
- Customer order reserved is updated in Merchandising for the item/store.
One week later the customer goes to the store and pays another $150 for the Item A.
- Transaction Type = SALE
- Sub-Transaction Type = Layaway Payment (LAYPAY)
- Payment = $150
- No item details on transaction
The customer pays the remaining $150 for the Item A and the sale is complete.
- Transaction Type = SALE
- Sub-Transaction Type = Complete Layaway (LAYCMP)
- Payment = $150
- Item Status = Layaway Complete (LCO)
- Customer order reserved is decremented in Merchandising for the item/store and the sale for the item is processed.