Search Results ap_web_cus_acctg_pkg

Overview

AP_WEB_CUS_ACCTG_PKG is a customization-support package in the APPS schema that belongs to the Oracle Payables Internet Expenses (OIE/OIE Web Expenses) accounting infrastructure. Its name reflects its role: it provides a customization ("CUS") hook for account generation ("ACCTG") within the Payables web-based expense entry flow. In Oracle EBS 12.1.1 and 12.2.2, the standard Payables expense accounting logic normally derives the charge, budget, accrual, and variance accounts from the expense report's distributions and the applicable Accounting Flexfield configuration. The AP_WEB_CUS_ACCTG_PKG body exposes extension points so that a customer-specific rule can override or supplement that default derivation, particularly for project-related and non-project distributions entered through expense reports.

The package is classified as OTHER in the ETRM metadata. It is not a seeded dictionary API intended for general public use; it is a support package that the standard expense accounting programs and project-related validation routines can invoke when a customization is present. In a vanilla installation the package may exist with minimal or no custom logic, but it remains a valid object because callers reference it conditionally.

Key Procedures and Functions

The documented package body contains four procedures/functions:

• GETISCUSTOMBUILDONLY — Returns a flag indicating whether the package should be used only for customer-specific account building, i.e., whether the standard build logic is to be bypassed or supplemented by the custom routine. This serves as a control switch consulted by the accounting engine before invoking custom account derivation.
• BUILDACCOUNT — Builds the accounting flexfield combination for an expense distribution. It is the central extension point for constructing a charge or accrual account using customer-defined attributes rather than only the standard distribution and default account sources.
• BUILDDISTPROJECTACCOUNT — Builds the account for a distribution that is associated with a project. Project-related expense lines require the project and task context to be incorporated into the account, and this routine performs that derivation.
• CUSTOMVALIDATEPROJECTDIST — Performs customer-specific validation of a project distribution. It allows additional business rules to be applied to project-related expense distributions, such as verifying that the derived account is valid for the project and task before the distribution is accepted.

No parameter signatures are asserted here; only the documented names and purposes are described.

Tables Accessed

The ETRM dependency information records direct references to a single table, APPS.AP_OIE_KFF_SEGMENTS_T, which is the Internet Expenses Key Flexfield Segments table. This table is the working store that OIE uses to assemble the individual Key Flexfield segments that make up an account combination during expense entry. The package reads from (and, in a customization, may contribute to) this structure to obtain or construct the segment values needed for the account being built. It also references the standard PL/SQL SYS.STANDARD package, which is a normal dependency and not a business table. No other tables are documented, so additional table access would only exist in a customer modification and is not described here.

Usage Notes

This package is invoked as part of the Internet Expenses expense-report accounting path. Typical invocation points are the standard web expense entry and expense report accounting routines, and the project-related distribution validation performed when project and task information is entered on an expense line. The metadata states that the package is not referenced by any database object tracked in ETRM, but it is referenced by two other packages, indicating that it is called from the Payables/OIE accounting layer rather than directly by forms or concurrent programs.

Because it is a customization package with a generic name, the correct usage pattern is to preserve the documented entry points and place customer-specific logic inside them. Any modification should remain within the body so the public specification and calling signatures are unaffected. In 12.1.1 and 12.2.2 the object remains VALID and in the APPS schema; because it is an undocumented, custom-oriented package, any change should be treated as a customization requiring regression testing of expense report accounting and project distribution validation, and should be reapplied or reviewed after product patches or an upgrade to a later release.