Skip to content

EFT correspondence history

clsProviderEFT.CreateHistory writes a PROVIDER_CORR_HIST row documenting an EFT authorization-letter event for a provider location, delegating address resolution and the insert itself to the PK83548_PROVIDER_CORR_HIST PL/SQL package. This is a thin pass-through operation from the VB layer, so most of its rules live at the stored-procedure level.

Field Value
Operation ID OP-PP-04
Trigger clsProviderEFT.CreateHistory()
Inputs ProviderSeqNum, ProviderLocationSeqNum, EffDate, ExpDate, acting user
Outputs One inserted PROVIDER_CORR_HIST row; procedure-level exception on failure
Primary components clsProviderEFT.CreateHistory, PK83548_PROVIDER_CORR_HIST.EFT_CORR_HIST, PK83548_PROVIDER_CORR_HIST.FETCH_TIN_ADDRESS
Entry point Business\SAIF.Business.Provider.PaymentPreference\clsProviderEFT.vb

Steps

  1. Invoke the stored procedure. CreateHistory() calls PK83548_PROVIDER_CORR_HIST.EFT_CORR_HIST (SQL-002), passing the provider, location, effective/expiration dates, and update user.
  2. Resolve the correspondence address. Inside the procedure, FETCH_TIN_ADDRESS is called first: it joins PROVIDER_TAX_ID to PROVIDER and restricts to the provider's primary tax-ID row (PBR-001) that is effective as of the supplied EFT effective date (PBR-002), returning only the first matching row (PBR-003). See FETCH_TIN_ADDRESS.
  3. If no matching tax-ID row is found or another failure occurs during the lookup, the failure is raised rather than silently ignored, and EFT_CORR_HIST does not proceed to the insert (PBR-007).
  4. Insert the history row. EFT_CORR_HIST inserts one PROVIDER_CORR_HIST row (PROVIDER_CORR_HIST) using the resolved address, always marking the row as an EFT authorization-letter event (PBR-004), normalizing the foreign-address flag to Y/N (PBR-005), and stamping CREATE_DATE/CREATE_NUM/CREATE_USER audit values (PBR-006). See EFT_CORR_HIST.
  5. If the insert itself fails, the procedure catches the error and re-raises its package-local exception rather than allowing the failure to be silently swallowed (PBR-008).
  6. Caller responsibility. CreateHistory does not appear to be invoked automatically from within BeforeInsert/AfterInsert/BeforeUpdate/AfterUpdate on clsProviderEFT; it is a public method that calling application code must invoke explicitly after an EFT change, so whether — and when — history is recorded for a given assignment or unassignment depends on the caller.*

Package sibling not exercised by this library

PK83548_PROVIDER_CORR_HIST also exposes EOB_CORR_HIST, which inserts a PROVIDER_CORR_HIST row for paperless-EOB correspondence events using the same FETCH_TIN_ADDRESS helper. No call site for EOB_CORR_HIST was found anywhere in this library's .vb source (including clsProviderEOB.vb); it exists in the Oracle package but is not invoked by SAIF.Business.Provider.PaymentPreference.* See EOB_CORR_HIST for its documented behavior in case another library invokes it.

Process flow

flowchart TD
    Start([clsProviderEFT.CreateHistory called]) --> Exec[Execute PK83548_PROVIDER_CORR_HIST.EFT_CORR_HIST]
    Exec --> Fetch[FETCH_TIN_ADDRESS: locate primary tax-ID row<br>effective on EFT EffDate]
    Fetch --> Found{Address row found?}
    Found -->|No / error| Raise([Raise error, no insert])
    Found -->|Yes, first match only| Normalize[Normalize foreign-address flag,<br>mark EFT_AUTH_LTR_FLAG = Y]
    Normalize --> Insert[Insert PROVIDER_CORR_HIST row<br>with audit stamps]
    Insert --> InsertOk{Insert succeeds?}
    InsertOk -->|No| Raise2([Catch, re-raise package exception])
    InsertOk -->|Yes| Done([History row recorded])

Failure and edge-case behavior

  • A missing or ineffective primary tax-ID row for the provider prevents the history row from being written at all — there is no fallback address source.
  • Only one address row is ever used per call, even if multiple tax-ID rows would otherwise match; the procedure takes the first fetched row and exits its fetch loop.
  • Because CreateHistory is not wired into the EFT record's own insert/update lifecycle, an assignment or unassignment performed through EFT record management or EFT payment location assignment does not automatically produce a correspondence-history row unless the caller separately invokes CreateHistory.*

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.Provider.PaymentPreference\clsProviderEFT.vb