Search Results get_visa_data
Overview
APPS.PER_AE_XDO_REPORT is a PL/SQL package within the Oracle E-Business Suite Human Resources (Oracle HRMS) module, specifically part of the person and assignment regulatory reporting infrastructure for the United Arab Emirates (the "AE" in the package name denotes the UAE localization). Its principal business function is to generate XML-based, XFDF-formatted report output for statutory workforce reporting — passport data, visa data, and contract data — collected against employee records. The package assembles regulatory report content and returns it as a BLOB suitable for downstream rendering to PDF, typically consumed by Oracle XML Publisher (BI Publisher) report definitions.
The package was last shipped in the 12.1.1 code line (header version 120.2.12010000.1) and remains available in 12.2.2. It is classified under ETRM as an OTHER API, indicating it is an internal utility package rather than a public, supported integration API.
Key Procedures and Functions
The package exposes seven documented program units:
- GET_VISA_DATA — Produces the XFDF/BLOB output for the visa regulatory report, accepting report selection and filtering parameters and returning the generated document through the
l_xfdf_blobOUT parameter. - GET_PASSPORT_DATA — The procedure matching the search term "get_passport_data." It generates passport-related regulatory report output for the specified report name and date range, filtered by business group, organization structure, and organization structure version, with optional expiry-window and unit filters. Like its siblings, it returns the XFDF content in
l_xfdf_blob. - GET_CONTRACT_DATA — Generates contract-related regulatory report output. It follows the same parameter pattern as the other generators, substituting an organization identifier (
p_org_id) in place of the version parameter. - CLOB_TO_BLOB — A conversion utility that translates CLOB content into BLOB form, supporting the character-set handling required when assembling XML/XFDF payloads.
- WRITETOCLOB — Writes assembled XFDF content into the BLOB output and registers the total page count for the report.
- FETCH_PDF_BLOB — Retrieves the generated PDF BLOB for a named report and date, typically from the FND_LOBS repository where concurrent program output is stored.
- GET_LOOKUP_MEANING — A helper function that resolves a lookup code to its displayed meaning for a given lookup type, used to present readable values in the report output.
The package also declares a record type (xmlrec), a collection type (txmltable), and associated global variables used to stage tag/value pairs during XML assembly.
Tables Accessed
The package reads from HR and person-model tables through APPS synonyms. Employee and assignment data is drawn from PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F, with periods of service in PER_PERIODS_OF_SERVICE and job references in PER_JOBS. Organization filtering uses HR_ALL_ORGANIZATION_UNITS, PER_ORGANIZATION_STRUCTURES, PER_ORG_STRUCTURE_ELEMENTS, and PER_ORG_STRUCTURE_VERSIONS. Document and identification data — central to passport and visa reporting — comes from HR_DOCUMENT_EXTRA_INFO and HR_DOCUMENT_TYPES_TL. Output retrieval and session context use FND_LOBS and FND_SESSIONS. DBMS_LOB and DUAL support large-object manipulation and scalar lookups, and PLITBLM is referenced for PL/SQL table handling.
Usage Notes
PER_AE_XDO_REPORT is invoked from the Oracle HRMS UAE localization reporting flow, most commonly as the data source behind concurrent programs or XML Publisher reports that produce passport, visa, and contract documentation for regulatory submission. Because the generator procedures accept a request ID and report name, they are designed to run in a concurrent-program context where the request ID links the invocation to FND output storage; the accompanying FETCH_PDF_BLOB and WRITETOCLOB routines support that lifecycle by persisting and retrieving the finished document. Custom code may call the procedures directly, but because the package is classified as OTHER and is not a published API, direct invocation should be treated as unsupported and subject to change between patch levels.