Conflicts and priorities
The rules that decide between two concurrent changes, how to read a conflict and the three ways to resolve it.
A conflict occurs when the same item has been changed in two places between two synchronisations: by you offline, and by a colleague on the server. NovaFisko applies fixed rules to settle most cases without involving you, and asks for your opinion only when one of your values has been set aside.
The four priority rules
1. Validated accounting data always wins
An offline change is rejected if it targets:
- an entry in a locked period or a closed fiscal year;
- a document or a bank transaction that has already been booked;
- an entry that has already been reversed.
No arbitration is possible: what is validated on the server cannot be called into question by a deferred entry.
2. Field-by-field merge
When the same record has been changed on both sides, NovaFisko compares field by field.
- A field changed on one side only is kept. If you changed the phone number of a third party while a colleague changed its address, both changes are kept.
- On the same field, the highest role prevails.
- With equal roles, the most recent change prevails. In the event of a perfect tie, the server value is kept.
| Rank | Role |
|---|---|
| 1 | Platform administrator |
| 2 | Firm administrator |
| 3 | Firm manager |
| 4 | Lead of the company file |
| 5 | Reviewer |
| 6 | Encoder |
| 7 | Client (person in charge, then employee) |
| 8 | Auditor, read-only |
The date retained for an offline change is that of your device at the time of entry. To prevent a badly set clock from distorting the arbitration, it is bounded to 24 hours around the server time.
3. An update prevails over a deletion
- You deleted offline an item that a colleague changed in the meantime: nothing is deleted.
- You changed offline an item that a colleague deleted in the meantime: the item is restored, then your change is applied.
In both cases, the data entry work is preserved. The deletion can be done again with full knowledge of the facts.
4. Duplicate creations are attached
If you create offline an item that already exists on the server, it is not created a second time. The following are considered identical:
- two third parties of the same type with the same VAT number;
- two accounts with the same number;
- two journals or two analytic codes with the same code;
- two vouchers with the same reference, the same journal, the same third party and the same date.
Your creation is attached to the existing item, and what you had linked to your local version follows.
When a conflict is presented to you
All conflicts are recorded, but only those in which one of your values was not applied remain open. The synchronisation indicator then switches to Conflicts (n).
- Click the indicator to open the Synchronisation panel.
- Under Conflicts to resolve, open the conflict.
- A table shows, for each Field concerned, the Server value and the This device value.
When the server cannot detail the fields, the message "The record was changed on the server since your offline entry" is displayed instead of the table.
The three ways to resolve
| Button | Effect |
|---|---|
| Keep server | You accept the arbitration. Nothing changes on the server, the conflict is closed. |
| Keep local | Your values that were set aside are applied over those of the server. If it was a rejected deletion, it is carried out. |
| Merge | You compose the result field by field, taking some values from one side and others from the other. |
Not all choices are always offered. For a conflict of the "locked" type, for example, only Keep server is possible.
The resolution is recorded with your name and the date. If a colleague resolved the conflict before you, the application tells you and removes it from your list.
Keep local overwrites the value entered by your colleague. Before using it on a sensitive field such as a VAT number or an IBAN, check which of the two values is correct.
Types of conflicts
| Type | Situation |
|---|---|
| Field | The same field was changed on both sides. |
| Deletion versus update | You deleted, the server had a changed version. |
| Update versus deletion | You changed, the item had been deleted on the server. |
| Duplicate | Your creation matched an existing item. |
| Locked | Your change targeted validated accounting data. |
Avoiding conflicts
- Synchronise before and after each offline session.
- Divide the work: a single team member enters a given journal for a given period.
- Lock the periods that have been reviewed. A late offline entry will be cleanly rejected there, instead of changing validated figures.
- Do not leave a device for several weeks with pending changes.
The server keeps track of the devices that synchronise a company file and of the date of their last sending. If a team member has worked offline for several days, ask them to synchronise before you validate a period.
What does not go through the merge
The account allocation lines of a document are not merged field by field. The only rule that applies to them is the lock: as soon as the document is booked on the server, any offline correction of its lines is rejected.