Search Results igs_fi_lb_rec_types_u1

Overview

The IGS_FI_LB_REC_TYPES table is a core configuration table within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, specifically for the IGS (Oracle Grants Accounting) module. Its primary function is to manage the mapping between bank-supplied identifiers in lockbox transmission files and the system's internal record type codes. When a bank transmits electronic payment data (a lockbox file), each row of data contains an identifier. This table defines which system record type—such as a payment header, payment line, or trailer record—corresponds to each unique identifier string for a specific lockbox configuration. This mapping is essential for the successful parsing, validation, and posting of incoming lockbox receipts into the EBS Receivables module.

Key Information Stored

The table stores the critical linkage between a lockbox setup, the raw bank data, and the system's processing logic. The most important columns are:

• LOCKBOX_NAME (VARCHAR2(30), Mandatory): The name of the configured lockbox, as defined in the IGS_FI_LOCKBOXES table. This is part of the table's primary key.
• RECORD_IDENTIFIER_CD (VARCHAR2, Mandatory): The actual character or code provided by the bank within the transmission file to signify a specific record type (e.g., 'HDR' for header, 'DTL' for detail). This is the second component of the primary key.
• RECORD_TYPE_CODE (VARCHAR2(30)): The system-defined lookup code that classifies the record type for internal EBS processing, such as 'PAYMENT_HEADER' or 'PAYMENT_LINE'.
• Standard WHO Columns (CREATED_BY, CREATION_DATE, etc.): Audit columns tracking the creation and last update of each mapping record.

Common Use Cases and Queries

This table is primarily accessed during the lockbox transmission import process and for configuration troubleshooting. A common use case is diagnosing parsing errors by verifying the mapping for a specific lockbox. For example, if the bank changes an identifier code, an administrator must update the corresponding record in this table. A typical query to review all mappings for a specific lockbox would be:

SELECT lockbox_name, record_identifier_cd, record_type_code
FROM igs.igs_fi_lb_rec_types
WHERE lockbox_name = '&LOCKBOX_NAME'
ORDER BY record_identifier_cd;

Another critical reporting use case is generating a configuration summary for all lockboxes to ensure consistency, which can be achieved by joining with the main lockbox table:

SELECT lb.lockbox_name, lb.description, rt.record_identifier_cd, rt.record_type_code
FROM igs.igs_fi_lockboxes lb,
igs.igs_fi_lb_rec_types rt
WHERE lb.lockbox_name = rt.lockbox_name
ORDER BY lb.lockbox_name, rt.record_identifier_cd;

Related Objects

The table has defined relationships with other key IGS lockbox objects, forming a configuration hierarchy. The primary documented relationship is a foreign key constraint where the LOCKBOX_NAME column in IGS_FI_LB_REC_TYPES references the LOCKBOX_NAME column in the parent table IGS.IGS_FI_LOCKBOXES. This ensures that a record type mapping cannot exist for an undefined lockbox. The table itself is referenced by other APPS objects, indicating it is a source for views or APIs within the application layer. Its two unique indexes, IGS_FI_LB_REC_TYPES_PK and IGS_FI_LB_REC_TYPES_U1, enforce data integrity by preventing duplicate mappings by identifier or by system code for a given lockbox.