Notifications

The Notifications screen is the portal inbox that surfaces every notification routed to the current user. Each row is a single delivery — one invoice status change matched by a Notification Rule, wrapped with the right subject, message and metadata, and persisted in the F564253 table.

The page is the read side of the notification system. The write side — which event triggers what notification, sent to whom, on which channels — lives in the Notification Rules editor.

A complementary bell in the top utility bar polls the unread count every 30 s and previews the last six entries without leaving the current page; clicking a preview opens the linked invoice modal directly.

The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP — since the notification payload is built from the persisted UBL invoice, not from the raw source XML.

---

Opening the inbox

• Sidebar → Management → Notifications.
• Or click the 🔔 bell in the top utility bar, then View all at the bottom of the dropdown.
• The inbox always opens on the All tab; switch to Unread to focus on what has not been acknowledged yet.

---

At a glance

A notification row carries five visual cues: the status badge at the left (colour from the statuses catalogue), the subject (default Invoice {doc} {dct} {kco} — {statusLabel}), the message (the rule's body or the dispatcher's default), the meta line with the canonical identifiers, and a right column with relative time + the dismiss button.

---

Toolbar actions

Action	Effect
Refresh	Re-fetches the inbox from /api/notifications, honouring the active tab filter (All vs Unread).
Mark all read	Posts to /api/notifications/mark-all-read. Every row that was unread switches to read; the bell badge clears at the next 30 s poll, or immediately on the next focus event. Disabled when there are no unread rows.
Filter tabs	All shows every undismissed row; Unread keeps only the rows where read = false. The unread tab carries the ( N ) count next to its label.

---

A row, in detail

Element	Source	Meaning
Left accent stripe + tinted background	read = false	Unread rows. The stripe disappears the moment the row is marked read.
Status badge	NTEV01 joined to the statuses catalogue	The status that fired the notification. The badge background, foreground and border come from the catalogue colours, so 9904 / PA Reject is red, 10 / Deposited is green, 9906 / PA Pending is orange, etc.
Subject (top line)	NTSUBJ (rule's emailSubject, or the dispatcher default)	Short, human-readable headline. The default is Invoice {doc} {dct} {kco} — {statusLabel}.
Message (second line)	NTMSGE (rule's emailBody, or the dispatcher default)	The fuller body text. Truncated on overflow; the modal that opens on click carries the full lifecycle.
Meta line	NTDOC · NTDCT · NTKCO · reason · action · rule	Canonical invoice identifiers, plus the PA rejection reason / expected action / rule name when present. The reason and action are resolved against the rejection-reason-codes and action-codes catalogues, so the user reads the human label, not the bare code.
Action audit chips (2026.05.7)	NTK74MSG2 audit footer	One coloured chip per connector call the dispatcher fired for the rule. See Action audit chips below.
Relative time	NTUPMJ + NTTDAY	just now, 2 min ago, 14:32 (today), Yesterday, then the absolute dd/mm/yyyy hh:mm for older entries.
Dismiss button	per-row	Removes the row from the inbox without marking the rest as read.

Clicking anywhere in the row body opens the invoice detail modal for the linked (doc, dct, kco) triplet — same seven tabs as the E-Invoicing page (Summary, Parties, Lines, VAT, Notes, History, PDF). The row is marked read on the way through.

---

Action audit chips

Since 2026.05.7, every notification dispatched by a Notification Rule that defines one or more action calls carries a permanent audit trail stored in the NTK74MSG2 column. The inbox renders the trail as a row of colour-coded chips below the message, one chip per call:

Chip	Colour	Meaning
OK	green	The call ran without error. For an api-action: HTTP < 400. For a sql-action: the statement returned without an exception.
FAIL	red	The call returned an error. The message text on the chip carries the failure reason — HTTP status + body for an api-action, JDBC exception for a sql-action.
STOP	orange	The call was a STOP · N remaining call(s) skipped marker. Set by a previous FAIL on a call whose On failure flag was Stop the chain on failure.
SKIP	muted	A call that was skipped because an earlier call in the chain hit a STOP.

Because the audit lives in NTK74MSG2 rather than the body, it survives the body's line-clamp truncation and remains readable at a glance — a row whose message ends with OK · OK · FAIL is easier to triage than one where the audit was buried in the body text. The audit footer is capped at the column width minus a safety margin; long error messages are truncated, but the Status and count fields always fit.

---

The 🔔 bell in the navbar

A complementary entry sits in the top utility bar of every page. Three things it does:

1. Polls every 30 s the unread count (GET /api/notifications/unread-count). A red badge shows the count when greater than zero.
2. Drops down the last 6 entries on click — same shape as an inbox row, but condensed: subject, message, doc reference, relative time. Unread rows carry the same blue dot used in the inbox. When the rule fired one or more action calls, the bell preview strips the NTK74MSG2 audit footer and shows a compact summary line in its place: 2 action(s) ran (muted) when every call returned OK, 1 of 2 action(s) failed (red) when at least one chip is FAIL. A glance at the bell is enough to know whether to drill into the inbox.
3. Clicking a preview marks the entry read and opens the invoice modal directly. The bell uses a small dance to handle both cases: when the user is already on the inbox, it dispatches a nomaubl:open-notification window event so the modal opens without a remount; otherwise it stores the payload in sessionStorage under notif-auto-open and navigates to /notifications, which drains the entry on cold mount.

A View all footer at the bottom of the dropdown links to /notifications for the full inbox.

The bell stays visible regardless of authentication state: when global.authEnabled != "Y", the inbox shows the broadcast notifications written under the NTUSER='*' sentinel, and the bell counts them.

---

Storage & retention

Every delivered notification is one row in F564253 (Oracle + Postgres). The columns the inbox cares about are:

Column	Type	Role
NTUKID	numeric	Primary key. Unique across the whole table — the row addresses no longer carry the (doc, dct, kco) triplet.
NTUSER	string	Resolved username, or * when running with auth disabled (broadcast).
NTEV01	string	0 for unread, 1 for read. The bell badge counts rows where NTEV01 = 0.
NTSUBJ / NTMSGE	string	Subject / message body.
NTK74MSG2	string	Action audit footer written by the dispatcher (OK / FAIL / STOP / SKIP per call) — drives the chips section. New in 2026.05.7.
NTDOC / NTDCT / NTKCO	mixed	The invoice triplet; nullable for system-level alerts that don't link to a specific invoice.
NTUPMJ / NTTDAY	jul / hms	Issue date and time. The composite index on (NTUSER, NTEV01, NTUPMJ DESC) keeps the bell badge query and the inbox sort fast.

A daily retention sweep in BackgroundScheduler deletes rows older than global.notificationsRetentionDays (default 90 days). Set the property to 0 to disable the sweep — useful for installations that want to keep notifications indefinitely or that drive their own retention policy.

---

Tips & best practices

• Triage with the Unread tab. Switching to Unread is faster than scrolling the All feed; Mark all read clears every row in one click when the day-end review is done.
• Use the meta line for context. The reason · action · rule fragment tells you why a notification fired — useful when several rules cover overlapping status codes.
• The bell is a peek, not the inbox. It only shows the last six entries; for triage of every undismissed row, open Notifications. The View all footer of the dropdown is the one-click shortcut.
• Dismissing is not the same as marking read. Dismiss removes the row from your inbox; Mark read leaves it in All with no accent. Use Dismiss for entries that don't need an audit trail.
• For PA rejections, click through. A 9904 / PA Reject row carries the reason in the meta line, but the lifecycle on the invoice modal's History tab carries the full PA payload and the expected action.
• Configure retention. Notifications can grow fast — every status change of every invoice produces a row when a matching rule fires. The 90-day default fits most installations; raise or lower it via global.notificationsRetentionDays.