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. 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.
Person’s old data are back
A vessel user sees rotation plan. The rotation plan, even if it is for the correct vessel, can contain people outside the replicated period: persons planned later than e.g. 30 days from today. From Rotation it is possible to get access to the personal files same as if the person were in Crew List: open datagroups, personal profile etc. However as long as this person is not supposed to be replicated to the vessel, his/her data on the vessel might be outdated. The vessel user can make changes to this person’s records, this will be replicated over to the office, with overwriting other changes that could be done in the office previously.
If the user removes a person from rotation plan or makes dates changes while the shift is outside the replication period, results in a mess in activities records in the office.
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 person record, shift, anything if this person’s activity is outside the replicated period.
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.