This page documents the Non-EB Claims web workflow: list and filter claims, create and edit tickets, status-driven form sections, document uploads, manual email reply, mail template CRUD, auto-mail on create/status change, and claim reports.

Scope: authenticated MVC routes under /non-eb-claim/* only. Mobile/REST endpoints in Api\NonEbClaimApiController are not covered here.

Policy types are limited to policy_type.allocg IN ('Non-EB', 'Marine'). Claim records live in non_eb_ticket_master; claim files use ticket_type = 2 in claim_files.

End-to-end flow

Typical user path:

1. Open claim list (default: open claims excluding settled/closed/rejected/withdrawn).
2. Add claim → form opens with canonical status policy type 50 — see why 50 is hardcoded.
3. On save, optional auto-mail fires if a matching template has is_auto_mail = 1.
4. Open claim from list → edit view with history, messages, files, notes.
5. Change status → allowed next statuses from ticket_claim_status.allowed_status; section visibility updates.
6. Configure templates at /non-eb-claim/mail_template (direct URL; not in main Claims sidebar today).

Why policy type 50 is hardcoded (read this before changing Non-EB Claims)

Design assumption

Claim statuses live in ticket_claim_status, keyed by ticket_type (which equals policy_type.id). Mail templates in ticket_mail_template also key off ticket_type + trigger_type from that status row.

Instead of maintaining duplicate status trees for every Non-EB product, developers assumed:

All Non-EB and Marine policy types share one identical claim status lifecycle. That lifecycle is configured only under policy type 50 in ticket_claim_status (and matching templates under ticket_type = 50).

New claims opened via the list Add button or New Non EB Claim menu therefore pass 50 into the form URL. Status dropdowns, section visibility, and initial status resolution in getClaimStatusForPolicyType($policy_type_id) all use that id on create — not the id of the policy the user later picks from client_policy.

Policy type 50 vs policy selected on the form

On create (non_eb_claim_form.php):

• Hidden policy_type_id is set from the URL segment (typically 50) and is not updated when the user selects a branch policy.
• The UI shows the real product name in policy_type_display from the selected policy row (data-policy-type).
• POST /non-eb-claim/create persists policy_type_id from that hidden field — so new tickets from Add often store policy_type_id = 50 even when the linked policy is Fire, Marine, etc.

On edit (non_eb_claim_edit.php), policy_type_id comes from non_eb_ticket_master as saved. Status changes and templates use that stored id.

Where 50 appears in code (change all if this design changes)

When a Non-EB product needs a different status set

If a new (or existing) policy type must have its own statuses, triggers, or allowed transitions (not the shared tree under 50), you cannot only change the product row in policy_type. You must update both backend and frontend:

1. Database — Add full ticket_claim_status rows with ticket_type = <that policy_type.id> (claim_status, display_name, trigger_type, allowed_status JSON). Add matching ticket_mail_template rows for that ticket_type if auto-mail applies.
2. Routes / entry URL — Stop routing every new claim through 50: e.g. change claimForm/50, restore policy-type picker modal (commented in non_eb_claim_search.php), or pass the correct policy_type_id per product.
3. List Add button — Replace hardcoded new/50 in non_eb_claim_list.php with the correct id or dynamic selection.
4. Create form — On policy selection, set hidden #policy_type_id to the real policy_type_id from getBranchAndPolicy (field p.policy_type_id is already returned) so create/update and getVisibleSections use the right status tree.
5. Controller logic — Ensure getClaimStatusForPolicyType, getTemplateDataByTicketID, and filters that assume a single Non-EB status catalog are tested for the new ticket_type.
6. API — Replace hardcoded 50 in listClaimStatuses() if mobile clients need per-product statuses.

Until those steps are done, pointing Add at another id without cloning the full status + template set under that id will produce empty status lists, wrong section visibility, or missing auto-mail.

Key files and routes

MVC route map

Access control

All routes in the /non-eb-claim group use the authMVC filter. Acl.php allows roles HEAD, ADMIN, MANAGER, ACCOUNT_MANAGER on the Claims team.

List row actions (view / delete) render only for roles 1, 2, 5 in non_eb_claim_list.php.

List and filter

GET /non-eb-claim/list loads non_eb_claim_search.php, which includes the table partial. Initial data comes from claimSearch(1): active tickets where status display name is not in Claim Settled, Claim Closed, Claim Rejected, Claim Withdrawn.

Filter sidebar posts the same URL with criteria (at least one required):

• policy_type_id, insurer_id, claim_number, nhance_claim_ref_no
• client_id, claim_status_id (status options filtered by policy type in JS)
• date_type + start_date / end_date (created_date or updated_date)

Response is JSON { status: true, html: "…" }; JS replaces #claim_list_div and re-initializes the DataTable. Row click navigates to /non-eb-claim/view/{id}.

Add button: window.location.href = '/non-eb-claim/new/50'. Header menu uses /non-eb-claim/new (routes to claimForm/50). See Policy type 50 for why this id is fixed and what to change if a product needs its own statuses.

Create and edit claim

Create

1. GET /non-eb-claim/new/{policy_type_id} → getFormData(): ACMs (role 3), clients, insurers, initial claim status for product, visible sections.
2. User selects client → POST getBranchAndPolicy fills branch, policy (Non-EB/Marine only), branch contact.
3. Status change → POST getVisibleSections toggles accordion sections client-side.
4. POST /non-eb-claim/create — validation via getValidationRules(), sanitizeInputArrayAdvanced, date normalization, optional asset file upload.
5. Duplicate guard: same client_id + loss_date + policy_no (if policy set) → HTTP 409-style JSON.
6. On success: insert non_eb_ticket_master, saveAssets(), history row, sendAutoMailTrigger(), redirect to list.

View / edit

view_claim($id) loads ticket via NonEbTicketMasterModel::getTicketDataByTicketID(), merges mail template preview (getTemplateDataByTicketID + placeholder replace), messages, history, assets, and reuses the edit view non_eb_claim_edit.php.

POST /non-eb-claim/update mirrors create validation. If claim_status_id changes, auto-mail runs again. remark_mode=append appends to closure_remark with a separator.

Status-driven sections

$statusSectionVisibility in the controller maps each ticket_claim_status.claim_status label to section keys: policy_account, loss_incident, intimation, insured_contact, asset, documents, surveyor, settlement.

Allowed next statuses come from getClaimStatusForPolicyType(): current status plus IDs in allowed_status JSON on the status row. Both create and edit forms call getVisibleSectionsAjax when the user changes status.

Auto-mail and placeholders

Template lookup (NonEbTicketMasterModel::getTemplateDataByTicketID):

• Join ticket_claim_status on ticket’s claim_status_id (or explicit status_id for tests).
• Join ticket_mail_template where ticket_type = policy_type_id AND trigger_type = tcs.trigger_type.

sendAutoMailTrigger($ticket_id) sends only when the matched template has is_auto_mail = 1. Mail goes to insured_contact_email from constructMailContent(); from address claims@nhanceindia.in via MailHelper::send_email(). Successful sends insert a ticket_messages row via autoMessageInsertBasedOnMailResponse().

Placeholders (subject/body):

Edit screen also supports manual reply: POST /non-eb-claim/reply validates To/Subject, inserts ticket_messages, sends via sendReplyMessage() with placeholder replacement.

Mail template CRUD

Page: GET /non-eb-claim/mail_template. DataTable lists rows from ticket_mail_template (is_active = 1). Tooltip on each row shows the matching ticket_claim_status.claim_status for that policy type + trigger type.

Template fields

• template_name, ticket_type (policy type id), trigger_type (1–9)
• subject, mail_content (Jodit HTML)
• is_auto_mail — checkbox “Auto Mail” (1 = send on create / status change when matched)
• Optional id on save for update

Trigger ↔ status: Each ticket_claim_status row for a Non-EB/Marine ticket_type has a trigger_type. The template’s trigger_type must match that column for auto-mail and for the “Claim Status” readonly hint (tool_tip from server on fetch).

UI actions

Placeholder dropdown in the modal inserts tokens into subject (focused input) or Jodit body. Validation errors return HTTP 400 with errors map (shown via toastr).

Notes

On the edit screen:

• POST /non-eb-claim/note/1 — id (ticket), optional is_auto_query → fetch active note.
• POST /non-eb-claim/note/2 — save note (required 3–1000 chars) via TicketNoteModel.

Documents and IR checklist

• uploadFile — multi upload to writable/uploads/claim_files/ or Google Drive URLs (file_type 1 vs 2).
• getClaimFiles — lists rows; local files expose download URL downloadClaimFile/{id}.
• removeFile — soft delete by file id.
• saveIRDocs — stores JSON in non_eb_ticket_master.required_docs.
• Asset spreadsheet on ticket: asset_file under writable/uploads/non_eb_asset_files/; loss description required when file uploaded.

Reports

GET /non-eb-claim/reports renders filters: policy type, ACM name, date range (default last 60 days). generateReport() in the view POSTs to the same URL and expects { status: true, data: [ rows ] } for DataTable columns (status, policy type, claim/ref, client, insurer, loss fields, surveyor, settlement, ACM, created date).

Gap: NonEbClaimController::claimReports() only handles GET (layout load). There is no POST handler to return report data — Generate Report will fail until POST logic is added (mirror EB ticket_reports or reuse claimSearch with report-specific selects).

Data model (summary)

Controller reference

Developer checklist

1. Ensure ticket_claim_status rows exist per Non-EB/Marine policy_type.id with correct trigger_type and allowed_status.
2. Create mail templates at /non-eb-claim/mail_template with matching ticket_type + trigger_type; enable Auto Mail only where intended.
3. Verify insured email is present before relying on auto-mail.
4. Before changing Add/new URLs: read Policy type 50 — clone statuses + templates in DB and update every hardcoded 50 if a product needs its own workflow.
5. Implement POST branch in claimReports() if reports Generate must work.
6. Claim files: always set ticket_type = 2 in new file-related code paths.
7. ACL: extend #^/non-eb-claim# if new roles need access.

Common pitfalls

• Template mismatch: No row in ticket_mail_template for policy type + status trigger_type → no auto-mail and empty reply preview.
• Reports POST missing: UI POSTs to /non-eb-claim/reports but controller only loads view on GET.
• Duplicate claims: Same client + loss date + policy number blocked on create.
• Policy type 50 assumption: Shared status catalog under DB ticket_type = 50; Add/new routes and hidden form field use 50 — not the policy picked on the form. Different per-product statuses require full backend + frontend changes — checklist.
• Menu vs Non-EB templates: Sidebar “Mail Template” points to EB /ticket/mail_template, not Non-EB.
• Soft deletes: Remove claim/file/template sets is_active = 0; list queries filter active only.
• Asset file: Upload without loss description fails validation on create/update.
• REST API separate: Mobile create/list under employeeRest / Api\NonEbClaimApiController — different validation and flows.