Search Results mws_comment_code2

Overview

APPS.HR_WORKSITE_V is a supplementary Oracle E-Business Suite view registered under the FND design data object PER.HR_WORKSITE_V. It presents a denormalized, form-friendly projection of worksite (tax unit) information maintained within the Oracle HR organization model. In EBS 12.1.1 and 12.2.2 environments, the view is classified as VALID and is explicitly documented as a view type intended "to simplify forms coding." Oracle's documentation carries a standard warning that the view should not be used as a general-purpose query or data-alteration interface, since its definition may change dramatically across minor or major releases. Despite that caveat, the view remains relevant to reporting and integration work because it is the documented source referenced by the payroll-side program PAY_MWS_MAGTAPE_REPORTING, which consumes worksite attributes for magnetic media tax reporting.

Underlying Base Objects

The documented dependency list shows that HR_WORKSITE_V is defined over, and references, the following objects:

• HR_ORGANIZATION_UNITS (view) — provides the worksite/tax-unit organization definition.
• HR_ORGANIZATION_INFORMATION (synonym) — supplies the flexfield-style organizational attributes attached to the organization unit.
• HR_LOCATIONS (view) — supplies the address elements (lines, city, state, ZIP) exposed by the view.
• HR_GENERAL (package) — supplies the business-group-aware utility logic used in the view definition.
• HR_SECURITY (package) — enforces the organization/security filtering applied to the rows returned.

The view therefore sits on top of the core HR organization and location model, translating the underlying organization-information segments into named, worksite-specific columns. Note that HR_ORGANIZATION_INFORMATION and HR_LOCATIONS are exposed as synonyms/views in the APPS schema, with the physical data residing in the HR schema. The only documented downstream consumer is PAY_MWS_MAGTAPE_REPORTING.

Key Columns

All worksite-specific columns carry the MWS_ prefix. The principal identity and reference columns are:

• MWS_TAX_UNIT_ID (NUMBER 15) — the primary identifier of the worksite/tax unit record.
• MWS_BUSINESS_GROUP_ID (NUMBER 15) — the business group owning the worksite, used for security and multi-organization partitioning.
• MWS_PRIMARY_WORKSITE_ORG_ID (NUMBER 15) — the organization identifier of the primary worksite organization.

The descriptive and reporting columns include MWS_SUI_ACCOUNT_NO (state unemployment insurance account number, VARCHAR2 150), MWS_REPORTING_UNIT_NO (reporting unit number), MWS_TRADE_NAME (the operating or trade name), and MWS_WORKSITE_DESCRIPTION. Comment and free-text attributes are held in MWS_COMMENT_CODE1, MWS_COMMENT_CODE2 (the searched column, VARCHAR2 150), and MWS_COMMENTS. Address attributes are exposed as MWS_ADDRESS_LINE_1 through MWS_ADDRESS_LINE_3 (VARCHAR2 240), MWS_CITY (30), MWS_STATE (120), and MWS_ZIP_CODE (30). MWS_COMMENT_CODE2 is a generic, user-defined comment code field carried on the worksite record, often used for state- or locality-specific classification codes required by tax filing formats.

Common Use Cases and Queries

Typical applications include worksite validation, SUI/tax reporting extracts, and reconciliation of worksite addresses against HR locations. A direct select against all documented columns follows the query text pattern:

• SELECT MWS_TAX_UNIT_ID, MWS_BUSINESS_GROUP_ID, MWS_SUI_ACCOUNT_NO, MWS_TRADE_NAME, MWS_COMMENT_CODE2, MWS_CITY, MWS_STATE, MWS_ZIP_CODE FROM APPS.HR_WORKSITE_V;
• Filter by business group for multi-organization reporting: ... WHERE MWS_BUSINESS_GROUP_ID = :p_business_group_id.
• Locate a specific tax unit: ... WHERE MWS_TAX_UNIT_ID = :p_tax_unit_id.

Because the view is protected by HR_SECURITY and is documented as non-query-stable across releases, production integrations should treat HR_WORKSITE_V as a convenience read layer. Where long-term stability is required, direct extraction from HR_ORGANIZATION_UNITS and HR_ORGANIZATION_INFORMATION using the documented key flexfield segment mappings is the recommended alternative. Any custom code built on this view should be regression-tested on patch application, particularly when upgrading between 12.1.1 and 12.2.2 code levels.