Skip to content

Transfer adjustment processing

A transfer moves money already paid — claim-to-claim, in full, or for another documented reason — by writing a linked pair of offsetting financial transactions rather than altering the original payment. clsTransferAdjustment is a shared base (transfer-reason metadata, remark text generation) extended by three concrete transfer classes selected at construction (BR-CP-022).

Field Value
Operation ID OP-CP-06
Trigger Caller constructs clsClaimToClaimTransfer, clsFullTransfer, or clsOtherTransfer, sets FromClaim/ToClaim and TransferInfo, calls LoadPayments, marks candidate payments SelectForTransfer, and calls Save()
Inputs IDataPortalInfo, source and destination clsClaimData, transfer reason (claim change, policy change, injury-date change), issue-date filter, selected payment set
Outputs A paired "from" (negative) and "to" (positive) CL_FINANCIAL_TRANS row per transferred payment, linked by TransferTransID, each with mirrored detail lines; boolean save result
Primary components clsTransferAdjustment, clsClaimToClaimTransfer, clsFullTransfer, clsOtherTransfer
Entry point Business\SAIF.Business.Claim.Payment\Adjustments\Transfers\clsTransferAdjustment.vb

Steps

  1. Select the concrete transfer type (BR-CP-022). The caller instantiates clsClaimToClaimTransfer (moves payments between two claims), clsFullTransfer, or clsOtherTransfer, and records TransferInfo.TransferReason (ClaimChange, PolicyChange, or InjuryDateChange).
  2. Load candidate payments. LoadPayments(issueFromDate) reads the source claim's posted transactions (cached per claim/issue-date pair in Static locals on the base class) and groups their detail lines by transaction and payment category into read-only clsClaimPayment candidates.
  3. Mark payments for transfer. The caller sets SelectForTransfer = True on each candidate the adjuster chooses to move; unmarked payments are left untouched on the source claim.
  4. Validate the request. For clsClaimToClaimTransfer, full validation (including the base remark/amount rules) runs only when the transfer reason is ClaimChange; other reasons bypass MyBase.IsValid entirely and are always considered valid at this level.
  5. Build the paired transactions. For each selected payment, Save() creates a "from" transaction (on the source claim, amount negated) and a "to" transaction (on the destination claim, amount positive), each pointing at the other's sequence number via TransferTransID; both are stamped Released status, today's entry date, the configured issue date, and IgnoreBusinessRules = True.
  6. The "from" transaction's remark is a generated string naming the destination claim; the "to" transaction's remark is reason-specific text from GetToTransRemarkText (claim number, injury date, or policy number changed-from text depending on the reason), or blank for unrecognized reasons.
  7. Mirror detail lines with sign flips. For every original detail line, a new detail is added to both the "from" and "to" transactions, copying category/reimbursement/cost/penalty/MCO-fee/EAIP flags unchanged, but negating TransactionAmt, TDDayQty, and TDOffsetAmt on the "from" side and keeping them positive on the "to" side.
  8. Save both transactions per payment. Each generated transaction is saved individually through Financial transaction and remark management (clsFinancialTrans.Save()); the loop stops and returns False at the first failed save, leaving any already-saved transactions committed.

Process flow

flowchart TD
    Start([Adjuster loads source claim's<br>posted payments]) --> Select[Mark payments SelectForTransfer]
    Select --> Which{Transfer reason<br>= ClaimChange?}
    Which -->|Yes| Validate{Remark/amount<br>rules pass?}
    Which -->|No| Build
    Validate -->|No| Blocked([Broken rule; save blocked])
    Validate -->|Yes| Build[For each selected payment:<br>build From and To transactions]
    Build --> Mirror[Mirror detail lines,<br>negate amounts on From side]
    Mirror --> SaveFrom[Save From transaction]
    SaveFrom --> FromOk{Saved?}
    FromOk -->|No| Fail([Save returns False;<br>remaining payments not processed])
    FromOk -->|Yes| SaveTo[Save To transaction]
    SaveTo --> ToOk{Saved?}
    ToOk -->|No| Fail
    ToOk -->|Yes| More{More selected<br>payments?}
    More -->|Yes| Build
    More -->|No| Done([Transfer complete])

Failure and edge-case behavior

  • Save() iterates payments and, within each payment, both transaction halves, but does not roll back transactions from earlier payments in the same call if a later one fails — a multi-payment transfer can leave a partially-completed transfer split across claims.
  • For clsClaimToClaimTransfer, any transfer reason other than ClaimChange skips the base validation rules entirely (IsValid returns True unconditionally), so amount and remark checks only apply to claim-change transfers.
  • The "from"/"to" pairing depends on both clsFinancialTrans.NewFinancialTrans calls succeeding in obtaining sequence numbers before either is saved; a sequence exhaustion or portal failure at that point would leave TransferTransID referencing a transaction that was never persisted.*
  • LoadPayments's claim/issue-date cache is process-wide (Static), not per-instance, matching the same cross-cutting caching pattern seen in refund processing.

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.Payment\Adjustments\clsAdjustmentBase.vb
  • Business\SAIF.Business.Claim.Payment\Adjustments\Transfers\clsTransferAdjustment.vb
  • Business\SAIF.Business.Claim.Payment\Adjustments\Transfers\clsClaimToClaimTransfer.vb
  • Business\SAIF.Business.Claim.Payment\Adjustments\Transfers\clsFullTransfer.vb
  • Business\SAIF.Business.Claim.Payment\Adjustments\Transfers\clsOtherTransfer.vb