| Oracle® Retail Enterprise Inventory Cloud Service User Guide Release 22.1.301.0 F58716-01 |
|
 Previous |
| Oracle® Retail Enterprise Inventory Cloud Service User Guide Release 22.1.301.0 F58716-01 |
|
Previous |
This chapter describes the sales integration. The following topics are covered:
Overview: Description of how EICS, Point of Sale (POS) systems, and Sales Audit systems are integrated. Also, how the sales wastages process is handled in EICS.
Processing: Information on how the sales integration is processed.
EICS integrates with POS systems and Sales Audit systems to ensure that the inventory positions are accurate. This is especially important for Commerce Anywhere 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 updates using a web service. Sales Audit systems can only communicate through a file import process.
Following are the features of the integration:
Real-time web service and batch integration
POS transaction and audited sales data integration
Automatic disposition processing for returns
Wastage processing for grocery
The following figure shows how a POS, such as Xstore Point of Service, 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. Xstore is interfaced with EICS to update the inventory transactions near real time through a web service. Other POS systems can also 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.
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.
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.
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. |
POS has the opportunity to move inventory for return and post void transactions to 'unavailable' or 'out of stock'. This is especially useful in some environments where items returned have to be disposed of or have to 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.
Wastage is the process through which inventory is lost over time (for example, bananas turning black) or when processing the item for sale (trimming off fat for sale of a ham).
In order to maintain more accurate inventory values, EICS uses two methods to control wastage:
The first method provides users in stores the ability to create wastage product groups.
The second method is controlled through the sales process. The sales transaction information can contain a wastage percentage for variable unit of measure items. If that is not present on the sales transaction coming in, EICS looks up the wastage percentage and uses that for inventory reduction beyond the sale.
Each of these methods has a specific use and can be used in combination with each other. In the sales method, items such as cheese or ham, are only reduced when the outside layers are cut off to sell the item.
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.
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. Concession, non-inventory items, and consignment 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.
The POS Transactions can contain the RFID Tags and the system while processing the transactions updates the status of the tag.
SIOCS maintains the tag status as below.
Present - This means the tag is physically present in the store. An item tag can be in this status when a new item is created/added or when the existing tag that was in 'Not Present' is moved to 'Present' because of some transaction event.
Not Present -This means the tag is not present in the store. The system will move it to this status when there are out bound inventory transactions.
The transaction processing supports the RFID tag updates as below.
Table 11-1 Supported RFID Tag Updates
| SI.Number | Transaction Type | Update | Remarks |
|---|---|---|---|
|
1 |
Sale |
Not Present |
Transaction will be processed and the Stock on Hand will be decreased and RFID tag will be updated to Not Present. |
|
2 |
Void of Sale |
System will not update anything |
Transaction will be processed for Stock on hand update but RFID tag updates will not happen via sales processing. The RFID tag status update is expected via RFID solution. |
|
3 |
Return |
System will not update anything |
Transaction will be processed for Stock on hand update but RFID tag updates will not happen via sales processing. The RFID tag status update is expected via RFID solution. |
|
4 |
Void of Return |
Not Present |
Transaction will be processed and the Stock on Hand will be decreased and RFID tag will be updated to Not Present. |
|
5 |
New Order |
System will not update anything |
No Inventory movement. |
|
6 |
Order Cancel |
System will not update anything |
No Inventory movement. |
|
7 |
Order Fulfill |
Not Present |
Transaction will be processed and the Stock on Hand will be decreased and RFID tag will be updated to Not Present. |
RFID tag integration for sales should only be enabled if an RFID solution is also integrated into SIOCS, be it manual through stock counts or automatic with scanners.
The external RFID solution will manage which tags are present or not. The reason why increase of inventory does not update the tag status is that time delays can happen between scanning the tags and recognizing the return of the item. Since the return of an item may generate a new RFID tag, or locate the tag again, the RFID tag update will happen through the external RFID system. In reverse, a removal of a tag is something EICS can handle as the only response from the external system would be the removal of the same tag resulting in a no-change scenario.
EICS maintains the history of the RFID tags which can be viewed in the reports.
Outside of updating inventory buckets directly, sales data also has impacts on three other areas. For more information, see their relevant sections:
In-Store replenishment
Stock Counts - late sales
History Trail
POS to EICS: Option A (Web Service)
POS may integrate its transactions to EICS using a web-service: POSTransaction. The published WSDL has only one operation: ProcessPOSTransactions. ProcessPOSTransactions processes point-of-sale transactions through an asynchronous process.
This service only allows 5,000 overall PosTrnItms, though they may be distributed between any number of actual PosTrn transactions. Exceeding this limit causes a web service fault to occur. These transactions may belong to multiple store IDs. This operation validates the input, parses the payload information, creates a POSTransaction object, and stages these records to be processed later.
POS to EICS: Option B (Flat File Upload)
POS may integrate its transactions to EICS using a bulk-load flat file. The POS Transaction Import Batch loads all the data within the file, saving the records in the POS_TRANSACTION table and then grouping the records into requests to write into the STAGED_MESSAGE table to be processed shortly.
As previously described, an actual sales transaction extract is given by POS directly to EICS. All the transactions in a file must belong to a single store. After parsing the records from the file, the process stages them into the POS_TRANSACTION and MPS_STAGED_MESSAGE tables as previously described. Following are the key technical Java classes:
RetailSaleAuditImportHandler which prepares a list of POSTransaction from the import file.
RetailSaleAuditDataParser, which contains the actual file parsing logic.
StageResaTransactionCommand, which contains the actual staging logic.
