...
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.
| Table of Contents |
|---|
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 no one else. Usually, the query is built such that the crew having that has planned onboard activity within the 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 the crew sign signs off.
Limit access to Crew
But that also means that when a crew member has signed off the ship, all the information relevant for to 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 has a new planned onboard activity on that ship.
...
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 the next chapter.
Crew Change: only accessing crew changes relevant for to 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, This means all measures need to be taken to hide these crew from the vessel users.
Rotation
The 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 a crew that are is not supposed to be seen for this vessel, otherwise, such actions could lead to a messloss of data integrity.
In addition to hiding other vessels vessel 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 are such that still the planning has to be done onboardon board, we recommend minimize minimizing the nr number of crew vessel the crew they are planning. This is done by splitting and hence plans by splitting the vessels into 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.
...
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. As an example, the option “Move subsequent empty shift“ used by the vessel user when changing a rotation shift will influence other shifts in the future, which potentially might have assignments in the office and thus will be jeopardized by the vessel user actions. Thus, the best would be to avoid having any rotation updates onboard.
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.
...
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.
...