Search Results per_bf_payment_details_api




Overview

PER_BF_PAYMENT_DETAILS_API is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Payroll and Human Resources product family, where the "BF" component naming convention denotes functionality associated with statutory or third-party payment processing — commonly encountered in legislative and localized payroll solutions such as the UK, Irish, and Australian payment and deduction reporting requirements. The package provides a controlled, programmatic interface for creating, maintaining, and removing payment detail records held in the PER_BF_PAYMENT_DETAILS entity. It encapsulates the validation and persistence logic for individual payment instructions that are linked to a payroll run, an assignment, and a payment method, shielding callers from the underlying data model and allowing Oracle to evolve the physical schema without breaking dependent code. The package is documented as VALID and is classified as an API, confirming its status as a supported integration point for custom extensions, batch loaders, and concurrent processing.

Key Procedures and Functions

The package exposes three documented procedures that together provide the full maintenance lifecycle for a payment detail record.

  • CREATE_PAYMENT_DETAIL — Inserts a new payment detail row, validating the supplied payment method, assignment context, and monetary attributes before writing to the underlying table. It is the primary entry point for building out payment instructions generated by a payroll run or an external feeder system.
  • UPDATE_PAYMENT_DETAIL — Modifies an existing payment detail record, allowing changes to the attributes governed by the API (for example, amount, payment method, or processing status) while re-applying the same validation rules used at creation.
  • DELETE_PAYMENT_DETAIL — Removes a payment detail row, typically invoked when a payment instruction is reversed, cancelled, or superseded before transmission to the payment provider.

Consistent with Oracle's API standards, these procedures are expected to perform their own validation and raise defined application errors rather than permitting direct DML against the base table. Parameter lists are not documented in the source metadata and should be confirmed against the package specification in the target instance.

Tables Accessed

The package operates against the following tables, accessed through APPS synonyms:

  • PER_BF_PAYMENT_DETAILS — The primary transactional table holding the payment detail records created, updated, and deleted by the API.
  • PAY_PERSONAL_PAYMENT_METHODS_F — Supplies the employee-level payment method definition used to validate and enrich the payment detail.
  • PAY_ORG_PAYMENT_METHODS_F — Provides the organization-level payment method configuration, ensuring the payment detail is consistent with the paying organization's setup.
  • PER_BF_BALANCE_AMOUNTS — Holds the balance amount values that underpin the payment detail, linking the payment to the payroll balance result it represents.
  • PER_BF_PROCESSED_ASSIGNMENTS — Records which assignments have already been processed, supporting the logic that prevents duplicate or inappropriate payment detail creation.

Usage Notes

PER_BF_PAYMENT_DETAILS_API is most commonly invoked from the HRDPP_CREATE_PAYMENT_DETAIL program unit, which the dependency metadata identifies as the principal consumer of this package. That reference indicates the API is a building block within the standard payroll payment-generation flow rather than an end-user-facing component. Customers extending the payment process should call the API from their own PL/SQL rather than inserting directly into PER_BF_PAYMENT_DETAILS, because the procedures enforce referential and business validation and preserve the integrity of the processed-assignment tracking. The package itself depends on HR_API and the STANDARD library, so the usual HR security context and initialization requirements apply. When porting customizations between EBS 12.1.1 and 12.2.2, verify the package specification in each environment, since the documented metadata does not include signature detail.