Deletion removes active members from a client policy via Excel upload (files.action = deletion). Unlike inception, the final step does not delete rows immediately — it creates pending endorsement records on employee_polices for approval/processing later.

Core processing lives in EmployeeServiceController::employeeDisembark. EmployeeController::initializeDeletionProcessForTpaApiData is a separate TPA-reconcile path that builds a deletion Excel file and calls the same disembark function.

Overview

In short:

Step 1 — Format: 7 columns (A–G), mandatory exit fields per action code D.
Step 2 — Data: Member must exist in DB (emp code + name + active policy); code 10 if not found.
Step 3 — Disembark: Writes pending deletion endorsements; Self row removes whole family, dependent row removes one member.
Files < 1 MB run format validation inline; data validation and disembark are always queued.

Key files and routes

Area	Location
UI	`app/Views/employee_upload.php` — action Deletion
Upload	`EmployeeController::employeesUplodWithEvents`
Validation	`EmployeeServiceController::excelFileFormatValidation`, `excelFileDataValidation`
Deletion process	`EmployeeServiceController::employeeDisembark`
TPA auto-deletion	`EmployeeController::initializeDeletionProcessForTpaApiData`
Job	`employeeDisembark` in `JobWorker.php`
Endorsements	`EmpEndorsementModel` → `emp_endorsement` (`actions = d`, `status = pending`)

Routes (group /employee, authMVC):

GET /employee/upload — upload screen
POST /employee/upload — upload-action-type=deletion
GET /employee/excel_error/{file_id} — read files.reason after validation failure

files.policy_id is the client policy id. Member lookup joins employees + employee_polices on that policy and branch.

Sync vs background jobs

Step	< 1 MB	≥ 1 MB
Format validation	Inline on upload	Job `excelFileFormatValidation`
Data validation	Job `excelFileDataValidation`	Same
Disembark	Job `employeeDisembark`	Same

Step 1: excelFileFormatValidation

Uses $deletion_excel_columns — 7 columns (A–G).
Action code D drives mandatory fields: Change event, Date of exit, Reason for exit, Claim status.
Date of exit format: d-M-Y.
Claim status allowed: 0 or 1.

Format error codes

Code	Meaning
1	Mandatory missing
2	Wrong format
3	Not in allowed list
4	Custom validation failed
5	File / policy problem
6	Column headers wrong

Step 2: excelFileDataValidation

Rows are grouped by EMP ID. For deletion, the main check is name_and_empid_check_in_db:

Each row must match an active employee + active employee_polices row on the uploaded policy/branch.
If not found → error code 10 (“Record Not found”) on that Excel row.

On success → queues employeeDisembark (not employeesOnboardPreprocess).

Step 3: employeeDisembark

Loads the Excel again and processes each non-empty row.

flowchart TD A["Match emp_code plus name on active policy"] --> B{"Found?"} B -->|No| C["Log error skip row"] B -->|Yes| D{"Pending deletion endorsement?"} D -->|Yes| E["Log skip row"] D -->|No| F{"Relationship Self?"} F -->|No| G["Endorse this member only"] F -->|Yes| H["Endorse all active family members"] G --> I["emp_endorsement pending"] H --> I

Per matched member, four pending endorsement rows are inserted on employee_polices:

date_of_exit ← Excel column E (converted to Y-m-d)
reason_for_exit ← column F
status → inactive
claim_status ← column G

Returns an array of processed employee.id values. Sets files.status = success when the loop finishes (even if some rows were skipped — check logs for “not found” or “existing endorsement pending”).

TPA auto-deletion (EmployeeController)

initializeDeletionProcessForTpaApiData($file_id):

Reads TPA reconcile file context (tpa_api_data, action_flag_status = D).
Builds candidate members and writes writable/uploads/excel/tpa_auto_deletion_{fileId}_{timestamp}.xls.
Inserts a new files row with action = deletion.
Calls employeeDisembark(['file_id' => $newFileId]) synchronously.
Exports endorsement data for TPA via getDeletionEmployeeDataForExportExcel.

Deletion Excel columns

Col	Header	Required	Notes
A	S.No	Yes
B	EMP ID	Yes	Employee / family code
C	NAME OF EMP/DEP	Yes	Must match DB name exactly
D	Change event	Yes	e.g. `deletion`
E	Date of exit	Yes	`d-M-Y`
F	Reason for exit	Yes
G	Claim status	Yes	`0` or `1`

Row layout examples

Delete one dependent — only that name appears; Self row is not required in the file.

Row	EMP ID	NAME	Change event	Date of exit	Reason	Claim
2	EMP001	Arjun Kumar	deletion	19-May-2026	Resigned	0

Result: endorsements for Arjun only (relationship ≠ Self).

Delete entire family — list the Self row; disembark loads all active family members for that EMP ID.

Row	EMP ID	NAME	Change event	Date of exit	Reason	Claim
2	EMP001	Raj Kumar	deletion	19-May-2026	Resigned	0

Result: pending endorsements for Self + all active dependents on that policy (same exit date/reason/claim from the row).

Developer steps

Upload via /employee/upload with action deletion; note file_id.
If validation fails, use GET /employee/excel_error/{file_id} — look for code 10 (member not in DB).
After success, query emp_endorsement where file_id = upload id, actions = 'd', status = 'pending'.
If rows were skipped, search logs for not found or Existing endorsement pending.
TPA path: trace initializeDeletionProcessForTpaApiData and the generated tpa_auto_deletion_*.xls file.

Common pitfalls

Name mismatch — Excel name must match employees.name exactly (case/spacing).
Not active — only emp_status = active and employee_polices.status = active match.
Duplicate pending deletion — row skipped if a pending deletion endorsement already exists for that policy row.
Self vs dependent — wrong relationship in the row changes scope (one member vs whole family).
File always success after disembark — files.status does not reflect per-row skips; use endorsements table + logs.
Not immediate delete — members stay active until endorsements are approved/applied downstream.

Related: Inception (onboard pipeline uses the same upload screen and first two validation steps).