View Source

1. Current Gap

Laptops issued but not configured. No VAN ID assigned. No beneficiary data available locally. Field tracking cannot begin.

2. What We Need

Each laptop configured with its correct VAN ID, then synced with the central DB so local records are ready for offline field use.

End-to-End Flow:

Define Van Structure -> Create VANs in central DB, Map Tab logins with VAN -> Allocate Beneficiaries to Vans -> Central DB (all ben) -> Down-sync (filter by vanid) -> Laptop Local DB (van-specific records) -> Field worker tracks beneficiaries

3. Planning Steps:

Phase 1 - Define VAN Structure

Decide total no. of VANs and names

List all field locations and corresponding logins

Get the Beneficiary count per tab login

Finalize the Location -> Login -> VAN allocation

Phase 2 - Central DB Setup

Create all VAN records in the central

Map each tab login to its VAN ID

Verify all the logins are mapped to a VAN

Phase 3 - Beneficiary Allocation

Beneficiary record - look at “CreatedBy” - assign the ben to that VAN of CreatedBy login’s VAN mapping

Verify - VAN ID | Beneficiary Count

Phase 4 - Laptop Configuration & Down-sync

In each local laptop - configured the VAN

Trigger the down-sync process from the application of local laptop

Down-sync pulls all beneficiary records for the laptop's VAN

Verify the count on laptop

4. Tables Involved in VAN Setup and Sync

Table	Purpose
m_van	VAN master records
m_uservanmapping	Maps user login to VAN
m_parkingplace	Area / Parking Place
m_servicepoint	Service Points
m_synctabledetail	Sync table configuration
m_providerservicemapping	State _ Service mapping
m_vanserialpointmap	VAN to village mapping
m_userparkingplacemap	User to Area mapping

5. TB Clinical Tables - Verify Sync Columns (VanId, VanSerialNo, ParkingPlaceID, Processed, SyncedBy, SyncedDate, SyncFailureReason, LastModDate, LastModBy)

Tb_screening

Tb_suspected

Tb_confirmed_cases

Tb_stoptb_visit

6. New columns to track per-record down-sync delivery

Central DB (Add to each table which involved in downsync):

Column

Type

Default

Purpose

DownSynced

char(1)

'N'

'N' : Never Sent

'P' : Processed (downsynced)

'F' : Failed

'U' : Update Pending re-sync

DownSyncDate

datetime

Null

When last successfully delivered to local

DownSyncFailureReason

varchar(255)

Null

Failure detail if 'F'

Local DB:

Column	Type	Default	Purpose
LastDownSyncDate	datetime	Null	When this specific record was last received from central - the reference point for conflict / update detection

Note: Processed = 'F' + SyncFailureReason : Carries all required information

Any edits on the record resets Processed back to 'N' - same as a new record.

LastDownSyncDate provides the conflict detection reference during up-sync.

Downsync Order of tables: FK dependency chain — records must arrive in this order

Master / Reference Data

M_state / m_district / m_districtblock

M_providerservicemapping

m_van/ m_vantype / m_parkingplace

M_servicepoint / m_servicepointvillagemap

M_user / m_uservanmapping

Clinical masters

Beneficiary Root Tables

M_beneficiaryregidmapping

I_beneficiarymapping

Then followed by the rest of the tables.

Note: The down-sync query for each transactional table is simply SELECT * FROM {table} WHERE VanID = {vanID}