| Oracle® Retail Merchandising Implementation Guide Release 15.0 E65391-01 |
|
 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, retails 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 act as 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 taxation that results in an invoice. 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:
Allocations- When the allocations is moved to Approved or Reserved status, the Allocation is written to RMS tables to give visibility to the allocation results.
Purchase Orders created by What-If process in Allocation-If this option is enabled in Allocation the client can create a simulated allocation based on current need and then automatically create a purchase order from that Allocation in RMS to fulfill that need. Allocation uses an RMS API to build the purchase order in RMS.
RMS provides the following to Invoice Matching:
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.
ARI is a monitoring system that interacts with any applications database (including RMS). It stores the RMS database structure as metadata information, monitors the event defined by a client and notifies the client when the event occurs.
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. |
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.
In order to configure RMS to use this functionality, 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 that should be called from base RMS should have an entry in this table. The key fields in this table are:
Table 4-1 CUSTOM_PKG_CONFIG table columns
| 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. Valid values are:
Note: In custom order approval, if the retailer wishes to use the same package function for replenishment, UI, Store Orders or PO Induction, three records would need to be inserted into CUSTOM_PKG_CONFIG. The schema name, package name, and function name should be same for each of the three records each of which will bear a different function key value. |
|
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:
Table 4-2 Custom Function Inputs
| 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. |
Table 4-3 Custom Calculation 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.
