Skip to content

Vocational data retrieval

Vocational data retrieval loads the ordered vocational-detail history for a claim through the PK82003_VOCDATA package and exposes each row as an editable child object. Adding, changing, or removing details persists directly against the vocational-detail table, and a post-save hook keeps the claim header's vocational responsibility code synchronized with the most recent detail row.

Field Value
Operation ID OP-CM-05
Trigger Caller invokes clsVocationalDetailCollection.GetVocationalDetails(dpi, claimID) to load the history, or NewVocationalDetail plus collection Save() to add and persist a row
Inputs Data-portal info (connection and user context) and inClaimID (Decimal); for row creation the child properties StatusCode, StatusDate, RehabProviderLocationID, CounselorProviderLocationID, ResponsibilityCode, StatusDetailCode
Outputs Populated collection of vocational-detail children with identifier, status, dates, provider and counselor identifiers, responsibility code, status detail, and update audit information; on save, inserted, updated, or deleted vocational-detail rows and a conditionally updated claim vocational responsibility code
Primary components clsVocationalDetailCollection (GetVocationalDetails, BeforeRetrieve, AfterRetrieve, NewVocationalDetail, OnSaveComplete), clsVocationalDetail (Create, Load, Fill, insert, update, and delete lifecycle hooks)
Entry point Business\SAIF.Business.Claim.Maintenance\clsVocationalDetailCollection.vb

Steps

  1. Request the vocational history. GetVocationalDetails(inDataportal, inClaimID) builds a criteria carrying the data-portal info and claim identifier and calls DataAccessLayer.RetrieveObject.
  2. Build the retrieve request (BeforeRetrieve). Configure a stored-procedure request for the vocational package's get-by-claim entry point with an input claim parameter and an output cursor (SQL-073, VOCATIONAL_DETAIL), cache the claim identifier, and eagerly load the related claim header data.
  3. Sub-step: the claim header read resolves the current claim record, including its vocational responsibility code, which the post-save synchronization step later compares against.

Origin: clsClaimData.GetData is implemented in SAIF.Business.Claim and executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see Operations and processes in the SAIF.Business.Claim documentation set. 3. Execute the retrieve. The portal runs the stored-procedure request against the database and returns the cursor (SQL-073). 4. Materialize the children (AfterRetrieve). Loop the reader; for each row create a vocational-detail child, assign the cached claim data, call Load, and add it to the collection. 5. Map each row (Load and Fill). Initialize the update-info wrapper if absent, then map claim identifier, detail sequence number, status code, status date, rehab provider location, counselor provider location, responsibility code, and status detail code into smart-typed properties, load the audit fields, assign a per-child criteria keyed by the detail identifier, and call MarkOld(). 6. Return the collection. The populated collection is handed back to the caller; an empty cursor simply yields a zero-count collection. 7. Add a new detail row. collection.NewVocationalDetail(dpi) creates the child through the data portal; Create() obtains the next vocational-detail sequence number, initializes the update info, copies the claim identifier from the criteria, and calls MarkNew(), after which the child is appended to the collection. 8. Caller edits the child properties. Each setter calls MarkDirty(). 9. Save the collection. Save() first applies any pending list edit, then the base save iterates the children and runs the matching lifecycle for each: - New rows: insert into the vocational-detail table binding every mapped column plus the audit fields and the detail identifier (SQL-017, VOCATIONAL_DETAIL); a rows-affected value other than one adds an insert error, otherwise the child is marked old (BR-CM-001). - Modified rows: update the row keyed by the detail identifier and the last update number as the concurrency token (SQL-099, VOCATIONAL_DETAIL); a rows-affected value other than one adds an update error with the DB contention message, otherwise the update number advances and the child is marked old (BR-CM-001). - Removed rows: delete the row by detail identifier (SQL-118, VOCATIONAL_DETAIL); a rows-affected value other than one adds a delete error, otherwise the child is marked new (BR-CM-001). 10. Synchronize the claim responsibility code (OnSaveComplete). - Determine the most recent detail by maximum status date. - If the collection is now empty, flag the claim update to write a null responsibility code. - Otherwise compare the most recent detail's responsibility code with the cached claim responsibility code. 11. Push the claim update when the code differs. Execute an inline update of the claim's vocational responsibility code and update date, keyed by claim identifier, through a directly constructed portal request rather than the standard criteria path (CL_INJURY_CLAIM); a null value is bound when the collection is empty. The cached claim data is then refreshed.* 12. Return the outcome. Save() returns overall success or failure; errors added during step 9 make the affected children invalid for callers that check validity around the save.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([GetVocationalDetails claimID]) --> Req[BeforeRetrieve builds<br>stored proc request<br>and loads claim data]
    Req --> Exec[Portal executes<br>get-by-claim cursor]
    Exec --> Rows{Rows returned?}
    Rows -->|No| Empty([Empty collection returned])
    Rows -->|Yes| Load[AfterRetrieve loads<br>one child per row;<br>Fill maps columns, MarkOld]
    Load --> Ready([Collection returned to caller])
    Ready --> Edit[Caller adds, edits,<br>or removes details]
    Edit --> Save[Save applies edit<br>then base save]
    Save --> Kind{Child state}
    Kind -->|New| Ins[Insert vocational detail]
    Kind -->|Modified| Upd[Update by detail id<br>and update num]
    Kind -->|Removed| Del[Delete by detail id]
    Ins --> Check{RowsAffected = 1?}
    Upd --> Check
    Del --> Check
    Check -->|No| Err([Error message added;<br>child not marked old])
    Check -->|Yes| Complete[OnSaveComplete finds<br>most recent detail by status date]
    Complete --> Diff{Responsibility code differs<br>or collection empty?}
    Diff -->|Yes| Sync[Inline update of claim<br>vocational responsibility code;<br>refresh claim data]
    Diff -->|No| Done([Save returns result])
    Sync --> Done

Failure and edge-case behavior

  • When the retrieval stored procedure returns no rows, the collection is simply empty; the most-recent-detail lookup then returns nothing and the post-save hook treats that as a request to null the claim's responsibility code.
  • The PK82003_VOCDATA package was not found in the Oracle catalog during retrieval, so the exact query, joined tables, and sort order behind the get-by-claim entry point are unconfirmed and may be dead, legacy, or environment-specific code.**
  • The insert, update, and delete hooks all use the rows-affected check, so a concurrent modification that invalidates the update number produces an error message rather than an exception, and does not roll back other children saved in the same batch unless the surrounding transaction aborts (BR-CM-001).
  • The claim responsibility-code update runs as part of the post-save hook whenever the code comparison differs, even when only unrelated fields such as the status date were modified; it is gated by a straight value comparison rather than a dedicated rule.*
  • The cached claim data is refreshed only when it is missing or its claim identifier no longer matches, so stale claim data could be served if the claim identifier is mutated without matching cache invalidation elsewhere.*
  • Removing a detail only takes it out of the in-memory list and deleted list; the database delete happens on the next save.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business\SAIF.Business.Claim.Maintenance\clsVocationalDetailCollection.vb
  • Business\SAIF.Business.Claim.Maintenance\clsVocationalDetail.vb