Replication of Different Data Types

This topic has additional information about how different data types are replicated. 
Replication of Documents

Replication of Permissions
Prism uses a role-based access system in which permissions are assigned to groups and then employees are assigned to groups. Information about the permissions assigned to each employee group is replicated from the POA to a subordinate.
If you change permissions at the Corp/Sub/Store level, then the following will occur:

• Root Authority will automatically propagate to POA and subordinate
• POA will automatically propagate to subordinate
• In no case will changes flow up the enterprise.

Important! Document sequencing does not replicate whether set at the subsidiary, store, or workstation level. The correct sequence numbers must always be defined at the local installation.

Replication of Prism Preferences
Prism Preferences are replicated as part of the Core Resources. The Core Resources are defined as those resources that are replicated from the POA to its members, but not back to the POA from a member.
If you change preferences at the Corp/Sub/Store level, then the following will occur:
•    Root Authority will automatically propagate to POA and subordinate
•    POA will automatically propagate to vassal
•    In no case will changes flow up the enterprise
When defining preferences, it is important to be aware of the various levels and which level you are changing: Corporate, Subsidiary, or Store (Workstation-level-defined preferences are never replicated). Each of the levels of preferences exist at every Prism installation and can be configured by users (regardless of whether the installation is the Root Authority (RA), a child POA, a Store, or an individual workstation).
Preferences overwritten by POA when joining the Enterprise
When joining the enterprise, the server will inherit preference settings from the POA (Corp, Sub, Store levels). This is usually the desired behavior. A downside is that if you have configured custom preferences at any level, those custom settings will be overwritten by the POA's settings during JTE.

Store Level Changes
Store level changes will only affect that store.  Therefore if a user drills into Store 1 and makes changes, systems will not see the changes unless the WS is assigned to that store. If the Root Authority changes a Corp-level preference and the store has a store level setting for the same preference, the store's preference wins.

Warning about Editing EFT settings
EFT settings are typically configured at the Store level. Once EFT settings are configured at stores, users must be careful about editing settings at a higher-level that will trickle down and overwrite the settings at the store level. This is because Preferences are sent as a CLOB, so if a user changes ANY setting for a store, the whole CLOB will be sent and overwrite the settings defined at the store.

Replicating Preferences from Prism to Prism (POA to New Server)
Currently if the POA has already been set up and you connect a new system to this POA the preferences are not sent to the new server. The user must make an edit to the POA preferences to have the new system get the POA's preferences. In future versions, users will be able to propagate preferences to from an existing Prism server to a new Prism server (Prism-to-Prism).

Replication of Grid Format Preferences
Changes to grid formats made at the Corp, Subsidiary, or Store level will replicate with other preferences. Workstation settings will not replicate. Any workstation-specific grid format settings must be made at each individual workstation that needs them.

Replication of Customer Loyalty

Customer Loyalty information is replicated using multiple resources. The following table lists the resources that replicate loyalty information and the specific information replicated.

In a typical scenario, when initializing Prism using all resources most loyalty information is copied over, with the exception of the customer point balances. To copy customer loyalty points balances from RIL to Prism, initialize Prism using a RIL-to-Prism profile that includes the "ltycustcentral" resource. You must create this profile separately. When creating the profile, first check the Centrals checkbox and then check the ltycustcentral resource checkbox. To replicate customer point balances from Prism to RIL (for transactions created in Prism), create a Prism-to-RIL profile that includes the ltycustcentral resource and link it to the appropriate connection. This will cause any points earned in Prism to be replicated to RIL as part of day-to-day replication.
Important! Be sure to link the profiles to their connections. If you find that loyalty points are not replicating, check to make sure the profiles are linked to the appropriate connections.
Replication of Loyalty Settings for Inventory Items
Item-based programs use the values entered in the Points Earned and Price in Points fields in the Prism Inventory item records. For items that are in item-based programs, the Loyalty Earned and Loyalty Redeemed values in RIL inventory are copied to the Points Earned and Price in Points fields in the item record in Prism as the inventory resource replicates. If an item is part of an Item Reward program, that information is replicated, too, and can be viewed in the item record..
Replication of Customer History
In Prism, certain key data about each transaction and its items is stored as part of the customer record. This data is replicated along with the customer record. If a customer is available at an installation, then the customer history will be available, too, although the full document may not be. If a user wants to view a document that does not exist locally, then the document will have to be viewed at the POA (or the document can be replicated separately). If you want to view a document that does not exist locally, make sure the customerdocumenthistory resource is selected.

Replication of Drawer Events (includes Time Clock)
Drawer Events are replicated via the "drawerevent" resource from Prism to Prism, or Prism-to-RIL only (not from RIL to Prism). Important! The Pop Drawer event is NOT replicated. The Paid In, Paid Out and Cash Drop drawer events ARE replicated. In addition, Z-Out drawer open events are replicated via the drawerevent resource.
This resource includes Time Clock events (also known as "Check In/Check Out").

Replication of Reasons
Reasons are replicated between Prism and RIL. Reasons created in RIL Prism Management  are copied to Prism during initialization. Reasons created in Prism are replicated to RIL Prism Management if the reason resource is included in the profile.
•    If both systems were initialized from an RIL Connection, then changing an attribute like Reason Name in Prism creates a new (duplicate) record during replication.
•    If the POA was initialized from RIL, but other servers were initialized from the POA, then all Reasons will have the same SIDs and changing an ID Attribute like Reason Name will not create a new record.
Replication of Promotions
The "pcppromotion" resource is responsible for replicating promotions. Add the pcppromotion resource to individual profiles to replicate promotions from one. When you press the Broadcast button, promotions are prepared for replication.

• Promotions are sent one promotion per message (instead of one large message with all promotions). If the promotion contains a long list of items it will still be a large message, but not as large as before. Also, since promotions are now sent as multiple messages, they can be processed in parallel with multiple day-to-day consumer threads.
• A field in the PCP_PROMOTION table - PUBLISHED_DATETIME - tracks the date and time when that specific promotion was broadcast. The PUBLISHED_DATETIME is compared to the MODIFIED_DATETIME on the same record and if the MODIFIED_DATETIME is older than the PUBLISHED_DATETIME, the promotion will NOT be sent when you press the Broadcast button. This means that only those promotions edited after the last broadcast will be sent.

The Promotions list is created and managed at the headquarters location (or designated central location). The headquarters location then broadcasts the list to stores. Important! When you broadcast promotions, Promotions will be overwritten at the locations that receive the broadcast. The actual promotions that can be used at each individual store will be limited to those promotions assigned to the store itself or to "All Stores."
Broadcasting Promotions from HQ to Stores
Currently, any location can broadcast Promotions simply by clicking the Broadcast button on the interface.; however, you should only broadcast Promotions from the HQ server down to the child POAs and stores. If stores broadcast promotions back up to the POA, then there is a chance that promotions priority can be duplicated at locations across the enterprise, leading to unexpected results.

Replication of Coupon Sets
The serialized coupons feature is available in the Promotions module, provides retailers with a versatile tool for managing coupons as part of a coupon set. Prism-to-Prism profiles can include the couponset and couponsetcoupon resources.

Replication of Z-Out Reports
Z-Out reports are not replicated between RIL and Prism; however, Z-Out Drawer Open and Drawer Close reports are replicated from Prism store servers to the POA (Prism-to-Prism) and from child POAs to the HQ. Z-Outs are replicated via the drawerevent resource.

Replication of Document Designs
There is no resource for replicating Document Designs; however, Document Designer includes an "import/Export" feature that can be used to copy document designs from one location to another.

Replication of Employee Information
Employee information includes passwords and other sensitive data; therefore, you need to consider carefully how you want to replicate Employee data across the enterprise. When you initialize Prism, employee groups and employees are copied to the Prism server; however, not all employee and employee group information is replicated between Prism and RIL. The data that is NOT REPLICATED includes group permission assignments (Prism has its own permissions).
How Employee Data is Replicated: RIL to Prism, Prism to RIL and Prism to Prism

The following resources are available for replicating employee information:

• employee
• employeeudf
• usergroup
• userpasswordhistory

Replication of Password History
The userpasswordhistory resource is available in Prism-to-Prism profiles. This enables you to replicate passwords between Prism servers so that employees can log in.

Replication of Biometric Data
Two database columns play a key role in biometric login: user_name and empl_name:
The EMPLOYEE table includes user_name and empl_name columns. The BIOMETRICS table includes empl_name column.

• The user_name column is unique across all subsidiaries. When a user does a regular log in using user name and password, the server looks in the EMPLOYEE table and tries to find a matching record. The employee resource is a core resource and cannot be filtered or excluded from replication. As a result, you can use the user_name and password of any employee and login to Prism at any store.
• The empl_name column is unique within a single subsidiary. When a user logs in using a fingerprint, the server first looks in the BIOMETRICS table and retrieves the empl_name and sbs_sid. The server tries to match the retrieved information with a corresponding empl_name and orig_sbs_sid in the EMPLOYEE table. If a match is found, the server uses the user_name and its password from the EMPLOYEE table for the login.

The biometrics resource is not a core resource; therefore, you can apply a filter or simply not replicate the resource. This creates the possibility that a user may be able to log in using the username and password but the log in using the fingerprint fails.
If you want to filter your data by subsidiary (desirable for performance reasons) but still want all fingerprints to be replicated you must create a separate profile that only includes the biometrics resource and do not apply any filter to it.
The rule is: empl_name + orig_sbs_sid from EMPLOYEE table MUST match empl_name + sbs_sid from BIOMETRICS table. Therefore when you create a biometrics record, you should pass empl_name and sbs_sid equal to empl_name and orig_sbs_sid (important! Not employee sbs_sid but employee orig_sbs_sid) of the employee who you are creating the fingerprint for.
Include Employee Subsidiary Number when Creating Biometric Record
When you create a biometric record, you must pass the employee's subsidiary number. In that way, when the employee logs in, the subsidiary numbers will match.
Data that is not Replicated
Images: Images are not replicated between Prism and RIL. To use images in Prism, you must first export the images using the RILImageExport.exe tool. You must then copy the extracted \image folder to the \ProgramData\RetailPro\Server folder. You can add customer images in Prism; however, you cannot add item or style images. Item and Style images must be exported from RIL.

Replication of Taxes
There are two resources used to replicate tax information: taxcode and taxarea. (Note: Before 1.14.5, four resources (taxcode, taxarea, taxrule and tax) were used to replicate tax information between Prism and RIL.  The taxrule and tax resources are now child resources of taxarea.)

Replication of Receiving Information (ASN Vouchers and Vouchers)
ASN vouchers are replicated using the receiving resource. The receiving resource sends both ASN vouchers and vouchers as well as shipping package numbers and other batch receiving information.

Resources to edit only in Prism (or RIL)
There are several data types that have an ID that is based on a local sequence in RIL, not a global sequence. As a result, it is important to make any changes, including adding or removing records, in either Prism or RIL, but not both systems. If you make some changes in Prism and some in RIL, the changes may not be written to the database correctly. Keep in mind that as functionality is migrated from RIL to Prism, the ability to edit the corresponding records in RIL will be removed.