Search Results replicate_bank_accounts




Overview
Explore in AI Chat

Overview

XTR_REPLICATE_BANK_ACCOUNTS_P is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM metadata as an OTHER API. Its documented purpose is to replicate internal bank accounts that are created and maintained in Oracle Cash Management (CE) into the Treasury (XTR) schema tables. The package provides the integration bridge that keeps treasury-side bank account representations synchronized with the authoritative bank, bank branch, and bank account data owned by Cash Management.

The header identifies the package as created on 19-May-2005 by Bhargav Adireddy, with the source file revision bearing a header dated 30-June-2005. In the context of EBS 12.1.1 and 12.2.2, the package retains its role as the inbound replication interface from CE to XTR, invoked at the point where internal bank account definitions must be made available to treasury processing. The package is referenced by three other packages, confirming that it is a dependency within the broader treasury integration layer rather than a standalone utility.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions within this package:

  • REPLICATE_BANK_ACCOUNTS — The main entry point called by Cash Management to replicate bank, bank branch, and bank account data created in CE into the XTR tables. It supports both a record-based signature accepting an XTR_BANK_ACCOUNTS row type and a signature accepting individual bank account attributes. The action flag determines whether the target record is inserted ('I') or updated ('U'), and the standard FND_API return status, message count, and message data out parameters report success, expected error, or unexpected error.
  • INSERT_BANK_ACCOUNTS — Performs the physical insert of bank account information into the XTR bank account table when the replication action is an addition.
  • UPDATE_BANK_ACCOUNTS — Applies changes to an existing XTR bank account record when the replication action is a modification.
  • VALIDATE_BANK_ACCOUNTS — Validates the incoming bank account data before it is written, ensuring that required attributes and reference values are consistent prior to insert or update.
  • MODIFY_BANK_ACCOUNTS — Handles modification of existing bank account data as part of the replication flow.
  • LOG_ERR_MSG — Writes error messages to the logging mechanism used by the package, supporting the message count and message data returned to the caller.
  • REPLICATE_INTEREST_SCHEDULES — Replicates interest schedule information associated with bank accounts into the XTR tables. This procedure is the documented match for the search term "replicate_interest_schedules" and is the focus of interest for users investigating how interest schedules are propagated from Cash Management into Treasury.

Tables Accessed

The metadata documents two tables referenced through APPS synonyms:

  • XTR_BANK_ACCOUNTS — The primary target of the package. Bank account records originating in Cash Management are inserted into or updated in this table, and its row type is used as the input record structure for the main replication procedure. Interest schedule data handled by REPLICATE_INTEREST_SCHEDULES is likewise associated with the bank account records held here.
  • XTR_PARTY_INFO — Holds party information referenced during replication, used to resolve or validate the party code and party type attributes carried on the bank account record.

Usage Notes

This package is not intended for direct end-user invocation. It is called programmatically by Oracle Cash Management at the time internal bank accounts are created or amended, passing the bank account record and an action flag that distinguishes insert from update. The standard FND_API return status contract means callers must inspect x_return_status and, when an error is signaled, retrieve the stacked messages via x_msg_count and x_msg_data. Custom integrations that create or modify internal bank accounts in CE should rely on the existing CE-to-XTR replication path rather than writing to XTR_BANK_ACCOUNTS directly, because VALIDATE_BANK_ACCOUNTS and the insert/update helpers enforce the expected data shape. The presence of LOG_ERR_MSG indicates that failures are logged, which is useful when diagnosing replication problems. The REPLICATE_INTEREST_SCHEDULES procedure is invoked in the same replication context to carry interest schedule definitions into Treasury, and is the documented object to examine when troubleshooting how interest schedules reach the XTR tables.