---
title: Claim employee work address management
summary: Maintains the address of the work site where the injury occurred, applying the shared address validation rules and returning an empty new address when none is on file.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim
reference_type: package
operation_id: OP-BC-13
trigger: A caller retrieves or creates the employee work address for a claim and saves it
---

# Claim employee work address management

The employee work address records where the injured worker was working when the injury occurred, which matters for jurisdiction, employer verification, and correspondence. This operation retrieves that address for a claim, or hands back a blank one when none exists yet, applies the shared address validation rules with a claim-specific error prefix, and persists inserts, updates, and deletes.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-BC-13 |
| **Trigger** | `clsClaimEmployeeWorkAddress.GetClaimEmployeeWorkAddress`, `NewClaimEmployeeWorkAddress`, or `EmptyAddress`, followed by `Save()` |
| **Inputs** | `ClaimID`; address lines, city, state code, ZIP code and ZIP plus-four, county, country, and the foreign-address flag; `UpdateNum` |
| **Outputs** | A persisted `CL_CLAIM_EMPLOYEE_WORK_ADDRESS` row; the populated address object; error messages `InsertError`, `UpdateError`, `DeleteError`, and address rule failures |
| **Primary components** | `clsClaimEmployeeWorkAddress.Create`, `clsClaimEmployeeWorkAddress.SetupAddressObject`, `clsClaimEmployeeWorkAddress.AfterRetrieve`, `clsClaimEmployeeWorkAddress.Fill`, `clsClaimEmployeeWorkAddress.IsEmpty` |
| **Entry point** | `Business\SAIF.Business.Claim\clsClaimEmployeeWorkAddress.vb` |

## Steps

1. **Create a blank address.** `Create` stores the claim identifier and the acting portal user, sets the county to the numeric-zero character, sets the update number to zero, clears the foreign-address flag, configures the address object, and marks the object new. The `EmptyAddress` factory does the same and then marks it clean, so a caller can display an empty form without the object appearing edited.
2. **Configure the address behavior.** `SetupAddressObject` tells the state code field not to treat an empty value as blank, sets the address rule error prefix to "Error: The employee work address", switches on ZIP, ZIP plus-four, and state code validation, and registers the address business rules.

   > **Origin**: The address validation rules applied in this step are implemented by `clsAddress` in `SAIF.Business` and executed on behalf of this operation; see [Address and bank validation support](../../saif-business/operations/address-and-bank-validation-support.md).
3. **Retrieve the claim's address.** `GetClaimEmployeeWorkAddress` selects the address columns for the claim ([SQL-018](../sql/SQL-018-saif-business-claim.md), [CL_CLAIM_EMPLOYEE_WORK_ADDRESS](../database-tables.md#cl_claim_employee_work_address)).
   - When a row is returned: fill the object and mark it old so a subsequent save takes the update path.
   - When no row is returned: seed the same defaults used at create, then mark the object new and clean, so the caller receives a usable blank address instead of an error.
   - Either way, the address object is reconfigured afterwards so the validation rules apply to a retrieved address as well as a new one.
4. **Normalize the stored values while filling.** `Fill` temporarily disables active formatting so the raw column values load unchanged, then re-enables it; it interprets the foreign address flag as the character `Y`, and reads the ZIP code as a number, treating a value of zero as an empty ZIP and otherwise left-padding it to five digits ([BR-015](../business-rules.md#br-015-employee-work-address-zip-codes-are-stored-numerically-and-normalized-to-five-digits)).
5. **Insert the address.** Saving a new address inserts the claim identifier and the address columns with a literal `SYSDATE` and a literal update number of zero ([SQL-005](../sql/SQL-005-saif-business-claim.md), [CL_CLAIM_EMPLOYEE_WORK_ADDRESS](../database-tables.md#cl_claim_employee_work_address)).
   - If exactly one row is not affected: add `InsertError` carrying the framework database contention message ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).
6. **Update the address.** Saving an existing address writes the address columns, `SYSDATE`, an incremented update number, and the update user, keyed on the claim identifier and the prior update number ([SQL-032](../sql/SQL-032-saif-business-claim.md), [CL_CLAIM_EMPLOYEE_WORK_ADDRESS](../database-tables.md#cl_claim_employee_work_address)).
   - If exactly one row is not affected: add `UpdateError` carrying the framework database contention message ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).
7. **Delete the address.** Deleting removes the row by claim identifier and prior update number ([SQL-043](../sql/SQL-043-saif-business-claim.md), [CL_CLAIM_EMPLOYEE_WORK_ADDRESS](../database-tables.md#cl_claim_employee_work_address)).
   - If exactly one row is not affected: add `DeleteError` carrying the framework database contention message ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).
8. **Test for emptiness.** `IsEmpty` concatenates every address field and reports the address as empty when the combined length is zero, which lets a caller skip saving a form the user never filled in.
9. **Short-circuit validity for untouched new addresses.** The object reports itself valid whenever it is new and not dirty, so a blank, untouched address never raises address rule failures.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Caller requests the employee<br>work address for a claim]) --> Sel[Select the address row<br>for the claim]
	Sel --> Row{Row returned?}
	Row -->|Yes| Fill[Fill fields, normalize ZIP<br>and foreign flag; mark old]
	Row -->|No| Blank[Seed defaults;<br>mark new and clean]
	Fill --> Cfg[Configure validation prefix,<br>ZIP and state rules]
	Blank --> Cfg
	Cfg --> Edit[Caller edits the address]
	Edit --> Empty{Address still empty<br>and untouched?}
	Empty -->|Yes| Skip([Reported valid;<br>nothing to save])
	Empty -->|No| Rules{Address rules pass?}
	Rules -->|No| RuleErr([Address rule messages surface])
	Rules -->|Yes| Which{New address?}
	Which -->|Yes| Ins[Insert with SYSDATE<br>and update number zero]
	Which -->|No| Upd[Update keyed on claim<br>and prior update number]
	Ins --> Rows{Rows affected = 1?}
	Upd --> Rows
	Rows -->|No| Err([Add Insert or Update error])
	Rows -->|Yes| Done([Address persisted])
```

## Failure and edge-case behavior

- A claim with no stored address is indistinguishable from a claim whose address was just created, because both states are reported as a new, clean object.
- ZIP codes are stored numerically, so a leading zero survives only because the fill routine pads the value back to five digits; any consumer reading the column directly sees the unpadded number.
- A stored ZIP of zero is reported as an empty ZIP, so a genuine ZIP of `00000` cannot be represented.*
- The insert writes a literal update number of zero rather than binding the object's value, so an object created with a non-zero update number is persisted inconsistently with its in-memory state.
- The validity short-circuit means an untouched new address bypasses the state, ZIP, and ZIP plus-four rules entirely; the rules only bite once the caller has changed something.
- The class inherits the shared address base rather than the plain business base, so its rule set and formatting behavior are governed by that base and change with it.
- An unused blank-checking helper remains in source and is never called, which can mislead maintainers into thinking blank handling is centralized there.*

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts.

## Sources

- `Business\SAIF.Business.Claim\clsClaimEmployeeWorkAddress.vb`
- `Business\SAIF.Business\ContactInfo\clsAddress.vb`