| Oracle® Retail Xstore Suite 18.0/Merchandising 16.0.2 Implementation Guide Release 18.0 E99047-05 |
|
 Previous |
 Next |
| Oracle® Retail Xstore Suite 18.0/Merchandising 16.0.2 Implementation Guide Release 18.0 E99047-05 |
|
Previous |
Next |
This chapter provides the considerations that should be taken into account when implementing these solutions to minimize errors in data movement between solutions, as well as to call out some functional differences in the solutions that may limit the use of functionality in one or the other solutions.
If you are already live with RMS and RPM and are implementing Xstore, you should use the kill/fill export option in the RMS and RPM extracts to populate Xstore, along with running the staging batch for every store and extracting the data using the standard batch processes to convert items, price, and other key data elements from the Merchandising solutions into Xstore.
There are a number of basic data elements that are common between the two solutions but which are not part of the integration. This is because they are generally a one-time set up at initial implementation with only infrequent updates afterward. However, because this data is foundational to how the solutions work, it is critical that they are set up properly. These data elements fall into a couple different categories:
Seed data refers to data that is loaded into both solutions on implementation by Oracle Retail provided install scripts. These are coordinated between solutions as part of the base installation, but if any updates are made in one solution to add or remove items, the corresponding change should be made in the other solution. Data elements that fall into this category are:
Currency codes
Country codes
Units of measure
The mapping of transaction details from Xstore POSlog to ReSA RTLog depends on the mappings of valid values. These mappings are detailed in Appendix A. It is critical that the mappings are complete. If additional valid values are configured for Xstore in RTLogMappingConfig.xml, they must also be configured for ReSA for the appropriate code types.
Similar to seed data, some initial data is provided for the data entities in this category, but this is an area that is more commonly configured for retailers based on their specific business processes. On initial implementation, the configurations in both Xstore and RMS should be made to be in synch, with any changes made post-implementation continuing to be made in both solutions. The entities in this category include:
Transaction Types
Tender Types
Tender Total IDs
Item Types
Reason Codes
Item Statuses
Sales Types
See the Appendix: POSLog to RTLog Mapping Details for details on configuring and mapping these entities.
Exchanges rates for currencies are not one of the things integrated between RMS and Xstore, as RMS is not considered the system of record for this information at a retailer - generally that comes from the financials solution. However, if you require currency exchange rates in Xstore, then it expected that the same source of data used for exchange rates in RMS will also be used to load those rates into Xstore, in order to ensure both solutions are operating with the same information and to prevent a financial impact from occurring due to differences in the rates used. Tender exchange transactions that occur in Xstore, where a customer is given USD in exchange for CAD, will be mapped to the transaction type OTHER in ReSA.
By default, Xstore is configured to allow four digit store IDs, but it can be configured to hold up to five digit store numbers. Although RMS can hold up to a ten digit store ID, when integrating with Xstore, it is strongly recommended that only four or five digit location IDs are used. Custom modifications would be required to Xstore to support larger store IDs.
Additionally, latitude and longitude information that is used by Xstore to determine nearby stores for its inventory lookup function are not available as part of the integration from RMS. If you wish to use this functionality in Xstore, the record type, RETAIL_LOCATION_COORDINATES, is available to DataLoader to populate the latitude and longitude of stores using the .mnt format.
Xstore supports up to 4 levels of the Merchandise Hierarchy, which will be populated by the bottom four levels of the merchandise hierarchy from RMS - group, department, class, and subclass. In RMS, the class ID displayed to users is unique only when combined with its department ID. Similarly, the displayed subclass ID is only unique when combined with its department and class. However, instead of using the composite key in the integration with Xstore, the unique key that is held in the RMS tables for class and subclass is written into .mnt files. This unique ID is not visible to users of RMS.
Following is the Xstore Merchandise Hierarchy configuration:
<MerchHierarchy dtype="Default"> <NumberOfLevels dtype="Integer">4</NumberOfLevels> <Level1Code dtype="String">GROUP</Level1Code> <Level2Code dtype="String">DEPARTMENT</Level2Code> <Level3Code dtype="String">CLASS</Level3Code> <Level4Code dtype="String">SUBCLASS</Level4Code> </MerchHierarchy>
This section lists considerations regarding items.
Physical merchandise items should be mastered in RMS and use the integration described in this document to flow the data to Xstore. Xstore Office should not be used to create physical items in order to prevent errors when loading sales data into ReSA where the item being sold or returned cannot be identified and accounted for in RMS.
If using non-merchandise items, such as warranties, fees, and services, in Xstore, special attributes are required that are not available in RMS. Therefore to configure these items, the following approach is required:
Create the non-merchandise item in the Xstore Office UI, specifying the required attributes to control its behavior in Xstore.
Create an item in RMS with the same ID as that created in Xcenter. The item created in RMS should be set up as a non-merchandise item to prevent it from being re-exported to Xstore.
The creation of the item in RMS will prevent any errors from occurring in the sales auditing process. Any maintenance on the non-merchandise items should occur in Xstore Office going forward.
To allow end users to create non-merchandise items, but be prevented from creating or editing merchandise items in Xstore, the CFG_MERCH_ITEMS privilege should not be granted to any users. The merch items option will still be on the screen, but it will not be accessible.
Kits, or pack items in RMS, are items that contain multiple components but are sold as a single unit. As part of the standard item integration, Xstore does not import the component level information from RMS, so these items will appear as standard items in Xstore and the component details will not be available.
Differentiators are used in RMS to define how a transaction level item (for example, SKU) differs from its parent (for example, style). For example, a differentiator might be a color, size, or flavor for an item. In Xstore, differentiators are called dimensions. RMS supports up to 4 differentiators/dimensions for items, while Xstore can support only three. It is strongly recommended that the 4th differentiator is not used when implementing RMS with Xstore, as it will be ignored in the integration.
Additionally, in RMS an item can be assigned differentiators without having a parent (style) associated with it. This could be used for hardline or grocery items to indicate the color or size of an item for reporting purposes, for example. However, in Xstore, dimensions are primarily used to allow a user to determine the sellable SKU by entering a style ID and selecting the valid dimensions (usually color and size). Therefore, if an item does not have a parent, the dimensions sent from RMS will be ignored and will not be visible in Xstore.
It is possible in RMS to range a child item to a store without also ranging its parent. However, it should be noted that in this case because the parent is not ranged, child items (SKUs) associated with the style cannot be selected by scanning the style ID in Xstore; it can only be looked up by the child IDs (SKUs). In addition, when the style does not exist, the item dimension values are not displayed in the Xstore UI.
Finally, it should be noted that RMS sends parent item/location combinations as well as transaction item/location combinations to Xstore. If you have transaction items in RMS with a parent item that is not deemed a "style" by Xstore per the definition above, the parent item/location combination will be recorded in the Xstore item/location table (itm_item_options), but may not have a corresponding record in the item table (itm_item). This does not cause any systematic issues, but be aware that the data in the tables may not match in this case.
Product restrictions can be set up in RMS to indicate limitations on certain products. For example, a restriction may be set up to limit alcohol from being sold to customers under a certain age. Product restrictions are not currently supported in the integration to Xstore.
RMS has a concept of related items that can be used to define items that are substitutes for one another, or that could be used to cross-sell or up-sell to a customer when purchasing the main item. Substitute items from RMS are mapped to the Xstore substitute items to indicate items that may be substituted or offered in place of another item.
The cross-sell and up-sell types of related items are mapped to Xstore's Attached Items and configured as prompt-to-attach. Only transaction level related items are used by Xstore. Those created at the parent item level (for example, style) in RMS are ignored.
Item Restocking - unlike Xstore, RMS does not have a flag that indicates whether an item is subject to an item restocking fee, nor the ability to define what an item's fee would be. Therefore, Xstore would not have the ability to prompt for a restocking fee during returns.
Xstore can support prorated refunds for items, but to do so requires specific attributes sent for an item, which are not currently available in RMS. Therefore, this function would not be available in Xstore.
RMS has the ability for retailers to extend the available item attribution by creating user defined attributes and custom flex attributes. Although included in the available data from RMS, these are currently not used by Xstore.
Xstore uses the item level description (which is communicated in the primary RMS language) for Xoffice and the item/location level descriptions for the store in Xstore. If you have the requirement to send item descriptions in different languages to your stores, it is recommended that the item/location level description in RMS be updated to show the localized item description.
This section describes considerations regarding taxes.
RMS integration includes VAT rates and the regions in which the stores have been classified for companies with operations in geographies where this type of tax is applicable. For retailers that have operations in both VAT and non-VAT regions - such as stores in the US and Canada - non-VAT regions are configured as exempt in RMS and communicated as such to Xstore. For more information on configuration for VAT in Xstore, see the Oracle Retail Xstore Technical Guide.
When RMS sends VAT rate updates for an item, it also includes the active date for the rate to be applicable. Retailers sometimes enter new VAT rates in advance for future planning. However, Xstore currently does not support an active date for VAT code and will ignore the active date sent, which means any new codes will go into effect immediately. Therefore, it is recommended that retailers enter the VAT code changes in RMS only when needed.
|
Note: Buying from a VAT store and returning to a non-VAT store (and vice versa) is not supported in Xstore. |
RMS does not provide US Sales tax information to Xstore; it is assumed that product tax groups are imported into Xstore from a third-party system using Xstore Point of Service DataLoader and .mnt files.
In standalone mode, DataLoader has to be executed twice, first to import RMS files and second to import this .mnt file. If they are placed together in the download directory, .mnt files always get loaded first.
In an integrated environment with Xstore Office/Xenvironment, the retailer has to drop the .momzip file first, and wait until that zip file is processed by Xstore Office before dropping this .mnt file. This guarantees the .mnt file is imported into Xcenter after all RMS files, and is staged for store deployment with a deployment ID greater than the deployment ID of the RMS files.
After loading RMS data, the following additional steps are required to configure sales tax using the .mnt file format:
Set up sales tax rules. To set up a simple rate based tax rule, use existing record types TAX_LOCATION, TAX_AUTHORITY, TAX_GROUP, TAX_GROUP_RULE, and TAX_RATE_RULE to populate tax tables tax_tax_loc, tax_tax_authority, tax_tax_group, tax_tax_group_rule, and tax_tax_rate_rule. For more details on tax rule configuration, see the TAXING section in the Oracle Retail Xstore Point of Service Host Interface Guide available on My Oracle Support.
Set up retail store and tax location mapping in table tax_rtl_loc_tax_mapping using existing record type TAX_RETAIL_LOCATION_MAPPING. For more details on this record type, see the TAXING section in the Oracle Retail Xstore Point of Service Host Interface Guide available on My Oracle Support.
ITEM_TAX_GROUP is used to update the item record in the itm_item_options table with sales tax group ID. This .mnt file has to be imported after the RMS data import. There is no built-in mechanism in DataLoader or Xstore Office to ensure this ordering. It has to be enforced by retailer manually.
Inventory functionality in Xstore should be disabled when implemented with RMS. No inventory information is integrated between Xstore and RMS, other than sales related data and it is assumed store inventory is managed in another application, such as Oracle Retail Store Inventory Management (SIM) or Store Inventory and Operations Cloud Service (SIOCS), which is also integrated with RMS. Therefore, when these systems are all part of a retailer's implementation, the .sim entry in the configuration path should be used in Xstore to turn off Xstore inventory functionality. Inventory integration outside of sales and returns between ReSA/RMS and Xstore is not supported.
RMS supports the concept that an item can be a serialized item in one store, but not in another, however in Xstore, the designation for whether or not an item is serialized is held at the item level, so there is not any differentiation by store. 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.
|
Note: RMS does not support serialized inventory at this time. It only flags items as being serialized or not. |
When customer orders are initially captured in Xstore, the Xstore RTLog generator sets the Fulfillment order number in the RTLog to UNKNOWN, as 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.
Orders taken in the store on behalf of a customer that do not go through an Order Management System (OMS) for fulfillment will include only a customer order number, but not a fulfillment order number when it the transactions related to it are integrated to ReSA.
For customer orders, Xstore can be configured to recognize a sale at either the time the order is place or at the time of pickup. Integration with RMS requires that this configuration be time of pickup, which corresponds to when inventory is decremented from the store, in order to prevent out of synch issues between actual store inventory and what is shown in RMS.
In order to configure this in Xstore, the following settings should be set to false (which is the default) under both <Layaway> and <SpecialOrder> in SystemConfig.xml (whose settings are also controllable in Xadmin):
<Layaway> <BookAsSaleOnSetup dtype="Boolean">false</BookAsSaleOnSetup> <SpecialOrder> <BookAsSaleOnSetup dtype="Boolean">false</BookAsSaleOnSetup>
In both RMS and RPM the data type for retail prices is NUMBER(20,4), but in Xstore, the standard is to use a data type of NUMBER(17,6). This applies to the following item prices:
Selling Unit Retail (from RMS and RPM)
Manufacturer's Recommended Retail (from RMS)
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 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 has a system option (RPM_SYSTEM_OPTIONS.COMPLEX_PROMO_ALLOWED_IND) to not allow users to use any complex promotions, which includes all Multi-Buy Threshold, Transaction, and Finance promotions. This system option can be used to prevent end users from creating complex promotions that are not supported by Xstore including. However, this system option would also prevent the ability to create some complex promotions that are supported in both solutions. So, consideration should be taken to determine whether that is the right approach or whether a business process should be used to prevent users from creating unsupported promotions.
Promotions supported in RPM but not in Xstore include the following:
Multi-Buy promotions with a reward of cheapest free (Buy N and get Cheapest Free)
Multi-Buy promotions that use the OR condition between buy lists and/or reward lists
Threshold promotions with a qualifier of item level
Finance promotions
Customer Segment promotions - Xstore can support customer segment promotions, but it is not supported in the integration with RPM
When Simple Promotions are created in RPM, the promotional retail for each 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. However, Xstore also calculates a retail price based on the promotion criteria and ignores the value sent by RPM. This could result a slight difference in expected promotional price between solutions.
RPM does not support tying a coupon to a promotion and the RMS coupon functionality is not integrated with Xstore. It is recommended that if coupons are required for your business that these be managed in Oracle Retail Customer engagement and leverage the base integration of that solution with Xstore. Or, if managed in an external solution, these could be integrated to Xstore as part of your implementation.
This section describes sales audit considerations.
Xstore workstation and ReSA register are equivalent concepts; however ReSA does not have an entity equivalent to the Xstore till, which means that Xstore cannot be configured for till-level balancing when integrated with ReSA. When integrated with Xstore, ReSA should be configured with a balancing level of Register and Xstore will always sends the workstation ID as the register.
In Xstore, the sales person field length can be up to 60 characters in length, but ReSA only allows up to 10 characters. Retailers should, as a business process, not use Xstore sales person IDs with more than 10 characters.
Additionally, Xstore allows multiple sales associates at the line item level, however ReSA only supports one. Therefore only the transaction level sales associate is exported to ReSA.
