Synchronisation
How changes made offline reach the server, how to read the synchronisation panel and what to do with a rejected change.
Synchronisation is the exchange between the local copy of a company file and the server. It works both ways: your changes go up, those of your colleagues come down. It is automatic; this page helps you understand what happens and step in when something is rejected.
When synchronisation takes place
- When the connection is back: as soon as the server responds again, the pending changes are sent.
- Regularly while online: the application queries the server every five minutes to retrieve the changes of other users.
- On demand: the Sync now button of the Synchronisation panel starts an immediate exchange.
Offline, the application probes the server every 20 seconds to detect the return of the network.
The Synchronisation panel
Click the synchronisation indicator to open the panel. It has five parts.
| Part | Content |
|---|---|
| Header | The current state, the date of the Last sync and, where applicable, the Last error. |
| Pending changes | What was done on this device and has not been sent yet. "Everything is synchronised" when the list is empty. |
| Conflicts to resolve | The changes that require your choice. See Conflicts and priorities. |
| Synchronisation log | Each exchange with the number of changes sent and received, the conflicts and the rejections. |
| Local data | The space used on the device and the button to clear it. |
What happens on sending
Pending changes are sent in the order in which you made them. The server processes each one separately, with exactly the same checks as if you had entered it online: balanced entry, open period, postable account, uniqueness of a code. For each change, it returns one of these results.
| Result | Meaning | What the application does |
|---|---|---|
| Applied | The change is saved. | The Pending sync badge disappears. The item receives its identifier and, for an entry, its final number. |
| Already processed | The same change had already arrived, for example after a connection loss during sending. | Nothing is replayed. No duplicate is created. |
| Conflict | The item had changed on the server. The server decided according to the priority rules. | Your copy is replaced by the result. If one of your values was not retained, a conflict is opened for review. |
| Rejected | The change cannot be applied. | It remains visible in the list with the reason "Rejected by the server". |
Each change carries a unique identifier generated by the device. This is what allows the server to recognise a repeated sending and never create the same entry twice, even if the connection is cut at the worst moment.
Items created offline and linked to each other
You can create a third party offline and then immediately enter an invoice in its name. At synchronisation, the third party receives its final identifier and the invoice is automatically attached to the right third party. The sending order guarantees that the third party arrives before the invoice.
Rejection reasons
| Reason | Explanation | What to do |
|---|---|---|
| Locked | The period has been locked, the fiscal year closed, or the document has already been booked by someone else. | Accounting data validated on the server always prevails. Discard the local change and, if necessary, enter it again in an open period. |
| Validation | An entry rule is not met: unbalanced entry, non-existent account, missing mandatory field. A deletion rejected because the item is in use also arrives under this reason. | Read the detail, correct and send again, or discard the change. |
| Not found | The targeted item no longer exists on the server. | Discard the local change. |
| Forbidden | Your rights on the company file have changed, or your role is read-only. | Contact the lead of the company file. |
| Not supported offline | The action cannot be deferred. | Do it again online. |
| Server error | Temporary incident. | Nothing: the application retries automatically. |
To remove a rejected change, use Discard local change. A confirmation reminds you that it will not be sent and will disappear from the device.
A rejected change is saved nowhere other than on your device. Before discarding it, note the information you will have to enter again.
What comes down from the server
At each exchange, the application asks the server for everything that has changed since the last pass: creations, updates and deletions made by your colleagues, by the Novadesko synchronisation or by automatic processes. Only the latest state of each item is transmitted.
If the device has gone too long without synchronising (more than 90 days), the server can no longer provide the detail of the changes. The application then reloads the whole company file. This requires no action on your part, but takes a little longer.
Limits to be aware of
A few bulk operations carried out on the server are not transmitted change by change: lettering, the locking of periods at closing and the return of a document or a transaction to "to be booked" after a reversal. The application reloads the lists concerned when it detects these operations. If in doubt about a displayed state, use Update in the Offline section of the company settings.
If several people work on the same company file, synchronise before starting a long data entry session. You then start from the latest state and limit conflicts.
Who sees what
In the history of the company file, a change entered offline carries the origin "Entered offline then synchronised", the name of the device and the date on which you actually made it. Your colleagues therefore know that it was entered before it reached the server.