Safety Report - Observation Due Date and Responsible Role
New Feature
Observations in Safety Reports now have two additional fields:
- Due Date — the date by which this observation should be resolved
- Responsible Role — the role responsible for follow-up (e.g. Master, Chief Officer, HSEQ Manager)
How it works
When a new observation is created, the Responsible Role is automatically pre-filled from the Audit Type configuration (if a default role has been set).
When the Safety Report is closed, the Due Date and Responsible Role are transferred to the generated task.
Configuration: Default Responsible Role per Audit Type
- Open the Audits module.
- Go to Configuration > Manage Audit Types.
- Select an Audit Type and set the Default Responsible Role dropdown.
- Save.
All new observations created under this Audit Type will automatically have this role pre-filled. The role can be changed manually per observation.
Note: The default role is only applied to new observations. Existing observations are not affected.
Safety Reports & Audit — New Features (April 2026)
Table of Contents
Part of Scoring Repeatable Sections Require Tank Type Sub-Items (Hierarchical Questions) Previous Inspection Flagged Items
1. Part of Scoring
You can now control which questionnaire elements contribute to the overall inspection score. A new "Part of Scoring" checkbox is available at three levels of the questionnaire hierarchy:
Default Behavior
By default, all items are included in scoring. You only need to take action if you want to exclude specific elements. Items that use Text, Date, or Numeric answer types are never scored regardless of this setting — only items with Answer Set gradings contribute to the score calculation.
Tip: Use the Answer Set level to globally exclude informational answer sets (e.g. "Yes / No / N/A" used for documentation purposes only). Use the Topic level when the same item should be scored in one questionnaire but not in another.
2. Repeatable Sections
Chapters in a questionnaire can now be configured as Repeatable Sections. This allows auditors to dynamically add multiple instances of the same question set during an inspection — for example, one set of questions per tank, per cargo hold, or per piece of equipment.
Configuration (Item Config)
- Open Item Config and navigate to the group (chapter) you want to make repeatable.
- In the group properties, check the "Repeatable Section" checkbox.
- Save the configuration. The chapter is now marked as repeatable for all questionnaires that use this group.
Usage in Questionnaires
- When a questionnaire is created, chapters marked as repeatable appear empty — no topics are pre-filled.
- Click the "Add Section" button within the chapter.
- Enter a name for this section instance (e.g. "Ballast Tank No.1 PS").
- A new sub-chapter is created containing all questions from the group template.
- Repeat to add as many section instances as needed.
Scoring: Each section instance is scored independently. The chapter total reflects the combined score of all section instances.
Example
A chapter "07 Tanks" is configured as a repeatable section. During the inspection, the auditor adds three sections:
- "Ballast Tank No.1 PS" — with its own set of questions and score
- "Ballast Tank No.2 SB" — independent questions and score
- "Fresh Water Tank FWD" — independent questions and score
3. Require Tank Type
This feature extends
Configuration
- In Item Config, select a group that is already marked as Repeatable Section.
- Check the "Require Tank Type" checkbox (only visible for repeatable groups).
Usage
- When clicking "Add Section", a Tank Type dropdown appears first.
- Select the appropriate tank type (e.g. "Fuel Oil Tank", "Ballast Tank", "Cargo Tank").
- Enter the section name (e.g. "ULSHFO Bunker Tk SB").
- The section is created with a combined caption:
Fuel Oil Tank - ULSHFO Bunker Tk SB
Note: The tank type is stored with the section and appears in the generated HTML report, making it easy to identify and filter sections by type.
4. Sub-Items (Hierarchical Questions)
Questionnaire items can now have sub-items, enabling hierarchical question structures. This is useful when a main question has several related follow-up questions or detail fields.
Creating Sub-Items (Item Config)
- In Item Config, select the parent item that should contain sub-items.
- Click "New".
- A confirmation dialog asks: "Create sub-item?" — click Yes.
- The new item is created as a child of the selected item.
- Configure the sub-item with its own question text, answer type, and scoring settings.
Display in Reports
- Sub-items are displayed indented underneath their parent item in both the questionnaire editor and the generated HTML report.
- Each sub-item can have its own answer set and grading (if "Part of Scoring" is enabled).
- The parent item's score is independent of its sub-items — each is graded separately.
Example
5. Previous Inspection
A new "Previous Inspection..." button on the Cover Page allows auditors to reference the previous inspection for the same vessel. This information is included in the generated HTML report under "Previous Report".
Availability: The button is visible once the report status is In Progress or later.
Two Input Modes
Clicking the button opens a dialog with two options:
Clear
Use the "Clear" button to remove the previous inspection reference if it was set by mistake.
6. Flagged Items
Auditors can now flag individual topics during an inspection to highlight items that require special attention. Flagged items are prominently displayed in the generated HTML report.
How to Flag an Item
- Open a topic in the questionnaire.
- In the Topic Details panel, check the "Flagged" checkbox.
- The item is now marked as flagged. Repeat for any additional items.
HTML Report: Flagged Items Overview
The generated HTML report includes a dedicated "Flagged Items & Actions" overview page, placed before the chapter details. This page provides a quick summary of all flagged findings:
Report Header Indicators
The overview page header shows a summary count, for example:
"7 flagged, 2 actions" — indicating 7 items were flagged, of which 2 have corrective actions assigned.
Each chapter header in the report also shows its flagged item count:
"2 flagged, 1 action, 143 / 186 (76.88%)"
Safety Report — Repeatable Sections (Add + Delete)
ZeeBORN Safety Report Editor — Customer Documentation
1. Overview
The Safety Report Editor supports Repeatable Sections: template chapters that can be instantiated multiple times within a single report. Each instance is independent and captures its own questions and observations.
Typical example — Tank Inspection: A safety report template contains one Tank Inspection section defined once as a Repeatable-template. When the ship has, for example, 8 cargo tanks and 2 slop tanks, the crew adds 10 instances under the template — one per tank. Each instance collects its own inspection answers, photos, and observations, but all share the same underlying question structure.
Repeatable Sections keep templates small and maintainable while letting reports scale to the actual number of tanks, holds, cranes, lifeboats, or any other repeating ship inventory.
2. What's new in this release
- Add Section dialog is now a proper IDE-designed form (cleaner look, correct tab order, consistent localization).
- Sibling-insert when an existing repeated section is selected — the new section is placed under the same Repeatable-template parent, not nested inside the selected sibling.
- Tank Type picker appears automatically when the template is flagged as tank-related.
- NEW: Delete Section — individual repeated sections can now be removed, including all their questions and observations.
3. Adding a section
In the report tree on the Report tab, Repeatable-template chapters are rendered with a yellow folder icon so they are easy to spot. The toolbar above the tree carries the two relevant buttons: Add Section and Delete Section.
To add a new repeated section to an open Safety Report:
- In the report tree (
tvReport) on the Report tab, select either:- the Repeatable-template chapter itself (the parent template), or
- any existing repeated section already created under that template.
- Click the Add Section button in the toolbar.
- The Add Section dialog opens. Enter the Name of the new section (e.g. "No. 3 Cargo Tank Port").
- If the template requires a Tank Type, a Tank Type dropdown is shown — pick the matching type (see section 5).
- Click OK.
The new section appears in the tree underneath the Repeatable-template parent and is ready for answering questions and capturing observations. The example below shows the repeatable template "07. Cofferdams, ballast and fresh water tanks" with one instance "Ballast Water - Tank 1" expanded to show its individual questions:
Button availability: Add Section is only enabled when the currently selected tree node belongs to a Repeatable-template (either the template itself or one of its existing instances). For all other nodes the button is greyed out.
4. Sibling vs. child insert
When the user clicks Add Section, ZeeBORN decides where the new section goes based on what is currently selected:
This means: if you are standing on "No. 2 Cargo Tank" and click Add Section, the new "No. 3 Cargo Tank" is created next to it, not inside it. The sibling rule ensures all instances remain flat under the same template — which is how Repeatable Sections are designed to work.
Before this change, clicking Add Section on an existing section could accidentally nest the new one as a child, producing a misplaced structure that had to be corrected manually. That no longer happens.
5. Tank Type picker
When the underlying template has the RequireTankType flag set (configured in at_itemgroups.RequireTankType = 1 during template setup), the Add Section dialog shows an additional Tank Type dropdown.
The dropdown is populated from the master list cd_tanktypes (Cargo Tank, Ballast Tank, Fuel Oil Tank, Slop Tank, Fresh Water Tank, etc.) and is mandatory when shown — the dialog will not accept the new section until a Tank Type has been selected.
Why this matters: Tank-related sections carry per-section metadata that is used downstream in reporting and analytics (e.g. comparing tank inspection findings across a fleet, filtering reports by tank type). Forcing the crew to assign the correct type at creation time keeps that metadata aligned with the ship's actual tank inventory and avoids blank or guessed values later.
Templates that are not flagged as tank-related (jobs, drills, crane inspections, etc.) do not show the picker — only the Name field is required.
6. Deleting a section
Individual repeated sections can now be removed from a report.
Steps:
- In the report tree on the Report tab, select the repeated section you want to remove.
- Click the Delete Section button in the toolbar.
- A confirmation dialog appears: "Do you want to delete the selected section including all its questions and observations?"
- Click Yes to delete. Clicking No or closing the dialog cancels the action.
What gets deleted:
- The selected section row itself.
- All questions belonging to that section.
- All observations linked to that section (including photos and linked follow-up tasks, as far as they are owned by this section).
Deletion is performed via the internal DeleteChapter(SectionID) routine and is immediate and permanent.
What is protected:
Button availability: Delete Section is only enabled when the currently selected tree node is a deletable repeated section. For templates, root chapters, and non-repeatable children the button is greyed out — this prevents accidental removal of structural chapters that are part of the report template itself.
7. Known limitations and notes
- Hard delete — cannot be undone. Deleting a section permanently removes its questions and observations. There is no undo, no soft-delete, and no recycle bin. If a section is removed by mistake, it must be added back manually via Add Section and the answers re-entered.
- Only Repeatable-template children are deletable. Template chapters and top-level chapters stay protected by design — they are part of the report structure, not per-instance data.
- Tank Type is mandatory when the picker is shown. If the template requires a Tank Type, the section cannot be created without one.
- Template changes are not retroactive. If an administrator later changes a template from "not tank-related" to RequireTankType = 1, existing sections created before the change will not automatically get a Tank Type. They must be recreated if the Tank Type is needed for reporting.
- Name field is free text. There is no uniqueness check — two sections with identical names are allowed. A consistent naming scheme (e.g. "No. 1 Cargo Tank Port", "No. 1 Cargo Tank Starboard") is recommended for clarity in printed reports.
Safety Report — Port State Control (PSC) and Conditions of Class (CoC) Tabs
1. Overview
The Safety Report Editor now has two dedicated tabs for capturing Port State Control inspections and Conditions of Class issued by class societies:
- Port State Control (PSC) — PSC inspections carried out on the vessel, with any deficiencies raised.
- Conditions of Class (CoC) — CoC items issued by classification societies, with their current status.
The tab order in the editor is now:
Cover / Questionnaire / PSC / CoC / Report
Both tabs only appear for Safety Reports whose Audit Type is configured to show them (see section 3). A Safety Report can have just the PSC tab, just the CoC tab, both, or neither — depending on the audit type configuration.
Each tab combines three data sources into a single view:
- System-loaded entries — existing PSC/CoC audits that already exist in the fleet's audit system, imported on demand with Load from System.
- Manual entries — captured directly in the Safety Report via Add.
- Live deficiencies — open tasks linked to PSC/CoC audits for this ship, shown read-only and kept in sync with the task system automatically.
2. Prerequisites / Setup
Before the tabs become usable, two things must be in place:
Database migration — docs/sql/sr_psc_coc.sql adds:
- 4 new columns on
at_audittypes:ShowAsPSCInSafetyReport,ShowPreviousPSCInSafetyReport,ShowAsCoCInSafetyReport,ShowPreviousCoCInSafetyReport - 2 new tables:
sr_pscandsr_psc_deficiencies_manual
The migration has already been applied on the development database (ALBERICH) and the demo database (victoriademo). For customer databases (e.g. bluesquared), the migration is rolled out through the standard setup pipeline — no manual step required on the ship or office side.
Permissions — no new user rights are introduced. Anyone who currently has permission to edit Safety Reports can use the PSC/CoC tabs.
Configuration — the office must tick the appropriate flags on each relevant audit type (see section 3). Until that is done, the tabs stay hidden.
3. Configuring Audit Types (Office side)
This is a one-time setup done by office staff. Go to:
Audit Tool → Manage Audit Types → select the audit type → Handling area.
Four checkboxes control the PSC/CoC behaviour:
- This type is a Port State Control (source for PSC sections in safety report) — audits of this type will be offered when a user clicks Load from System on the PSC tab.
- This type is a Condition of Class (source for CoC sections in safety report) — audits of this type will be offered on the CoC tab.
- Show Port State Control section in Safety Report — Safety Reports based on this audit type will display the PSC tab and include the PSC section in the report output.
- Show Condition of Class section in Safety Report — Safety Reports based on this audit type will display the CoC tab and include the CoC section in the report output.
Both flags can be combined on the same audit type. For example, an audit type can be both a source for PSC data and a Safety Report type that renders the PSC tab in its own report.
Typical setup:
- The audit types used to record PSC inspections: tick This type is a Port State Control.
- The audit types used to record CoC items: tick This type is a Condition of Class.
- The Safety Report audit types (e.g. Master's Review, Internal Audit) that should carry the PSC/CoC sections: tick Show Port State Control section in Safety Report and/or Show Condition of Class section in Safety Report.
4. Opening a Safety Report with PSC/CoC Tabs Visible
Open the Safety Report as usual. If the report's audit type has the corresponding Show ... section in Safety Report flag set, you will see the PSC and/or CoC tab between Questionnaire and Report.
If the tabs do not appear for a report where you expect them, check with the office that the audit type is correctly configured — the tabs are hidden by design when the flag is off, so the Safety Report stays clean for types where PSC/CoC is not relevant.
5. The PSC Tab
The PSC tab shows a list of PSC inspections attached to this Safety Report. For each entry you see:
- Audit Date — when the inspection took place.
- Port — where it took place. Shown from the port table if linked, otherwise the free-text port recorded on the audit.
- Auditor — the inspecting authority.
- Source — whether the entry was loaded from the audit system or entered manually.
- Deficiencies — the list of findings, combining live open tasks and manual entries.
Actions available on the PSC tab:
- Load from System — import existing PSC audits for this ship (see section 6).
- Add — create a manual PSC entry (see section 7).
- Edit — modify a manual entry. Entries loaded from the system are controlled by their source audit.
- Delete — remove a manual entry.
- Add Deficiency — on an entry, add a deficiency by hand (see section 8).
6. Load from System
Click Load from System on the PSC tab to import existing PSC audits into the report.
A dialog opens showing all audits for this ship whose audit type is flagged as This type is a Port State Control. Pick one or multiple, then confirm.
What happens:
- Entries you previously added by hand stay untouched.
- Entries previously loaded from the system are replaced by the current selection.
- Each selected audit is inserted as a separate row, inside a single database transaction — if anything fails, the whole load is rolled back and nothing changes.
- Each inserted row carries a
SourceAuditIDback to the original audit, so the link is preserved for future reloads.
Use this whenever new PSC inspections have been recorded in the audit system and you want them reflected in the current Safety Report.
7. Adding a Manual PSC Entry
Click Add on the PSC tab. The AddPSC dialog opens. Fill in:
- Audit Date
- Port
- Auditor
Confirm to save. The entry appears in the list and is marked as manual — it will not be touched by future Load from System operations.
8. Adding a Manual Deficiency
On any PSC entry (system-loaded or manual), click Add Deficiency. The AddPSCDeficiency dialog opens. Fill in:
- Defect Code
- Description
- Date Found
- Status
Confirm to save. The deficiency is attached to that PSC entry and shown in its deficiency list.
Manual deficiencies stay attached to their entry regardless of whether the entry itself is reloaded from the system.
9. Live Deficiencies from Open Tasks
In addition to manual deficiencies, every PSC entry automatically lists open tasks that are linked to PSC/CoC audits for this ship. These come straight from the task system (tt_tasks) and are shown read-only in the PSC tab.
Why read-only: these tasks have their own lifecycle in the task system. Editing them in the Safety Report would break that lifecycle. To change a live deficiency, open the corresponding task in the task system — the change will show up here on the next refresh.
Closed tasks are not listed. Once a task is completed and closed, it drops out of the live deficiency view.
10. The CoC Tab
The CoC tab works exactly like the PSC tab — same layout, same actions, same dialogs (Add, Load from System, Add Deficiency). The only difference is the data scope:
- Load from System offers audits flagged as This type is a Condition of Class (instead of PSC).
- Live deficiencies come from CoC-linked audits.
- Configuration uses the Show Condition of Class section in Safety Report flag.
Everything described in sections 5 through 9 applies identically.
11. Read-Only Mode When the Report Is Closed
Once a Safety Report is set to status Closed (arClosed), the PSC and CoC tabs still render all entries exactly as before — but the action controls (Add, Edit, Delete, Load from System, Add Deficiency) are hidden.
A banner at the top of each tab reads:
Report is closed — entries are read-only
To make further changes, the report must be reopened by someone with the appropriate permission.
12. Report / PDF Export
When the Safety Report is exported, the PSC and CoC sections are rendered into the HTML and PDF output. Each section includes:
- All PSC (or CoC) entries in the report, with Audit Date, Port, and Auditor.
- The complete list of deficiencies per entry — both manual deficiencies and live open tasks.
The sections are only included in the export for Safety Report types where the corresponding Show ... section in Safety Report flag is set. Reports without the flag produce the same output they always did.
13. Known Limitations / Notes
- Historical PSC/CoC loads are not paginated. The Load from System dialog lists all matching audits for the ship without a
LIMIT. For a typical fleet this is fine — a ship usually has a manageable number of PSC inspections over its lifetime. For ships with exceptionally long audit histories, expect the dialog to take a moment to populate. - Source linking is one-way. A Safety Report entry remembers which audit it came from (
SourceAuditID), but changes made to the source audit after loading are not automatically pushed into the report. Use Load from System again to pull a refreshed copy. - Port field fallback. If the source audit has no linked port record, the free-text port is used. Keep port entries tidy on the audit side for cleaner PSC/CoC lists.
- Manual vs. system entries are distinct. Manual entries survive every Load from System; system entries are replaced on every load. Mixing both in the same report is supported and expected.