Search Results partial_post

Overview

APPS.IA_POST_REQUEST_PKG is the posting engine for Oracle EBS Asset Tracking (Oracle iAssets / Internet Assets) transfer requests. The package provides the server-side PL/SQL logic that converts approved asset transfer requests — captured in the IA_REQUEST_HEADERS and IA_REQUEST_DETAILS tables — into actual fixed asset cost and location changes recorded in Oracle Assets. It is part of the broader iAssets workflow through which employees, warehouse personnel, and asset administrators initiate requests to move assets between employees, locations, and expense accounts.

The package is classified as OTHER in the ETRM 12.2.2 metadata, indicating that it is a supporting internal module rather than a formally published public API. The source header ($Header: IAPREQB.pls 120.1 2005/10/05) shows that the body is a mature, minimally versioned artifact whose core structure dates to early 11i releases and remains functionally stable through 12.1.1 and 12.2.2.

Key Procedures and Functions

ETRM documents a single public entry point for this package body: POST_TRANSFER. This is the concurrent-program-maintained procedure that performs the bulk posting of eligible transfer request lines. It drives a cursor over IA_REQUEST_HEADERS and IA_REQUEST_DETAILS, joined to FA_BOOK_CONTROLS and FA_DEPRN_PERIODS, selecting only request headers in status POST or PARTIAL_POST and request details in status POST. For each qualified line the procedure applies the corresponding asset transfer to Oracle Assets, effectively updating the asset's distribution (employee, location, expense account) for the specified effective date, and then advances the request and detail statuses to reflect successful processing.

The header also declares an internal helper, VALIDATE_TRANSFER, which is used during processing to validate a transfer line and return the current asset units; and a commented-out GET_CURRENT_UNITS helper. The package uses bulk-fetching idioms (batch size and counter variables, a numeric collection type indexed by BINARY_INTEGER) to process request details efficiently. In the context of the user's search term "process_transfer," note that POST_TRANSFER is the documented name in this release; "process transfer" describes the same business action, and any wrapper or previous-generation code under a PROCESS_TRANSFER name should be treated as the same operation.

Tables Accessed

• IA_REQUEST_HEADERS — the transfer request header, supplying request_id, book_type_code, request_date, and header status used to filter POST/PARTIAL_POST requests.
• IA_REQUEST_DETAILS — the individual transfer lines, supplying asset_id, from/to distribution IDs, to_location_id, to_employee_id, to_expense_ccid, effective_date, and line status.
• FA_ADDITIONS — the asset master, joined to obtain the asset_number and confirm the requested asset exists.
• FA_BOOK_CONTROLS — the asset book definition, used to qualify the book_type_code being posted.
• FA_DEPRN_PERIODS — the depreciation calendar, used to restrict posting to open periods (period_close_date is null) and to compare the request effective date against the calendar period close date.
• FA_DISTRIBUTION_HISTORY — the history of asset distributions, read and updated as transfers are applied.
• PLITBLM — the standard Oracle EBS PL/SQL table/index-by helper package used for collection processing.

Usage Notes

IA_POST_REQUEST_PKG.POST_TRANSFER is typically invoked from the iAssets concurrent program that posts pending transfer requests. It accepts the standard concurrent-program parameters errbuf and retcode together with p_book_type_code, and is designed to be run per asset book. The procedure is safe to run repeatedly: because it only selects header/detail rows with status POST or PARTIAL_POST, already-posted lines are skipped, and any line whose effective date falls beyond the current open depreciation period is naturally excluded by the FA_DEPRN_PERIODS join.

Because the package is not a published API and is referenced by zero other packages in the ETRM 12.2.2 metadata, customizations should call POST_TRANSFER only through the delivered concurrent program or via a clearly identified custom wrapper, and should not depend on the internal VALIDATE_TRANSFER signature. Customers processing large volumes should be aware of the bulk-fetch design and run posting during periods of low activity to avoid contention on FA_DISTRIBUTION_HISTORY and the FA depreciation tables.