--- title: Code table lookups summary: Read-only reference/code-table classes that validate and describe the coded values used throughout the EFT payment lifecycle. status: draft owner: SAIF Doc Gen last_reviewed: 2026-07-30 library: SAIF.Business.Payment.EFT reference_type: package operation_id: OP-EFT-10 trigger: Any operation in this library validates a coded field (e.g., account type, banking network, authorization type) by retrieving and checking against the corresponding code-table class --- # Code table lookups This library defines a large set of small, mostly read-only code-table classes that back the coded fields used across [Bank account management](bank-account-management.md), [EFT authorization / consent](eft-authorization-consent.md), [Debit card enrollment](debit-card-enrollment.md), [Output control tracking](output-control-tracking.md), and other operations. Each class wraps a single lookup/GCODE table and exposes an `IsValid`-style check plus a description property; nearly all of them throw on insert/update/delete, since the underlying values are maintained as reference data rather than through the application. This page documents them collectively rather than one-per-class, following the same "light-touch" treatment used for comparable reference/code-table groupings in the pilot library. | Field | Value | | --- | --- | | **Operation ID** | OP-EFT-10 | | **Trigger** | Another operation in this library needs to validate or describe a coded field | | **Inputs** | A code value (e.g., `BankAccountTypeCode`, `BankingNetworkCode`, `AuthorizationTypeCode`) | | **Outputs** | Boolean validity result and/or a description string; for `clsBankingNetworkCode` only, full CRUD against its table | | **Primary components** | `clsAchStandardEntryClassCode`, `clsAddendaTypeCode`, `clsAuthorizationTypeCode`, `clsBankAccountDataSourceCode`, `clsBankAccountStatusCode`, `clsBankAccountTypeCode`, `clsBankingNetworkCode`, `clsConsumerBusinessCode`, `clsCreditDebitCode`, `clsCustomerTypeCode`, `clsEnrollStatusCode`, `clsOnlinePaymentTypeCode`, `clsOutputDocumentCode`, `clsPaymentSourceSystemCode` (each with a `Collection` counterpart) | | **Entry point** | Individual `cls*Code.vb` files in `Business\SAIF.Business.Payment.EFT\` | ## Steps 1. **Retrieve the full code table.** Each class's `Collection` variant retrieves all rows from its backing `*_GCODE` table, typically ordered by display sequence or code value, for use in populating dropdown lists and validating inbound values. 2. **Validate a supplied code.** Consuming operations (e.g., `clsBankAccount.ValidAccountTypeCode`, `clsEFTAuthorization`'s type-code validation) retrieve the single matching row by code and treat a missing row as an invalid/broken rule. 3. **Retrieve a description.** Where the underlying GCODE table supports localization, the description is joined against the caller's culture, mirroring the pattern documented for `PAYMENT_RETURN_REASON_GCODE` in [Payment return handling](payment-return-handling.md) ([BR-EFT-07](../business-rules.md#br-eft-07-return-reason-description-is-culture-aware)). 4. **Attempt to mutate (most classes).** Insert/Update/Delete on nearly every class in this group throws `ApplicationException`, since these tables are reference data maintained outside the application (e.g., via direct data administration) rather than through business-object CRUD. 5. **Exception: `clsBankingNetworkCode` has full CRUD.** Unlike every other class in this group, `clsBankingNetworkCode` implements real Insert, Update, and Delete methods against its backing table rather than throwing — this is the only banking-network/account-attribute code table in the library that supports being maintained through the application itself. - This asymmetry was not explained in code comments; it may reflect a historical requirement to let application administrators manage banking-network entries directly, but this could not be confirmed.* 6. **Cascading defaults.** `clsAuthorizationTypeCode` additionally supplies default banking-network/account-type values that `clsEFTAuthorization.AuthorizationTypeCode`'s setter cascades onto the linked bank account (see [BR-EFT-09](../business-rules.md#br-eft-09-selecting-an-authorization-type-cascades-default-bank-account-attributes) and [EFT authorization / consent](eft-authorization-consent.md)). 7. **ACH standard entry class validity.** `clsAchStandardEntryClassCode` supplies the valid entry-class values used by [BR-EFT-10](../business-rules.md#br-eft-10-ach-standard-entry-class-code-is-required-only-for-ach-banking-network-accounts) in [Payment detail, events, and allocation](payment-detail-and-allocation.md). ## Process flow ```mermaid flowchart TD Start([Operation needs to validate
or describe a coded field]) --> Retrieve[Retrieve matching code-table row] Retrieve --> Found{Row found?} Found -->|No| Invalid([Broken rule / invalid code]) Found -->|Yes| Valid([Code accepted; description available]) Valid --> Mutate{Attempt Insert/Update/Delete?} Mutate -->|Most classes| Throw([ApplicationException thrown]) Mutate -->|clsBankingNetworkCode only| CRUD[Full CRUD executed against table] ``` ## Failure and edge-case behavior - Nearly all code-table classes in this group are read-only from the application's perspective; any attempt to call Insert/Update/Delete on them will throw rather than silently failing or no-op'ing. - `clsBankingNetworkCode` is the sole exception with real CRUD support — a caller assuming uniform read-only behavior across this whole group would be surprised by this class specifically.* - If a code value used elsewhere in the library (e.g., a `BankAccountTypeCode` on an existing `BANK_ACCOUNT` row) is later removed from its reference table, any subsequent validation against that now-missing code would fail, potentially blocking updates to otherwise-valid existing records.* ## 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.Payment.EFT\clsAchStandardEntryClassCode.vb` - `Business\SAIF.Business.Payment.EFT\clsAddendaTypeCode.vb` - `Business\SAIF.Business.Payment.EFT\clsAddendaTypeCodecollection.vb` - `Business\SAIF.Business.Payment.EFT\clsAuthorizationTypeCode.vb` - `Business\SAIF.Business.Payment.EFT\clsAuthorizationTypeCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountDataSourceCode.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountDataSourceCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountStatusCode.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountStatusCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountTypeCode.vb` - `Business\SAIF.Business.Payment.EFT\clsBankAccountTypeCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsBankingNetworkCode.vb` - `Business\SAIF.Business.Payment.EFT\clsBankingNetworkCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsConsumerBusinessCode.vb` - `Business\SAIF.Business.Payment.EFT\clsConsumerBusinessCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsCreditDebitCode.vb` - `Business\SAIF.Business.Payment.EFT\clsCreditDebitCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsCustomerTypeCode.vb` - `Business\SAIF.Business.Payment.EFT\clsCustomerTypeCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsEnrollStatusCode.vb` - `Business\SAIF.Business.Payment.EFT\clsEnrollStatusCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsOnlinePaymentTypeCode.vb` - `Business\SAIF.Business.Payment.EFT\clsOnlinePaymentTypeCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsOutputDocumentCode.vb` - `Business\SAIF.Business.Payment.EFT\clsOutputDocumentCodeCollection.vb` - `Business\SAIF.Business.Payment.EFT\clsPaymentSourceSystemCode.vb` - `Business\SAIF.Business.Payment.EFT\clsPaymentSourceSystemCodeCollection.vb`