...
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.
...
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.
...
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 person record, shift , anything if this person’s activity is outside the replicated periodif 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
...