Search Results authorize_reval_event

Overview

XTR_STREAMLINE_P is an Oracle E-Business Suite package body owned by APPS that belongs to the Treasury module's Exposure and Risk Management (ETRM) product family. Its documented header identifies it as a component supporting the streamlined processing of batch-based revaluation, retrospective (retro), accrual, and journal generation activity within the ETRM subsystem. The package consolidates batch validation, locking, rate generation, detail generation, event authorization, and journal transfer into a single reusable body, allowing ETRM batch processing to be driven programmatically rather than exclusively through the concurrent manager.

The excerpt provided shows the source header dated 2005/11/24 (120.7), confirming the package is a legacy ETRM object retained across both 12.1.1 and 12.2.2. Because the search term "c_accrual" maps to accrual processing, the procedures GENERATE_ACCRUAL_DETAILS and AUTHORIZE_ACCRUAL_EVENT are the most relevant entry points for that query.

Key Procedures and Functions

• REVAL_DETAILS_INCOMPLETE — Function that determines whether a batch contains incomplete revaluation details. It resolves the batch either from an explicit batch id or by matching period start, period end, company code, and a null batch type (excluding NRA batches per fix 3527080), then checks XTR_REVALUATION_DETAILS for rows with an unreleased complete flag.
• RETRO_DETAILS_INCOMPLETE — Companion function that checks the completeness of retrospective details for a batch.
• GET_EVENT_STATUS — Retrieves the current status of an ETRM event.
• EVENT_EXISTS — Determines whether a given event has already been created.
• EVENT_AUTHORIZED — Indicates whether an event has been authorized.
• GET_PARTY_CREATED_ON — Returns the creation date of a party record from XTR_PARTY_INFO.
• LOCK_BATCH and LOCK_EVENT — Concurrency control procedures that lock batch and event records before processing.
• CHK_ELIGIBLE_COMPANY — Validates that a company is eligible for the requested streamlined operation.
• GET_PREV_NORMAL_BATCH and GET_LATEST_BATCH — Retrieval functions used to locate the preceding normal batch or the most recent batch for a company.
• GENERATE_REVAL_RATES and GENERATE_REVAL_DETAILS — Build revaluation rates and revaluation detail rows.
• AUTHORIZE_REVAL_EVENT — Authorizes the revaluation event after details are generated.
• GENERATE_RETRO_DETAILS and AUTHORIZE_RETRO_EVENT — Generate and authorize retrospective detail and event records.
• GENERATE_ACCRUAL_DETAILS and AUTHORIZE_ACCRUAL_EVENT — Generate accrual detail rows from XTR_ACCRLS_AMORT and authorize the corresponding accrual event. These procedures are the objects most closely associated with the "c_accrual" search.
• GENERATE_JOURNAL_DETAILS and TRANSFER_JOURNALS — Create journal detail lines and transfer them to the general ledger.

Tables Accessed

• XTR_BATCHES — Batch header records; queried to resolve batch ids by period and company.
• XTR_BATCH_EVENTS — Events associated with batches, used for event existence, status, and authorization checks.
• XTR_REVALUATION_DETAILS — Revaluation detail rows checked and generated by the revaluation procedures.
• XTR_REVALUATION_RATES — Stores revaluation rates produced by GENERATE_REVAL_RATES.
• XTR_ACCRLS_AMORT — Accrual amortization data driving accrual detail generation.
• XTR_HEDGE_RETRO_TESTS — Retrospective hedge test results used in retrofit processing.
• XTR_COMPANY_PARAMETERS — Company-level configuration governing eligibility and processing behavior.
• XTR_PARTY_INFO — Party master data supplying creation dates.

Usage Notes

XTR_STREAMLINE_P is an internal ETRM processing package rather than a published API; API classification is OTHER and no other package references it directly. It is typically invoked by ETRM concurrent programs, by the streamlined revaluation and accrual flows, or by internal forms that drive batch generation and authorization. Debug tracing is controlled through xtr_risk_debug_pkg, which logs in-parameters when g_Debug is enabled. Custom code should invoke the public procedures only after confirming batch eligibility via CHK_ELIGIBLE_COMPANY and acquiring locks through LOCK_BATCH or LOCK_EVENT. Because the package body has remained largely unchanged since release 120.7, behavior is consistent between 12.1.1 and 12.2.2.