| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.027 E96477-01 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising Cloud Services Implementation Guide Release 16.0.027 E96477-01 |
|
Previous |
Next |
This chapter gives an overview of the information maintained by Merchandising and integration with other applications.
Merchandising 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 Merchandising 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 retail store in Merchandising.
The Franchise stores are used to support franchise business models. Other applications, such as RWMS, view franchise stores as they would view any other store in Merchandising; however, Merchandising 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 Merchandising. Supplier enrichment can be maintained in Merchandising.
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.
Merchandising is responsible for the creation and maintenance of all items. Merchandising 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.
Merchandising creates several types of items, such as regular items, deposit items, packs, concession items, consignment items, and transformable items.
Through item maintenance, Merchandising 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). Merchandising 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 Merchandising, 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. Merchandising 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 Merchandising, 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.
Estimated landed cost is the total cost of an item received from a vendor inclusive of the supplier cost and all costs associated with moving the item from the supplier's warehouse or factory to the purchase order receiving location. Merchandising facilitates the setting up of various cost components, associating them to the purchase orders, calculating the estimated landed costs at the time of purchase order creation.
Estimated Landed Cost (ELC) is composed of cost components from the Supplier, Trading Partners, Item and Origin Country, which are brought together during Purchase Order (PO) creation to develop an estimate of costs associated with purchasing a particular item on the current PO.
Expenses are direct and indirect costs incurred in moving a purchased item from the supplier's warehouse/factory to the purchase order receiving location. Expenses should not be confused with up charges, which allow add-on costs from an initial receiving location to a final retail location and are not part of the landed cost.
An example of a direct expense is the packing cost or insurance cost. Charges incurred for clearing and loading goods at the lading port are an example of indirect costs. Expenses are either added to the base inventory value or booked as a separate expense. Expenses apportioned to inventory affect the weighted average cost (WAC) of the item. Expenses can be assigned to a particular country, supplier, or partner. Expenses are tracked at country or zone levels, as the following defines.
Country level expenses track the costs of bringing merchandise from the origin country, through the lading port, to the import country's discharge port. For example, track expenses for a silk blouse from China, through the lading port, Hong Kong, to the discharge port, Los Angeles.
Zone level expenses track the costs of bringing merchandise from the import country's discharge port to the purchase order receiving location. For example, track expenses for a silk blouse from discharge port, Los Angeles, through to the retailer's New York City warehouse and to the retailer's Chicago warehouse. Costs are different based on the final destination (for example, longer truck route, railroad).
Zones are defined using the Cost Zone dialog. When the zones are created they are used to define expenses at the supplier level (by zone) for default to 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 Merchandising 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 Merchandising is the core of the application. Inventory is tracked perpetually and financially in Merchandising. The following describes perpetual inventory tracking. For information on financial inventory tracking, see Stock Ledger.
Merchandising 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 Merchandising provide an organized framework for monitoring the movement of stock. Merchandising creates and maintains transfers; however, you can also interface transfer information into RMS from other systems.
Merchandising 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 Merchandising 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 Merchandising 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 Merchandising or imported from an external system. Merchandising 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 Merchandising, 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 Merchandising or imported from an external system (store or warehouse application). Merchandising 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 Merchandising 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 Merchandising. |
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. Merchandising 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 Merchandising, 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 Merchandising. 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 Merchandising 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 Merchandising 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 Merchandising 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.
Merchandising supports multiple sets of books. Clients that use multiple sets of books assign
Merchandising 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.
Merchandising provides essential information to all of the Oracle Retail Merchandising Operations Management applications (Sales Audit, Trade Management, Invoice Matching, Allocation), and interacts with all of them. Merchandising exists on the same database schema as all of the other applications, which provides flexibility in how information is shared between Merchandising 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 and batch processes.
Trade Management and Merchandising share the same database instance. When Trade Management is enabled in an Merchandising instance, certain import-specific data maintenance is required for country, supplier, partners and items. These are directly updated into the Merchandising database and subsequently used in Trade Management.
Sales Audit and Merchandising share the same database. Sales Audit shares some of its master data with Merchandising. Foundation data such as stores a company/location close dates, location traits, bank setup and tender types are maintained in Merchandising and used in Sales Audit.
Current reference data is retrieved from Merchandising into Sales Audit 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 Sales Audit. 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:
Currency File - This file contains valid currency codes in Merchandising.
Warehouse File - This file contains valid physical warehouses from Merchandising.
Inventory Status File - This file contains valid inventory status values from Merchandising.
All clean and audited sales and returns data is extracted from Sales Audit into a POSU file by the batch program SAEXPRMS. All sale and return transactions that do not have Merchandising 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 Merchandising 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.
Merchandising 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 Merchandising to provide Purchase Order information.
Transfer-One of the sources from which a user can allocate. Allocation relies on Merchandising to provide Transfer information.
Bill Of Lading (BOL)-One of the sources from which a user can allocate. Allocation relies on Merchandising to provide BOL information.
Advance Shipment Notices (ASN)-One of the sources from which a user can allocate. Allocation relies on Merchandising 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 Merchandising 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 Merchandising/Trade Management/Sales Audit:
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 Merchandising for processing by the financial (AP) system. This is performed by the ComplexDealUpload and FixedDealUpload batch processes that read from Merchandising staging tables.
Invoice Matching provides the following to Merchandising:
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 Merchandising, 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 Merchandising to complete the transaction.
Closing unmatched shipments-Invoice matching closes the invoice matching status for shipments in Merchandising 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 Merchandising. This process is managed by the ReceiptWriteOff batch program.
Merchandising 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 SKUs by style/color.
Item - Item information is generated at both the corporate and location level specific files and is sent to the Xcenter/Xstore application. Item information being sent includes the Item header, Item/Location, VAT Item, and Related Item information.
|
Note: The Merchandising System interfaces can integrate with other third party Point of Sale applications. |
The hierarchy terms used by Merchandising 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 Merchandising 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 Merchandising 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 terms are listed below.
| Token | Default Value | Token | Default 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 Merchandising application.
The RMS_OI_SYSTEM_OPTIONS table drives the configuration parameters for Merchandising 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_2 | No |
| 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 | No |
| 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 | No |
| 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_2 | No |
| 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 | No |
| 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 | No |
| 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 | No |
| 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 |
