| Oracle® Retail Merchandising Implementation Guide Release 16.0 E80776-04 |
|
 Previous |
 Next |
This chapter gives an overview of the information maintained by RMS and RMS integration with other applications.
RMS is the System of Record (SOR) for the following:
RMS contains data that must be populated at the time of installation. Either the data is required by the application, or the data is static and can be loaded for any client. The code tables CODE_HEAD and CODE_DETAIL are examples of tables with system-required values that must be loaded at the time of installation. Additional codes can be added as needed to these tables after installation, by either using the online form or additional client scripts. Customization of the seed data is based on the client's requirements.
Additionally, some configuration tables must be populated for the application to open and function correctly, even though the configuration values can be modified later. These configurations are maintained in System Options set of tables, and are required for initial setup that can be updated prior to the implementation, to reflect final configuration.
Foundation data is the base for all future information on which RMS builds. This information needs to be present before you begin using the system. The majority of foundation data can be set up online; more commonly, a client performs a data conversion process to import this information from legacy systems.
Foundation data consists of three types of information:
Organizational hierarchy
Merchandise hierarchy
Supplier and partner management
The organizational hierarchy allows you to create maximum of six levels of hierarchy relationships to support the operational structure of your company.
In a Retail store, the customer walks through the store and buys, retailers procure goods from suppliers and the retailer acts as a customer. In a Franchise store, the retailer supplies goods to the franchise customers, the retailer acts as a supplier and tracks the sales.
You can create a preferred organizational structure to support consolidated reporting at various levels of the company. You can also assign responsibility for any level of the hierarchy to one or more people to satisfy internal reporting requirements.
The organizational hierarchy also supports two types of stores to satisfy the franchise requirements:
Franchise
Company
A company store acts as a retail store in RMS.
The Franchise stores are used to support franchise business models. Other applications, such as RPM and RWMS, view franchise stores as they would view any other store in RMS; however, RMS performs special processing based on the store types.
The merchandise hierarchy allows you to create maximum of six levels of hierarchy relationships to support the product management structure of your company. You can assign a buyer and merchandiser at the division, group, and department levels of the merchandise hierarchy. You can also link a lower level to the next higher level. For example, you must indicate to which group a department belongs, or to which division a group belongs.
A supplier supplies the merchandise and a partner is involved in other financial transactions that result in invoices. Supplier and partner management provides functionality to create and store valid merchandise suppliers and partners. You can maintain a variety of information about suppliers such as financial arrangements, inventory management parameters, types of EDI transactions, and invoice matching attributes. Suppliers are typically created in a financial system and interfaced into RMS. Supplier enrichment can be maintained in RMS.
The supplier structure can be extended to supplier-parent and supplier-site relationships, to accommodate financial systems that support this configuration. A supplier site is a location from which the supplier ships merchandise.
RMS is responsible for the creation and maintenance of all items. RMS uses a flexible data hierarchy for an item, with levels that allow you to model items in a desired way. The hierarchy consists up to three levels, highest (level 1) to lowest (level 3). Within the defined levels for an item family, one level is denoted as the transaction level. This is the level at which all inventory and sales transaction takes place. This model gives retailers a flexibility to create families of items that share common characteristics.
RMS creates several types of items, such as regular items, deposit items, packs, concession items, consignment items, and transformable items.
Through item maintenance, RMS also maintains the relationships of items with other entities such as suppliers, locations, and attributes.
The Purchase Order module allows you to create and maintain purchase orders in a variety of ways. It provides commitments to vendors for products in specific amounts for specified locations. Purchase orders are created manually or automatically through replenishment or from an external system. They can be created against entered contracts and deals, or directly through direct store delivery or Vendor Managed Inventory (VMI). RMS also provides the ability to maintain the items, locations, and quantities ordered for Purchase Orders.
The contract dialog gives you the ability to create, maintain, submit, and approve contracts. A contract is a legally binding agreement with a supplier to supply items at a negotiated cost.
In RMS, the contracting functions fit closely with the replenishment and ordering functions. The main functions of the Contracts window are to book manufacturing time, track supplier availability and commitments, and match them with business requirements. The main business benefit of contracting is to achieve supplier involvement during the planning phase of a retailer's business.
Deals management allows you to create and maintain deals with partners or suppliers. Deal partners can be suppliers, distributors, and manufacturers. Within a deal, clients create deal components, specify the items for each deal component, and define thresholds.
Components are deals or parts of deals that a retailer receives from a supplier. There can be multiple components in a single deal. You must define thresholds to define the quantity or amount that must be purchased or sold to receive the deal. RMS components include off-invoice deals, rebates, vendor-funded promotions, vendor-funded markdowns, and fixed deals.
You also define the items and locations for which the deal can be applied. You can choose to include or exclude locations as necessary.
You also define the Proof Of Performance (POP) terms for a deal. POP terms are defined by the deal vendor that offers the deal. For deals, POP terms are defined at the deal, deal/component, or deal/component/item-location combination. For fixed deals, POP terms are defined at the deal level.
The deal pass-through functionality allows a percentage of a deals discount to be passed from a warehouse to a franchise store. This functionality applies to franchise stores.
For clients that choose to use supplier sites with RMS, deals are managed at the supplier parent level.
For cost changes, the Cost Management dialog gives you the ability to:
Accept cost changes received through EDI (flat files)
Create a cost change
Edit a cost change
View a cost change
A cost change is an adjustment to the supplier cost of an item, either up or down. Before you create a cost change, you must create a list of user-defined cost change reasons and then apply a reason to each cost change. This is useful in reporting.
The initial cost of an item is established at item setup. The cost of the item is adjusted in the item record until the status of the item is Approved. After the item is approved, any cost changes needs to be handled through the cost change dialog.
When a cost change is submitted through EDI, the EDI cost change is reviewed and released to create a cost change document. The cost change document is then viewed and submitted for approval.
When a cost change document is created online, you enter the cost change, an event description, an effective date, and a reason code, and then submit the cost change for approval.
After a cost change is approved, the item/supplier cost record is updated. Any outstanding purchase order line items with no received units are recalculated, if recalculation is indicated on the cost change.
Additionally, you use the Cost Management dialog to create cost zone groups for zone-type expenses for item estimated landed cost. Zone-type expenses are incurred when imported goods are moved from the discharge port to the purchase order receiving location. Because the expenses can vary depending on the distance between the discharge port and the receiving location, cost zones can be configured to appropriately reflect the expenses. The locations (stores and physical warehouses) must be grouped to reflect the expense variances for moving the goods. Normally a zone strategy is used for these cost zone groups, but it is possible that every location within the company has different expenses to move the goods from the discharge port. If that is the case, a store strategy would be used. If every location within the company has the same transportation costs from the discharge port, a corporate strategy is adequate (but not when multiple currencies are being used). After these cost zone groups are defined, they are added to new items as they are created, in anticipation of the expense profiles that are needed for the items.
Support for multiple sets of books provides better integration with financials systems that supports Multiple Sets of Books within a single installation. Multiple Sets of Books option is enabled by default in RMS and the client will need to set up additional location-specific foundation data, including:
Organizational units
Transfer entities
Set of books IDs
Inventory functionality in RMS is the core of the application. Inventory is tracked perpetually and financially in RMS. The following describes perpetual inventory tracking. For information on financial inventory tracking, see Stock Ledger.
RMS achieves inventory control through functions that include transfers, Return to Vendor (RTV), Inventory Adjustments, Sales Upload, Purchase Order Receipts (shipments), Stock Counts, Allocations, Franchise Orders and Returns, and Customer Orders.
Transfers in RMS provide an organized framework for monitoring the movement of stock. RMS creates and maintains transfers; however, you can also interface transfer information into RMS from other systems.
RMS supports a number of different types of transfers such as intercompany transfers, book transfers, Purchase Order-linked transfers, externally generated transfers, customer orders and franchise order. Transfer functions also support the movement of one or more items between two internal RMS locations, and multi-leg transfers in which the intermediate location is considered a finisher location. Finishers are locations where work is performed on merchandise, such as dying fabric and attaching labels.
Mass return transfers are used to reallocate merchandise to locations or to return merchandise to the supplier.
Return to Vendor (RTV) transactions are used to send merchandise back to a vendor. The RTV transaction in RMS allows one or more items to be returned to a single vendor. For each transaction, the items, quantities, and costs are specified. Upon shipment out of a location, inventory is removed from the stock on hand.
RTVs are created manually in RMS or imported from an external system. RMS also provides the ability to maintain RTVs. Shipped RTVs create a debit memo or credit note request (based on supplier configuration) in the invoice matching staging table in RMS, for export to Oracle Retail Invoice Matching.
Inventory adjustments are used to increase or decrease inventory to account for events that occur outside the normal course of business (for example, receipts, sales, stock counts). Inventory adjustments are created in RMS or imported from an external system (store or warehouse application). RMS supports two types of inventory adjustments; stock on hand or unavailable inventory. Inventory adjustments can also be created by locations for multiple items, by item for multiple locations, or through a product transformation for a specific location.
|
Note: The following Inventory Adjustment Reason Codes are required by RMS and cannot be deleted unless the noted functionality is not utilized:
Additionally, reason codes must be synchronized between SIM and WMS, or any other system communicating inventory adjustments to RMS. |
Purchase order receipts (Shipments) record the increment to on-hand when goods are received from a supplier. Weighted average cost (WAC) is recalculated at time of receipt using the PO landed cost. Transaction audit records are created for financial audit, and the receiver is made available for invoice matching.
Stock counts are the processes by which inventory is counted in the store and compared against the system inventory level for discrepancies. RMS supports two types of stock counts:
Unit Stock Counts: These adjust the on hand quantities for the item-locations affected and create an inventory adjustment transaction for the stock ledger.
Unit and value stock counts: These adjust the on hand quantities for the item-locations affected and adjust the stock ledger to the results of the stock count.
Automated replenishment constantly monitors inventory conditions. Based on inventory conditions, purchase orders or transfers are created to fulfill consumer demand.
Automated replenishment parameters are set up at the supplier, supplier/department, and supplier/location or supplier/department/location level. These parameters include:
Review cycle and order control
Due order processing
Investment buy attributes
Scaling constraints
Rounding attributes
Supplier minimums
Truck splitting constraints
Items can be set up for automated replenishment through the Item Maintenance dialog, either individually or through item lists.
Automated replenishment also supports different methods to determining whether purchase orders are created and quantities ordered. These replenishment methods are applied at the item/location.
Constant is a stock-oriented method in which the item is replenished when the inventory level falls below a specified level.
Min/Max is a stock-oriented method in which the item is replenished up to the maximum when the inventory level falls below a specified minimum stock level.
Floating Point is a stock-oriented method in which the item is replenished when the inventory level falls below a dynamic system-calculated maximum stock level.
Time Supply is a stock-oriented method in which replenishment is based on the number of days of supply for the item a retailer wants in inventory. The Time Supply method requires a forecasting system.
Time Supply Seasonal is the same as Time Supply, but it takes seasonality and terminal stock into account. The Time Supply Seasonal method requires a forecasting system.
Time Supply Issues is used only by warehouses, this is the same as Time Supply, but it uses warehouse issues forecast rather than store sales forecast. The Time Supply Issues method requires a forecasting system.
Dynamic is a method that controls inventory using dynamic calculations of order point and order quantities based on a number of factors, including forecast sales over order lead time, review lead time, inventory selling days, lost sales factor, and safety stock. The Dynamic method requires a forecasting system.
Dynamic Seasonal is the same as Dynamic, but it takes seasonality and terminal stock into account. The Dynamic Seasonal method requires a forecasting system.
Dynamic Issues is used by warehouses only, this is the same as Dynamic, but it uses warehouse issues forecast rather than store sales forecast. The Dynamic Issues method requires a forecasting system.
Store Orders is a method that allows replenishment to look at the store order need quantity when determining the recommended order quantity.
The Franchise Management allows the retailer to manage their franchise business in the following scenarios:
Retailer owns and manages the inventory for a franchise location.
In this case, the franchise customer (location) needs to be set up as stockholding stores in RMS, with a store type as Franchise. A stockholding franchise store functions similar to a company store with locations of inventory transactions such as Replenishment, Allocation, Stock Counts and Inventory Adjustments being allowed for such stores in RMS and the pricing being carried out in RPM. The main differences in these stores are, the way in which the orders are captured and accounted financially.
Retailer does not own or manage inventory for a franchise location.
Here the retailer does not manage the inventory for a franchise location or wherein the wholesale operations constitute a small fraction of the retailers business and thus does not warrant a separate Order Management System.
In both these scenarios, non-stockholding stores must be setup in RMS to represent these franchise (or wholesale) customers.
Franchise pricing determines the price that is charged on a franchise partners for an item. Pricing for these stores is maintained in the future cost table. The pricing for franchise locations are determined by setting up cost templates in RMS and associating these templates with an item or a franchise location. Franchise pricing includes any landed costs and applicable deals through deal pass-through to the final pricing.
The user has an option to override the future cost franchise price and instead define a fixed price to be charged for an item for manually or through the batch upload orders.
Franchise store can source the merchandise from company locations (Warehouse or Store) or from a supplier. The franchise order can be initiated manually using the franchise order form or by an batch upload process using flat file received from an external application. The franchise order created using the flat file also creates a purchase order for supplier sourced and transfers for company location sourced orders.
In addition, franchise order gets initiated in response to any inventory transaction process where the receiving location is a franchise store and the sending location is a company location or supplier. Some of these inventory transactions are Replenishment Requests, Allocation, Store Orders, Items requests; AIP generated Purchase Orders or Transfers, and externally generated transfers.
Franchise stores returns the items back to the company location (warehouse or store). Item return from a franchise store directly to the supplier is not allowed. The franchise returns can either be a physical return to the company location or can be a book return. Book Return is possible when the item is destroyed at the site, in such scenario the inventory is not physically returned but can be financially accounted.
The franchise return can be initiated manually using the franchise return form or by batch upload process using flat file received from an external application. Franchise returns results in creating a transfer to track the inventory movement.
In addition, franchise returns gets created in response to any inventory transaction where the sending location is a franchise store and receiving location is a company location. Some of these processes are AIP or externally generated transfers.
The stock ledger in RMS records the financial results of the merchandising processes such as buying, selling, price changes, and transfers. All of these transactions are recorded in the RMS stock ledger and rolled up to the subclass/location level for days, weeks, and months, depending on calendar settings. The aggregate levels in the stock ledger are used to measure inventory amounts and merchandise profitability. The stock ledger is mainly used for reporting purposes; however, there is some online visibility as well.
The stock ledger supports multiple currencies. All transaction-level information is stored in the local currency of the store or warehouse where the transaction occurred. As transaction-level information is rolled up to the aggregated levels in the stock ledger, records are kept in local currency and converted to primary currency. This allows corporate reporting to be performed in the primary currency of the company, while still providing visibility by location to the profitability in the local currency.
The stock ledger supports both the retail and cost methods of accounting. The cost method can use standard cost or average cost, depending on how the system is configured. The stock ledger supports both the retail (4-5-4) and the normal (Gregorian) calendar. If the retail calendar is used, data is maintained by the 4-5-4 month and the week. If the normal calendar is used, data is maintained only by the Gregorian month. Data can also be maintained daily using the retail (4-5-4) or normal (Gregorian) calendar.
RMS supports multiple sets of books. Clients that use multiple sets of books assign RMS locations to a particular set of books defined in an external financial system. Changes to the stock ledger affect the set of books with which a particular transaction is associated.
Investment buy facilitates the process of purchasing inventory in excess of the replenishment recommendation in order to take advantage of a supplier deal or to leverage inventory against a cost increase. The inventory is stored at the warehouse or in outside storage to be used for future issues to the stores. The recommended quantity to investment buy, that is, to order, is calculated based on the following:
Amount of the deal or cost increase
Upcoming deals for the product
Cost of money
Cost of storage
Forecasted demand for the product, using warehouse issue values calculated by Oracle Retail Demand Forecasting
Target return on investment (ROI)
The rationale is to purchase as much product as profitable at the lower cost and to retain this profit rather than passing the discount on to customers and stores. The determination of how much product is profitable to purchase is based on the cost savings of the product versus the costs to purchase, store and handle the additional inventory.
Investment buy eligibility and order control are set at one of these four levels:
Supplier
Supplier-department
Supplier-location (warehouse locations only)
Supplier-department-location
Warehouses must be enabled for both replenishment and investment buy on RMS WH (warehouse) table.
The investment buy opportunity calculation takes place nightly during the batch run, after the replenishment need determination, but before the replenishment order build. The investment buy module IBCALC.PC attempts to purchase additional inventory beyond the replenishment recommendation in order to achieve future cost savings. Two distinct events provide the incentive to purchase investment buy quantities:
A current supplier deal ends within the look-ahead period.
A future cost increase becomes active within the look-ahead period.
The calculation determines the future cost for a given item-supplier-country-location for physical warehouse locations only.
If the order control for a particular line item is buyer worksheet, it might be modified in the buyer worksheet dialog, and can be added to either new or existing purchase orders.
RMS provides essential information to all of the Oracle Retail Merchandising Operations Management applications (ReSA, RTM, RPM, ReIM, Allocation), and interacts with all of them. RMS exists on the same database schema as all of the other applications, which provides flexibility in how information is shared between RMS and the other Oracle Retail Merchandising Operations applications.
Information is shared with other Oracle Retail Merchandising Operations Management applications through direct reads from Oracle Retail Merchandising Operations Management application tables, calls to Oracle Retail Merchandising Operations Management application packages, batch processes, and the Oracle Retail Integration Bus (RIB) if the client is using this option.
The following diagram illustrates the RMS location in the merchandising footprint.
Oracle Retail Trade Management (RTM) and RMS share the same database instance. When RTM is enabled in an RMS instance, certain import-specific data maintenance is required for country, supplier, partners and items. These are directly updated into the RMS database and subsequently used in RTM.
Oracle Retail Sales Audit (ReSA) and RMS share the same database. ReSA shares some of its master data with RMS. Foundation data such as stores a company/location close dates, location traits, bank setup and tender types are maintained in RMS and used in ReSA.
Current reference data is retrieved from RMS into ReSA by the batch program SAGETREF. The data is extracted into multiple data files. The data in the files is used by the batch program SAIMPTLOG as reference data for doing validation checks on the POS/OMS transaction data during the data upload to ReSA. Having the reference in data file formats increases the performance of the SAIMPTLOG process. SAGETREF generates the following reference files:
Items
Wastage
Sub-transaction level items
Primary variant relationships
Variable weight PLU
Store business day
Code types
Error codes
Store POS
Tender type
Merchant code types
Partner vendors
Supplier vendors
Employee IDs
Banner IDs
Along with the reference files, the following files are generated:
Promotions File - This file contains RPM promotions.
Currency File - This file contains valid currency codes in RMS.
Warehouse File - This file contains valid physical warehouses from RMS.
Inventory Status File - This file contains valid inventory status values from RMS.
All clean and audited sales and returns data is extracted from ReSA into a POSU file by the batch program SAEXPRMS. All sale and return transactions that do not have RMS errors are extracted into the file. The sales audit system options parameter work unit controls the export of data into files in case of the presence of RMS errors in the POS/OMS transaction data. The shell scripts UPLOADSALES.KSH and SALESPROCESS.KSH will load the data from the POSU file into the RMS tables.
RPM exists on the same database schema as RMS which allows information to be shared between applications through direct database reads, package calls, and batch processes. RPM uses APIs to facilitate the exchange of information with RMS.
RPM provides the following to RMS:
Regular Price Event Approval/Modification/Deletion-Regular price event creation, modification, or deletion triggers a call to an RMS API to generate (or remove if deleting) the ticket request information.
Price Event Execution- For regular, promotional, or clearance price events that end or are set to go into effect, the PriceEventExecutionBatch owns the process. When the pricing event has been processed by the batch program it updates item/location pricing in RMS by interfacing with the RMSSUB_PRICECHANGE API in RMS.
Initial Pricing-Initial pricing for items in RMS is dependent upon the primary zone group for the item defined in RPM and characteristics of that zone group. These characteristics include markup percent, markup percent type, and pricing guides. RPM provides this information to RMS through an API (MERCH_ RETAIL_API_SQL).
Deal Creation- For Price Changes and Clearances, RPM creates new details under existing deals. Promotions can create new deals in addition to creating details under existing deals. When this occurs RPM uses an RMS API (PM_DEALS_API_ SQL) to create the deal in RMS.
RMS provides the following to RPM:
Foundation Data is essential to RPM functionality. To successfully set up price changes RPM requires RMS merchandise hierarchy, organizational hierarchy, and suppliers. RPM is able to access this information through the RMS database.
Item-Price changes created in RPM ultimately relate to an item/location within RMS. RPM must know all eligible items currently in the merchandising system, the locations at which they are eligible (item/location relationships) in any status and the suppliers associated with the items. RPM can access this information through the RMS database.
Competitive Pricing Information-RPM has the ability to create price changes based off competitive activity in the marketplace. RPM is able to access this information through the RMS database.
Deals can be associated with price changes in RPM (including vendor funded promotions). In order to associate a price change to an existing deal RPM needs visibility to the deals currently available in the RMS system. RPM is able to access this information through the RMS database.
Event Notification -To ensure appropriate processing, RPM must be notified of certain events:
Store/Warehouse Creation-A zone structure must be added to RPM when new stores and warehouses are created in RMS. To do this RMS provides RPM with the store and/or virtual warehouse being added, its pricing location, and its currency (to ensure it is the same as the zone it is being added to). A store/virtual warehouse creation event in RMS triggers an API call to RPM to perform the necessary processing.
Item/Location Creation-When new item/location relationships are established, RPM must verify that no future retail records currently exist, create an initial future retail record (for sellable items), and determine if there are existing price changes that would affect the item resulting in a future retail record for the price change as well. An item/location creation event in RMS triggers data to be staged in RPM so that it is picked up for the batch processing.
Item Modification is used to notify RPM when an item is reclassified. The details of the reclassification are written to an item modification table in RPM for the next batch processing run. An item modification creation event in RMS triggers an API call to RPM to perform the necessary processing.
Department Creation is used to notify RPM when new departments are created in RMS. RPM creates aggregation-level information for the new department using predefined system defaults. A department creation event in RMS triggers an API call to RPM to perform the necessary processing.
RMS provides the following to Allocation:
Foundation Data is essential to all areas of Allocation including valid locations to allocate to and from, location groupings, and valid merchandise hierarchies to allocate within.
Item-Allocations are generated at the item location level so it is necessary that the Allocation application understand what items and item/locations are eligible in the system.
Purchase Order-One of the sources from which a user can allocate. Allocation relies on RMS to provide Purchase Order information.
Transfer-One of the sources from which a user can allocate. Allocation relies on RMS to provide Transfer information.
Bill Of Lading (BOL)-One of the sources from which a user can allocate. Allocation relies on RMS to provide BOL information.
Advance Shipment Notices (ASN)-One of the sources from which a user can allocate. Allocation relies on RMS to provide ASN information.
Inventory-In order to determine the correct need at an item location level before performing an allocation the application needs visibility to the current on hand inventory at each location being allocated to. Allocation relies on RMS to provide inventory information at the item/location level.
Sales Information-Allocation can use historical sales, forecast sales, and plan sales in order to determine the need at an item/location level for an allocation. Allocation interfaces this information in from external planning system to an Allocation table.
Allocation provides the following to RMS/RTM/ReSA:
Foundation Data is essential to all parts of invoice matching including valid locations for Invoices to be implemented at, valid suppliers to receive invoices from, and supplier addresses to send credits and debits based on invoice matching results.
Item is essential to the invoice matching process as item information ensures that invoices being received are valid for the business. For example an item received on an invoice is carried by the client, is supplied by the supplier who sent the invoice, and is carried in the locations for which the item was received.
Purchase Orders are used by Invoice Matching to facilitate the invoice matching process which is performed at the purchase order location level.
Shipments-Shipment information is used by Invoice Matching to determine if a PO has been received yet which affects the matching algorithm used by the AutoMatch batch program in Invoice Matching.
Deals and Rebate-Invoice Matching creates credit memos, debit memos, and credit requests based on deal and rebate information in RMS for processing by the financial (AP) system. This is performed by the ComplexDealUpload and FixedDealUpload batch processes that read from RMS staging tables.
Invoice Matching provides the following to RMS:
Invoice Matching results for shipments-Shipment records are updated with the invoice matching results from the invoice match process (this involves updating the match status and quantity matched of the shipments in question). The matching process is handled by the AutoMatch batch process in Invoice Match which attempts to match all invoices in ready-to-match, unresolved, or multi-unresolved status.
Receiver Cost Adjustments-An API is executed when invoice matching discrepancies are resolved through a receiver cost adjustment. The API updates the purchase order, shipment, and potentially the item cost in RMS, depending on the reason code action used.
Receiver Unit Adjustments-An API is executed when invoice matching discrepancies are resolved through a Receiver Unit Adjustment. The API updates the purchase order and shipment in RMS to complete the transaction.
Closing unmatched shipments-Invoice matching closes the invoice matching status for shipments in RMS after a set period of time (defined by the client in system options). This updates the invoice matching status of the shipment on the shipment table in RMS. This process is managed by the ReceiptWriteOff batch program.
RMS provides the following to Xcenter/Xstore:
Foundation Data - This data is essential to the Xcenter/Xstore suite functionality. This includes the following:
Full organizational hierarchy to support functionality such as rolling out new keyboard configurations by region, etc.
Stores including their addresses
Full merchandise hierarchy to support Xcenter/Xstore reporting functionalities.
Differentiators and differentiator groups to support functionality such as looking up a sku by style/color.
Item - Item information is generated at both the corporate and location level specific files and are sent to the Xcenter/Xstore application. Item information being sent includes the Item header, Item/Location, VAT Item, and Related Item information.
|
Note: The Oracle Retail Merchandising System interfaces can integrate with other third party Point of Sale applications. |
RXM is the Retail eXtension Module which extends the core RMS data to the Oracle Commerce applications. RMS leverages Bulk Data Integration (BDI) to interface data from RMS to RXM. BDI (Bulk Data Integration) is an integration system that facilitates the bulk transfer of data between Oracle Retail applications. On this particular integration stream, the data flow is from RMS to RXM. RMS publishes full set data snapshots for RXM to consume. This information will be used to support Commerce Anywhere v2.0 business requirements. To accomplish this data transfer, BDI will be calling RMS owned API's that will pull data and deliver these to the BDI integration layer. These API's will be divided into multiple functional entities, each contained in its own PLSQL package.
Differentiators: Groups, IDs
Items and Item/Locations, Related Items
Merchandise Hierarchy
Stores, Store Addresses
Warehouse Available Inventory
Store Available Inventory
Because different retailers have different rules that they want to apply for their business in order to meet their own specific business processes, RMS supports the ability for retailers to configure custom rules for certain areas of RMS by providing an API that can be used to call a PL/SQL function. This process allows for configuration without modification to base code, which might impact the ability to apply patches or upgrade. Currently, this is supported for Item and Purchase Order approval, as well as for VAT calculations when RMS is configured to run in a simple VAT configuration. Some examples of how this could be used include:
Ensuring all transaction level items are not approved before reference item has been created for the item.
Preventing purchase orders from being approved if a factory has not yet been associated with the order.
Using alternative rates for calculating tax for certain items based on custom flex attributes (CFAS), when running RMS in a simple VAT configuration.
For items and purchase orders, a configurable API function is used. The package function is supplied by the retailer and contains the additional validations that should be performed for items or POs. The name of the function is entered into a configuration table, which allows it to be called by RMS base code. For VAT this works a bit differently, but conceptually supports the same concepts - allowing retailers to configure a process in RMS without modifying base code. The approaches for both are described in the sections below, along with the general guidelines that retailers and integrators should follow.
To configure RMS to use custom approval rules, records must be added to the CUSTOM_PKG_CONFIG table. This table holds the schema and package/function names defined by a retailer to be called for a particular entity. Each custom function to be called from base RMS must have an entry in this table. The key fields in this table are:
| Column Name | Notes |
|---|---|
| SCHEMA_NAME | The schema where the custom package function is compiled. |
| PACKAGE_NAME | This should be the name of the retailer's custom package, if applicable. This should be left blank if the custom code is a function without a package. |
| FUNCTION_NAME | The name of the retailer's custom function or package function within the package noted above. Only PL/SQL functions are allowed as custom code in this table, either standalone PL/SQL functions or as part of a package. Procedures are not allowed because RMS expects a return value to determine if the execution was successful or not. |
| FUNCTION_KEY | This value determines which part of RMS the function will be called from.
If the retailer wishes to use the same package function for more than one task, the schema name, package name, and function name will be the same for each records, while the function key will be different for each function. For example, to use the same package function for order approval through replenishment, UI, Store Orders or PO Induction, three records would need to be inserted into CUSTOM_PKG_CONFIG. One record will have a function key value set to |
Cost Change Submit and Approval Function Keys
|
|
Inventory Adjustment Creation Function Key
|
|
Item Approval and Submission Function Keys
|
|
Mass Return Transfer (MRT) Submission and Approval
|
|
Purchase Order Approval Function Keys
|
|
Replenishment Attribute Activate and Deactivate
|
|
RTM Finalization
|
|
RTV Submission and Approval
|
|
Supplier and Partner Activate and Deactivate
|
|
Transfer Submission and Approval Function Keys
|
|
| CALL_SEQ_NO | This indicates the sequence of the custom code to be executed. This must be set to 1. The calling function would need to be customized when using more than one package function for a particular function key. If retailers have more than one function that needs to be called it is recommended that these be called in the correct sequence from the package function indicated in this table. |
The custom function (CALL_CUSTOM_SQL.EXEC_FUNCTION) is called in the RMS code as described above. This package determines which custom code is to be executed by querying the CUSTOM_PKG_CONFIG table based on the function key and the call sequence number passed in. After the custom code schema, package, and function names are retrieved, it calls the custom code via Dynamic SQL and passes the input payload. The inputs required for the custom functions should be as follows:
| Input | Input/Output | Type | Comments |
|---|---|---|---|
| O_ERROR_ MESSAGE | In/Out | RTK_ ERRORS.RTK
_TEXT |
Errors returned from the function must exist on the RTK_ERRORS table in RMS to ensure that messages are properly displayed in standard RMS error handling. |
| O_ORD_ APPRERR_ EXIST | In/Out | BOOLEAN | This is only used for PO approval package functions. It works with the error message parameter and in the case of any custom validation failures, the parameter should be set to TRUE and the error message parameter should be populated accordingly. |
| IO_CUSTOM_ OBJ_REC | In/Out | CUSTOM_ OBJ_REC | This is PL/SQL TYPE object which has placeholders for base RMS to pass the input parameters to the custom code. The calling function will pass the following to this object:
|
Consider the following notes:
The custom function return type must be BOOLEAN. No other data type is allowed.
In case of fatal errors, the custom function should return FALSE along with an appropriate error message in the output variable.
Errors for item approval should be coded to write to the item approval errors (ITEM_APPROVAL_ERROR) table, similar to base approval rule violations. This will ensure that the approval rules are applied seamlessly for the end user. The custom package should return FALSE to the calling function only if exceptions occur. If there are no exceptions, but only item approval errors, the package should return TRUE.
When using the Order Subscription API (Xorder) or the Store Order Subscription API, the errors will be propagated to the calling function. Approval errors encountered during other methods of PO induction (e.g. spreadsheet upload or bulk upload) are logged in an error table, together with the other order creation validation issues.
For PO approval, the custom package should return TRUE to the calling function when only validation errors are encountered and the O_ORD_APPRERR_EXIST parameter should be set to TRUE.
An example package specification for items is as follows:
CREATE OR REPLACE PACKAGE MY_OWN_ITEM_APPROVAL AS ------------------------------------------------------------------------------- This function checks whether items that are to be approved have comments FUNCTION CHECK_COMMENTS (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, IO_custom_obj_rec IN OUT CUSTOM_OBJ_REC) RETURN BOOLEAN; ------------------------------------------------------------------------------- END MY_OWN_ITEM_APPROVAL; An example package specification for POs is as follows: CREATE OR REPLACE PACKAGE MY_OWN_APPROVAL_RULES AS ------------------------------------------------------------------------------- This function checks whether orders exist. FUNCTION CHECK_PRESENCE (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_apprerr_exist IN OUT BOOLEAN, IO_custom_obj_rec IN OUT CUSTOM_OBJ_REC) RETURN BOOLEAN; ------------------------------------------------------------------------------- END MY_OWN_APPROVAL_RULES;
The configurations set at both the system level and the VAT region level determines how RMS calculates tax for various transactions. The following diagram describes this process:
At a system level, the tax calculations in RMS are governed by the system option called Default Tax Type. The tax type options are:
SALES - which is used for US only implementations and results in no tax calculations within RMS.
GTAX - which is used for Brazil implementations and assumes the taxes are calculated by an external tax engine via Oracle Retail Fiscal Management (RFM).
SVAT - which is used for all other implementations of RMS in which one or more locations for the retailer are subject to value added tax (VAT).
For SVAT implementations, retailers can additionally configure the tax processing in RMS by VAT region as follows:
Simple - VAT Regions defined as having a tax calc type of 'Simple' will have VAT computation based on the existing logic in TAX_SQL that uses rates defined for items to compute VAT on the transaction.
Exempt - VAT Regions defined having a tax calc type of Exempt will not support VAT computation for transactions occurring in this region. For example, this is what would be used for US locations in an implementation that also contains locations for which VAT is applicable.
Custom Tax - VAT Regions having a tax calc type of Custom will use Custom Taxation Rules that need to be defined by the retailer. The configuration required to implement this functionality is described in this section.
|
Note: If only one entity or location is passed into the tax function as described in the diagram above, then the tax calculation function behavior will be based on the tax calculation type of that entity or location. If the transaction involves two entities or locations (e.g. transfers), the tax calculation support will be based on the below matrix. |
| Location A* | Location B* | Tax Calculation Support |
|---|---|---|
| Simple | Simple | If Entities A and B lie in the same VAT Region, base simple VAT rules used. If different regions, VAT calculated as zero. |
| Simple | Exempt | VAT calculated as zero |
| Simple | Custom | Custom function executed |
| Exempt | Simple | VAT calculated as zero |
| Exempt | Exempt | No VAT calculation performed |
| Exempt | Custom | Custom function executed |
| Custom | Simple | Custom function executed |
| Custom | Exempt | Custom function executed |
| Custom | Custom | Custom function executed |
*Location could refer to a store or warehouse, or to a supplier, partner or other entity.
|
Note: For VAT regions flagged as custom, VAT codes and rates are expected to be set up, even though the VAT code may not solely determine the tax behavior in all cases. |
The CUSTOM_TAX_SQL package has been created for defining custom rules. This package contains the below functions:
CALC_CTAX_COST_TAX - which is used for cost-based VAT calculations
CALC_CTAX_RETAIL_TAX - which is used for retail-based VAT calculations
ADD_CTAX_RETAIL_TAX - which is used for mark-up calculations
The input and output parameters of these functions are same as those passed to the base tax function.
Inputs:
Item
From Location
To Location
Tax Type - Cost, Retail, or Both
Transaction ID (e.g. PO number)
Outputs:
Tax Code
Tax Rate
Tax Amount
Tax Exempt flag (Y or N)
Error Message
However, the function body for each of these functions will not contain any logic for identification of the applicable tax rates or computation of the tax amount. The logic to achieve this will need to be added by the retailer as part of implementation. The logic written within these functions is not limited to using just the parameters passed as part of the call and can fetch additional data points required to calculate taxes, as needed. Any failures in VAT calculation logic in any of these functions should be configured to return an output error message. This error message must be added to the RTK_ERRORS table or an existing error message from that table could also be used.
This section gives an overview about the RMS ReSTful Web service Implementation API designs used in the RMS environment and various functional attributes used in the APIs. Retailers can access back end functionality by calling the application's ReSTful Web services. For more information on ReST architectural style applied for building Web services, access the following URL:
http://www.oracle.com/technetwork/articles/javase/index-137171.html.
The RMS ReSTful Web services are based on a mobile application defined by Oracle Retail. The services are designed to support the mobile application functionality.
The main objective of the ReSTful Web service is to support mobile applications, some of the services functionalities may not be useful for general use.The services are used for client's custom mobile application. The ReSTful Web services Java code cannot be customized, but the MBL PL/SQL functions and object types can be customized for a client use. In addition, the client uses the RSE tool to create their own custom services in place of the ReSTful Web services.
RMS packages its ReST services in RmsRestServices.ear as part of the application's Enterprise Archive (EAR) file. Specifically, those services are packaged as a Web Archive (WAR) within the EAR.
See the RMS Installation Guide for instructions on deployment of the ReST web services.
Services are secured using J2EE-based security model.
Realm-based User Authentication: This verifies users through an underlying realm. The username and password is passed using HTTP Basic authentication.
Role-based Authorization: This assigns users to roles, which in turn are granted or restricted access to resources/services. The authorization of ReSTful web services is static and cannot be reassigned to other rules post installation. The following role is associated with ReSTful Web Services and should be added to the Enterprise LDAP if not already exists for RMS Application:
| ROLE_NAME |
|---|
| RMS_APPLICATION_ADMINISTRATOR |
| BUYER |
All enterprise roles defined above are mapped in web.xml and weblogic.xml of the ReST Service webapp.
The communication between the server and the client is encrypted using one way SSL. In a non-SSL environment, the encoding defaults to BASE-64 so it is highly recommended that these ReST services are configured to be used in production environments secured with SSL connections.
RMS user data security is implemented in the APIs. The application user ID should be added to the RMS SEC_USER.APP_USER_ID table then associated to the appropriate group in SEC_USER _GROUP table
Retail Application ReSTful Web services have the following standard HTTP headers:
Accept: application/xml or application/JSON Accept-Version: 14.1 (service version number) Accept-Language: en-US,en;q=0.8
Depending on the type of the operation or HTTP method, the corresponding response header is updated in the HTTP response with the following codes:
GET/READ : 200
PUT/CREATE : 201 created
POST/UPDATE : 204
DELETE : 204
Example response payload in case of service error is shown below:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <messagesRDOes> <messagesRDO> <message>REST Service Version Mismatch</message> <messageType>ERROR</messageType> <status>BAD_REQUEST</status> </messagesRDO> </messagesRDOes>
Message: The error message - translated.
MessageType: Value of 'ERROR' is returned.
Status: For a bad request or error, the status is BAD_REQUEST.
The http error code for an error response is 400.
The following links provide access to the Web services:
To access the RMS ReSTful web services javadoc:
http://<host:port>/RMSReSTServices
To access the RMS ReSTful web services' WADL file:
http://<host:port>/RMSReSTServices/services/private/application.wadl
To access the RMS ReSTful web services:
http://<host:port>/RMSReSTServices/services/private/<service>
Some of the RMS ReSTful Web services have the potential to bring back a large number of records and therefore these services are equipped to segmenting the result into pages. The page number to retrieve and the size of the page are added as input parameters to all the paged services.
Each paged result includes the following information:
Total Record Count: Displays the number of all records matching the service input criteria.
Next Page URL: Shows the service URL with same input parameters, but with the pageNumber plus 1, when more records exists.
Previous Page URL: Shows the service URL with same input parameters and the pageNumber input value minus 1, when page number is not 1.
Next or previous page URL is not provided when:
No records are returned.
Previous page is not returned, when the page number is 1.
Next page is not returned, when the record reaches the last page.
The hierarchy terms used by RMS like department or class may not be the terms used by the retailer to call the merchandise hierarchy. They may be referring to these levels as Category and Sub-Category. The dynamic hierarchy capability of RMS allows retailers to configure at install time 15 hierarchy terms.
The UI labels and message along with code_detail description and rtk_errors message have tokens like @MHP4@ which refers to Department. The mapping of tokens to the default RMS terms and to custom client's terms is maintained in the table dynamic_hier_token_map and this table is loaded during installation using the script dynamic_hier_token_map.sql. During the installation process, the tokens in ADF bundle files inside the application ear and the tokens in code_detail and rtk_errors tables gets replaced with a client provided value for these tokens. If the client provided value is not available, the tokens get replaced with the RMS default value.
|
Note: The dynamic hierarchy support in the previous version was carried out by run-time token replacement in the strings. The token replacement now happens during install and patch time to avoid performance overhead for every message and label during runtime. |
If the retailer wants to use to use the dynamic hierarchy capability to use different terms to refer to the hierarchy terms, they should update the script dynamic_hier_token_map.sql with their client value of the token as a pre-installation step. The dynamic hierarchy strings can be changed post installation by updating the client value in the dynamic_hier_token_map table and running the installation again to replace the tokens with the new value for client value.
The list of dynamic hierarchy tokens and its default RMS terms are listed below.
| Token | RMS Value | Token | RMS Value |
|---|---|---|---|
| @COM@ | Country Of Manufacture | @COMN@ | Countries Of Manufacture |
| @MH2@ | Division | @MHP2@ | Divisions |
| @MH3@ | Group | @MHP3@ | Groups |
| @MH4@ | Department | @MHP4@ | Departments |
| @MH5@ | Class | @MHP5@ | Classes |
| @MH6@ | Subclass | @MHP6@ | Subclasses |
| @OH1@ | Company | @OHP1@ | Companies |
| @OH2@ | Chain | @OHP2@ | Chains |
| @OH3@ | Area | @OHP3@ | Areas |
| @OH4@ | Region | @OHP4@ | Regions |
| @OH5@ | District | @OHP5@ | Districts |
| @SUH1@ | Manufacturer | @SUHP1@ | Manufacturers |
| @SUH2@ | Distributor | @SUHP2@ | Distributors |
| @SUH3@ | Wholesaler | @SUHP3@ | Wholesalers |
| @SUH4@ | Franchise | @SUHP4@ | Franchisee |
|
Note: The dynamic hierarchy is translation supported and the translation entries are maintained in dynamic_hier_token_map_tl table. The installation token replacement replaces the tokens by language in code_detail_tl, rtk_errors_tl and the language bundle files in the application ear. |
Oracle Retail Operational Insights dashboards and reports provide pervasive business intelligence. To provide a seamless user experience, they are designed to be embedded within RMS application.
The RMS_OI_SYSTEM_OPTIONS table drives the configuration parameters for RMS Operational Insights Dashboards and reports. Default values are populated by seed data script during installation and can be changed later according to the customer requirements. Values for these parameters can also be defined at Department level using the RMS_ OI_DEPT_OPTIONS table. Department level values take precedence over the system level configuration.
| Report Name | System Option | Definition | Column Name | Department Level? |
|---|---|---|---|---|
| Cumulative Markon Variance | Variance threshold | A count of subclass/locations with variance higher that this number would result in tile turning Yellow or Red. | FA_CUM_ MARKON_VAR_ CRITICAL_CNT | No |
| Cumulative Markon Variance | Minimum Variance % | Configuration used to compare the CMO % of displayed month to the department budgeted intake %. | FA_CUM_ MARKON_MIN_ VAR_PCT | Yes |
| Early/Late Shipments | Beginning of Week to Estimated Arrival Date Duration | Number of days between beginning of week and Estimated Arrival Date to determine if an order qualifies as an OTB Shift In issue. | B_NUM_DAYS_ BOW_EAD | No |
| Early/Late Shipments | Estimated Arrival Date to Open to Buy Date Duration | Number of days between Estimated Arrival Date and OTB End of Week date to determine if an order qualifies as an OTB Shift Out issue. | B_NUM_DAYS_ EAD_OTB | No |
| Early/Late Shipments | Not After Date to End of Week Duration | Number of days between Not After Date and End of Week Duration. | B_NUM_DAYS_ NAD_EOW | No |
| Early/Late Shipments | Display OTB for Reports | This configuration allows the user to decide whether OTB should be shown in reports. | B_OTB_IND | No |
| Incomplete Items | Dimensions | Possible Values: Required, Optional and No.
This will determine whether the report will show dimension details. |
DS_SHOW_ INCOMP_ITEM_ DIMEN | Yes |
| Incomplete Items | HTS | Possible Values: Required, Optional and No
This will determine whether the report will show item HTS details. |
DS_SHOW_ INCOMP_ITEM_ HTS | Yes |
| Incomplete Items | Images | Possible Values: Required, Optional and No
This will determine whether the report will show item image details. |
DS_SHOW_ INCOMP_ITEM_ IMAGES | Yes |
| Incomplete Items | Import Attributes | Possible Values: Required, Optional and NoThis will determine whether the report will show item import details. | DS_SHOW_ INCOMP_ITEM_ IMP_ATTR | Yes |
| Incomplete Items | Locations | Possible Values: Required, Optional and No
This will determine whether the report will show Location details. |
DS_SHOW_ INCOMP_ITEM_ LOC | Yes |
| Incomplete Items | Minimum days past item creation | Specifies number of days post creation of items after which the item will appear in this report. | DS_DAYS_AFTER_ ITEM_CREATE | Yes |
| Incomplete Items | Reference Items | Possible Values: Required, Optional and No
This will determine whether the report will show reference item details. |
DS_SHOW_ INCOMP_ITEM_ REF_ITEM | Yes |
| Incomplete Items | Related Items | Possible Values: Required, Optional and No
This will determine whether the report will show related item details. |
DS_SHOW_ INCOMP_ITEM_ REL_ITEM | Yes |
| Incomplete Items | Replenishm ent | Possible Values: Required, Optional and No
This will determine whether the report will show replenishment details. |
DS_SHOW_ INCOMP_ITEM_ REPL | Yes |
| Incomplete Items | Seasons / Phases | Possible Values: Required, Optional and No
This will determine whether the report will show seasons/phases details. |
DS_SHOW_ INCOMP_ITEM_ SEASONS | Yes |
| Incomplete Items | Simple Packs | Possible Values: Required, Optional and No
This will determine whether the report will show Simple Pack details. |
DS_SHOW_ INCOMP_ITEM_ SPACK | Yes |
| Incomplete Items | Substitute Items | Possible Values: Required, Optional and No
This will determine whether the report will show substitute details. |
DS_SHOW_ INCOMP_ITEM_ SUBS_ITEM | Yes |
| Incomplete Items | Tickets | Possible Values: Required, Optional and No
This will determine whether the report will show ticketing details. |
DS_SHOW_ INCOMP_ITEM_ TICKETS | Yes |
| Incomplete Items | UDAs | Possible Values: Required, Optional and No
This will determine whether the report will show UDA details. |
DS_SHOW_ INCOMP_ITEM_ UDA | Yes |
| Incomplete Items | VAT | Possible Values: Required, Optional and No This will determine whether the report will show VAT details. | DS_SHOW_ INCOMP_ITEM_ VAT | Yes |
| Inventory Variance to Forecast | Low Lower Inventory Variance % | Specifies the lower limit of the lower threshold range which will limit the items returned in the table based on the inventory variance percentage for an item to the forecasted value. | IA_VARIANCE_ RANGE_PCT_3 | Yes |
| Inventory Variance to Forecast | Low Upper Inventory Variance % | Specifies the lower limit of the upper threshold range which will limit the items returned in the table based on the inventory variance percentage for an item to the forecasted value. | IA_VARIANCE_ RANGE_PCT_4 | Yes |
| Inventory Variance to Forecast, Order Alerts | Filter Location Type | Specifies if the user wants to see the inventory variance at the area level or at a store grade level. | IA_VARIANCE_ RANGE_PCT_1 | Yes |
| Inventory Variance to Forecast | High Lower Inventory Variance % | Specifies the upper limit of the lower threshold range which will limit the items returned in the table based on the inventory variance percentage for an item to the forecasted value. | IA_VARIANCE_ RANGE_PCT_3 | Yes |
| Inventory Variance to Forecast | High Lower Inventory Variance % | Specifies the upper limit of the lower threshold range which will limit the items returned in the table based on the inventory variance percentage for an item to the forecasted value. | IA_STORE_ GRADE_OR_ AREA_IND | No |
| Late Posted Transactions | Transaction Variance Threshold | If the count of late transactions per location is greater than this number the tile color will change to Yellow or Red. | FA_LATE_POST_ THRESHOLD_ TRN_CNT | No |
| Late Posted Transactions | Location Count threshold | If the count of locations with late transaction is greater than this number the tile color will change to Yellow or Red. | FA_LATE_POST_ THRESHOLD_ LOC_CNT | No |
| Late Posted Transactions | Organizatio nal Hierarchy Display Level | Configuration to define the level of organization hierarchy that the chart should display on its Y axis. | FA_LATE_POST_ ORG_HIER_LEVEL | No |
| Negative Inventory | Quantity Threshold | Indicates the count per item/location below which the item/loc should appear in this report. | IC_NEG_INV_ TOLERANCE_QTY | Yes |
| Unexpected Inventory | Item/Locati on Critical Count | A count of locations with unexpected inventory that is higher than this number would result in the related tile turning Red in the dashboard. | IC_UNEXP_INV_ CRITIAL_COUNT | Yes |
| Unexpected Inventory | Item/Locati on Warning Count | A count of locations with unexpected inventory that is higher than this number would result in the related tile turning Yellow in the dashboard. | IC_UNEXP_INV_ WARN_COUNT | Yes |
| Order Alerts | Include Factory Check | This option will control whether or not to check if a Factory has been associated with the order. | IA_ORD_ERR_ FACTORY_IND | No |
| Order Alerts | Validate Reference Items | This option will control whether or not to check for the existence of at least one Reference item for each item on the Order. | IA_ORD_ERR_ REF_ITEM_IND | No |
| Orders Pending Approval | Show Worksheet Orders | Determines whether orders in worksheet status will be shown in the report for approval. | B_PO_PENDING_ APPROVAL_ LEVEL | No |
| Overdue Shipments | Past Expected Receipt Date | Number of days since the transfer, allocation or RTV should have been received into a location, beyond which the transfer, allocation or RTV should be shown in the reports. | IC_OVERDUE_ SHIP_DAYS | No |
| Shrinkage Variance | Maximum Variance % | Will be used to determine the color of the tile (Red). | FA_SHRINKAGE_ VAR_MAX_PCT | No |
| Shrinkage Variance | Variance Count | Will be used to determine the color of the tile along with the variance value. | FA_SHRINKAGE_ VAR_CRITICAL_ CNT | No |
| Shrinkage Variance | Variance Tolerance % | Define the tolerance outside of which if the variance between budgeted shrinkage and actual shrinkage falls, that subclass/location will be shown in the report. | FA_SHRINKAGE_ VAR_ TOLERANCE_PCT | No |
| Stock Count Unit Variance | Variance Threshold % | Variance percent above or below what was expected on a count which determine if a location should appear on the report. | FA_STK_CNT_ VALUE_ TOLERENCE_PCT | No |
| Stock Count Value Variance | Variance Threshold % | Define the value variance tolerance % exceeding which the subclass/location will be displayed in the report. Open Q. Given that this is at the subclass location level can we re-use stake_cost_variance and stake_retail_variance. Number of days since the stock count, which if count results have not been received would trigger the count/location to appear in the report. | IC_MISS_STK_ COUNT_CRIT_ DAYS | No |
| Stock Counts Missing | Stock Count Location Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | IC_MISS_STK_ COUNT_CRIT_ CNT | No |
| Stock Count Unit Variance | Stock Count Unit Location Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | IC_STK_COUNT_ VAR_LOC_CNT | |
| Stock Count Value Variance | Stock Count Value Location Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | FA_STK_CNT_ VALUE_VAR_ CRIT_CNT | No |
| Stock Orders Pending Close | Past Receipt Date | Number of days since the transfer or allocation was received but is not yet closed, beyond which it should appear in this report. | IC_STKORD_CLS_ PEND_CRIT_DAYS | No |
| Transfers Pending Approval | Stock Order Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | IC_TSF_APPRV_ PEND_CRITIAL_ CNT | No |
| Stock Orders Pending Close | Stock Orders Pending Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | IC_STKORD_CLS_ PEND_CRIT_CNT | No |
| Overdue Shipments | Overdue Shipments Exception Count | This will determine whether the tiles for the applicable report is green, yellow, or red. | IC_OVERDUE_ SHIP_COUNT | No |
| Transfers Pending Approval | Past Creation Date | Number of days since transfer creation - determines whether a submitted transfer appears in this report. | IC_TSF_APPRV_ PEND_CRITIAL_ DAYS | No |
| Unexpected Inventory | Include Deleted Item/Locati ons | Indicates whether item/locations in deleted status with a ranged ind = Y should be included in this report if they have inventory. | IC_UNEXP_INV_ DELETE_IND | Yes |
| Unexpected Inventory | Include Discontinue d Item/Locati ons | Indicates whether item/locations in discontinued status with a ranged ind = Y should be included in this report if they have inventory. | IC_UNEXP_INV_ DISCONTINUE_ IND | Yes |
| Unexpected Inventory | Include Inactive Item/Locati ons | Indicates whether item/locations in inactive status with a ranged ind = Y should be included in this report if they have inventory. | IC_UNEXP_INV_ INACTIVE_IND | Yes |
| Unexpected Inventory | Quantity Threshold | Indicates the count per item/location above which the item/loc should appear in this report. | IC_UNEXP_INV_ TOLERANCE_QTY | Yes |
| WAC Variance | Maximum Variance % | This value will be used to determine the color of the tile, denoting the criticality along with # of item/locations. | FA_WAC_VAR_ MAXIMUM_PCT | No |
| WAC Variance | Variance Count | This value will be used to determine the color of the tile, denoting the criticality along with Max variance. | FA_WAC_VAR_ ITEMLOC_CNT | No |
| WAC Variance | Variance Tolerance % | Identifies the tolerance outside of which if the variance between unit cost and average cost falls, that item/location will show in the report. | FA_WAC_VAR_ TOLERANCE_PCT | No |
| Inventory Analyst Dashboard | Item Filter Display | Indicator to display all Item filters (Item/Item Parent/Parent Diff) in inventory analyst dashboard prompt. | IA_ITEM_ PARENT_FILTER | No |
| Variance to Forecast | Variance to Forecast Indicator | Indicates if the Inventory Variance to Forecast report in the Inventory Analyst dashboard is supported. If yes, the system will preserve 4 weeks of item weekly forecasted sales data before loading the next set of forecasting data. | IA_VARIANCE_ TO_FORECAST_ IND | No |
| Margin Impact Contextual Report | Margin Impact Month Range | Defines a Month Range Considered for Margin Impact Contextual BI Report | MI_MONTH_ RANGE | No |
When developing custom extensions for RMS, it is important to use the exposed APIs securely. This section contains guidelines for secure usage of these APIs.
If custom extensions produce output files, ensure that no sensitive data is written or that all files containing sensitive data are stored securely.
If sensitive data is written, zero out the data when it is no longer needed.
Audit access to custom functions that operate on sensitive data.
Do not write sensitive data to log files.
Validate all data coming from an untrusted source before passing it to the Merchandising Foundation application. The Merchandising Foundation application will validate incoming data; however, it is good practice to validate untrusted data before passing it along.
User IDs and passwords must not be hard-coded, shipped, or defaulted in the integrating application.
Passwords must not be stored in plaintext, either in a file or a database table.
Passwords must be stored in an encrypted format. Developers should not create their own password encryption mechanism. Consider storing passwords and other credentials in a wallet, or use an approved algorithm such as one recommended by National Institute of Standards and Technology.
If using Java, it is recommended that the user store all sensitive data in char arrays instead of strings so it can be zeroed out.
Error Handling:
Custom extensions must handle all exceptions securely. Care must be taken to respect data types and to process error conditions.
See the Oracle® Retail Merchandising System Operations Guide - Volume 2 for details on message formats and return codes.
For additional information on available APIs, see the Oracle® Retail Merchandising System Operations Guide - Volume 2.
Merchandising Foundation ReST services provide visibility to a limited amount of data. Custom extensions that utilize the ReST services must ensure that any sensitive data retrieved is handled in a secure manner. Potentially sensitive data exposed by the ReST services include:
System options
Supplier data
Purchase Order data
Transfer data
XML should be parsed using a well-known XML Framework.
The XML Framework settings should be updated to prevent XML External Entity (XXE) and XML Entity Expansion (XEE) attacks.
Disable external resource resolution, unless absolutely necessary. If this cannot be disabled, limit allowed values to a known set (whitelist).
Limit recursion depth.
Disable the ability for documents to specify their own DTD or XML schema, unless absolutely necessary. If this cannot be disabled, limit allowed values to a known set (whitelist).
Validate XML documents against the registered set of known DTDs or XML schemas applicable to the document. Reject non-compliant documents.
Subscription APIs modify records in tables that contain potentially sensitive information. Therefore, care should be taken to ensure that when an error message is returned, the error message is handled properly so as not to expose potentially sensitive information. For instance, an error message may confirm the existence of certain records in the system or may include record numbers. External applications should take this into consideration before logging errors or passing error messages to other external systems.
Publication APIs publish records that contain potentially sensitive information. Therefore, care should be taken to ensure that external systems handle this data securely when storing and transferring it.
Custom PL/SQL functions introduced via the Custom Package API should be reviewed for security vulnerabilities. It is the client's responsibility to ensure that custom functions operate securely.
Custom packages and functions should use invoker's rights (i.e. use the AUTHID CURRENT_USER clause when creating the package or function). This ensures that the code executes with the privileges of the current user, preventing it from executing with inadvertently elevated permissions.
