# Com / Fujitsu / Futurity / Bp / Custom / Constant

## Overview

This package provides a centralized collection of string-based constants used across the **eo Customer Core System** (eo顧客基幹システム), a Japanese broadband and telecommunications service management platform operated by K-Opticom and maintained by Fujitsu. The constants serve as a single source of truth for business values — service type codes, pricing plans, contract statuses, work order (SOD) fields, and transfer/toki flags — so that throughout the application, string comparisons use defined identifiers rather than magic strings.

The package contains three classes, each responsible for a specific functional domain: **Service Order (SOD)** issuance, general **service/business contract** management, and **transfer (itntoki)** work order state tracking.

## Key Classes and Interfaces

### JKKHakkoSODConstCC — Service Order Issuance Constants

**File:** [JKKHakkoSODConstCC.java](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/constant/JKKHakkoSODConstCC.java)

This class is the most extensive in the package. Its Japanese purpose comment reads "サービスオーダ発行定数クラス" — a constant class for **Service Order (SOD) issuance**. An SOD is an internal work order document generated by the system when a customer request (new contract, change, cancellation, repair, etc.) must be executed by field or operations staff.

The class is structured as a plain container of `public static final String` fields, organized into logical sections:

#### SOD Basic Information Keys

These constants define the map keys used when passing SOD-related data between processing layers. They form a data interchange vocabulary:

| Constant | Value | Purpose |
|---|---|---|
| `TRGT_DATA_LIST` | `"trgt_data_list"` | Target data list passed between layers |
| `SOD_KIHON_INFO` | `"sod_kihon_info"` | SOD basic info map |
| `INFO_SYSID` | `"sysid"` | System identifier within SOD info |
| `INFO_IDO_DIV` | `"ido_div"` | Change classification (e.g., new, add, cancel) |
| `INFO_PASSWORD_SHORI_DIV` | `"password_shori_div"` | Password processing classification |
| `INFO_PASSWORD_SAIHAKKO_DIV` | `"password_saihakko_div"` | Password re-issuance classification |
| `INFO_SYORI_DIV` | `"syori_div"` | Processing classification |
| `INFO_MALWARE_BLOCKING_DIV` | `"malware_blocking_div"` | Malware blocking flag |
| `INFO_KOTEI_IP_AD_8_DIV` / `KOTEI_IP_AD_8_DIV` | `"kotei_ip_ad_8_div"` | Fixed IP address type-8 classification |
| `INFO_BMP_SYORI_DIV` | `"bmp_syori_div"` | Phone number (bango-putting) processing classification |
| `RT_OP_CHG_DIV` | `"rt_op_chg_div"` | Router operation change classification |
| `INFO_TOKI_SYORI_DIV` | `"toki_syori_div"` | Transfer (toki) processing classification |

#### Service Contract Information Keys

These keys reference service contracts and their sub-agreements:

- `SVC_KEI_INFO` — Service contract info map
- `INFO_SVC_KEI_NO` — Service contract number
- `INFO_SAKI_SVC_KEI_NO` — Next (post-change) service contract number
- `INFO_MOTO_SVC_KEI_NO` — Previous (pre-change) service contract number
- `SVC_KEI_UCWK_INFO` — Service contract sub-agreement info
- `INFO_SVC_KEI_UCWK_NO` — Sub-agreement number
- `INFO_NEW_CRS_FLAG` — Flag indicating whether auth ID is newly assigned due to course change

#### Option and Equipment Service Keys

Option services (add-ons like email, home page, multiple authentication) and equipment-provided services (BBR routers, VNAs, ONU devices) each have dedicated info map keys:

- `OPSVKEI_INFO` — Option service contract info
- `KKOPSVKEI_INFO` — Equipment option service contract info
- `KKTSVKEI_INFO` — Equipment-provided service contract info

#### Service Type and Pricing Codes

This class defines business domain codes rather than interchange keys. These include:

**Service Kind Codes** (`SVC_KIND_*`): Numeric strings identifying the broad service category — `"1"` for eo Light Network, `"2"` for eo Light Telephone, `"4"` for eo Mobile, `"5"` for eo ADSL, `"99"` for others.

**Price Group Codes** (`PRC_GRP_CD_*`): Grouping codes for billing/pricing — `"02"` for Home Type, `"03"` for Mezón Type, `"04"` for Mansion Type, `"07"` for Wi-Fi, `"08"` for e-mobile, `"09"` for UQ WiMAX, `"10"` for telephone, `"16"` for Mail Address.

**Price Plan Codes** (`PPLAN_CD_*`): Specific billing plans — `"PA3001"` for Wi-Fi Spot, `"PA4501"` for Mobile Wi-Fi Unlimited, `"PC3001"` for UQ Router, `"PC3101"` for UQ USB Type.

**Price Course Codes** (`PCRS_CD_*`): Hundreds of course codes spanning from `"A03"` (100M course) through `"AA4"` and `"AB4"` (Type N 10G Mansion with Netflix). These cover every eo broadband offering: standard courses (100M through 10G), Mezón variants (100M through 10G), ADSL courses (EAccess/Flets), mobile courses (eMobile, WiMAX, UQ WiMAX, Wi-Fi Spot), mansion types (VDSL, Ethernet, Hikari/Fiber), and Netflix bundle variants.

**Equipment Service Codes** (`KKTK_SVC_CD_*`): Equipment types — `"C014"` for BBR router, `"C024"` for MRT (multi-function router), `"C017"` for UQ mobile device, `"C004"` for telephone VNA, `"C025"` for Home Gateway.

**Multi-function Router Function Codes** (`TAKINORT_KINO_CD_*`): `"A"` for router-only, `"B"` for VNA-only, `"C"` for both.

#### Template IDs

The class also holds numerous `TEMPLATE_ID_*` constants (e.g., `TEMPLATE_ID_EKK0081A010`, `TEMPLATE_ID_ETU0011B010`) — these are form/template identifiers used by the system's user interface layer to display service contract lists, work order lists, consent forms, address change details, and more.

#### Other Sections

- **Common Constants**: `STRING_BLANK`, `MAX_DTM` (maximum datetime `"20991231000000000"`)
- **Pause Status**: `PAUSE_JDG_CD_0` / `PAUSE_JDG_CD_1` (not paused / paused); `PAUSE_STP_CD_00` through `PAUSE_STP_CD_02` (paused before SOD issuance, after SOD issuance, during suspension)
- **Pause Type**: `PAUSE_SBT_PAUSE_STA` (pause start), `PAUSE_SBT_PAUSE_END` (pause end)
- **Contract Status**: `SVC_KEI_STAT_010` through `SVC_KEI_STAT_920` (received, approved, concluded, in-service, suspended/cut off, stopped, cancelled)
- **Work Order Mapping Map**: `HAKKOSODCCWORKMAP` — a named map key `"HakkoSODCCWORK"` for temporary processing
- **Operation Service Codes** (B-prefixed): Email, home page, mailing list, dual connection, multi-section, fixed global IP, IPv6, smart phone services
- **Sub-Option Service Codes** (D-prefixed): Email alias, email capacity add, virus watch, home page capacity, home page access analysis
- **Order/Service Order Codes**: Order types, service order types, request types, order issue conditions, order content codes
- **Function Codes**: `FUNC_CODE_1`, `FUNC_CODE_2`, `FUNC_CODE_4`

### JKKSvcConst — General Service Constants

**File:** [JKKSvcConst.java](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/constant/JKKSvcConst.java)

This class provides **general-purpose service constants** shared across multiple processing modules. It imports from `eo.common.constant.JKKStrConst`, indicating it extends a base constant hierarchy from the common library. This class serves as the central hub for service codes, contract statuses, and order-related constants used broadly across the application.

It shares many constant groups with `JKKHakkoSODConstCC` (pricing codes, service kind codes, operation codes, template IDs, pause/status codes), but also defines unique sections:

#### Service Codes (New Section)

- `SVC_CD_NET` (`"01"`) — Network
- `SVC_CD_TEL` (`"02"`) — Telephone
- `SVC_CD_TV` (`"03"`) — TV
- `SVC_CD_HS` (`"04"`) — Hosting

#### Service Flags (TV)

- `SVC_FLG_03` — eo Light TV (standalone building)
- `SVC_FLG_04` — eo Light TV (apartment)
- `SVC_FLG_05` — eo Light TV (re-transmission), eo Light TV (KCN)

#### Contract Status Codes

This class defines a comprehensive set of contract lifecycle status codes:

- `SVC_KEI_STAT_*`: Standard service contract statuses (010: received, 020: approved, 030: concluded, 100: in service, 210: suspended/cut off, 220: stopped, 910: cancelled, 920: voided, 110: exchanging equipment)
- `KAP_KEI_STAT_*`: Discount contract statuses (same numeric pattern but ending with "completed" instead of "in service")
- `HMPIN_STAT_*`: Return/repayment status (001: received, 002: stocked, 003: accepted, 004: cancelled)

#### Change Classification Codes (IDO_DIV_*)

A rich set of 20+ `ido_div` codes:

| Code | Meaning |
|---|---|
| `IDO_DIV_NEW` (`"00001"`) | New contract |
| `IDO_DIV_SVCADD` (`"00002"`) | Service addition |
| `IDO_DIV_OPHKTGI` (`"00003"`) | Option succession |
| `IDO_DIV_KAIHK` (`"00004"`) | Restoration |
| `IDO_DIV_DSL` (`"00005"`) | Cancellation |
| `IDO_DIV_TEKKYODSL` (`"00006"`) | Removal (cancellation) |
| `IDO_DIV_KYOSEIDSLFIX` (`"00007"`) | Forced cancellation determination |
| `IDO_DIV_CANCEL` (`"00008"`) | Cancellation request |
| `IDO_DIV_COURSECHG` (`"00009"`) | Course change |
| `IDO_DIV_STPUK` (`"00010"`) | Suspension reception |
| `IDO_DIV_STPRLS` (`"00011"`) | Suspension release |
| `IDO_DIV_ADCHGADD` (`"00019"`) | Address change / registration |
| `IDO_DIV_ADCHGFIX` (`"00020"`) | Address change / confirmation |
| `IDO_DIV_PAUSEUK` (`"00024"`) | Pause reception |
| `IDO_DIV_PAUSERLSCHGE` (`"00025"`) | Pause change / reservation cancellation |
| `IDO_DIV_KIKIKEICHGE` (`"00026"`) | Equipment contract change |
| `IDO_DIV_MIRTNKIKIDSL` (`"00030"`) | Unreturned equipment cancellation |
| `IDO_DIV_OPSETTE` (`"00031"`) | Option setting |
| `IDO_DIV_HTELNOADD` (`"00041"`) — `IDO_DIV_HTELNODSL` (`"00043"`) | Light telephone number add/change/cancel |
| `IDO_DIV_HTELITNTOKISETTE` (`"00046"`) | Light telephone transfer work order setting |
| `IDO_DIV_ENUMDEL` (`"09001"`) — `IDO_DIV_ENUMIADD` (`"09002"`) | ENUM deletion / registration |

#### Cancellation and Transfer Codes

- `SVC_DLRE_CD_KYOSEIDSL` — Forced cancellation reason
- `SVC_CANCEL_RSN_CD_*` — Various cancellation reasons (request-based, home work IE, work IE, review IE, other, forced cancellation)
- `ITNTOKI_KIBO_UM_*` — Transfer work order desire (present/absent)
- `ITNTOKI_ADD_CD_*` — Transfer work order registration codes (by destination registration, by source cancellation, by pause)

### JKKItntokiStaEndConstCC — Transfer Work Order Start/End Constants

**File:** [JKKItntokiStaEndConstCC.java](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/constant/JKKItntokiStaEndConstCC.java)

Created 2013-06-17, this class manages the state machine for **transfer (itntoki / 移転) work orders** — the process by which a customer's service is moved from one location (or line) to another. This involves coordinating the termination of the source contract and the activation of the destination registration.

#### Work Order State Machine

The core of this class is the `ITNTOKI_STA_END_JUDGE_CD` constants, which define the lifecycle states of a transfer work order:

| Constant | Value | Meaning |
|---|---|---|
| `ITNTOKI_STA_END_JUDGE_CD_NON` | `"0"` | No work order start/end (no-op state) |
| `ITNTOKI_STA_END_JUDGE_CD_ITNS_STA` | `"1"` | Work order start by destination registration |
| `ITNTOKI_STA_END_JUDGE_CD_ITNS_END` | `"2"` | Work order end by destination registration |
| `ITNTOKI_STA_END_JUDGE_CD_DSL_STA` | `"3"` | Work order start by source cancellation |
| `ITNTOKI_STA_END_JUDGE_CD_DSL_END` | `"4"` | Work order end by source cancellation |
| `ITNTOKI_STA_END_JUDGE_CD_PAUSE_STA` | `"5"` | Work order start by pause |
| `ITNTOKI_STA_END_JUDGE_CD_PAUSE_END` | `"6"` | Work order end by pause |

#### DSL Termination Status Codes

The `DSL_TOKI_JSSI_CHU_CD` constants track whether a source contract termination work order is currently being executed:

- `DSL_TOKI_JSSI_CHU_CD_NON` (`"0"`) — Not being executed / not scheduled
- `DSL_TOKI_JSSI_CHU_CD_JSSI` (`"1"`) — Currently being executed
- `DSL_TOKI_JSSI_CHU_CD_RSV` (`"2"`) — Scheduled

#### Interchange Keys

The class also defines map keys used to pass transfer-related data between processing components:

- `ITNM_SVC_KEI_UCWK_LIST` — Source service contract sub-agreement list
- `ITNM_SVC_KEI_NO` / `ITNM_SVC_KEI_GENE_ADD_DTM` — Source service contract number and registration datetime
- `ITNM_SVC_KEI_UCWK_NO` / `ITNM_SVC_KEI_UCWK_GENE_ADD_DTM` — Source sub-agreement number and datetime
- `ITNM_ITNTOKI_STA_END_JUDGE_CD` — Source transfer work order start/end judgment code
- `IDO_DTL_CD_KAIHK_PAUSE` — Pause triggered by restoration

## How It Works

### Constant Pattern

All three classes follow the same design pattern: they are **non-instantiable containers** of `public static final String` fields with no methods, no constructors, and no instance state. This is a deliberate design choice for a shared constants package:

1. **No instantiation needed** — Any class that needs a constant simply references `JKKHakkoSODConstCC.INFO_SYSID`.
2. **String-based identification** — All values are `String` types, which ensures consistency across JDBC parameters, JSON payloads, map keys, and UI form fields.
3. **Single source of truth** — Adding a new code value requires changing exactly one location.

### How a Service Order Flows

While this package contains no executable logic, the constants it defines are consumed by the service order (SOD) processing pipeline. A typical flow:

1. A customer request arrives (e.g., "change from 100M course to 1G course").
2. The processing module reads the request and looks up `INFO_IDO_DIV` to determine this is a course change (`"00009"`).
3. It builds an SOD info map using keys like `SOD_KIHON_INFO`, `SVC_KEI_INFO`, `SVC_KEI_UCWK_INFO`.
4. The map is populated with contract numbers (`INFO_SVC_KEI_NO`), pricing codes (`PCRS_CD_MEZON_1G`), and the change classification.
5. If a transfer is involved, the `ITNTOKI_STA_END_JUDGE_CD` values coordinate the work order lifecycle.
6. The SOD is issued and passed to downstream processing (field dispatch, billing, provisioning).

### Relationship Between Classes

- `JKKSvcConst` is the **general-purpose** constant class — it covers service codes, contract statuses, and order types used across the entire application.
- `JKKHakkoSODConstCC` is **SOD-specific** — it focuses on the data interchange keys used when constructing and passing service order work order documents, plus a comprehensive set of pricing and equipment codes needed during SOD generation.
- `JKKItntokiStaEndConstCC` is a **narrow specialist** — it exclusively handles the transfer (itntoki) work order state machine.

## Data Model

Since these classes contain no data structures, the "data model" here is the **constant taxonomy** — a hierarchy of code families used throughout the system:

```
Constant Categories
├── Common
│   ├── STRING_BLANK, MAX_DTM, MAX_YMD
│   └── UM_NASI / UM_ARI, FLG_OFF / FLG_ON
├── Service Order (SOD) Info Keys
│   ├── Map keys (SOD_KIHON_INFO, SVC_KEI_INFO, OPSVKEI_INFO, etc.)
│   └── Field keys (INFO_SYSID, INFO_IDO_DIV, INFO_TOKI_SYORI_DIV, etc.)
├── Service Kind
│   ├── SVC_KIND_NET, SVC_KIND_TEL, SVC_KIND_MOB, SVC_KIND_ADSL, SVC_KIND_ELSE
├── Pricing
│   ├── Price Group (PRC_GRP_CD_*)
│   ├── Price Plan (PPLAN_CD_*)
│   └── Price Course (PCRS_CD_*) — 60+ codes
├── Contract Status
│   ├── SVC_KEI_STAT_* (standard)
│   ├── KAP_KEI_STAT_* (discount)
│   └── HMPIN_STAT_* (return/repayment)
├── Change Classification (IDO_DIV_*) — 20+ codes
├── Operation Service Codes
│   ├── Network ops (B-prefixed: email, HP, IPv6, etc.)
│   └── Sub-option ops (D-prefixed: alias, virus watch, etc.)
├── Order / Service Order Codes
│   ├── Order type (ORDER_SBT_CD_*)
│   ├── Service order (SVC_ORDER_CD_*)
│   ├── Request type (YOKYU_SBT_CD_*)
│   ├── Issue condition (ODR_HAKKO_JOKEN_CD_*)
│   └── Content codes (ODR_NAIYO_CD_* — 80+ codes)
├── Equipment
│   ├── Equipment service (KKTK_SVC_CD_*)
│   └── Home equipment (TAKNKIKI_SBT_CD_*)
├── Pause / Suspension
│   ├── PAUSE_JDG_CD, PAUSE_STP_CD, PAUSE_SBT_*
├── Transfer (Itntoki)
│   ├── ITNTOKI_STA_END_JUDGE_CD_* (state machine: 0-6)
│   └── DSL_TOKI_JSSI_CHU_CD_* (termination status: 0-2)
├── UI Template IDs (TEMPLATE_ID_*)
└── Work Map Key (HAKKOSODCCWORKMAP)
```

## Dependencies and Integration

### External Dependencies

| Dependency | Description |
|---|---|
| `eo.common.constant` | The `JKKSvcConst` class imports `JKKStrConst` from this package, suggesting a base constant class in the common library that provides shared string constants (e.g., `"C005"` for MODEM used as `KKTK_SVC_CD_MODEM`). |

### Consumers

These constants are referenced by:
- **Service Order (SOD) processing modules** — to build and interpret work order data maps
- **Contract management modules** — to compare and update contract status
- **UI/template rendering** — `TEMPLATE_ID_*` values identify which form to display for listing or consent
- **Business rule evaluation** — `IDO_DIV_*` codes drive branching logic for different operation types
- **Billing/pricing engines** — `PCRS_CD_*` and `PRC_GRP_CD_*` codes determine charges

### Cross-Module Relationships

```
flowchart TD
    subgraph Constants["Constant Classes"]
        HAKKO["JKKHakkoSODConstCC<br/>Service Order Issuance Constants"]
        SVC["JKKSvcConst<br/>Service Constants"]
        ITNTOKI["JKKItntokiStaEndConstCC<br/>Transfer Work Order Constants"]
    end

    HAKKO -->|"depends on"| SVC
    SVC -->|"extends"| STR["eo.common.constant.JKKStrConst"]

    subgraph Groups["Key Constant Groups"]
        G1["Service Order Info"]
        G2["Pricing / Course Codes"]
        G3["Contract Status"]
        G4["Operation Service Codes"]
        G5["Transfer States"]
    end

    HAKKO --> G1
    HAKKO --> G2
    SVC --> G3
    SVC --> G4
    ITNTOKI --> G5
```

## Notes for Developers

### No Methods — Pure Constants

None of these classes contain methods or constructors. They are data-only containers. If you need to add a constant, simply add a new `public static final String` field with a clear Javadoc comment.

### Duplicate Constants Across Classes

Some constants appear in both `JKKHakkoSODConstCC` and `JKKSvcConst` (e.g., `SVC_KIND_NET`, `PAUSE_JDG_CD_*`, `SVC_KEI_STAT_*`, `IDO_DIV_*` codes). This duplication exists because the two classes evolved independently to serve different functional areas. When adding a new shared constant, prefer `JKKSvcConst` as the canonical location.

### String Values Are Business Keys

These `String` values are **not arbitrary** — they are the values stored in the database and transmitted to external systems (billing, provisioning, NTT). Never change an existing constant's value. To add a new code, define a new constant and update any relevant processing logic.

### Version History Tracking

All three source files maintain detailed change logs in their file headers, documenting every version since initial creation (2011–2025). When modifying a class, add your change to this header following the existing format: version, date, author, and issue number.

### Japanese Comments

The Javadoc and inline comments are primarily in Japanese. This is intentional — the eo Customer Core System is a Japanese product used by Japanese operations teams. Do not translate existing comments; instead, write new comments in Japanese to match the codebase convention.

### New Code Addition Checklist

When adding a new constant:
1. Determine which class owns the relevant domain (SOD-specific → `JKKHakkoSODConstCC`, general service → `JKKSvcConst`, transfer-specific → `JKKItntokiStaEndConstCC`).
2. If it's a business code (not a map key), add it to the appropriate grouped section.
3. If it's a map key for SOD data interchange, add it to the corresponding info section.
4. Add a Javadoc comment describing the meaning in Japanese.
5. Add a version entry in the file header.
6. Use a value that fits the existing code scheme (e.g., `"A98"` for the next price course code after `"A97"`).