5 Integration Considerations

This chapter provides the following considerations that should be taken into account when implementing the integration:

Functional Considerations
Technical Considerations

For information on functionality gaps, see Chapter 7.

Functional Considerations

This section contains functional information that should be considered for the implementation.

Sales Tax

RMS is not the system of record for sales tax.

RMS does not provide US Sales tax information to Xstore. This includes Xstore product tax groups. This integration assumes 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 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

Inventory functionality in Xstore should be disabled. This integration assumes that inventory functionality in Xstore is not implemented.

Seed Data

The integration requires that a number of very basic seed data values are the same in both Merchandising and Xstore. These data values are set to common values in both Merchandising and Xstore installation scripts. If changes are made in one system after installation, changes also need to be made in the other system. Synchronized seed data includes the following:

Currency codes
Country codes
Units of measure

Currency Exchange

This integration assumes that Xstore and RMS are fed consistent currency exchange rates from the same source system.

Xstore tender exchange transactions (that is, where a customer is given USD in exchange for CAD) are mapped to the transaction type OTHER in ReSA. These transactions are to have a zero net financial impact, and are not reported to the General Ledger (GL) by ReSA and RMS.

Physical Items

Physical merchandise items should be mastered in RMS. Xstore Office UIs should not be used to create physical items.

Non-Merchandise Items

Non merchandise items, including warranties, fees, services, and so on, should be fully mastered in Xstore Office:

Non-merchandise items require special attributes for Xstore processing that do not exist in RMS. These attributes do exist in Xstore Office.
Shell items with the same IDs should be manually created in RMS so that the items are valid on an ReSA upload.
Note that changes made to these items in RMS are not consumed by Xcenter/Xstore. RMS exports all items, including non-merchandise items. The Xcenter/Xstore DataLoader will not load non-merchandise items.
Any maintenance of non-merchandise items should occur using Xstore Office.

Latitude and Longitude in Lookup

The Xstore inventory lookup functionality, which helps store associates find inventory at nearby stores, requires that stores have latitude and longitude attributes. RMS does not have latitude and longitude. The record type, RETAIL_LOCATION_COORDINATES, is available to DataLoader to populate the latitude and longitude of stores using the .mnt format.

Populate Data at Implementation and Upgrade

At the time of implementation and upgrade, retailers should use the kill/fill export option in the RMS extracts to populate Xstore with RMS data. The upgrade process does not automatically republish all RMS data.

Also, retailers should run the staging batch for every store and then extract the data using the standard batch processes. RPM does not flag the files that would contain the refresh data as anything different than the normal delta data. The upgrade process does not automatically republish all RPM data.

In-Store Orders

The Xstore RTLog generator sets the Fulfillment order number in the RTLog to NULL. A fulfillment order number is not required because the order is completed within the store and does not require any participation from an order management system.

Mapping of Transaction Details

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.

Recognition of a Sale

Xstore can be configured to recognize a sale at either the time of sale or time of pickup. Integration with Merchandising requires that this configuration be time of pickup, as that is the time that inventory decrements. (If set to time of sale, inventory would decrement early, causing downstream inventory correctness issues.)

The following setting needs to be set to false (which is the default) under both <Layaway> and <SpecialOrder> in SystemConfig.xml (whose settings are also controllable in Xadmin):

<BookAsSaleOnSetup dtype="Boolean">false</BookAsSaleOnSetup>

VAT

This integration allows RMS to be configured for VAT enabled (SVAT), but allows specific zones to be configured as VAT Exempt. This enables a single instance of RMS to support both VAT locations and non-VAT locations. The same Xcenter instance can support both VAT and non-VAT stores. For more information on configuration for VAT, see the Oracle Retail Xstore Technical Guide.

Technical Considerations

This section contains technical information that should be considered for the implementation.

RMS

To better integrate with downstream systems, including Xstore, RMS has a unique key to the CLASS and SUBCLASS tables. This means it is possible to identify a class or subclass with a single key value (instead of a composite key including dept/class or dept/class/subclass). The unique key is generated and not displayed to RMS end users.

RPM

RPM has an option to not allow users to use any complex promotions which includes all Multi-Buy promotions, all Threshold promotions, and all Transaction promotions and Finance promotions. This system option can be used to prevent end users from creating complex promotions which are not supported by Xstore including: Multi-Buy promotions with a reward of cheapest free, Multi-Buy promotions that use the OR qualifier between multiple buy and/or reward lists, Threshold promotions created with a qualification of ”item level,” and Finance promotions.

Note:

Setting this system option to not allow creation of complex promotions limits the other types of Xstore supported promotions that the RPM user can create.

RPM_SYSTEM_OPTIONS.COMPLEX_PROMO_ALLOWED_IND

Xstore

For the Xstore Suite, consider the following:

The ReSA/RMS and Xstore integration assumes that store inventory is being managed in SIM (or another similar store inventory management application). SIM provides updates to RMS on shipments and receipts and other inventory movements in the store, while Xstore provides this system with updates on sales and returns. 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.
To allow end users to create non-merchandise items, but prevent users from creating or editing merchandise items, 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.
By default, the following settings in the Xstore SystemConfig.xml file (whose settings are also controllable by the user in Xstore Office) are false. The settings should not be changed. If they are changed, sales and inventory information may post incorrectly to ReSA.
```
<Layaway>
      <BookAsSaleOnSetup dtype="Boolean">false</BookAsSaleOnSetup>
<SpecialOrder>
      <BookAsSaleOnSetup dtype="Boolean">false</BookAsSaleOnSetup>
```

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>

RMS allows up to 10-digit store and warehouse IDs. By default, Xstore is configured to allow four digit store IDs. It is recommended that four or five digit location IDs are used in RMS. The size of Xstore store IDs can be configured in SequenceConfig.xml, however, custom modifications are required in order to have Xstore support store IDs longer than five digits.