Search Results ca_glb

Overview

APPS.HR_CA_TAX_UNITS_V is a Canadian localization view that exposes tax unit organizational data—typically legal entities and reporting establishments used for payroll tax filing—as they are defined in Oracle HRMS. The view flattens the deeply denormalized HR_ORGANIZATION_INFORMATION model into a single readable row per organization, resolving the descriptive flexfield segments that hold Canadian tax unit attributes into columns. Its primary role in Oracle E-Business Suite is to feed provincial and federal tax reporting processes, payroll year-end extracts, and integration interfaces that need to identify which tax unit an employee or assignment belongs to.

Because the view joins multiple contexts of the same underlying information table, it is most commonly consumed by Oracle's Canadian Payroll reporting components and by customer-built extracts that must map organizations to tax registration numbers, remittance addresses, and tax unit identifiers.

Underlying Base Objects

Per ETRM documentation, the view is defined over the following documented base objects: HR_ALL_ORGANIZATION_UNITS_VL, HR_GENERAL (package), HR_LOCATIONS, HR_ORGANIZATION_INFORMATION, and PER_BUSINESS_GROUPS.

• HR_ALL_ORGANIZATION_UNITS_VL supplies the driving organization rows (ORGANIZATION_ID, BUSINESS_GROUP_ID, NAME, TYPE, dates, and location reference).
• HR_ORGANIZATION_INFORMATION appears four times (aliases hoi, hoi1, hoi2, hoi4), each joining a different ORG_INFORMATION_CONTEXT to retrieve distinct classes of flexfield segments.
• PER_BUSINESS_GROUPS is joined on BUSINESS_GROUP_ID and filtered with LEGISLATION_CODE = 'CA', enforcing the Canadian localization scope.
• HR_LOCATIONS is joined outer-style on LOCATION_ID to provide address lines, city, region, postal code, country, and telephone details.
• HR_GENERAL is referenced as an underlying package supporting the view's HRMS access logic.

The selector hoi.ORG_INFORMATION_CONTEXT = 'CLASS', hoi.ORG_INFORMATION1 = 'HR_LEGAL', and hoi.ORG_INFORMATION2 = 'Y' restricts the driving rows to organizations flagged as legal entities.

Key Columns

• ORGANIZATION_ID, BUSINESS_GROUP_ID, NAME, DATE_FROM, DATE_TO — identity and effective dating of the tax unit.
• The unaliased NVL(hoi2.org_information9, O.NAME) — this is the expression the user's org_information9 search targets; it returns a tax unit name derived from the hoi2 context, falling back to the organization name when the attribute is null.
• hoi1.ORG_INFORMATION1 through ORG_INFORMATION16 — the legal-entity flexfield segment set (the CLASS context flagged HR_LEGAL).
• hoi4.ORG_INFORMATION2 through ORG_INFORMATION19 — a further attribute context, including segments 17, 18, and 19.
• hoi2.ORG_INFORMATION1, ORG_INFORMATION2, ORG_INFORMATION5 — context-specific identifiers, with ORG_INFORMATION9 used for the display name.
• ADDRESS_LINE_1/2/3, TELEPHONE_NUMBER_1, TOWN_OR_CITY, POSTAL_CODE, COUNTRY, and the DECODE on L.STYLE (which returns REGION_2 for US style, REGION_1 for CA and CA_GLB styles, else blank) — mailing and remittance address of the tax unit.
• legislation_code from PER_BUSINESS_GROUPS — always 'CA' given the view's filter.

Common Use Cases and Queries

The view supports identifying the Canadian tax units within a business group, extracting their registration identifiers and addresses, and resolving the effective-dated tax unit name. A representative query searches specifically on ORG_INFORMATION9 as surfaced by the view:

• SELECT organization_id, name, org_information9 FROM apps.hr_ca_tax_units_v WHERE sysdate BETWEEN date_from AND NVL(date_to, sysdate);
• SELECT t.organization_id, t.name, t.town_or_city, t.postal_code, t.org_information1 FROM apps.hr_ca_tax_units_v t WHERE t.legislation_code = 'CA';

Typical scenarios include Canadian Payroll year-end and periodic tax remittance reporting, mapping employees to their filing tax unit, and reconciliation of legal-entity tax registration data against the organization hierarchy. Because the view filters strictly on the CA legislation and the HR_LEGAL class context, queries need not reapply those predicates, though callers should still respect effective dates using DATE_FROM and DATE_TO.