Search Results ce_ba_signatories_u1

Overview

CE.CE_BA_SIGNATORIES is a Cash Management (CE) transaction table that stores information about the people holding signature authority for a bank account. Each row represents a single signatory assignment on a specific bank account, capturing the monetary limits under which that person may authorize transactions, the effective date range of the assignment, and its approval status. The table is designated as a Transaction Data (TX_DATA) object and resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10.

Signatory records are not physically removed when an assignment ends or is revoked. Instead, the table continues to store information about deleted signatories and flags them via the DELETED_FLAG column to prevent further use. This soft-delete behavior preserves audit history and supports compliance reporting for treasury and internal control functions.

From a dimensional modeling perspective, the mined foreign-key structure classifies CE_BA_SIGNATORIES as satellite-leaning. This is a heuristic suggestion rather than a fixed property: the table behaves as a dependent child of the bank account entity, holding descriptive and time-bounded attributes keyed by a surrogate identifier rather than constituting an independent business hub.

Key Information Stored

The table contains 34 documented columns, including standard WHO audit columns and a 15-column descriptive flexfield (ATTRIBUTE_CATEGORY plus ATTRIBUTE1 through ATTRIBUTE15). The columns of greatest functional importance are:

• SIGNATORY_ID — Number(15). The surrogate primary key and the single column of the unique index CE_BA_SIGNATORIES_U1. It uniquely identifies each row in the table and is the appropriate join key for dependent objects.
• BANK_ACCOUNT_ID — Number(15). Foreign key to the bank account record (CE_BA_SIGNATORIES.BANK_ACCOUNT_ID references AP_BANK_ACCOUNTS_ALL). This is the primary business grouping column and leads the nonunique index CE_BA_SIGNATORIES_N1.
• PERSON_ID — Number(15). Person identifier of the individual added as a bank account signatory. It is the second column of the CE_BA_SIGNATORIES_N1 index, supporting lookups by signer.
• SINGLE_LIMIT_AMOUNT and JOINT_LIMIT_AMOUNT — Number. The monetary authorization ceiling applicable when the signatory acts alone versus jointly with another authorized signer.
• STATUS — Varchar2(60). Approval state of the signatory, with documented values of APPROVED, PENDING, or REJECTED.
• APPROVAL_TYPE_FLAG — Varchar2. M indicates the signatory was approved manually; W indicates approval was routed through Oracle Workflow.
• DELETED_FLAG — Varchar2. Y indicates the row is soft-deleted and cannot be used; default is N. Queries for active signatories must filter on this column.
• REQUESTER_ID — Number(15). Person identifier of the user who submitted the workflow request, derived from the employee_id in FND_USER.
• START_DATE and END_DATE — Date. The effective period of the signatory assignment.
• SIGNER_GROUP — Varchar2(60). The signatory group to which the person belongs.
• OTHER_LIMITS — Varchar2(150). Free-text description of additional limitations on signing authority.

SIGNATORY_ID is the surrogate key; no alternate business key is documented beyond the unique index on that single column, so the surrogate also serves as the effective business-key candidate.

Common Use Cases and Queries

The most frequent access pattern retrieves all active signatories for a given bank account, typically excluding soft-deleted rows:

• SELECT signatory_id, person_id, single_limit_amount, joint_limit_amount, status FROM ce_ba_signatories WHERE bank_account_id = :p_account_id AND NVL(deleted_flag,'N') = 'N'; — this query is well served by index CE_BA_SIGNATORIES_N1, whose leading column is BANK_ACCOUNT_ID.
• Identifying signatories for a specific person across all accounts uses the same N1 index, since PERSON_ID is its second column: SELECT bank_account_id, signatory_id, status FROM ce_ba_signatories WHERE person_id = :p_person_id;
• Reconciling workflow-driven approvals: filter on approval_type_flag = 'W' and status = 'PENDING' to locate signatory requests awaiting action, joining REQUESTER_ID to FND_USER for the requesting user.
• Audit and compliance reporting on authorization limits can group by SIGNER_GROUP and compare SINGLE_LIMIT_AMOUNT against transaction amounts, subject to START_DATE and END_DATE covering the period under review.
• Historical signatory reporting should not filter on DELETED_FLAG, since retained rows document the full succession of signers on an account.

Related Objects

The principal relationships documented in the ETRM metadata are:

• AP_BANK_ACCOUNTS_ALL — referenced by CE_BA_SIGNATORIES.BANK_ACCOUNT_ID. This is the parent bank account entity and the join used for nearly all signatory reporting.
• CE_BA_SIGNATORIES_U1 — the unique index on SIGNATORY_ID in APPS_TS_TX_IDX, enforcing row uniqueness.
• CE_BA_SIGNATORIES_N1 — the nonunique index on (BANK_ACCOUNT_ID, PERSON_ID), supporting the dominant access paths.
• FND_USER — joined via REQUESTER_ID to identify the user who submitted a signatory approval request.
• Related Cash Management bank account children such as account contacts and account uses are typically queried alongside this table when producing a complete bank account profile.