Search Results p_concurrent_request_id

Overview

PAY_NO_ALTINN_TFR_PKG is an Oracle E-Business Suite payroll extension package owned by APPS and classified under the ETRM taxonomy as OTHER. Its name and internal logic identify it as the Norwegian statutory reporting integration layer that transmits payroll transfer data to the Altinn reporting portal. Altinn is the Norwegian government's shared digital infrastructure for electronic submission of statutory forms, and for payroll this includes the A-melding (monthly employer and employee reporting) as well as related year-end and termination filings. The package body carries the RCS header identifier pynaftfr.pkb 120.0.12020000.1, confirming it is a 12.2-level build delivered with the Norwegian localizations.

The package bridges the Oracle Payroll action model into the Altinn transfer staging schema. Payroll processes run as payroll actions; each action may need to produce an Altinn submission, and the results of that submission must be tracked against the originating concurrent request that the user launched. PAY_NO_ALTINN_TFR_PKG supplies the primitives for checking whether a transfer already exists for a given concurrent request, resolving tokenized legislative parameters, persisting a transfer record for later retry, and submitting or deleting that record.

Key Procedures and Functions

• GET_PARAMETER_VALUE — Parses the legislative_parameters column of PAY_PAYROLL_ACTIONS to extract the value associated with a named token. It returns the substring immediately following the token name, bounded by the next space or the end of the parameter string, and is the mechanism by which the package reads configuration passed down from the payroll action.
• SAVE_FOR_LATER — Persists a transfer record so that it can be submitted in a subsequent run rather than immediately. It accepts the transfer identifier, the concurrent request identifier, the payroll action identifier, the report name, the run effective date, shipment reference, organization, business group, and object version number, and returns save status and status text. An internal object-version check cursor and a raised exception handle optimistic locking and duplicate detection.
• SUBMIT_RECORD — Drives submission of a staged record to Altinn. This is the invocation point that performs the outbound transfer once a record has been saved.
• DELETE_TRANSFER_RECORD — Removes a staged transfer record, typically used to discard an obsolete or rejected submission before it is re-created.

The body also contains the helper function check_exists, an internal existence probe keyed on the transfer identifier and concurrent request identifier; it is not exposed in the documented procedure list but underpins the duplicate-suppression logic used by the save and submit paths.

Tables Accessed

• PAY_NO_ALTINN_TRANSFERS — The Altinn transfer staging table. It holds one row per pending or historical Altinn transfer, including transfer_id, concurrent_request_id, and object version tracking. The package reads it in check_exists and writes to it via SAVE_FOR_LATER and DELETE_TRANSFER_RECORD.
• PAY_PAYROLL_ACTIONS — The payroll action repository. It is read by GET_PARAMETER_VALUE to extract token values from legislative_parameters, and it links each transfer back to the payroll run that produced it via payroll_action_id.

Usage Notes

The package is invoked through the Norwegian payroll concurrent programs and request-set logic that generate Altinn submissions. The presence of concurrent_request_id as the primary duplicate-detection key means the caller supplies the current request identifier — the same value surfaced in the standard Concurrent Requests form — and the package refuses to create a second transfer row for a request that has already been staged. Developers customizing Norwegian payroll reporting should treat this package as a black box and integrate through SAVE_FOR_LATER and SUBMIT_RECORD rather than inserting into PAY_NO_ALTINN_TRANSFERS directly, because the object version number and status text columns are maintained by the package's own locking logic. ETRM records no other package that references PAY_NO_ALTINN_TFR_PKG, so the dependency direction is inbound only: the package depends on the payroll action and transfer tables, and no downstream extension package reuses it.