Search Results medium_code

Overview

APPS.PAY_NL_TAXOFFICE_FILE is a Dutch localization (NL) payroll package within Oracle E-Business Suite, documented in ETRM as an OTHER-classified PL/SQL API owned by APPS. Its primary business function is to support the archival and reporting of Dutch tax office (Belastingdienst) payroll data. The package operates in the payroll action framework, identifying eligible assignment actions, initializing archival context, and extracting the statutory and tax-relevant data required for Dutch tax reporting and year-end processing. The package is defined with AUTHID CURRENT_USER, meaning its unqualified database object references resolve under the privileges of the invoking schema rather than the package owner. The header comment (pynltosf.pkh 120.0.12000000.1) confirms its release lineage within the 11i/12.x code line, and it remains present in 12.1.1 and 12.2.2 environments. In this context, the user-searched column "medium_code" typically appears in the tax-office file layout as an identifier for the submission medium (for example, electronic transmission versus other channels) and is surfaced through the package's parameter retrieval routines.

Key Procedures and Functions

The package exposes seven documented procedures and functions:

• RANGE_CODE — Returns a SQL string selecting the range of assignments eligible for archival. It accepts a payroll action identifier and returns the SQL text through an OUT parameter.
• ASSIGNMENT_ACTION_CODE — Further restricts the assignment identifiers returned by RANGE_CODE, narrowing the population processed for a given payroll action, person range, and chunk.
• ARCHIVE_INIT — Receives a payroll action identifier and initializes global tables used throughout the run, including g_statutory_balance_table, g_stat_element_table, g_user_balance_table, and g_element_table.
• ARCHIVE_CODE — The main driver procedure. It receives an assignment action identifier and an effective date, and coordinates the subordinate procedures that archive the payroll data.
• GET_PARAMETER — Retrieves a single named parameter value from the payroll action context, the mechanism through which values such as medium_code are exposed to the file-generation logic.
• GET_ALL_PARAMETERS — Returns the complete set of parameters associated with the payroll action, supporting bulk parameter resolution.
• GET_TOS_SENDER_DETAILS — Supplies sender/organization details required for the tax office (TOS) file transmission.

Tables Accessed

The package references the following objects through APPS synonyms:

• PAY_PAYROLL_ACTIONS and PAY_ACTION_INFORMATION — drive payroll run context and parameter values, including medium_code.
• PAY_ASSIGNMENT_ACTIONS and PAY_ASSIGNMENT_ACTIONS_S — identify the assignment-level actions subject to archival.
• PAY_ACTION_INTERLOCKS — coordinates action sequencing and chunk processing.
• PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F — supply the person and assignment data for the eligible population.
• PER_ASSIGNMENT_STATUS_TYPES — filters assignments by status.
• HR_ORGANIZATION_INFORMATION — provides organization attributes used in the sender details.
• FND_NEW_MESSAGES — supports message and diagnostic handling.
• DUAL — used for single-row utility queries.

Usage Notes

PAY_NL_TAXOFFICE_FILE is invoked within the Oracle Payroll archival and Dutch tax reporting flow. The RANGE_CODE and ASSIGNMENT_ACTION_CODE routines are called by the payroll action framework to assemble the assignment population, typically when a Dutch tax office file concurrent program (or a predecessor archival program) initiates a payroll action. ARCHIVE_INIT and ARCHIVE_CODE execute during the archival phase to stage and process payroll results into the archival schema. GET_PARAMETER and GET_ALL_PARAMETERS are used to resolve run-time parameters such as medium_code, controlling the format and routing of the tax office submission. GET_TOS_SENDER_DETAILS supplies the legal employer identity required on the transmitted file. The package is referenced by two other database packages, indicating it is consumed programmatically rather than directly by end users, and any customizations should preserve the documented signatures to avoid breaking dependent localization logic.