5 Sales Integration
EICS integrates with POS systems and Sales Audit systems to ensure that the inventory positions are accurate. This is especially important where accurate up-to-date inventory positions are required to reduce customer disappointment when trying to locate items that appear in inventory or delays in filling customer orders.
POS is the primary source of sales, returns, void, and some customer order transaction information to EICS.
ReSA sends only modified or new POS transaction records to EICS.
POS systems integrated with EICS can do the transaction notifications using a web service.
Sales Audit systems can only communicate through a file import process.
Figure 5-1 POS and Sales Audit Integration
The following features are part of this integration:
-
Real-time web service integration
-
Batch integration
-
Audited sales data integration
-
Automatic disposition processing for returns
Batch processing and ReSA processing are discussed elsewhere as are the store and system configurations that might determine how the sale is processes.
POS and Sales Audit Process Flow
The following figure shows how a POS, Retail Sales Audit, and EICS are integrated. A POS generates an RTLog containing all the POS transactions and sends it to the Oracle Retail Sales Audit system (ReSA). ReSA sends the audited modified or new transactions to EICS. ReSA also sends the POS transaction upload file to merchandising to update inventory.
Please note that Oracle Retail Xstore is interfaced with EICS to update the inventory transactions near real time only through web service. It does not use batch.
Non-Oracle POS systems can use a batch to import transactions directly into EICS. EICS also processes the POS transactions that have been changed or entered into the sales audit system and updates the inventory based on the delta.
Figure 5-2 POS and Sales Audit Process Flow
There are two reasons for POS to send sales data directly to EICS and not to the auditing system:
-
Real-time inventory updates to support Commerce Anywhere are critical. A possible round trip from POS to ReSA to EICS takes too long in the dynamic inventory environment of today.
-
POS is the application that owns sales data and ReSA owns audited data. Architecturally, it makes more sense to have data supplied by the owner of that data. POS sends sales data and ReSA sends audit changes to EICS.
Sales and Return Processing
As part of the sales processing, EICS updates the inventory depending on the nature of the transaction. The following are the supported transaction types for the sales processing: Sale, Return, and Post Void of these transactions. The audit system should not modify the post void transactions. A change to a void is not supported by EICS.
Customer Order Processing
In EICS, the Retail Sales Audit import process, POS Transaction import process, and POS Transaction web service process support the following types of customer orders.
-
For layaway and on hold, EICS supports create, update, cancel, and pickup/delivery. For external web order type, only pickup transactions performed in POS are sent to EICS.
-
Pickup transactions, both in-store and external, cannot be voided or modified by sales audit and if these transactions are modified by sales audit system, EICS just drops the transaction and does not process.
Note:
Current Xstore functionality is limited to only layaway and on hold orders. Web order processing is not supported in this release.
Item Disposition
POS can move inventory for return and post void transactions to ’unavailable’ or ’out of stock’. This is especially useful in some environments where items returned must be disposed of or must be reprocessed.
The external sale transaction coming into EICS may include a reason code that is mapped to the inventory adjustment reason codes in EICS. Point of Service maps the EICS reason codes, and the reason codes are sent to EICS in the web service or file extract for the return and post void transactions. EICS first processes the return or post void and updates stock on hand. Next, if the reason code exists, EICS checks this reason code with the one in inventory adjustment reason code table. If a valid match is found, EICS generates an inventory adjustment to notify external systems and execute the disposition instructions tied to the inventory adjustment reason code. Based on the disposition mapped to the reason code, EICS moves the returned inventory to not for sale or out of stock and updates the history trail. If sub-buckets are used, they are also updated if the movement is to not for sale.
If the reason code received is invalid/not present/mapped incorrectly, the system writes an error log and continues to process the stock on hand part of the transaction.
Drop Ship
When the sales records indicate the record is a drop ship, EICS does not perform any processing of this record since the drop ship process implies the inventory is shipped from a third-party location and not from the store.
Item Types
EICS only processes SKU or UPC numbers. GS1 databars, or any other smart barcodes such as VPLUs or Type-E barcodes, should have been extracted to their SKU or UPC number by the POS system.
In addition, EICS only updates inventory for stock holding items. Non-inventory items do not update any stock on hand and are not processed.
Items with the store pack inventory indicator turned off are automatically broken down and the inventory of the component items is updated.