Search Results pay_jp_swot_numbers




Overview
Explore in AI Chat

Overview

The PAY_JP_SWOT_NUMBERS table, owned by the HR schema, is a Payroll (PAY) module data object that stores Japanese Tax Special Withholding Obligation Taxpayer (SWOT) numbers. In the Japanese payroll localization, employers are required to register and maintain a unique taxpayer identification number for each tax withholding district in which they operate, and to exchange electronic files with the relevant tax office. This table serves as the master repository for those district-level identifiers, together with the file names and processing flags used during electronic filing (e-Filing) and import cycles. It is a configuration and reference object rather than a transactional payroll table; records are typically maintained infrequently and consumed by Japanese payroll reporting and e-Filing programs.

From a data modeling perspective, the metadata provides a heuristic Data Vault classification of standalone. This should be treated as a modeling suggestion rather than a definitive designation: the absence of foreign-key relationships to other documented objects indicates that the table functions as an independent reference set. Its composite primary key of ORGANIZATION_ID and DISTRICT_CODE effectively identifies each row as a distinct district-level registration, which is analogous to a business key in a Data Vault hub, with the descriptive attributes (file names, flags) behaving like satellite attributes.

Key Information Stored

The documented physical schema for 12.2.2 contains 13 columns. The most significant are summarized below.

  • ORGANIZATION_ID — The operating unit / organization identifier that scopes the SWOT registration. Part of the composite primary key.
  • DISTRICT_CODE — The Japanese tax district code to which the SWOT number applies. Second component of the composite primary key.
  • SWOT_NUMBER — The actual Special Withholding Obligation Taxpayer number assigned to the organization for the district; the core business payload of the row.
  • REPORT_DISTRICT_CODE — The district code used on the tax report, which may differ from the registration district and is relevant when filings are consolidated.
  • EFILE_EXCLUSIVE_FLAG — Flag indicating whether the district uses the exclusive e-Filing process.
  • IMPORT_EXCLUSIVE_FLAG — Flag controlling the exclusive import processing path for the district.
  • OUTPUT_FILE_NAME — The name of the file generated for e-Filing output for this district.
  • INPUT_FILE_NAME — The name of the inbound file consumed during import processing.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns recording the last modification of the record.
  • CREATED_BY, CREATION_DATE — Standard WHO audit columns recording row creation.

The unique index PAY_JP_SWOT_NUMBERS_PK on (ORGANIZATION_ID, DISTRICT_CODE) is the sole documented business-key candidate. No separate surrogate key column exists; the composite key itself serves as the row identifier. All remaining columns are descriptive attributes.

Common Use Cases and Queries

Typical usage centers on verifying registrations and driving the e-Filing/import programs. A common lookup retrieves the SWOT number for a given organization and district:

  • SELECT SWOT_NUMBER, REPORT_DISTRICT_CODE FROM HR.PAY_JP_SWOT_NUMBERS WHERE ORGANIZATION_ID = :org AND DISTRICT_CODE = :district;
  • Reporting on all districts configured for an operating unit: SELECT DISTRICT_CODE, SWOT_NUMBER, EFILE_EXCLUSIVE_FLAG FROM HR.PAY_JP_SWOT_NUMBERS WHERE ORGANIZATION_ID = :org ORDER BY DISTRICT_CODE;
  • Auditing recently changed registrations: SELECT * FROM HR.PAY_JP_SWOT_NUMBERS WHERE LAST_UPDATE_DATE >= :since;
  • Identifying districts with exclusive processing enabled: SELECT DISTRICT_CODE FROM HR.PAY_JP_SWOT_NUMBERS WHERE EFILE_EXCLUSIVE_FLAG = 'Y' OR IMPORT_EXCLUSIVE_FLAG = 'Y';

These queries support implementation validation, tax reporting reconciliation, and troubleshooting of failed e-Filing runs.

Related Objects

The metadata classifies this table as standalone, so no documented foreign keys exist. Related objects are therefore inferred from shared key columns and functional context:

  • HR_ORGANIZATION_UNITS — joined on ORGANIZATION_ID to resolve the operating unit name.
  • PAY_JP_SWOT_NUMBERS_PK — the primary key index guaranteeing uniqueness of (ORGANIZATION_ID, DISTRICT_CODE).
  • HR_ALL_ORGANIZATION_UNITS — alternate organization view for validation of ORGANIZATION_ID.
  • PAY_JP_TAX_DISTRICTS (localization reference) — supplies district descriptions keyed by DISTRICT_CODE where available.
  • FND_FLEX_VALUES — key flexfield values used to validate district codes in some implementations.

Because the object is standalone, integration is driven through key-value joins on ORGANIZATION_ID and DISTRICT_CODE rather than enforced referential constraints.