Improvements to replication management.

Definitions:

1. Configured Locations on head office define, which branches head office needs to send data to.
2. GREEN - Development completed or existing functionality

1. Objectives:

1. Reduce the number of rules and simplify data transfer logic. (Current processes is very complex and not financially sustainable)
2. Shift is created for a user/location combination. (Required so that a user can move between locations and create a new shift for reconciliation purposes)
3. All account customer sales is sent to all branch (We expect credit sales volume to be minimum and this allows receipts at any location). 13/09/2017 Agreed to leave this as it is, since it is managed via configured locations.
4. Branch will send all transactions to head office only.

2. Replication Notes:

1. POSCASH is an issue because of the high volume sales. 
   1. POSCASH sales only flows from BRANCH to HQ
   2. Sales done on location A on behalf of Location B will flow from Location A to HQ then from HQ to Location B
2. Inventory Management
   1. Item properties flows to all configured locations
   2. Transfer, adjustments, stocktake, purchase order flow to configured locations
3. Credit sale flow from head office to all branches. "Configured locations" are not used for this scenario.13/09/2017 Agreed to leave this as it is, since it is managed via configured locations.
4. On POS server configuration, we define which locations are available in each branch. This information is sent from HQ to BRANCH and is used to restrict BRANCH/LOCATION access. 13/09/2017 we cannot block locations at branch level as we allow inter branch transfers which may not be part of configured locations.

3. Additional changes:

1. Remove field LBS_Inventory.AllowNegative from Table and Replication - unused field however significant amount of change to upload template and replication scripts is needed to remove this field

4. Replication Configuration Rules:

1. We know replication is configured in branch if there is an active entry in "server connections" 
2. We can identify branch when there is 1 server connection and connection type is "child" or "stand-alone"
3. We can identify server by having all connection types as "Parent"
4. If replication is configured, a branch should be permitted to use the configured locations in servers only

Improvements to replication management.

Definitions:

1. Configured Locations on head office define, which branches head office needs to send data to.

1. Objectives:

1. Reduce the number of rules and simplify data transfer logic. (Current processes is very complex and not financially sustainable)
2. Shift is created for a user/location combination. (Required so that a user can move between locations and create a new shift for reconciliation purposes)
3. All account customer sales is sent to all branch (We expect credit sales volume to be minimum and this allows receipts at any location)
4. Branch will send all transactions to head office only.

2. Replication Notes:

1. POSCASH is an issue because of the high volume sales. 
   1. POSCASH sales only flows from BRANCH to HQ
   2. Sales done on location A on behalf of Location B will flow from Location A to HQ then from HQ to Location B
2. Inventory Management
   1. Item properties flows to all configured locations
   2. Transfer, adjustments, stocktake, purchase order flow to configured locations
3. Credit sale flow from head office to all branches. "Configured locations" are not used for this scenario.
4. On POS server configuration, we define which locations are available in each branch. This information is sent from HQ to BRANCH and is used to restrict BRANCH/LOCATION access.

3. Additional changes:

1. Remove field LBS_Inventory.AllowNegative from Table and Replication

4. Concerns and issues:

Completed the following:

1. Consolidated rules for "Configured location"
2. Consolidated rules for closed transactions
3. Removed VOID, VOID_BY, VOID_DATE columns from rules table as this is unused
4. Shift changes to create by User/Location combination
5. Refactored shift procedures
6. Applied rules changes to compare data process

Next Step:

1. Package 8.18
2. Setup replication for HQ and 2 branches
3. Validate above changes
4. Review diagnostics and provide user ability to trace and resolve replication issues.

THe following changes have been made:

1. Added the ability to create BRANCH Database from Headoffice
2. Simplified replication rules
3. Corrected server, connections and topology entries
4. Added columns to view server status for Failed and Queue items
5. Improved Server Status view

Hi Team, 

The following areas have been tested. See link for test plan.

• Replication Setup and Configuration.
• Back Office Transactions
• Replication Rules - Partially.

Cases have been logged for areas failed.

1. Case 8831 - Replication Rule R1081 failed
2. Case 8829 - Mismatch with In Stock and Lot Bin details after Stock Take
3. Case 8828 - Mismatch with In Stock and Lot Bin details after Transfer. This is with replication setup
   

We will continue to test further and update case accordingly.

Hi Alvis, 

We have tested the cases. Attached is the test plan with details and areas failed.

Case 8832 logged - Compare data under Replication failed

Regards
Rashna

Hi Alvis, 

This case has been tested in QA1 with 818 BETA 2.

The individual cases logged have been tested accordingly.

Regards
Rashna

Documentation Completed.

Documentation updated under POS- Web 

Replication -- Servers

Replication -- Server Connections

Replication -- Rules