Search Results cf_period_start_dateformula

Overview

APPS.PAY_PAYAUSOE_XMLP_PKG is the Oracle E-Business Suite PL/SQL package associated with the Australian "Payment Summary" / AUSOE (Australian Statement of Earnings) XML Publisher report. Its principal business function is to assemble, format, and publish the payment summary information required for Australian payroll statutory reporting, including gross earnings, tax withheld, pre-tax deductions, allowances, leave balances, and leave taken. The package acts as the backend logic layer for the concurrent program report definition, binding package-level variables to the report layout, constructing the SQL query's WHERE and ORDER BY clauses at runtime, and supplying XML Publisher formula columns through which monetary, date, and descriptive values are rendered.

The package was last shipped in the 12.1.x line (header version 120.1, dated 2008) and remains catalogued in the ETRM metadata for 12.2.2, indicating that it continues to be available on the current application tier for the Australian legislative payroll report.

Key Procedures and Functions

The package exposes forty-four documented procedures and functions. The most significant are summarized below.

• BEFOREREPORT / AFTERREPORT: Standard XML Publisher report triggers that initialize report-level parameters and perform cleanup or derived calculations before and after the report body is rendered.
• CONSTRUCT_WHERE_CLAUSE / CONSTRUCT_ORDER_BY: Build the runtime WHERE and ORDER BY fragments that filter assignments, payroll actions, and time periods according to the concurrent program parameters supplied at submission time. The resulting text is exposed through CP_WHERE_CLAUSE and CP_ORDER_BY.
• SET_PRINT_FLAGS: Coordinates the display switches that determine whether leave, balances, and messages appear on the printed output.
• CF_PERIOD_START_DATEFORMULA: The formula referenced by the search term "cf_period_start_dateformula". This function returns the starting date of the reporting period, derived from the payroll action and time period context, and is bound to the period start column on the payment summary layout.
• CF_NET_ACCRUALFORMULA: Calculates accrual values for a given absence type, assignment action, payroll, and accrual plan over a specified period end date.
• CF_NET_THIS_PAYFORMULA / CF_NET_YTDFORMULA: Derive net pay for the current pay period and year-to-date respectively.
• CF_CURRENCY_FORMAT_MASKFORMULA / CF_HOURS_FORMAT_MASKFORMULA: Return the XML Publisher format masks applied to currency and hours figures.
• CF_GET_MISCELLANEOUS_VALUESFOR: Retrieves supplementary values appended to the payment summary.
• CF_CHANGE_PRINT_MESSAGESFORMUL, CF_CHANGE_PRINT_LEAVE_TAKENFOR, CF_CHANGE_PRINT_LEAVE_BALANCES: Conditionally toggle the display of messages, leave taken, and leave balances.
• CF_GRADE_STEPFORMULA: Resolves the employee's grade step for display on the statement.
• CP_ADDRESS_LINE_1_P, CP_ADDRESS_LINE_2_P, CP_ADDRESS_LINE_3_P, CP_POSTAL_CODE_P: Format the employer/employee postal address fields.

Tables Accessed

The package reads from the following APPS synonyms. Payroll and assignment data are drawn from PAY_PAYROLL_ACTIONS, PAY_ASSIGNMENT_ACTIONS, PAY_ACTION_INTERLOCKS, PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_LINKS_F, and PAY_ELEMENT_TYPES_F. Leave and accrual details come from PAY_ACCRUAL_PLANS, PER_ABSENCE_ATTENDANCE_TYPES, and PER_TIME_PERIODS. Grade and step information is retrieved from PER_SPINAL_POINT_PLACEMENTS_F and PER_SPINAL_POINT_STEPS_F. Reference data is supplied via FND_CURRENCIES (currency formatting) and FND_TERRITORIES_TL (territory names). All access is effectively read-only, as is typical for report supporting packages.

Usage Notes

PAY_PAYAUSOE_XMLP_PKG is not called directly by typical application code. It is invoked by the Oracle XML Publisher engine when the associated Australian payment summary concurrent program or BI Publisher report is executed, with the report definition referencing the package's functions as data and formula columns. Because the package is not referenced by any other package (0 dependents documented), customers should treat it as a report-private API. Customisations should avoid modifying the packaged code and instead extend the report definition or use supported personalisation frameworks, since the package may be replaced during patching.