Skip to content

Resolve policy associations

Oregon workers' compensation policies are frequently connected to one another — manually recorded affiliations, wrap-up and leasing relationships, premium-discount combinations, and experience-rating combinations. This operation gathers all four families in a single round trip and presents them in one uniform shape so that callers do not need to know which mechanism produced a given link.

Field Value
Operation ID OP-04
Trigger clsPolicyData.Associations is first accessed, a preferred association type is assigned, or a caller invokes the list directly
Inputs IDataPortalInfo, policy number, an include-source-policy flag, and an optional as-of date
Outputs A sequence of PolicyAssociation values
Primary components PolicyAssociationList.GetPolicyAssociationList
Entry point Business/SAIF.Business.View.Policy/PolicyAssociations.vb

Steps

  1. Create a portal request whose statement is the four-part UNION that covers manual affiliations, system-derived policy relationships, premium-discount combinations, and experience-rating combinations (SQL-026).
  2. The statement reads POLICY_RELATIONSHIP, POLICY, COMBO_POLICY_PERIOD, POLICY_PERIOD, and ER_COMBINATION_POLICY.
  3. Decide the two as-of dates that scope the combination branches (BR-014).
  4. If the caller supplied an as-of date, bind it to both the experience-rating and discount-combination date parameters.
  5. If the caller supplied none, bind the experience-rating date to the data source date and query the policy's latest policy-period effective date for the discount-combination date (SQL-027, POLICY_PERIOD).
  6. The default path therefore costs one extra round trip.
  7. Bind the policy number and execute the request through the data access layer.
  8. Project each returned row into a PolicyAssociation, translating the relationship code into a typed association type (BR-015, BR-016).
  9. Codes sourced from the manual affiliation table carry an M. prefix and resolve to the manual association types.
  10. A code that matches none of the known values is retained as not specified rather than discarded, and maps to a non-affiliated affiliate type.
  11. Unless the caller asked for the source policy to be included, drop the row whose policy number equals the requested policy.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Associations requested]) --> D{As-of date supplied?}
    D -->|Yes| Bind[Bind the supplied date<br>to both date parameters]
    D -->|No| Def[Bind data source date<br>and query the latest period date]
    Bind --> Ex[(Four-part UNION query)]
    Def --> Ex
    Ex --> Proj[Project rows and translate<br>relationship codes]
    Proj --> U{Code recognised?}
    U -->|Yes| Typed[Typed association]
    U -->|No| NotSpec[Not specified association]
    Typed --> Filt[Drop the source policy<br>unless requested]
    NotSpec --> Filt
    Filt --> Ok([Association list])

Failure and edge-case behavior

  • An unrecognised relationship code is retained with no meaningful type rather than raising (BR-015).
  • A policy with no associations returns an empty sequence.
  • The default date path issues an extra scalar query before the main statement (SQL-027).

Note: Statements marked with † are derived from dependency library documentation via the Legends CLI. Statements marked with * were inferred from code structure or contextual evidence. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business/SAIF.Business.View.Policy/PolicyAssociations.vb