## Introduction This document follows one inspection from end to end: from the moment it is planned in the office, through the work on board, to the final verification that closes it — and on to the next inspection, which inherits what was left open. It describes the **way through the system**, not the menus. Where a step uses a function that works the same everywhere — attachments, history, search — it is linked rather than explained again, so that there is one place to keep up to date. Two things shape the whole workflow and are worth knowing before the first step: * **The work changes sides.** Planning and verification happen in the office, the inspection itself on board. What one side has done reaches the other with the [data transfer](/Administration/Database-Replication/), not immediately. A finding entered on board is not in the office the same minute. * **Who may do what is configurable.** Several steps depend on rights, and a few on whether you are on board or ashore. Where that matters, it is said at the step in question — a missing button is usually a right, not a fault. ## Planning the inspection An inspection is normally planned in the office, through the **Planned Audits** report, by setting the date for the next one per vessel and inspection type. Where an interval is configured for that type, it is shown here, and the schedule follows the same principle as class surveys: the window in which the inspection has to happen is what moves, not the anniversary date. The **Audit Schedule Overview** shows the year as a timeline per vessel and type, including the tolerance windows — also across the turn of the year, so what is due in January is visible in the preceding December. Colours: green completed, yellow within the tolerance, orange due, red overdue. See [Reports for Audit and Inspect](/HSSEQ/Audit-and-Inspect/Reports-for-Audit-and-Inspect.md). If the planned date has to move, use `Edit Planned Audit Date`. This is **not** the same as correcting the date on which the inspection was actually carried out — that is [Change Inspection Date](/HSSEQ/Audit-and-Inspect/Change-Inspection-Date.md), a different function for a different purpose. ## Carrying it out on board The inspection is created with `New`, with or without a questionnaire depending on the type, and the details are filled in. See [Add Report](/HSSEQ/Audit-and-Inspect/Add-Report.md) for the fields. **If findings from the previous inspection are still open**, they do not have to be typed again: `Carry Over Open Findings` copies them into the new inspection and closes the originals with a reference to their successor. The button only appears where the inspection type has carry-over switched on — see [Carry-Over Findings](/HSSEQ/Audit-and-Inspect/Carry-Over-Findings.md). Doing this at the **start** is what makes it useful; afterwards the new inspection already contains what was left over. `Fill Out` opens the questionnaire. Answers, remarks and pictures are entered per topic, and topics that need attention can be flagged so they stand out in the report. Attachments follow the usual pattern — see [Attachments](/General-Usage/Attachments.md). ## Recording findings Findings are recorded on the deficiencies side. Depending on the category, a finding may require a **root cause analysis** and a **risk level** from the risk matrix; where the category has it set as mandatory, the finding cannot be saved without one. Which categories demand what is configuration — see [Risk Level for Findings](/HSSEQ/Audit-and-Inspect/Risk-Level-for-Findings.md). Each finding carries its actions. Whether these are free text or separately tracked items with their own responsible person and due date is decided per category, and it changes how the rest of the workflow behaves: tracked actions are closed individually, and a finding is only complete once its actions are. See [Action](/General-Usage/Action.md). A picture that shows a problem can become an observation directly, without attaching the image twice. ## Closing the questionnaire When the questionnaire is finished, it is **not** closed from within the questionnaire editor — it is closed from the audit, with `Close Report` on the safety report tile. Closing it creates the tasks from the observations, so this is the step that turns what was seen into what will be followed up. See [Closing the Safety Report](/HSSEQ/Audit-and-Inspect/Closing-the-Safety-Report.md). Where the inspection type requires office approval, the vessel sees `Approve on Board` instead, which hands the report over rather than closing it. If closing is refused because an observation has no category, assign it and close again. ## Handing over to the office Findings completed on board are set to **Completed on Board**. This is where the risk level is checked, if the category requires one. The inspection then moves on for the office to confirm. **Completed on board is not closed**: the office reviews each finding again, and only then does the inspection reach the final verification. See [Handling in Office](/HSSEQ/Audit-and-Inspect/Handling-in-Office.md). ## Final verification The last step is carried out in the office. Two conditions have to be met, and both are frequent causes of an inspection that will not close: * **Master and Position** have to be filled in, if the configuration requires them. They are deliberately not demanded when saving — only here. * **The questionnaire has to be closed.** An inspection whose safety report is still open cannot be finally verified. Where every finding is at least completed on board, the whole inspection can be closed in one step, together with the actions belonging to those findings — see [Configuration > Task Tracking](/Administration/Configuration/TaskTracking.md). Nothing is changed until both confirmations have been answered. ## After it is closed A closed inspection is **write-protected**: it opens for reading, without a save button, and its findings and attachments can no longer be changed. This protects what was approved. Editing it anyway needs a special right — see [Closed Audits](/HSSEQ/Audit-and-Inspect/Closed-Audits.md). Two things still happen after closing: * **Distribution.** An inspection considered relevant for the fleet can be distributed; the vessels confirm that they have reviewed it, and once all have, it moves to the closed inspections. * **The official report.** It can be saved with or without attachments, and optionally with a list of the attached documents, so a reader without access to the system still sees which documents belong to the inspection. ## And back to the start Findings that were not resolved do not disappear with the inspection. At the next inspection of the same type they are carried over into the new one — which is where this workflow begins again, and why the carry-over belongs at the start rather than the end. *[PO]: Purchase Order *[AZA]: local folder *[(PO]: Purchase Order *[RQ]: Requisition *[(RQ]: Requisition *[RfQ]: Request for Quotation *[(RfQ]: Request for Quotation *[SO]: Service Order *[(SO]: Service Order *[SQ]: Service Requisition *[(SQ]: Service Requisition *[SRfQ]: Service Request for Quotation *[OoB]: Open on Board *[(OoB]: Open on Board *[ART]: Average Running Time (operation hours per day) *[MC]: Master Contract *[ADS]: Advantage Database Server (database engine used in previous versions of the ZeeBORN software) *[.replic]: file extension for replication files (aka data transfer files)