| Oracle® Retail Xstore Suite 18.0/Oracle Retail Merchandising Foundation Cloud Service 16.0.030 and Oracle Retail Pricing Cloud Service 16.0.030 Implementation Guide Release 18.0/16.0.030 F14603-04 |
|
 Previous |
 Next |
| Oracle® Retail Xstore Suite 18.0/Oracle Retail Merchandising Foundation Cloud Service 16.0.030 and Oracle Retail Pricing Cloud Service 16.0.030 Implementation Guide Release 18.0/16.0.030 F14603-04 |
|
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.
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, "Appendix: POSLog to RTLog Mapping Details". It is critical that the mappings are complete. If additional valid values are configured for Xstore in the 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 RMFCS 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 A, "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 RMFCS and Xstore, as RMFCS 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 RMFCS 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 Sales Audit.
By default, Xstore is configured to allow four digit store IDs, but it can be configured to hold up to 5 digit store numbers in the SequenceConfig.xml. Although RMFCS can hold up to a 10 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 RMFCS. 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 RMFCS - group, department, class, and subclass. In Merchandising, 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 RMFCS tables for class and subclass used in the OCDS and is written into .mnt files. This unique ID is not visible to users of RMFCS.
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 RMFCS 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 Sales Audit where the item being sold or returned cannot be identified and accounted for in RMFCS.
If using non-merchandise items, such as warranties, fees, and services, in Xstore, special attributes are required that are not available in RMFCS. 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 RMFCS with the same ID as that created in Xcenter. The item created in RMFCS should be set up as a non-merchandise item to prevent it from being re-exported to Xstore.
The creation of the RMFCS item in Merchandising 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 RMFCS, 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 RMFCS, so these items will appear as standard items in Xstore and the component details will not be available.
Differentiators are used in RMFCS 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. RMFCS 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 RMFCS with Xstore, as it will be ignored in the integration.
Additionally, in RMFCS 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, 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 RMFCS will be ignored and will not be visible in Xstore.
Product restrictions can be set up in RMFCS 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.
RMFCS 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 RMFCS 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 RMFCS are ignored.
Item Restocking - unlike Xstore, RMFCS 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 RMFCS. Therefore, this function would not be available in Xstore.
RMFCS 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 RMFCS, these are currently not used by Xstore.
Translated item descriptions are available from RMFCS as part of the integration but are not currently used by Xstore. Xstore uses the item level description (which is communicated in the primary RMFCS 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 RMFCS be updated to show the localized item description.
This section describes considerations regarding taxes.
RMFCS 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 RMFCS and communicated as such to Xstore. For more information on configuration for VAT in Xstore, see the Oracle Retail Xstore Technical Guide.
When RMFCS 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 RMFCS only when needed.
|
Note: Buying from a VAT store and returning to a non-VAT store (and vice versa) is not supported in Xstore. |
RMFCS 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 Merchandising 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 Merchandising .zip 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 Merchandising files, and is staged for store deployment with a deployment ID greater than the deployment ID of the Merchandising files.
After loading RMFCS 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 RMFCS 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 RMFCS. No inventory information is integrated between Xstore and RMFCS, 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 RMFCS. 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 RMFCS and Xstore is not supported.
RMFCS 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 RMFCS, the last location to be processed by the integration code sets the item level serialized flag in Xstore.
|
Note: RMFCS 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 Sales Audit.
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 Merchandising 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 RMFCS.
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 RMFCS and RPCS 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 RMFCS and RPCS)
Manufacturer's Recommended Retail (from RMFCS)
If an RPCS retail value is over 17 digits, DataLoader into Xstore will fail. Non-failing records from the same file will continue to be loaded.
This section describes sale audit considerations.
Xstore workstation and Sales Audit register are equivalent concepts; however Sales Audit does not have an entity equivalent to the Xstore till, which means that Xstore cannot be configured for till-level balancing when integrated with Sales Audit. When integrated with Xstore, Sales Audit 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 Sales Audit only supports one. Therefore only the transaction level sales associate is exported to Sales Audit.
The OCDS_SUBTASK_DETAILS table contains metadata that controls what data is requested from OCDS by the Oracle Retail Xstore Suite. Since the flow of promotion data into and out of OCDS is not currently supported, the ”PROMOTION” subtask must not be enabled in the database.
|
Important: The flow of Promotion data into and out of OCDS is not currently supported.To prevent Xstore Office from requesting promotion data from OCDS, delete all records from the |
