Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
other_stuff:remote_sync [2021/10/08 11:22] – Gary Willetts | other_stuff:remote_sync [2022/02/11 15:44] (current) – removed Gary Willetts | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | {{indexmenu_n> | ||
- | |||
- | ====== 26.03. Remote synchronisation ====== | ||
- | <wrap info> | ||
- | |||
- | mSupply' | ||
- | |||
- | ===== Synchronisation explained ===== | ||
- | |||
- | It's like this: | ||
- | |||
- | {{: | ||
- | |||
- | ==== Definitions ==== | ||
- | |||
- | * The **//central server//** (a.k.a. **//sync server//**) is a central mSupply server. In any given setup, there will only be //one// central server, which must be running a //web server//, and it is responsible for: | ||
- | * aggregating the store data from all stores => enables centralised reporting, and a real-time backup | ||
- | * controlling how all of the stores sync with each other | ||
- | * routing transfers from one store to another | ||
- | * running the mSupply dashboard | ||
- | * The **//primary server//** is a central mSupply server. In any given setup, there will only be **one** primary server, and it is responsible for: | ||
- | * controlling the central data which is common across all stores e.g. names and items | ||
- | * controlling the store records themselves, their preferences and visibility in stores => all stores exist on the primary | ||
- | * A **//remote site//** is any mSupply server, single-user standalone mSupply, or mSupply mobile instance which is //not the central server//: | ||
- | * the syncing process is initiated from each remote site on a schedule, and pushes its own updated records to the central server first, before pulling any updated records from the central server | ||
- | |||
- | * For most installations, | ||
- | * 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 (IP address, username and password), setup in the [[preferences: | ||
- | |||
- | * Multiple copies of the same store can exist across multiple sites (see [[other_stuff: | ||
- | * each store is **// | ||
- | * a **// | ||
- | * a **// | ||
- | |||
- | * To preserve data integrity, and to avoid potential clashes where more than one sync site tries to modify the same record, //only one sync site can edit/update any specific type of data//. There are some special cases (see [[other_stuff: | ||
- | * **//Central data//** (a.k.a. **//system data//**) is common to all stores (e.g. suppliers, customers, items) - this can only be edited or imported on the primary server, and changes are synced to all sites | ||
- | * **//Central store data//** is data related directly to a store record e.g. store preferences and visibility - this can only be edited or imported on the primary server, but changes are only synced to the site where the store is // | ||
- | * **//Store data//** (e.g. transactions, | ||
- | * **//Patient data//** (e.g. patients, PMR records, insurance policies) 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 | ||
- | |||
- | ===== Mirrored sync ===== | ||
- | |||
- | In a mirrored synchronisation system, the primary server becomes a remote site with responsibility for editing the central data: | ||
- | * this remote site doesn' | ||
- | * the central server (especially if it's in the cloud) can be always online and available for remote access to reports and the dashboard, and for processing and routing of sync data | ||
- | |||
- | The typical use case is where a site in a country that has the responsibility for administering items has poor internet (typically the Central Medical Stores), so that it either can't run the central server locally and/or can't reliably connect to a cloud-based central server. By using mirrored sync, this site retains authority, but a reliable central server elsewhere ensures that synchronisation with other sites is not hindered and that external users can still access the dashboard. | ||
- | |||
- | ===== Store setup ===== | ||
- | |||
- | 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' | ||
- | <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' | ||
- | </ | ||
- | * store data (e.g. store transactions, | ||
- | |||
- | {{ : | ||
- | |||
- | **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' | ||
- | |||
- | **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' | ||
- | |||
- | **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' | ||
- | |||
- | **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' | ||
- | |||
- | <WRAP center round tip 60%> | ||
- | This setting is a bit confusing, but it does work to understand it as ' | ||
- | </ | ||
- | |||
- | <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//. | ||
- | </ | ||
- | |||
- | * 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: | ||
- | * To do that, once you log in to the central server, you need to switch to the new store - see [[admin: | ||
- | * To do that, you need to have permission to log in to it - see [[admin: | ||
- | |||
- | <WRAP center round alert 95%> | ||
- | These settings are necessarily complex and should //only be modified by Sustainable Solutions//, | ||
- | </ | ||
- | |||
- | ==== Store sync types ==== | ||
- | |||
- | Each store in a synchronised system needs to have a sync " | ||
- | |||
- | === Active === | ||
- | |||
- | A store whose sync type is // | ||
- | |||
- | === Collector === | ||
- | |||
- | A store whose sync type is // | ||
- | |||
- | === Transfer === | ||
- | |||
- | A store whose sync type is // | ||
- | |||
- | |||
- | |||
- | ==== Store sync-with options ==== | ||
- | |||
- | <wrap info> | ||
- | |||
- | The Store ' | ||
- | |||
- | === None === | ||
- | |||
- | A value of // | ||
- | |||
- | === Active/ | ||
- | |||
- | A value of // | ||
- | |||
- | === Transfer === | ||
- | |||
- | A value of // | ||
- | |||
- | {{: | ||
- | |||
- | * 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. | ||
- | * On **remote site 1** store-specific data for this store cannot be entered. | ||
- | |||
- | {{ : | ||
- | ==== 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. | ||
- | * On **sync server**, store-specific data for this store cannot be entered. | ||
- | * On **remote site 2**, store-specific data for this store cannot be entered, and //**is not**// synced from **sync server**. | ||
- | |||
- | {{ : | ||
- | ==== 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. | ||
- | * On **sync server**, store-specific data for this store cannot be entered. | ||
- | * On **remote site 1**, store-specific data for this store cannot be entered. | ||
- | |||
- | {{ : | ||
- | ==== 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. | ||
- | * On **sync server**, store-specific data for this store cannot be entered. | ||
- | |||
- | {{ : | ||
- | ==== 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. | ||
- | |||
- | {{ : | ||
- | ==== 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. | ||
- | |||
- | {{ : | ||
- | |||
- | ===== 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 store data//** can only be edited or imported on the primary server, but changes are only synced to the site where the store is // | ||
- | * **//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 // | ||
- | * **//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 | ||
- | * **//Local data//** can be edited or imported on any site but doesn' | ||
- | * **//Sync data//** can only be edited on the central server but doesn' | ||
- | * **//Message data//** can be edited on any site and syncs according to the sending/ | ||
- | * Some data can fall into more than one type, depending on the situation. | ||
- | |||
- | ^ Data ^ Type ^ Notes ^ | ||
- | | Items | Central | Including item-related data e.g. item categories, units, BOM masters | | ||
- | | Names (except patients) | Central | Including name-related data e.g. name categories, contacts, tags | | ||
- | | Merging of items, units and names (except patients) | Central | | | ||
- | | Groups and departments | Central | | | ||
- | | Item master lists and programmes | Central | | | ||
- | | Budgets, periods and accounts | Central | | | ||
- | | Transaction categories and payment types | Central | | | ||
- | | Purchase order categories | Central | | | ||
- | | Custom data | Central | | | ||
- | | Barcodes | Central | | | ||
- | | Currencies | Central | | | ||
- | | Options and properties | Central | | | ||
- | | Location types | Central | | | ||
- | | Regimens and indicators | Central | | | ||
- | | Drug interactions and warnings | Central | | | ||
- | | Abbreviations and item directions | Central | Dispensary data | | ||
- | | Diagnoses | Central | Dispensary data | | ||
- | | Insurance providers | Central | Dispensary data | | ||
- | | Patient event types | Central | Dispensary data | | ||
- | | Vaccinators and vaccine settings | Central | | | ||
- | | Custom reports | Central | Standard reports are regenerated on each upgrade | | ||
- | | Asset settings | Central | | | ||
- | | Regions | Central | | | ||
- | | Sites and sync-related preferences | Sync | Changes on the central server indirectly update related records on remote sites | | ||
- | | Dashboard reports | Sync | | | ||
- | | Messages | Message | Depends on sending and/or receiving store (which can be blank) | | ||
- | | Stores and non sync-related store preferences | Central store | | | ||
- | | Purchase orders (centralised) | Central store | | | ||
- | | Payments (centralised) | Central store | | | ||
- | | Visibility of items and names (except patients) | Central store | | | ||
- | | Visibility of existing patients and prescribers | Central store | | | ||
- | | Visibility of new patients and prescribers | Patient | New visibility records sent to central server | | ||
- | | Patients and prescribers | Patient | Including patient-related data e.g. PMR, insurance policies | | ||
- | | Merging of patients and prescribers | Patient | | | ||
- | | Repeats | Patient | Dispensary data | | ||
- | | Patient events | Patient | Dispensary data | | ||
- | | Name notes | Store | | | ||
- | | Customer stock history and requisitions | Store | | | ||
- | | Locations | Store | | | ||
- | | Merging locations | Store | | | ||
- | | Stock and replenishments | Store | | | ||
- | | Stocktakes and inventory adjustments | Store | | | ||
- | | AMC projections | Store | | | ||
- | | Transactions and prescriptions | Store | Including other transaction-related data e.g. backorders, builds | | ||
- | | Transaction notes | Store | | | ||
- | | Item notes | Store | | | ||
- | | Boxes | Store | | | ||
- | | Goods received | Store | | | ||
- | | Indicator values | Store | | | ||
- | | Vaccine monitors/ | ||
- | | Assets | Store | | | ||
- | | Store credentials | Store | | | ||
- | | Authorisers and authorisation | Store | | | ||
- | | Purchase orders | Store | Except for centralised procurement or supervisor-mode ordering | | ||
- | | Payments | Store | Except for centralised payments | | ||
- | | New users | Store | New user records sent to central server | | ||
- | | User licenses and existing users | Local | | | ||
- | | User permissions | Local | | | ||
- | | Preferences (non-store) | Local | Except for a few special cases which are explicitly synced | | ||
- | | Tenders and quotes | Local | | | ||
- | | Incoterms and tender conditions | Local | | | ||
- | | Reference documents | Local | | | ||
- | | HIS | Local | | | ||
- | | Drug registration | Local | | | ||
- | | Labels | Local | | | ||
- | | Logs | Local | | | ||
- | | Reminders | Local | | | ||
- | | Adverse drug reactions | Local | | | ||
- | ==== Stores ==== | ||
- | |||
- | These are a special case: | ||
- | * changes to the store record itself (all except the // | ||
- | * the store' | ||
- | * a store should only ever be //Active// on one sync site at a time (usually on the site where it is //Local//) | ||
- | |||
- | ==== Centralised procurement ==== | ||
- | |||
- | If this preference is switched on in the primary site, then purchase orders can be entered for any store on the primary, regardless of its sync type (i.e. not just for active stores). | ||
- | |||
- | If it is switched on in a satellite, then purchase orders cannot be entered for any store on the satellite, even if it is active. | ||
- | |||
- | When this preference is changed on the primary, the change will propagate to all the satellites as well. | ||
- | |||
- | <WRAP center round alert 95%> | ||
- | It is still possible to edit the preference on the remote (e.g. to allow local procurement for stores active on that site), but if that is the case, then the related permissions for purchase orders for those stores on the primary will need to be disabled manually in order to prevent purchase orders for those stores being editable on both sites. | ||
- | </ | ||
- | |||
- | ==== 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, | ||
- | |||
- | 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' | ||
- | === Patients === | ||
- | |||
- | Patients in mSupply are a special kind of customer, but for the purposes of synchronisation, | ||
- | |||
- | 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/ | ||
- | |||
- | Newly created patients will also be made visible in any other dispensary stores on the home site, depending on the store' | ||
- | |||
- | === Other dispensary data === | ||
- | |||
- | Abbreviations, | ||
- | |||
- | 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' | ||
- | |||
- | === Transferring patients/ | ||
- | |||
- | Watch this space... | ||
- | |||
- | ===== Transfers ===== | ||
- | |||
- | Transfers occur when there are two stores involved in a transaction, | ||
- | |||
- | Both stores need to exist on both sites, and usually the initiating store is a transfer store on the responding site, and vice-versa. As of mSupply v3.83, unless both stores are active on the same site (in which case, everything can be done locally), the bulk of the processing is done on the central sync server when it detects the initiating half of a transfer transaction. In simple terms, the logic is something like this: | ||
- | |||
- | - when the sync server detects the initiating half of a transfer transaction | ||
- | - it creates the responding half of the transaction, | ||
- | - it ensures that both halves of the transaction are synced to both initiating and responding sites | ||
- | - when the responding site receives the responding half of the transaction | ||
- | - it assigns the next invoice/ | ||
- | - it also creates a log message for the initiating half of the transaction and sends that back to the initiating site via the sync server | ||
- | - any subsequent changes to the initiating half of the transaction (usually very limited in scope) on the initiating store/site will be synced back to the sync server (according to the normal sync rules) | ||
- | - any subsequent changes to the responding half of the transaction on the responding store/site will be synced back to the sync server (according to the normal sync rules) | ||
- | |||
- | ==== Stock transfers ==== | ||
- | |||
- | * This is where the customer in a customer invoice is another store | ||
- | * The initiating half of the transaction is where the customer invoice is finalised in the initiating store/site | ||
- | * The responding half of the transaction is a supplier invoice (on hold by default) in the responding store/ | ||
- | |||
- | ==== Mobile requisitions ==== | ||
- | |||
- | * This is where the supplier in a supplier (aka request) requisition is another store | ||
- | * The initiating half of the transaction is where the supplier requisition is finalised on mobile | ||
- | * The responding half of the transaction is a response requisition in the responding store/site | ||
- | * this shows up as a customer requisition on mobile if the responding store is active on another mobile site | ||
- | * or as a response requisition if the responding store is active on a desktop site | ||
- | * the user can create one or more customer invoices to fulfil the requistion | ||
- | * these customer invoices (when finalised) will generate corresponding supplier invoices back in the initiating store as stock transfers | ||
- | |||
- | ==== Internal requisitions ==== | ||
- | |||
- | * This is where the supplier in a purchase order is another store, and is a two-stage process | ||
- | * The initiating half of the first transaction is where the purchase order is confirmed in the purchase order store/site (i.e. where the purchase order is editable) | ||
- | * if centralised procurement is enabled, this will be the primary site, otherwise it will be the normal initiating store/site (i.e. where the purchase order' | ||
- | * The responding half of the first transaction is a customer invoice in the responding store/site | ||
- | |||
- | * The initiating half of the second transaction is where the customer invoice is finalised in the responding store/site | ||
- | * note that adding extra customer invoice lines before the invoice is finalised will create corresponding new goods received lines | ||
- | * The responding half of the second transaction is a goods received record in the initiating store/site (i.e. where the purchase order' | ||
- | * If centralised procurement is enabled: | ||
- | * 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 | ||
- | * 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 | ||
- | |||
- | ===== Reporting ===== | ||
- | |||
- | * On the sync server if you login in supervisor mode, you can then run reports on one or more stores. The reports can answer questions such as: | ||
- | * How much stock on hand of item X (or all items) are there at each location? | ||
- | * What is the value of stock on hand across the whole system? | ||
- | * How many of item X is being used each month at each location? | ||
- | * When the synchronisation system is turned on, a new **Special > Users report... > Sync report...** menu item is available. Choosing this will create a report showing the last time each of your sync stores connected to the central sync server. Those that connected more than a month ago will be highlighted in red. | ||
- | |||
- | ===== Requirements ===== | ||
- | ==== Synchronisation Server ==== | ||
- | The Sync server module is the component that controls all the logic of the sync system described in this chapter. | ||
- | ==== Web Server ==== | ||
- | Any communication through the web to an mSupply central server requires the [[web_interface: | ||
- | ==== Internet connection ==== | ||
- | Each sync site requires an internet connection. | ||
- | Obviously, the internet needs to be on at the central server at the same time as any other sync site that it will communicate with. For this reason, the central server needs to have high availability, | ||
- | </ | ||
- | |||
- | |||
- | |||
- | ===== How to tell if synchronisation is happening ===== | ||
- | ==== The Manual Sync Button ==== | ||
- | |||
- | {{: | ||
- | |||
- | If you click the "2 arrows" | ||
- | ==== On a remote site ==== | ||
- | |||
- | If there are queued sync records, there will be a message at the bottom left of the navigator which shows the number of sync records in the queue. If this is not going down, there may be an entry in the log. | ||
- | |||
- | ==== On the sync server ==== | ||
- | |||
- | * Choose **Help > About mSupply** | ||
- | * At the bottom left of the window there is a list of tables and the number of records in each table. | ||
- | * Scroll the list to near the bottom, and you will see the number of records in the **sync_out** table. | ||
- | * If the number is zero, your copy of mSupply is up to date | ||
- | * If the number is growing from day to day, there are possible reasons: | ||
- | * you need to provide more internet time or faster internet | ||
- | * there may be a problem that needs the attention of Sustainable Solutions. Before contacting us, make sure the internet is connected for an hour, and see if the number is decreasing or not. | ||
- | |||
- | {{ : | ||
- | |||
- | |||
- | ===== Setting up or extending a sync system ===== | ||
- | |||
- | This is not something for end users to configure, so it's best left to the experts at Sustainable Solutions! However, there is a lot of preparation ground work that can be done beforehand: | ||
- | |||
- | - Decide how to configure your server(s) | ||
- | * 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)? | ||
- | * have you a fixed external IP address? | ||
- | * can you open the necessary firewall ports to allow access to the local server from outside? | ||
- | * for a combined primary and sync server on the cloud: | ||
- | * is your local internet fast enough to support remote access to the cloud server to administer system data? | ||
- | * otherwise, it's better to have a separate local primary server and cloud sync server | ||
- | - Do a site survey for all the proposed stores | ||
- | * how is the internet access and local network? | ||
- | * how reliable is the power supply? | ||
- | * is there a suitable location for mSupply? | ||
- | - Decide which version of mSupply is best for each store - don't worry, this can be changed later and licenses can be transferred | ||
- | * central primary server: mSupply server with local clients (depending on the number of users) | ||
- | * central sync server: mSupply server with local clients (depending on the number of users) and web server | ||
- | * multi-user central/ | ||
- | * single-user store/quiet dispensary (desktop): mSupply single-user desktop | ||
- | * small store/ | ||
- | - Decide on the heirarchy of the stores you want to include | ||
- | * which stores supply other stores? | ||
- | * 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/ | ||
- | |||
- | ===== Moving stores and sites ===== | ||
- | |||
- | <WRAP center round important 60%> | ||
- | |||
- | ==== Moving a store from the central server to a new sync site ==== | ||
- | |||
- | Use the [[synchronisation: | ||
- | |||
- | ==== Moving a store from one sync site to another ==== | ||
- | |||
- | To move a store from one site to another means to make it //not// **Active** on the ' | ||
- | |||
- | <WRAP center round alert 60%> | ||
- | This process involves editing store sync settings which is dangerous. | ||
- | </ | ||
- | |||
- | <WRAP center round important 60%> | ||
- | * A mobile site can only have one **Active** store. | ||
- | * Therefore, only one of the stores on a ' | ||
- | </ | ||
- | |||
- | <WRAP center round tip 60%> | ||
- | If the ' | ||
- | </ | ||
- | |||
- | - Ensure that both the ' | ||
- | - Ensure that no new data is entered on either site until the move is complete. | ||
- | - On the central server, **Special** > **Stores** > double-click the store that is being moved > **Synchronisation** tab > **Click to un-lock**, enter code to edit (<color # | ||
- | - If the ' | ||
- | - If the ' | ||
- | - Set the sync type for this store on the ' | ||
- | - **None** if the ' | ||
- | - **Transfer** if this store will likely need to transfer to / from another store on the ' | ||
- | - **Collector** // | ||
- | - Click **OK** to save changes | ||
- | - Click **OK** to exit the stores list | ||
- | - If the ' | ||
- | - If the ' | ||
- | - If the ' | ||
- | - If the ' | ||
- | - If the ' | ||
- | - If the ' | ||
- | |||
- | <WRAP center round alert 60%> | ||
- | If you are moving the store from **Mobile** to **Desktop** of vice versa, this process will not change the [[synchronisation: | ||
- | </ | ||
- | |||
- | |||
- | \\ | ||
- | \\ | ||
- | | // Previous: | ||
- | ---- struct data ---- | ||
- | pagestatus.status | ||
- | ---- | ||