| Oracle® Retail Store Inventory Management Store User Guide Release 16.0 E76179-08 |
|
 Previous |
 Next |
| Oracle® Retail Store Inventory Management Store User Guide Release 16.0 E76179-08 |
|
Previous |
Next |
This chapter describes the sales integration. The following topics are covered:
Overview: Description of how SIM, Point of Sale (POS) systems, and Sales Audit systems are integrated. Also, how the sales wastages process is handled in SIM.
Processing: Information on how the sales integration is processed.
Technical: POS transaction update import process, Oracle Retail Sales Audit (ReSA) sales audit import process, web services, batch, and the database structure.
SIM 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 SIM. ReSA sends only modified or new POS transaction records to SIM.
POS systems integrated with SIM 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
Full Unique Identification Number (UIN) integration
This section covers store parameters.
Enable Item Disposition in Transaction Updates:
Values: Yes/No
Default: Yes
Topic: Admin
Editable: Yes
This parameter is used to determine whether, while processing the return and void transactions, the POS reason codes mapped to the item disposition in SIM have to be considered and the inventory updated based on the item disposition.
The following figure shows how a POS, such as Xstore Point of Service, Retail Sales Audit, and SIM 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 SIM. ReSA also sends the POS transaction upload file to RMS to update inventory. Xstore is interfaced with SIM 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 SIM. SIM 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 SIM 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 SIM 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 SIM.
As part of the sales processing, SIM 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 SIM.
Part of the transaction sent to SIM supports UIN integration. When items are sold, the UIN is updated in SIM to "sold." If it is returned, the UIN is moved back to "In Stock." In some scenarios, the UIN sold or returned is in an invalid state for SIM to process. For example, a UIN that is sold, but was already sold or moved out of inventory. In such a case, SIM still processes the stock on hand change, but adds the UIN to the resolution screen for processing.
For more information on UINs, see Chapter 6, "Item."
In SIM, the Retail Sales Audit import process, POS Transaction import process, and POS Transaction web service process support the following types of customer orders. For more information, see Chapter 20, "Customer Order Management."
For layaway and on hold, SIM supports create, update, cancel, and pickup/delivery. For external web order type, only pickup transactions performed in POS are sent to SIM.
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, SIM 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. |
When the "Enable Item Disposition in the Transaction Update" store admin parameter is turned on, 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 SIM may include a reason code that is mapped to the inventory adjustment reason codes in SIM. Point of Service maps the SIM reason codes, and the reason codes are sent to SIM in the web service or file extract for the return and post void transactions. SIM first processes the return or post void and updates stock on hand. Next, if the indicator is set and a reason code exists, SIM checks this reason code with the one in inventory adjustment reason code table. If a valid match is found, SIM 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, SIM 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. UIN states are updated accordingly as well.
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.
For more information on inventory adjustment reason codes, see Chapter 8, "Inventory Adjustments."
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, SIM uses two methods to control wastage:
The first method provides users in stores the ability to create wastage product groups. For more information, see Chapter 8, "Inventory Adjustments."
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, SIM 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, SIM 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.
SIM 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, SIM 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 following figure shows the transaction import flow.
SIM has one place to stage POS transactions. Similarly, SIM also stages ReSA audit batch transactions. After staging, the transactions are picked up for processing and the inventory gets updated in SIM tables. Following are the steps involved in staging:
The sales and order transactions are split into separate lists.
Processing request identifiers are assigned to groups of records based on grouping criteria. For sales, the same item ID cannot span across multiple requests. For orders, the same customer order ID cannot span across multiple requests.
All the POS records are written to the POS_TRANSACTION table.
If low volume of records, the records are processed immediately. If high volume of records, a processing message is stored in MPS_STAGED_MESSAGE table for the POS transaction message family containing information such as the request ID, store ID, and transaction type (POS-SALE, POS-ORDER, and ReSA).
Message are picked up from the MPS_STAGED_MESSAGE table, the POS transaction are retrieved, and processing in completed.
POS may integrate its transactions to SIM 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 may integrate its transactions to SIM 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 SIM. 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.
The following figure shows the integration processing flow.
SIM can update SOH correctly in its transaction tables. The Polling Timer Framework polls the MPS_STAGED_MESSAGE table for any unprocessed/failed messages for which the message family is enabled in the MPS_WORKER_TYPE table.
ProcessPosTransactionCommand: Reads message details when triggered by the polling timer framework and identifies which command will process the transactions the logic as follows:
If transaction type = SALE, it triggers ProcessPosSaleCommand.
If transaction type = ORDER, it triggers ProcessPosOrderCommand.
If transaction type = ReSA, it triggers ProcessResaTransactionCommand.
ProcessPosSaleCommand: Designed to process the business logic for sale, void sale, return, or void return transactions. It internally calls ProcessSaleUinCommand for UIN related transactions.
ProcessPosOrderCommand: Designed to process the business logic for order new, order cancel, and order fulfill transactions. It internally calls ProcessOrderUinCommand for UIN related orders.
ProcessReSATransactionCommand: Designed to process the audited transactions coming in from the Retail Sale Audit System. If the transaction was created in ReSA, it processes it straight away. If the transaction was not created in ReSA but rather by POS, it rolls back the original transaction that came from POS and then processes the audited records.
SIM can import transactions from both POS and ReSA. The whole process is divided into two parts: Staging and Processing.
Staging:
The activity of importing transactions into SIM data models is called staging. SIM imports the transactions into its data models using the web service (POS only) or the batch import process (POS-ReSA).
The staging logic for POS separates the sale transactions from order transactions and stages them into separate records. In addition to that, there is a MAX_SIZE limit on the number of transactions in each request provided that the same item_id does not span across multiple request IDs for sale and for order, the same order ID does not span across multiple request IDs. POS cannot stage a transaction ID more than once for the same store ID.
The staging logic for ReSA creates multiple request IDs depending on the MAX_SIZE limit for each request, provided that same transaction ID does not span across multiple request IDs.
Processing:
For each request ID, the polling timer framework picks up the staged records. The records are then passed on to the consumer which calls the processing logic to update the inventory.
For POS sale/order processing, failure can occur at the line item level but for ReSA transactions, failure can only occur at the transaction level, that is, if a single line item fails in a transaction then the whole transaction is failed.
ReSA processing is different from POS processing in the way that it first tries to roll back the completed transactions with the same transaction ID. If the rollback is successful, it processes the audited transactions and only when all the transactions are processed successfully, the data models are updated.
Business objects are used within the application code for all business processing.
| Business Object | Description |
|---|---|
| PosTransaction | Contains detailed information about the transaction including the transaction type and source. |
This section covers integration.
The following batches are provided by SIM:
| Batch Name | Description |
|---|---|
| POSTransactionImport | Batch to import sale/order information coming directly from POS. |
| RetailSaleAuditImport | Batch to import sale/order audit transaction coming in from ReSA. |
The following database tables are used by SIM:
| Table Name | Description |
|---|---|
| POS_TRANSACTION | Table to hold staged POS transaction records for sale and order transactions. |
| POS_TRANSACTION_LOG | Table to hold transaction processing logs for failed transactions. |
| MPS_STAGED_MESSAGE | Table to hold the staged inbound and outbound messages.
For the posTransaction message family, this table holds header level request details. |
