Search Results delete_finance_header

Overview

The APPS.OTA_FINANCE_HEADER_API package body is a public Oracle E-Business Suite API that governs the creation, maintenance, and removal of finance header records within the Oracle Training Administration (OTA) module. In the ETRM data model, a finance header represents the top-level financial entity associated with training-related financial transactions, such as receivables, payments, and transfers linked to learner enrollments, events, and external vendors. The package encapsulates the business logic required to validate, default, and persist these header records so that integrating applications do not need to insert directly into the underlying base tables.

The package is classified as an API in the ETRM 12.2.2 repository and is owned by APPS. Because it is a public API, it exposes a stable interface that shields callers from the physical schema. It is referenced by one other package, indicating that it forms part of a dependent call chain used by other OTA components rather than operating in isolation. The source header identifies the file as ottfhapi.pkb, version 120.0, consistent with the 12.1.1 and 12.2.2 code lines.

Key Procedures and Functions

The package exposes three documented procedures, each corresponding to a standard DML operation on the finance header entity:

• CREATE_FINANCE_HEADER — Inserts a new finance header record. It accepts inbound attributes covering the authorizer, organization, administrator, currency, date raised, payment and transfer statuses, finance and receivable types, comments, external reference, invoice address and contact, payment method, and the full payment information descriptive flexfield attribute set. It returns the newly generated finance_header_id and the associated object_version_number to the caller through OUT NOCOPY parameters. Optional identifiers for a superceding header, vendor, and contact are also accepted.
• UPDATE_FINANCE_HEADER — Modifies an existing finance header, using the object version number for optimistic concurrency control so that conflicting updates are detected rather than silently overwritten.
• DELETE_FINANCE_HEADER — Removes a finance header record, enforcing the integrity constraints and referential checks appropriate to the entity before deletion.

Application logic within these procedures performs the required validation, derives default values, and populates WHO columns and the object version number automatically, so callers supply only business data.

Tables Accessed

The ETRM metadata does not enumerate specific base tables for this package. Functionally, the API operates against the OTA finance header base table through its APPS synonym and any dependent child tables implied by the entity, together with standard EBS auditing infrastructure such as FND_SESSIONS and the DBMS_STANDARD locking conventions used to generate the object version number. The descriptive flexfield attribute columns passed into CREATE_FINANCE_HEADER are physically stored on the finance header table rather than in a separate flexfield table, which is characteristic of the OTA schema design. Because all access is performed through APPS synonyms, the package remains valid across the 12.1.1 and 12.2.2 application schemas.

Usage Notes

OTA_FINANCE_HEADER_API is intended to be invoked from PL/SQL rather than through the user interface directly, although the OTA forms and concurrent programs that manipulate training finances ultimately route through it or through the package that references it. Typical callers include custom integrations, conversions, and extension code that need to establish finance headers for enrollments or events programmatically. When invoking CREATE_FINANCE_HEADER, the caller must always supply the required keys in the order declared and must capture the returned finance_header_id and object_version_number for later updates and deletes. Failure to carry forward the object version number will cause subsequent update attempts to fail. As with all EBS public APIs, the procedure should be called within an explicit transaction so that the caller controls commit and rollback behavior. Direct DML against the underlying OTA tables should be avoided, since it bypasses the validation and auditing performed by this package.