# 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

1. Open the **Audits** module.
2. Go to **Configuration** > **Manage Audit Types**.
3. Select an Audit Type and set the **Default Responsible Role** dropdown.
4. 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

1. [Part of Scoring](#1-part-of-scoring)
2. [Repeatable Sections](#2-repeatable-sections)
3. [Require Tank Type](#3-require-tank-type)
4. [Sub-Items (Hierarchical Questions)](#4-sub-items-hierarchical-questions)
5. [Previous Inspection](#5-previous-inspection)
6. [Flagged Items](#6-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:

| Level | Where to find it | Effect when unchecked |
|-------|-----------------|----------------------|
| **Answer Set** | Item Config → Answer Sets → Edit | The entire answer set is excluded from scoring wherever it is used |
| **Item Number** | Item Config → select an item → Details panel | This specific question is excluded from scoring in all questionnaires that use it |
| **Questionnaire Topic** | Questionnaire → Topic Details panel | This topic is excluded from scoring in this specific questionnaire only |

### 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)

1. Open **Item Config** and navigate to the group (chapter) you want to make repeatable.
2. In the group properties, check the **"Repeatable Section"** checkbox.
3. Save the configuration. The chapter is now marked as repeatable for all questionnaires that use this group.

### Usage in Questionnaires

1. When a questionnaire is created, chapters marked as repeatable appear **empty** — no topics are pre-filled.
2. Click the **"Add Section"** button within the chapter.
3. Enter a **name** for this section instance (e.g. "Ballast Tank No.1 PS").
4. A new sub-chapter is created containing all questions from the group template.
5. 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 [Repeatable Sections](#2-repeatable-sections) with an optional **tank type classification**. When enabled, auditors must select a tank type before creating a new section instance.

### Configuration

1. In Item Config, select a group that is already marked as **Repeatable Section**.
2. Check the **"Require Tank Type"** checkbox (only visible for repeatable groups).

### Usage

1. When clicking **"Add Section"**, a **Tank Type dropdown** appears first.
2. Select the appropriate tank type (e.g. "Fuel Oil Tank", "Ballast Tank", "Cargo Tank").
3. Enter the section name (e.g. "ULSHFO Bunker Tk SB").
4. 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)

1. In **Item Config**, select the parent item that should contain sub-items.
2. Click **"New"**.
3. A confirmation dialog asks: **"Create sub-item?"** — click **Yes**.
4. The new item is created as a child of the selected item.
5. 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

| Item | Type | Answer |
|------|------|--------|
| **Ballast Water Management** | Parent (Answer Set) | Satisfactory / Unsatisfactory |
|     Last Sample Date | Sub-item (Date) | *date picker* |
|     Certificate Valid Until | Sub-item (Date) | *date picker* |
|     Treatment System Operational | Sub-item (Answer Set) | Yes / No |

---

## 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:

| Mode | Description | When to use |
|------|-------------|-------------|
| **Select from list** | Shows all previous audits/inspections for this vessel (across all inspection types). Each entry displays the inspection name, date, and achieved score. | When the previous inspection was conducted in ZeeBORN |
| **Enter manually** | Allows free-text entry of: Name, Date, Score, Max Score | When the previous inspection was conducted externally or before ZeeBORN was in use |

### 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

1. Open a topic in the questionnaire.
2. In the **Topic Details** panel, check the **"Flagged"** checkbox.
3. 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:

| Column | Description |
|--------|-------------|
| **Chapter** | The chapter containing the flagged item |
| **Topic** | The specific question/topic that was flagged |
| **Grading** | The score/grade assigned to the item |
| **Remarks** | Auditor remarks for the item |
| **Action** | Any corrective action assigned to the item |

### 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

1. **Add Section dialog** is now a proper IDE-designed form (cleaner look, correct tab order, consistent localization).
2. **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.
3. **Tank Type picker** appears automatically when the template is flagged as tank-related.
4. **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**.

![Toolbar and chapter tree — yellow folder icons mark Repeatable-templates](images/repeatable-sections/01-toolbar-tree-with-repeatable.png)

To add a new repeated section to an open Safety Report:

1. 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.
2. Click the **Add Section** button in the toolbar.
3. The **Add Section** dialog opens. Enter the **Name** of the new section (e.g. *"No. 3 Cargo Tank Port"*).
4. If the template requires a Tank Type, a **Tank Type** dropdown is shown — pick the matching type (see section 5).
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:

![Repeatable section instance with its own questions](images/repeatable-sections/02-section-instance-with-questions.png)

**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:

| Current selection                           | New section is placed as... |
|---------------------------------------------|------------------------------|
| The Repeatable-template chapter             | **Child** of the template    |
| An existing repeated section (sibling)      | **Sibling** under the same template parent |

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:**

1. In the report tree on the **Report** tab, select the repeated section you want to remove.
2. Click the **Delete Section** button in the toolbar.
3. A confirmation dialog appears: *"Do you want to delete the selected section including all its questions and observations?"*
4. 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:**

| Node type                                       | Can be deleted? |
|-------------------------------------------------|-----------------|
| Sub-chapter under a Repeatable-template parent  | Yes             |
| The Repeatable-template itself                  | No              |
| Top-level (root) chapters                       | No              |
| Regular, non-repeatable child chapters          | No              |

**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:

1. **System-loaded entries** — existing PSC/CoC audits that already exist in the fleet's audit system, imported on demand with **Load from System**.
2. **Manual entries** — captured directly in the Safety Report via **Add**.
3. **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_psc` and `sr_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 `SourceAuditID` back 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.

*[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)