Replication of Specific Data Types
This topic has additional information about how different data types are replicated.
Replication of Documents
| Document Type | Notes |
|---|---|
| Transactions | Replicated using the document resource. Use the document resource to replicate transactions (sales, returns, orders) from a store to its POA or HQ. The document resource is available on Prism to RIL profiles (Store to HQ) or Prism to Prism profiles (Store to POA). When creating a profile that includes the document resource, be aware that documents created in Prism BEFORE the profile is linked to the connection ARE NOT replicated. Only documents created AFTER the profile is linked to the connection are replicated. |
| Sales Orders | Sales orders are replicated using the document resource. |
| Purchase Orders | Purchaser orders are replicated using the purchaseorder resource. Use the purchaseorder resource to replicate purchase order from a store to its POA. If you replicate purchase orders from the HQ to stores, create separate profiles and filters so that each store only receives its own purchase orders, not those for other stores. |
| Transfer Orders | Transfer orders are replicated using the transferorder resource. Use the transferorder resource to replicate transfer order from a store to its POA. If you replicate transfer orders from the HQ to stores, create separate profiles and filters so that each store only receives its own transfer orders, not those intended for other stores. |
| Vouchers | Vouchers are replicated using the receiving resource. |
| Vendor Invoices | Vendor invoices are replicated using the vendorinvoice resource |
| Slips | Transfer slips (out slips) are replicated using the transferslip resource |
| Memos | Adjustment memos are replicated using the adjustment resource. |
| Disbursements | Cash drops, Paid Ins and Paid Outs are replicated using the drawerevent resource. |
| Z-Out reports | Z-Out drawer closing reports are replicated using the zoutcontrol resource. (Prism-to-Prism only). Z-Out drawer open records are replicated using the drawerevent resource. |
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 Records
The "customer" resource controls the replication of customer information (except loyalty). An important thing to consider with replication of customer information has to do with the Share Type field in the customer record. The Share Type field in the Customer record controls the subsidiaries and stores where a customer record will be available. The available settings are Not Shared, Local, Global, or Region. If a customer's Share Type field is set to Global, the record will be shared to all stores in all subsidiaries EVEN IF the replication profile uses subsidiary filtering.
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.
| Resource | Notes |
|---|---|
| inventory | Replicates Item Loyalty Redeem and Loyalty Reward point values from RIL to Prism (item-based loyalty programs). The Item Reward program information is for those items that part of programs that have a Redeem Type of "Item Reward." |
| ltylevel | (RIL-to-Prism profiles only) Use this resource to replicate loyalty levels and programs to Prism. |
| ltycustcentral | Use this resource to replicate customer point balances. You must create a separate profile that only includes this resource. First click the Centrals checkbox on a RIL-to-Prism or Prism-to-RIL profile and then select the ltycustcentral resource. |
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
Drawer Events are replicated via the "drawerevent" resource. 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.
Replication of Licensing
Licensing information is replicated downstream from the root authority (RA) to subordinate controllers as part of Core Resources. To ensure smooth replication of licensing, allocate licensing from the top-down (if it becomes necessary to de-allocate licensing, de-allocate from the bottom-up).
Important! When a server joins the enterprise, that server will not be licensed until BOTH of the following are complete:
- The JTE process is complete, including initialization
- That server's parent has allocated licensing and the licensing has been consumed by the child
Replication of Reasons
Reasons are replicated using the reasons resource.
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
The following resources are available for replicating employee information:
- employee
- employeeudf
- usergroup
- userpasswordhistory (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.
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.