There is an existing manual on partial replication, see here.
This article will focus on items that need to be taken into consideration when setting it up: user access on the vessel, user procedures and other recommendations that Adonis can suggest as best practices.
Basic Principles
The idea of partial replication is in the intention to send over only the crew / or only the records relevant for that specific vessel, noone else. Usually the query is built such that crew having planned onboard activity within next 30 -60 days is sent over to the ship, and then all the changes done with these crew records are sent over both ways until crew sign off.
Limit access to Crew
But that also means that when a crew member has signed off the ship, all the information relevant for this crew member already exists in the vessel database. It will not be deleted/gone. But this crew member’s information will not be replicated from the office to the vessel any longer, until he/she have a new planned onboard activity on that ship.
Resulting in crew member information existing on the ship being outdated.
Thus, it is very important to set up access rights for the vessel users such that they only have access to planned onboard crew and current onboard crew.
That means setting up access rights in:
Organization: only accessing the vessel in question.
Crew List views: only access crew list views showing planned onboard or current onboard crew. No access to crew list views like Standard.
Rotation: only accessing rotation plans relevant for this vessel. This can be done via Global Option or via access rights limitation in ACC. See also more detailed suggestions on Rotation in next chapter.
Crew Change: only accessing crew changes relevant for this vessel. Can be done via ACC.
If a user makes an update for a crew member he/she is not supposed to see, that can jeopardize this person’s records and even influence Payroll. Meaning, all measures need to be taken to hide these crew from the vessel users.
Rotation
Rotation Planning tool is mainly recommended to be used for planning in the office, not onboard. For partial replication it is absolutely necessary to restrict users from updating shifts with crew that are not supposed to be seen for this vessel, otherwise such actions could lead to a mess.
In addition to hiding other vessels plans, the best practice is to set Read access rights for Rotation for the vessel users, if this is required.
If the company procedures presuppose that still the planning has to be done onboard, we recommend minimize the nr of crew vessel should plan as much as possible and make it a separate plan. E.g. most of the crew is planned/assigned and maintained by the office. Only extra crew or guests are maintained by the vessel and are made as a separate plan. All the other plans need to be marked as Maintained by Main Site.
Pin Range
Another highly important set up that must be done when partial replication is set up is the pin range for the different vessels. In fact, this is important to do for any kind of replication set up, but for the partial replication it is absolutely necessary.
Challenges and Possible Solutions
Deleting current onboard activity
Sometimes office users try deleting a current onboard activity (from Rotation, Activity datagroup, Crew Change), and then it is re-created again. This happens due to the following reason: the person already has a timesheet onboard. So deleting this activity on the vessel would not be possible, the system would stop from that. Office database “does not know“ of the timesheet if that info is not replicated, so allows the deletion. However, when deletion is replicated to the vessel, the vessel database does not allow activity deletion, as long as there is a timesheet linked to it. Thus activity is recreated, and is then sent to the office again.
Solution: if the person was confirmed to be onboard and has a timesheet, do not delete such activity. Try to make corrections if possible. If deletion is still necessary, vessel user needs to delete the timesheet first, then activity deletion will be allowed. Deleting such activities in the office is not recommended.
Crew disappearing from Rotation / activities losing Rotation link
As we discussed before, vessel user is not supposed to get all the information from the office, only partially. In Rotation that means empty shift dates changes, newly added positions and such will be replicated from the office to the vessel. However, as we remember, anything related to crew, will be replicated only once it corresponds to the replication rule, e.g. planned onboard activity starting 30 days from today. Meaning, if the office made an assignment 75 days from today, this crew assignment is not replicated to the vessel. Also, if that assignment dates are changed in the office, e.g. to start 74 days from today instead of 75, still this change will not be replicated to the vessel.
Meaning, if vessel user has access to Rotation, there is a high chance that the rotation plan he/she sees looks quite different to what an office user sees. However if a vessel user makes a change in Rotation, the system will do replicate this change to the office, with the risk of jeopardizing what was planned in the office.
Example: If the user tries updating the shift where that assignment exists on the office, but not seen on the vessel, this will most probably result in crew disappearing from Rotation in the office as well, while activities will still exist. Meaning crew’s activities will lose their link to Rotation, as they are deleted by the vessel user actions, who actually was thinking he is playing with an empty shift.
Solution: restrict access to rotation as much as possible. If having access to Rotation for the vessel is absolutely necessary, users need to be instructed not to update any shift if its date is laying outside the replication dates rule for the company.
Person’s old data are back
If access rights are set up for the vessel user not accurately enough, and he/she still has access to crew who is not planned onboard that vessel within the specified period of e.g. 30 days, the consequence can be that old data of the crew is replicated to the office.
How it happens?
E.g. the vessel user has access to a crew list view showing not only planned crew, for example Standard crew list view. Or another example, is that vessel user has access to other rotation plans, lets say for rotation plans of other vessels. From those rotation plans, similar to crew list views, it is possible to get access to personal profiles, datagroups of the crew.
Office has these profiles up-to-date, while these changes are not replicated to the vessel as these persons are not planned onboard within the specified period of time. If the vessel now starts updating these crew records, the system will then send over these profiles to the office, with overwriting the up-to-date information with the one that existed on the vessel, resulting new up-to-date info being overwritten by the old info.
Solution: restrict vessel user access in Crew List views, Rotation, open client etc and ensure vessel users only can see their relevant crew.
Person’s name and other data were overwritten with someone else
This can happen if pin ranges are not set up on the vessels. It can happen, that pin nr exists on one vessel, while another vessel cannot “know“ this, due to only relevant crew replicated. So when creating a new person, the system just picks up the biggest existing pin nr, and defines the next nr as a pin for the newly created person.
Then this information is replicated over to the office and then to the other vessel.
Solution: always ensure pin range is set up when partial replication is being set up on a new site.