synchronisation:introduction

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
synchronisation:introduction [2025/03/31 16:25] – [Active vs Collector] Adrian Boonesynchronisation:introduction [2025/04/01 16:29] (current) – [Setting up or extending a sync system] Adrian Boone
Line 8: Line 8:
  
 ===== Synchronisation explained ===== ===== Synchronisation explained =====
 +
 It's like this:  It's like this: 
  
Line 31: Line 32:
   * For most installations, the **//Central server//** and the primary server are one and the same, but for **//mirrored//** systems (see [[synchronisation:introduction#mirrored_sync|Mirrored sync]] below for details) they can be different - in that case the primary server is just a special case of a remote site.   * For most installations, the **//Central server//** and the primary server are one and the same, but for **//mirrored//** systems (see [[synchronisation:introduction#mirrored_sync|Mirrored sync]] below for details) they can be different - in that case the primary server is just a special case of a remote site.
   * The **//Central server//**, and all of the remote sites are collectively referred to as **//sync sites//**.   * The **//Central server//**, and all of the remote sites are collectively referred to as **//sync sites//**.
-  * Each sync site has a unique ID and connection parameters, along with a list of the other sync sites with which it can send/receive synchronisation data. These are largely determined by inter-store visibility i.e. if store A (active on site A) is visible in store B (active on site B), then store B is automatically visible in store A, and site A can send data to site B (and vice-versa).+  * Each sync site has a unique ID and connection parameters, along with a list of the other sync sites with which it can send/receive synchronisation data. These are largely determined by inter-store visibility i.e. if store A (active on site A) is visible in store B (active on site B), then store B is automatically visible in store A, and store A on site A can send/receive transfers to/from store B on site B.
  
 === Active vs Collector === === Active vs Collector ===
Line 39: Line 40:
   * Each store that is **//Active//** on a **//remote site//** also has a **//Collector//** copy of the store on the **//Central server//**.  These can be logged into and reported on.   * Each store that is **//Active//** on a **//remote site//** also has a **//Collector//** copy of the store on the **//Central server//**.  These can be logged into and reported on.
   * The **//Central server//** can optionally also have **//Active//** stores on it.   * The **//Central server//** can optionally also have **//Active//** stores on it.
-   
  
 === Sync and data integrity === === Sync and data integrity ===
Line 61: Line 61:
  
 Stores to be synced will exist as separate instances of the same store on more than one sync site: Stores to be synced will exist as separate instances of the same store on more than one sync site:
-  * on the primary server - the store itself and its non-sync related preferences are editable => all stores must exist on the primary server +  * on the central server - the store itself and its related preferences, along with name visibility in the store are editable => all stores and their transaction data must exist on the central server. 
-  * on the central server - the store's sync preferences are editable => all stores must exist on the central server+  * on the primary server - item visibility in the store is editable => all stores must exist on the primary server
 <WRAP center round important 95%> <WRAP center round important 95%>
-On a mirrored sync system, the store must be created first on the primary server. It will then sync to the central server, where the store's site can then be assigned and its sync preferences configured.+On a mirrored sync system, the store must be created first on the central server. It will then sync to the primary server, where item visibility and/or master lists can be configured.
 </WRAP> </WRAP>
-  * store data (e.g. store transactions, stock) can only be edited on a single sync site - the site on which the store is defined as //active//. This is controlled on the central server by the store preferences on the **Synchronisation tab** for each [[other_stuff:virtual_stores|virtual store]] on each sync site:+  * store data (e.g. store transactions, stock) can only be edited on a single sync site - the site on which the store is defined as //active// - and this store data is synced to the central server, as a read-only copy. This is controlled on the central server by assigning which site the store belongs to - see [[synchronisation:sync_sites|sync sites]].
  
-{{ :other_stuff:2016-10-16_store_sunchronisation_tab.png?700 |}} +Once a store has been set up (see the relevant parameters below), item and name visibility for the store needs to be set up - see [[other_stuff:virtual_stores#controlling_item_visibilitythe_master_lists_tab_or_the_visibility_tab|Virtual stores, Controlling item visibility]]: 
- +  * To do that, once you log in to the central/primary server, you need to switch to the new store - see [[admin:user_tasks#switch|Switching store]]
-**Synchronisation type** drop down list: Shows the sync type of the current store. Will be editable on the central server if you have unlocked it using the **Click to unlock** button. +
- +
-**Click to unlock** button: Click it to enter the unlocking password to enable you to edit the settings on this tab. +
- +
-**Set as local store** checkbox: Will be editable on the central server if you have unlocked it using the **Click to unlock** button. If checked, this will change the store's **Sync ID** to be that of the current site and will uncheck any of the elements in the **Local** column in the **Sync with** table. +
- +
-**Include transactions in sync** checkbox: Only affects dispensary stores, as transactions are always synced otherwise. If checked for a dispensary store, this will also sync prescriptions and related dispensary data. This preference is turned on by default for all stores and is permanently disabled (regardless of whether you have unlocked the settings using the **Unlock** button). It can only be turned off by Sustainable Solutions. +
- +
-**Resync patient records when store is saved** checkbox: If checked, when you click the **OK** button to save the store's settings, the central server will resend all the patient records for patients visible in the store to the active copy of the store. Along with that, all the other dispensary related information that is required will be sent, such as patient medication records, prescribers, abbreviations, insurance providers, directions, prescription categories and diagnoses. Quite a lot of information ;-)  +
- +
-**Sync ID** field: Displays the sync ID of the current store so that you can see which one in the table below you're talking about! The store's sync ID should almost always be the ID of the site where the store is active. +
- +
-**Sync with** table: Shows the other sites in your sync setup that the current store will sync with. Also defines what relationship those other store instances have to your current one and therefore what records need to be sent to that site from the instance of the current store on the current site. Will be editable (//only// on the central server) if you have entered the password using the **Click to unlock** button. Checking any checkbox in the **Local** column will set the store's **Sync ID** to be that of the selected row, and will uncheck any others as well as the **Set as local store** checkbox. +
- +
-<WRAP center round tip 60%> +
-This setting is a bit confusing, but it does work to understand it as 'whatever the sync //type// of the store is on that site'.  +
-</WRAP> +
- +
-<WRAP center round important 95%>If your version of mSupply server is pre 3.50, after changing sync settings for a store //you will have to restart the mSupply application on the primary server for the changes to be applied//. +
-</WRAP> +
- +
-  * Once a store has been set up (see the relevant parameters below), item and store visibility for the store needs to be set up on the //central server// - see [[other_stuff:virtual_stores#controlling_item_visibilitythe_master_lists_tab_or_the_visibility_tab|Virtual stores, Controlling item visibility]]. +
-  * To do that, once you log in to the central server, you need to switch to the new store - see [[admin:user_tasks#switch|Switching store]]+
   * To do that, you need to have permission to log in to it - see [[admin:managing_users|Managing users]] (It's a good thing this doesn't happen often! :-D)   * To do that, you need to have permission to log in to it - see [[admin:managing_users|Managing users]] (It's a good thing this doesn't happen often! :-D)
- 
-<WRAP center round alert 95%> 
-These settings are necessarily complex and should //only be modified by Sustainable Solutions//, after discussions to agree on the configuration which is the best fit for requirements. 
-</WRAP> 
- 
-==== Store sync types ==== 
- 
-Each store in a synchronised system needs to have a sync "type" as described here.   
- 
-=== Active === 
- 
-A store whose sync type is //**active**// means that the store-specific data can be edited (added, edited, deleted) on the sync site where you are logged into this store. 
- 
-=== Collector === 
- 
-A store whose sync type is //**collector**// means that the store-specific data can //not// be edited on this sync site.  The store on this server receives all store data from an active store on another sync site i.e. it is a replica of a corresponding active store on another sync site.  This means that the store can be examined and reports generated on this sync site. 
- 
-=== Transfer === 
- 
-A store whose sync type is //**transfer**// is similar to the collector type except that the store on this sync site is used //only// as a vehicle for receiving stock transfers or requisitions from other stores on the //same// sync site and passing them on to the corresponding store on other sync sites.  It doesn't receive any other store data (such as stock lines). That is, //it is not a replica of an active store//, and should not be used as such.  The store can //not// be examined or have reports generated on this sync site.  The benefit of a transfer store over a collector store is that transfer stores require less data to be synced between servers. 
- 
- 
- 
-==== Store sync-with options ==== 
- 
-<wrap info>Updated: mSupply Version 4.12</wrap> 
- 
-The Store 'sync-with' options control which store-specific synchronisation data gets sent to the other sync sites which are linked to that sync site: 
- 
-=== None === 
- 
-A value of //**None**// means that this store doesn't sync with the corresponding store on the selected sync site.  That is, there is no instance of this store on that sync site.  If a store is not visible to any stores //active// on the selected sync site, or its visibility settings are changed so that it becomes invisible to all //active// stores on the selected sync site, then it will automatically be set to //**None**// for that site. 
- 
-=== Active/collector === 
- 
-A value of //**Active/collector**// means that store-specific data edits, including any edits to the core store data, are synced to the corresponding store instance on the selected sync site.  The store instance on the selected sync site will normally be of type //active// (on the site with matching sync ID) or //collector// (on any other sites).  A store cannot be a collector on the selected sync site unless it is visible to at least one other store which is active on the site. 
- 
-=== Transfer === 
- 
-A value of //**Transfer**// means that any updates to the core store data, or any stock transfers or requisitions into that store, are synced to the corresponding store instance on the selected sync site.  No other transactions or other store-specific data will be transferred.  The store instance on the selected sync site will normally be of type //transfer//.  If a store's visibility settings are changed so that it becomes visible to any other stores which are active on the selected sync site, then it will automatically be set to //**Transfer**// for that site. 
- 
-{{:other_stuff:sync-diagram-new.jpg? |}} 
- 
-  * In a standard (non-mirrored) setup, the sync server is //both// the primary server //and// the central server 
-  * In a mirrored setup, the sync server is //only// the central server - the primary server is one of the remote sites, except that: 
-    * it can also control central data 
-    * like the central server, //all// stores must exist 
-==== Store A ==== 
- 
-An example of a store on the sync server which needs to also be reportable on another remote site. 
- 
-**Store A** exists as an //Active store// on **sync server** and as a //Collector store// on **remote site 1**: 
- 
-  * On **sync server** store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**sync server**).  This data is then synced to **remote site 1**. 
-  * On **remote site 1** store-specific data for this store cannot be entered.  However, the store can receive stock transfers or requisitions from other stores active on the same sync site (**remote site 1**).  These will be synced to **sync server**. 
- 
-{{ :other_stuff:storea1.png?1000 |}} 
-==== Store B ==== 
- 
-An example of a store on one remote site which needs to receive stock transfers from a store on another remote site. 
- 
-**Store B** exists as a //Collector store// on **sync server**, an //Active store// on **remote site 1**, and a //Transfer store// on **remote site 2**: 
- 
-  * On **remote site 1**, store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**remote site 1**).  This data is then synced to **sync server**. 
-  * On **sync server**, store-specific data for this store cannot be entered.  However, it can receive stock transfers or requisitions from other stores active on the same sync site (**sync server**).  These are then synced to **remote site 1**. 
-  * On **remote site 2**, store-specific data for this store cannot be entered, and //**is not**// synced from **sync server**.  However, it can receive stock transfers or requisitions from other stores active on the same sync site (**remote site 2**).  These are then synced to **sync server**, and then to **remote site 1**. 
- 
-{{ :other_stuff:storeb1.png?1000 |}} 
-==== Store C ==== 
- 
-Another example of a store on one remote site which needs to receive stock transfers from a store on another remote site. 
- 
-**Store C** exists as a //Collector store// on **sync server**, an //Active store// on **remote site 2**, and a //Transfer store// on **remote site 1**: 
- 
-  * On **remote site 2**, store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**remote site 2**).  This data is then synced to **sync server**. 
-  * On **sync server**, store-specific data for this store cannot be entered.  However, it can receive stock transfers or requisitions from other stores active on the same sync site (**sync server**).  These are then synced to **remote site 2**. 
-  * On **remote site 1**, store-specific data for this store cannot be entered.  However, it can receive stock transfers or requisitions from other stores active on the same sync site (**remote site 1**).  These are then synced to **sync server**, and then to **remote site 2**. 
- 
-{{ :other_stuff:storec1.png?1000 |}} 
-==== Store D ==== 
- 
-An example of a store on a remote site which needs to also be reportable on the sync server. 
- 
-**Store D** exists as an //Active store// on **remote site 2** and as a //Collector store// on **sync server**: 
- 
-  * On **remote site 2**, store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**remote site 2**).  This data is then synced to **sync server**. 
-  * On **sync server**, store-specific data for this store cannot be entered.  However, it can receive stock transfers or requisitions from other stores active on the same sync site (**sync server**).  These are then synced to **remote site 2**. 
- 
-{{ :other_stuff:stored1.png?1000 |}} 
-==== Store E ==== 
- 
-An example of a store which is local to the sync server only. 
- 
-**Store E** exists only on **sync server** (and **primary server**, if different): 
- 
-  * On **sync server**, store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**sync server**).  This data is not synced anywhere. 
- 
-{{ :other_stuff:storee1.png?1000 |}} 
-==== Store F ==== 
- 
-An example of a store which is local to a single remote site. 
- 
-**Store F** exists on **remote site 1**, but it must also exist on the **sync server** (and **primary server**, if different) as a //Transfer store//, so that it can be centrally managed: 
- 
-  * On **remote site 1**, store-specific data for this store can be entered.  It can also receive stock transfers or requisitions from other stores active on the same sync site (**remote site 1**).  This data is not synced anywhere. 
- 
-{{ :other_stuff:storef1.png?1000 |}} 
  
 ===== Data types ===== ===== Data types =====
  
 The table below is a high-level summary of the different data types: The table below is a high-level summary of the different data types:
-  * **//Central data//** can only be edited or imported on the primary server, and changes are synced to all sites  +  * **//Central data//** can only be edited or imported on the primary server (or sometimes the central server), and changes are synced to all sites  
-  * **//Central store data//** can only be edited or imported on the primary server, but changes are only synced to the site where the store is //active// +  * **//Central store data//** can only be edited or imported on the central server (or sometimes the primary server), but changes are only synced to the site where the store is visible 
   * **//Store data//** can only be edited or imported on the sync site where the store is //active//, and changes are only synced to any site where the store exists as a //collector// copy (e.g. the central server)   * **//Store data//** can only be edited or imported on the sync site where the store is //active//, and changes are only synced to any site where the store exists as a //collector// copy (e.g. the central server)
   * **//Patient data//** can only be edited on the sync site where its //home store// is //active//, and changes are synced to any site where the patient is visible   * **//Patient data//** can only be edited on the sync site where its //home store// is //active//, and changes are synced to any site where the patient is visible
 +  * **//Name data//** can only be edited or imported on the primary server, and changes are synced to all sites where the name is visible
   * **//Local data//** can be edited or imported on any site but doesn't sync anywhere   * **//Local data//** can be edited or imported on any site but doesn't sync anywhere
   * **//Sync data//** can only be edited on the central server but doesn't directly sync anywhere   * **//Sync data//** can only be edited on the central server but doesn't directly sync anywhere
-  * **//Message data//** can be created on any site and syncs according to the sending/receiving store, but can't be edited anywhere+  * **//Message data//** can be created on any site, but can't be edited anywhere, and syncs according to the sending/receiving store: 
 +    * if the receiving store is set, then the message will be processed on the site where that store is active 
 +    * if the receiving store is blank and the sending store is set, then the message will be processed only on the central server 
 +    * if both are blank, then the message will be processed on all remote sites (i.e. all except the central server)
   * Some data can fall into more than one type, depending on the situation.   * Some data can fall into more than one type, depending on the situation.
  
-^  Data  ^  'Normal' Sync  ^  If using Mirror Sync ^  Notes  ^                                                                                                 +^  Data  ^  Type  ^  Editable  ^  Notes  ^                                                                                                 
 | Items | Central | Primary | Including item-related data e.g. item categories, units, BOM masters |  | Items | Central | Primary | Including item-related data e.g. item categories, units, BOM masters | 
-| Names (except patients) | Central | Primary | Including name-related data e.g. name categories, contacts, tags | +| Names (except patients) | Central | Primary | Including name-related data e.g. name categories, contacts | 
 | Merging of items, units and names (except patients) | Central | Primary |  |  | Merging of items, units and names (except patients) | Central | Primary |  | 
 | Groups and departments | Central | Primary |  |  | Groups and departments | Central | Primary |  | 
Line 224: Line 98:
 | Purchase order categories | Central | Primary |  |  | Purchase order categories | Central | Primary |  | 
 | Custom data | Central | Primary |  |  | Custom data | Central | Primary |  | 
-| Barcodes | Central | Primary |  | +| Barcodes | Central | Primary | Can be added on any site; duplicates are automatically merged when synced to the primary | 
 | Currencies | Central | Primary |  |  | Currencies | Central | Primary |  | 
 | Options and properties | Central | Primary |  |  | Options and properties | Central | Primary |  | 
Line 242: Line 116:
 | Tenders and quotes (centralised) | Central store | Primary |  |  | Tenders and quotes (centralised) | Central store | Primary |  | 
 | Payments (centralised) | Central store | Primary |  |  | Payments (centralised) | Central store | Primary |  | 
-| Visibility of items and names (except patients) | Central store | Primary |  |  +| Visibility of items | Central store | Primary |  |  
-| Visibility of existing patients and prescribers | Central store | Primary |  | +| Visibility of names (including existing patients) | Central store | Central |  |  
-| Stores and non sync-related store preferences | Central store | Central | Managed on Central Mirror since v7.13  |  +| Visibility of existing prescribers | Central store | Central |  | 
 +| Stores and non sync-related store preferences | Central store | Central |  |  
 | Sites and sync-related preferences | Central | Central | Changes on the central server indirectly update related records on remote sites |  | Sites and sync-related preferences | Central | Central | Changes on the central server indirectly update related records on remote sites | 
 | Dashboard reports | Central | Central |  |  | Dashboard reports | Central | Central |  | 
 | Authorisers and authorisation | Central | Central |  |  | Authorisers and authorisation | Central | Central |  | 
-| Messages | Message | Store | Depends on sending and/or receiving store (which can be blank) | +| Messages | Message | Store | Depends on sending and/or receiving store | 
 | Visibility of new patients and prescribers | Patient | Store | New visibility records sent to central server |  | Visibility of new patients and prescribers | Patient | Store | New visibility records sent to central server | 
 | Patients and prescribers | Patient | Store | Including patient-related data e.g. PMR, insurance policies |  | Patients and prescribers | Patient | Store | Including patient-related data e.g. PMR, insurance policies | 
-| Merging of patients and prescribers | Patient | Store |  |  +| Merging of patients and prescribers | Patient | Store | Both records must have the same home store |  
-| Patient events | Patient | Store | Dispensary data  | +| Patient events | Patient | Store | Dispensary data | 
 | Repeats | Patient | Store | Dispensary data; preference can be set to allow processing on all sites where the patient is visible |  | Repeats | Patient | Store | Dispensary data; preference can be set to allow processing on all sites where the patient is visible | 
-| Prescriptions | Patient | Store | Preference can be set sync to all sites where the patient is visible | +| Prescriptions | Patient | Store | Preference can be set to sync to all sites where the patient is visible |  
 +| Adverse drug reactions | Patient | Store | Dispensary data |  
 +| Name-related tags, budgets and master-lists | Name | Primary |  |
 | Name notes | Store | Store |  |  | Name notes | Store | Store |  | 
 | Customer stock history and requisitions | Store | Store |  |  | Customer stock history and requisitions | Store | Store |  | 
Line 284: Line 161:
 | Logs | Local | Local |  |  | Logs | Local | Local |  | 
 | Reminders | Local | Local |  |  | Reminders | Local | Local |  | 
-| Adverse drug reactions | Local | Local |                                                                                                  | +                                                                                                
  
-==== Stores ==== 
- 
-These are a special case: 
-  * changes to the store record itself (all except the //Synchronisation// tab) are allowed only on the primary server, and then propagate on to any other sync sites as determined by the "syncs with" settings for that store on the sync server (i.e. to any other sync sites where "syncs with" is not //None//) 
-  * the store's sync preferences (the //Synchronisation// tab) are controlled on the sync server 
-  * a store should only ever be //Active// on one sync site at a time (usually on the site where it is //Local//) 
  
 ==== Centralised procurement ==== ==== Centralised procurement ====
Line 307: Line 178:
 ==== Dispensary data ==== ==== Dispensary data ====
  
-=== Stock transactions === 
- 
-By default, prescriptions and any other operations in dispensary mode which affect stock levels are not synced to the sync server, unless the //Include transactions in sync// option is enabled in the store sync preferences, as these can potentially generate a lot of sync traffic and there is usually no need for the central users to have this level of detail - the same site will usually have another store which supplies the dispensary and its transactions will be synced, and that's usually enough to infer usage for the dispensary store. 
- 
-If this preference is switched off in a dispensary store on a remote site, the following data will not be synced back to the central sync server: 
- 
-  * Transactions (including backorders, builds etc.) 
-  * Prescriptions 
-  * Stock lines 
-  * Stocktakes 
  
-If the preference is switched on, all of the store's transaction & stock data will be synced to the sync server. 
 === Patients === === Patients ===
  
Line 325: Line 185:
 Since mSupply v4.09, patients have a //home store//, initialised either according to the store they were created in, or according to their most recent prescription. Patients and their related data (patient medication records, repeats, insurance policies) can only be edited in an active dispensary store on the same //home site// where their home store is active. Since mSupply v4.09, patients have a //home store//, initialised either according to the store they were created in, or according to their most recent prescription. Patients and their related data (patient medication records, repeats, insurance policies) can only be edited in an active dispensary store on the same //home site// where their home store is active.
  
-Patients and their related data records will be synced to the primary server, and forwarded on to any other site which has an active/collector store in which the patient is visible. Prescriptions will be allowed in dispensary stores on any of those sites, except for repeats which can only be processed in dispensary stores on the patient's home site.+Patients and their related data records will be synced to the central server, and forwarded on to any other site which has an active/collector store in which the patient is visible. Prescriptions will be allowed in dispensary stores on any of those sites, except for repeats which can only be processed in dispensary stores on the patient's home site.
  
-Newly created patients will also be made visible in any other dispensary stores on the home site, depending on the store's visibility preferences. Subsequently, patient visibility is controlled from the primary server in the same way as for other name (customer & supplier) records.+Newly created patients will also be made visible in any other dispensary stores on the home site, depending on the store's visibility preferences. Subsequently, patient visibility is controlled from the central server in the same way as for other name (customer & supplier) records.
  
 === Other dispensary data === === Other dispensary data ===
Line 333: Line 193:
 Abbreviations, item directions, insurance providers and patient event types are treated as a special kind of system-specific data i.e. they are editable on the primary, but only synced to sites having at least one active dispensary store. Abbreviations, item directions, insurance providers and patient event types are treated as a special kind of system-specific data i.e. they are editable on the primary, but only synced to sites having at least one active dispensary store.
  
-Prescribers are also treated as a special kind of store-specific data, like patients i.e. they are editable in any active dispensary store on their home site, synced back to the primary server, and shared with dispensary stores on other sites where they've previously prescribed.+Prescribers are also treated as a special kind of store-specific data, like patients i.e. they are editable in any active dispensary store on their home site, synced back to the central server, and shared with dispensary stores on other sites where they've previously prescribed.
  
 === Transferring patients/prescribers to a different home store === === Transferring patients/prescribers to a different home store ===
  
-Watch this space...+This can be done only on the central server, by selecting a different dispensary store from the "Home store" pull-down menu. If you confirm that you want to start the transfer process, the patient/prescriber will become read-only and create a special type of message for the current home store's site. When that site syncs with the central server, the transfer process will complete. This makes the patient/prescriber visible in the new home store and then syncs any related records (e.g. prescriptions) to the new home store's site.
  
 ===== Transfers ===== ===== Transfers =====
Line 383: Line 243:
     * the received quantities for the original purchase order lines will be updated on the primary whenever the corresponding goods received lines are received there (and forwarded from there to the initiating store/site)     * the received quantities for the original purchase order lines will be updated on the primary whenever the corresponding goods received lines are received there (and forwarded from there to the initiating store/site)
     * when the primary receives any subsquent updates to goods received lines from the initiating store/site, it will update the quantities in the corresponding purchase order lines     * when the primary receives any subsquent updates to goods received lines from the initiating store/site, it will update the quantities in the corresponding purchase order lines
-  * If centralised procurement is not enabled, the received quantities for the original purchase order lines will be updated in the initiating store/site when it receives the goods received lines from the primary+  * If centralised procurement is not enabled, the received quantities for the original purchase order lines will be updated in the initiating store/site when it receives the goods received lines from the central server
  
 ===== Reporting ===== ===== Reporting =====
Line 434: Line 294:
   - Decide how to configure your server(s)   - Decide how to configure your server(s)
     * for a local combined primary and sync server:     * for a local combined primary and sync server:
-      * can your local server be online most of the time (it is more important that the internet to be reliable than for it to be fast)?+      * can your local server be online most of the time (it is more important for the internet to be reliable than for it to be fast)?
       * have you a fixed external IP address?       * have you a fixed external IP address?
       * can you open the necessary firewall ports to allow access to the local server from outside?       * can you open the necessary firewall ports to allow access to the local server from outside?
Line 450: Line 310:
     * single-user store/quiet dispensary (desktop): mSupply single-user desktop     * single-user store/quiet dispensary (desktop): mSupply single-user desktop
     * small store/clinic: mSupply mobile      * small store/clinic: mSupply mobile 
-  - Decide on the heirarchy of the stores you want to include+  - Decide on the hierarchy of the stores you want to include
     * which stores supply other stores?     * which stores supply other stores?
     * can stores which have the same supplying store transfer to each other, or just with the supplying store?     * can stores which have the same supplying store transfer to each other, or just with the supplying store?
-    * for dispensary stores, do you need to see prescription details on the central server 
   - Decide on the users for each site and their roles/permissions   - Decide on the users for each site and their roles/permissions
    
  • Last modified: 2025/03/31 16:25
  • by Adrian Boone