7 Existing Functionality Gaps

There are certain functionality gaps that exist in the integration that are not remedied at this time. This chapter describes these functional gaps.

RMS

Table 7-1 is a list of functionality gaps that exist for the RMS to Xstore integration.

Table 7-1 RMS to Xstore Functionality Gaps

Identified Functionality Gap
Xstore has functionality to configure non-physical items to be used for certain tasks, such as repairs, warranties, and shipping fees. However, the attributes needed to fully configure these items for processing in Xstore are not currently available in RMS. Therefore, to configure these types of items, a two-step process is needed. First, the items should be created in RMS as non-inventory and non-merchandise. Then, the same item, using the same item ID/barcode, is created in Xstore and assigned the needed attributes to drive processing. This will ensure the smooth handling of sales of these items between systems through ReSA, but will also ensure that these items will be filtered out of the item integration from RMS to Xstore, to avoid duplication after the initial configuration.
RMS does not provide kit components for a kit header. Kits will appear as standard items in Xstore.
RMS supports up to four differentiators for each item. Xstore supports only three. RMS Diff4 is ignored. If the fourth differentiator is used in RMS, it will be exported from RMS, but Xstore DataLoader will not load the fourth value.
Xstore item records support four merchandise levels. The RMS Item Header records contain only three Merchandise Hierarchy levels: Department, Class, and Subclass. The Group Merchandise Hierarchy level is not included, and therefore cannot be mapped to an Xstore merchandise level.
Xstore can support up to four levels of merchandise hierarchy. RMS supports five levels. Levels above group in the RMS hierarchy will not be used in Xstore. For store operations, the lower four levels of the RMS merchandise hierarchy (group, department, class, subclass) are the most important, so these are the levels integrated into Xstore.
The data type and length of the RMS field MfgRecRetail is Number(20). When provided, the MfgRecRetail value is used to populate the itm_item table's list_price column, which can contain a max of Number(17,6).
It is possible in RMS to range a child item to a store without also ranging its parent to the store. RMS items can be associated with diffs without having a parent item (for example, a broom is red; red is an attribute of the item, but there is no parent for brooms and the same broom is not available in other colors). Xstore must receive from RMS the parent item's information in order to take advantage of Xstore Style features. Without a parent item available to create a Style in Xstore's database, Xstore will not display dimension values such as size, color, and width for an L1 item having Diff ID assignments. In Xstore, a Style is an entry in the Item database that has properties such as size, color, width, and so. These properties are known as Dimensions in Xstore, and DIFFs in RMS. Multiple regular items may be associated with a Style ID. If you enter a Style ID in Xstore's Scan Item Prompt, the system prompts with additional item selection criteria by displaying dimension value choices. The Style ID, also known as the dimension system, is the RMS parent (or grandparent if one exists) of the transaction level item. If the RMS item used to represent a Style item in Xstore is not ranged to the store, items associated with the Style cannot be selected by scanning the Style ID. In addition, when a Style record does not exist in the database, the item dimension values are not displayed in the Xstore UI.
RMS items can be associated with DIFFs without having a parent item associated with one or more DIFF Groups. Without a parent item that can be set up in Xstore as an Item Style, these kinds of items will not be associated with a Dimension System.
RMS does not have a item restocking fee indicator.
The data type and length of the RMS field SellingUnitRetail is Number (20). When provided, the SellingUnitRetail value is used to populate the itm_item_prices table's price column, which can contain a maximum of Number (17,6).
In RMS, the data type of manufacture's recommended retail is NUMBER (20,4). In Xstore, the value is mapped to ITM_ITEM.LIST_PRICE, which is a NUMBER (17,6). If an RMS recommended retail value is over 17 digits, DataLoader into Xstore will fail for this record. Non-failing records from the same file will continue to be loaded.
RMS and SIM both support the concept that an item can be a serialized item in one store, but not in another. In Xstore, the SERIALIZED_ITEM_FLAG applies to an item in all locations. Serialized item is an item/location level flag in RMS, but an item level flag in Xstore. The Xstore DataLoader maps the item/location level information from RMS to the item level in Xstore. This means that if the serialized flag actually varies by location for an item in RMS, the last location to be processed by the integration code sets the item level serialized flag in Xstore.
RMS does not export Age and Quantity product restrictions.
RMS does not provide enough information in an ItemLoc record for the integration layer to identify above-transaction level items that do not need to be created as itm_item_options records. If above-transaction records are ranged to stores, which is likely, itm_item_options will be populated with records using Item IDs that do not exist in itm_item.
The ID displayed in the RMS UI for Class and Subclass is not the same ID as the numeric portion of the merchandise hierarchy displayed in the Xstore UI. RMS displays a display ID. Xstore's UI displays the RMS-supplied unique Class ID and Subclass ID (fields that are not displayed in RMS UI). The inconsistent display of identifiers in the two systems may cause some confusion.
RMS supports cross-sell and up-sell related item types. Xstore does not. RMS CRSL/UPSL records are mapped to Xstore's AttachedItems.
RMS supports creation of CRSL/UPSL items with above-transaction level parents; however this relationship is not useful in Xstore. In Xstore, both members of the relationship must be transaction level items.
Xstore's attached items can be auto-attached or prompt-to-attach. RMS does not have the same auto-attach concept, so attached items are always prompt-to-attach in Xstore.
RMS sends the VAT code for an item along with the active date for the VAT code to be applicable. Retailers use the active date for future planning. However, Xstore currently does not support an active date for VAT code: Xstore will ignore the active date for VAT code. Whenever the retailer sends the VAT code, the changes will be effective immediately. It is recommended that retailers send the VAT code change only when they need it.
Restocking fee is not maintained by RMS. Xstore Point of Service uses this to prompt for a restocking fee during returns.
Buying from a VAT store and returning to a non-VAT store (and vice versa) is not supported.
RMS product restrictions are not integrated to Xstore.
Packs are sent from RMS to Xstore as they are items. But pack details (the items that make up a pack) are not integrated. In Xstore, RMS packs are kits. Xstore does not have visibility to drill into kit components.
Xstore supports defining partial refunds for certain products based on item attribution. RMS does not export any attributes to support this Xstore functionality.
RMS does not manage coupons. Coupons should instead be managed in Oracle Retail Customer Engagement or another system that directly integrates with Xstore.
RMS UDAs and CFAS are not integrated to Xstore.
Xstore supports translation of some data; however, RMS only exports data in the primary integration language to stores. The exception to this is item description. RMS can hold a local item description at the item/location level. Retailers can use this to hold item descriptions in the store's local language or dialect.

RPM

Table 7-2 is a list of functionality gaps that exist for the RPM to Xstore integration.

Table 7-2 RPM to Xstore Functionality Gaps

Identified Functionality Gap
In RPM, the data type of selling unit retail is NUMBER (20,4). In Xstore, the value is mapped to ITM_ITEM_PRICE.PRICE, which is a NUMBER (17,6). If an RPM retail value is over 17 digits, DataLoader into Xstore will fail. Non-failing records from the same file will continue to be loaded.
RPM supports multi-buy promotions with a reward of cheapest free. Xstore does not support a cheapest free (Buy N and get Cheapest Free) promotion.
RPM and Xstore have different approaches to multi-unit pricing. RPM regular price update information for multiple units is not supported in this integration. Xstore converts multi-unit prices to single price, but cannot accurately do this without rounding information which varies from stores to stores.
RPM enables the execution of Finance Promotions. Xstore Point of Service does not support Finance Promotion components.
RPM integration includes customer segment information. Xstore does not support the integration.
RPM supports the integration of Multi-Buy promotions that use the OR condition between buy lists and/or reward lists. Xstore does not support the integration.
RPM supports the integration of threshold promotions with a qualifier of item level. Xstore does not support the integration.
When Simple Promotions are created in RPM, the retail for the Item Location is calculated based on the promotion criteria, rounding rules, and taking into consideration any promotion overlaps. The retail from RPM is provided to RMS, SIM, and Xstore. Xstore calculates a retail based on the promotion criteria; Xstore does not use the retail sent by RPM. This may cause an out of sync between RPM, RMS, SIM, and Xstore.

Xstore to ReSA Integration

Table 7-3 is a list of functionality gaps that exist for the Xstore to ReSA integration.

Table 7-3 Xstore to ReSA Integration Functionality Gaps

Identified Functionality Gap
Till ID is not available for retail transactions. Xstore workstation and ReSA register are equivalent concepts. ReSA does not have an entity equivalent to the Xstore till. When integrated with Xstore, ReSA should be configured with a balancing level of Register. Xstore always sends the workstation ID as the register. The separate concept of a till is not supported in the integration, so Xstore cannot be configured for till-level balancing when integrated with ReSA.
Bounce back coupon number length in Xstore can be 60 characters long, but ReSA only allows 16 characters. If retailers want to use the integration, they should as a business process, not use IDs with more than 16 characters.
In Xstore, the Sales person field length can be 60 characters in length, but ReSA only allows 10 characters. Retailers should, as a business process, not use Xstore sales person IDs with more than 10 characters.
Commerce Anywhere is not supported. For Commerce Anywhere orders, the Xstore RTLog generator sets the Fulfillment order number in the RTLog to UNKNOWN. The fulfillment order number is not known at the time the order is created, because information has not yet been sent to the order management system.
Xstore supports a tender type of Home Office Check. This tender type is not supported by ReSA. Retailers using this integration should not use the Xstore Home Office Check tender type.
Many Xstore transaction types and subtypes are exported as OTHER/OTHER. For more information on the types and subtypes, see Appendix A.
Xstore allows multiple sales associates at the line item level, however ReSA does not. Only the transaction level sales associate is exported to ReSA.