# Eo / Ejb / Cbs / Cbsmsg/other

## Overview

This subpackage belongs to the **eo customer core system** (eo顧客基幹システム) and contains a family of schema classes used for CBS (Central Billing System) message exchanges. Every class extends `com.fujitsu.futurity.model.base.CAANSchemaInfo`, which is the Fujitsu Futurity framework's base class for structured data schemas (row data pattern).

The `Other` group collects message schemas that did not fit into other named subpackages. Collectively, they cover:

- Service contract agreement searches
- Return equipment cancellation operations
- Number reservation registrations
- Service contract contents and line contents lookups
- Option service contract management
- Equipment provision service contract detail views

Each business area is represented by a **paired class set**: a `CBSMsg` class (header / search-condition wrapper) and a `CBSMsg1List` class (detail / data rows).

## Architecture

### Two-class pattern

Every business function uses the same two-class convention:

| Convention | Responsibility |
|---|---|
| `EKKxxxxCBSMsg` (or `EDKxxxxCBSMsg`) | Header-level fields — pagination, search conditions, error flags. Contains a `getContents()` method returning the full `Object[][]` template. |
| `EKKxxxxCBSMsg1List` (or `EDKxxxxCBSMsg1List`) | Detail rows — the actual business data columns returned per record. Also contains `getContents()`. |

The `CBSMsg` class embeds a reference to its `CBSMsg1List[]` array inside its `CONTENTS` definition, establishing a parent-child relationship. On the server side, the framework uses these `CONTENTS` arrays to:

1. Validate incoming request data against the schema.
2. Map database result sets or domain objects into strongly-typed schema instances.
3. Serialize the structured message across EJB boundaries.

All field names are defined as `public static final String` constants (e.g., `TEMPLATEID`, `SVC_KEI_NO`), making them referenceable across modules.

```java
public static final String TEMPLATEID = "templateID";
public static final String IDENTIFYCD = "identifyCD";
```

### Common header fields

Every `CBSMsg` class shares an identical set of ~23 header fields:

| Field | Type | Purpose |
|---|---|---|
| `templateID` | String | Service IF identifier |
| `identifyCD` | String | Identification code |
| `status` | int | Overall processing status |
| `operatorID` | String | Operator ID |
| `operateDate` / `operateDatetime` | String | Business date and timestamp |
| `ac_group_cd` / `func_code` | String | Authorization group and function code |
| `sort_column_code` / `sort_flg` | Long | Sort column and order |
| `search_type`, `max_search_num`, `display_num`, `display_page_num` | String | Search parameters and pagination |
| `total_search_num`, `total_page_num` | String | Computed totals for UI pagination |
| `search_err_flg` and associated `*_err` fields | String | Per-field validation error flags |

### Data row classes

`CBSMsg1List` classes define function-specific row schemas. The `CONTENTS` array lists each column as `{ fieldName, type }` pairs, where type is typically `"String"` (with occasional `"Long"` or `"int"`). Each column also has a Japanese comment describing its business meaning.

Key constants are exported as `public static final String` fields so other modules can reference column names without hard-coding strings.

## Business Functions

### 1. Service Contract Agreement Search — EKK0081

**Classes:**
- [`EKK0081A010CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0081A010CBSMsg.java) — search header
- [`EKK0081A010CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0081A010CBSMsg1List.java) — search result rows

The `CBSMsg` is the standard header-only skeleton (no extra fields beyond the common set). The `CBSMsg1List` is one of the largest classes in the package at **955 lines**, defining ~120 fields that cover:

- Service contract identifiers (`SVC_KEI_NO`, `SYSID`, `SVC_CD`)
- Application details (`MSKM_DTL_NO`, `SEIRI_NO`, `MENKAIHAT_ANKEN_NO`)
- Pricing details (`PRC_GRP_CD`, `PCRS_CD`, `PPLAN_CD` and their `_nm` display-name variants)
- Equipment provisioning (`TK_HOSHIKI_KEI_NO`)
- Dates spanning the full contract lifecycle — service start (`SVC_STAYMD`), plan start/end, trial period, actual billing, cancellation, disconnection, resumption
- Status codes and reasons for pause, stop, cancellation, and disconnection
- Audit fields (`add_dtm`, `upd_dtm`, `del_dtm`, operator account references)
- Compliance flags (NTT deregistration division, volume-over-notification)

This appears to be the primary service contract agreement inquiry, providing a comprehensive view of the contract state.

### 2. Return Equipment Cancellation — EDK0301

**Classes:**
- [`EDK0301B060CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EDK0301B060CBSMsg.java) — search header
- [`EDK0301B060CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EDK0301B060CBSMsg1List.java) — search result rows

This pair handles the **return equipment cancellation inquiry** (返品機器取消一覧照会). The `CBSMsg1List` row schema defines:

| Field | Meaning |
|---|---|
| `HMPIN_KIKI_NO` | Return equipment number |
| `HMPIN_KIKI_STAT` | Return equipment status |
| `SOKO_CD` / `SHELF_CD` | Warehouse and shelf codes |
| `KKTK_SVC_KEI_NO` | Equipment provision service contract number |
| `KIKI_CHG_NO` | Equipment change number |
| `TAKNKIKI_MODEL_CD` | Home equipment model code |
| `KIKI_SEIZO_NO` | Equipment serial number |
| `UPD_DTM` | Last update timestamp |
| `HMPIN_DIV` | Return classification |
| `BTRYHOZN_CD` | Logistics safety code |

The `CBSMsg` includes search key fields (`KEY_KKTK_SVC_KEI_NO`, `KEY_HMPIN_KIKI_STAT`, `KEY_KIKI_CHG_NO`, `KEY_KIKI_SEIZO_NO`) and embeds the detail list. Error suffixes (`*_ERR`) exist for both the search keys and the detail list.

### 3. Number Reservation Registration — EKK0161

**Classes:**
- [`EKK0161A010CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0161A010CBSMsg.java) — header
- [`EKK0161A010CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0161A010CBSMsg1List.java) — detail rows

**`EKK0161B003CBSMsg`** / **`EKK0161B003CBSMsg1List`** — registration detail

**`EKK0161B004CBSMsg`** / **`EKK0161B004CBSMsg1List`** — additional processing

**`EKK0161B008CBSMsg`** / **`EKK0161B008CBSMsg1List`** — number reservation type inquiry

The `EKK0161B008` pair handles **number reservation type inquiry** (番ボ申込種別照会). Its detail row defines:

| Field | Meaning |
|---|---|
| `BMP_UM` | Number board presence (yes/no) |
| `MSKM_SBT_CD` | Application type code |
| `MSKM_NO` | Application number |
| `GENE_ADD_DTM` | Generation registration timestamp |
| `MSKM_YMD` | Application date |

This is a smaller, focused schema used for displaying what types of number reservations have been submitted.

### 4. Service Contract Contents — EKK0191

**Classes:**
- [`EKK0191A010CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0191A010CBSMsg.java) — header
- [`EKK0191A010CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0191A010CBSMsg1List.java) — detail rows

**`EKK0191B001`** — eo light phone contract contents (サービス契約内容<eo光電話>一覧照会)

**`EKK0191B502`** — pre-transfer service contract contents (移転元サービス契約内容)

The `B001` detail class (`EKK0191B001CBSMsg1List`, 909 lines) covers eo light phone contract details including:

- Contract identifiers and status
- Pricing code and plan
- Service start/end dates
- Phone numbers (`TELNO`, `TELNO_JUN`)
- Equipment details — VA model codes, port numbers, serial numbers
- Cancellation/pause dates with transfer target information (transfer destination phone, contract number)
- Construction method codes (`KOJI_JSSI_WAY`)
- Estimated switch time zones
- Same-number transfer flag (`DOBANITEN_MSKM_UM`)

The `B502` variant handles pre-transfer (former service contract) contents for service portability scenarios.

### 5. Equipment Provision Service Contract — EKK0341

**Classes:**
- [`EKK0341A010CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0341A010CBSMsg.java) — header
- [`EKK0341A010CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0341A010CBSMsg1List.java) — detail rows (~1,469 lines — the largest)

**B-variant subtypes:**

| Class | Purpose |
|---|---|
| `EKK0341B001CBSMsg` / `CBSMsg1List` | Equipment provision service contract list by serial number |
| `EKK0341B002CBSMsg` / `CBSMsg1List` | Equipment provision service contract change detail |
| `EKK0341B008CBSMsg` / `CBSMsg1List` | Additional processing view |
| `EKK0341B021CBSMsg` / `CBSMsg1List` | Special handling inquiry |
| `EKK0341B022CBSMsg` / `CBSMsg1List` | Additional detail view |
| `EKK0341B029CBSMsg` / `CBSMsg1List` | Additional processing |
| `EKK0341B504CBSMsg` / `CBSMsg1List` | Alternative processing path |

The `B001` detail schema (`EKK0341B001CBSMsg1List`, 202 lines) covers equipment-level data:

| Field | Meaning |
|---|---|
| `KKTK_SVC_KEI_NO` | Equipment provision service contract number |
| `KIKI_SEIZO_NO` | Equipment serial number |
| `SVC_KEI_NO` | Service contract number |
| `SVC_KEI_UCWK_NO` | Service contract contents number |
| `KKTK_SVC_KEI_STAT` | Equipment provision status |
| `PCRS_CD` / `PCRS_CD_NM` | Pricing cost code |
| Installation address fields (`KIKI_STC_SAKI_*`) | Prefecture, city, district, block number, building name |
| `TAKNKIKI_MODEL_CD` | Home equipment model code |

### 6. Option Service Contracts — EKK0351

**Classes:**
- [`EKK0351A010CBSMsg`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0351A010CBSMsg.java) — header
- [`EKK0351A010CBSMsg1List`](Source/koptModel/src/eo/ejb/cbs/cbsmsg/EKK0351A010CBSMsg1List.java) — detail rows

**`EKK0351B002CBSMsg`** / **`CBSMsg1List`** — Option service contract list by service contract number

**`EKK0351B003CBSMsg`** / **`CBSMsg1List`** — Additional processing

**`EKK0351B010CBSMsg`** / **`CBSMsg1List`** — Additional view

The `B002` detail class (`EKK0351B002CBSMsg1List`, 237 lines) defines option service contract details:

| Field | Meaning |
|---|---|
| `OP_SVC_CD` / `OP_SVC_CD_NM` | Option service code and name |
| `OP_SVC_KEI_NO` / `OP_SVC_KEI_STAT` | Option service contract number and status |
| `OP_SVC_NIY` | Option service content/description |
| `SVC_KEI_NO`, `PPLAN_CD`, `PCRS_CD` | Associated service contract and pricing |
| `SBOP_SVC_KEI_NO` / `SBOP_SVC_CD` | Sub-option service contract number and code |
| `MAX_OP_SVC_CNT` | Maximum option service count |
| `FMTCEL_JGS_CD` | Femto cell provider code |
| `KAIHK_PSB_PRD` | Recovery possible period |

### 7. Other Classes

| Class | Notes |
|---|---|
| `EKK0361A010CBSMsg` / `CBSMsg1List` | Option service ISP agreement search. Header-only (251 lines for Msg, 895 for List). |
| `EKK0401A010CBSMsg` / `CBSMsg1List` | Generic EKK0401 schema. 279 lines for Msg, 580 for List. |
| `EKK0401B001CBSMsg` / `CBSMsg1List` | Additional processing variant for EKK0401. |
| `EKK0411A010CBSMsg` / `CBSMsg1List` | Generic EKK0411 schema. 269 lines for Msg, 202 for List. |
| `EKK0791A010CBSMsg` / `CBSMsg1List` | Generic EKK0791 schema. 269 lines for Msg, 461 for List. |
| `EKK0191B001CBSMsg1List` | Detail rows for eo light phone contract contents (see Section 4). |
| `EKK0191B001CBSMsg` / `EKK0191B001CBSMsg1List` | eo light phone contract contents by service contract number. |
| `EKK0251B001CBSMsg` / `CBSMsg1List` | Service contract line contents search by service contract number (サービス契約回線内容一覧照会). The detail schema includes mansion property number, line content usage start/end dates, and residence type code. |

## How It Works

### Typical usage flow

1. **A frontend or EJB caller** instantiates a `CBSMsg` object (e.g., `EKK0081A010CBSMsg`).
2. **Search conditions** (pagination, sort keys, filter values) are set on the `CBSMsg` fields via the framework's setter methods (inherited from `CAANSchemaInfo`).
3. **The message is sent** to the backend EJB layer. The Futurity framework uses the `getContents()` template to validate and deserialize the incoming data.
4. **The EJB executes** a database query, mapping result sets to `CBSMsg1List` schema rows.
5. **The `CBSMsg1List[]` array** is populated and attached as a field inside the `CBSMsg` object.
6. **The complete `CBSMsg`** (header + row list) is serialized back to the caller.
7. **Error states** are tracked via the `*_err` fields on the header, so the UI can display per-field validation errors.

### Schema definition structure

Each class declares a `static final Object[][] CONTENTS` at the top, followed by `static final String` constants for every field name. A static initializer block binds the constants to the string values:

```java
static {
    TEMPLATEID = "templateID";
    IDENTIFYCD = "identifyCD";
    // ... one line per field
}
```

The `getContents()` method simply returns this `CONTENTS` array — a three-element `Object[]` per column: `{ fieldName, javaType, columnLabel }` (or similar, depending on framework conventions).

```java
public Object[][] getContents() {
    return CONTENTS; // returns the template definition
}
```

This pattern allows the Futurity `CAANSchemaInfo` framework to introspect the schema at runtime for validation, serialization, and UI generation.

## Data Model

```mermaid
flowchart TD
    subgraph CBSMsg["CBSMsg Schema Classes"]
        Msg["CBSMsg
Header / Query class
Search params, pagination,
error tracking"]
        List["CBSMsg1List
Detail / Data class
Function-specific fields"]
    end

    subgraph Business["Business Functions"]
        SCA["EKK0081
Service Contract Agreement
Search & Detail"]
        Ret["EDK0301
Return Equipment Cancellation
Search & Detail"]
        Nbr["EKK0161
Number Reservation Registration
Search & Detail"]
        Cnt["EKK0191
Service Contract Contents
Search & Detail"]
        Cng["EKK0341
Equipment Provision Service
Contract Search & Detail"]
        Opt["EKK0351
Option Service Contract
Search & Detail"]
        Svc["EKK0361
Option Service ISP
Agreement Search & Detail"]
        RetC["EKK0341B
Equipment Provision
Contract Change Detail"]
    end

    SCA --> Msg
    Ret --> Msg
    Nbr --> Msg
    Cnt --> Msg
    Cng --> Msg
    Opt --> Msg
    Svc --> Msg
    RetC --> Msg

    SCA --> List
    Ret --> List
    Nbr --> List
    Cnt --> List
    Cng --> List
    Opt --> List
    Svc --> List
    RetC --> List
```

**Key relationships:**

- **Parent-child**: Each `CBSMsg` embeds a reference to its corresponding `CBSMsg1List[]` within its `CONTENTS` array (e.g., `"EDK0301B060CBSMsg1List", "eo.ejb.cbs.cbsmsg.EDK0301B060CBSMsg1List[]"`).
- **Header + detail**: Every business function has at least one header (`CBSMsg`) and one detail (`CBSMsg1List`) class, though some functions have multiple `B`-variant detail schemas for different use cases.
- **Common header**: All `CBSMsg` classes share the same ~23 header fields, enabling a uniform search/pagination/error interface across all functions.
- **Cross-references**: Detail classes reference fields from other domains (e.g., `EKK0081A010CBSMsg1List` references `SVC_KEI_NO` which also appears in `EKK0341B001CBSMsg1List`), indicating shared entity relationships in the underlying database.

## Dependencies and Integration

- **Framework dependency**: All classes extend `com.fujitsu.futurity.model.base.CAANSchemaInfo` from the Fujitsu Futurity application framework. This base class provides the serialization, validation, and schema introspection infrastructure.
- **EJB layer**: These message classes are used at EJB boundaries. The package path `eo.ejb.cbs.cbsmsg` indicates they are part of the EJB module communicating with the CBS (Central Billing System).
- **Cross-module**: While no explicit cross-module dependencies are indexed in this subpackage, the field names (service contract numbers, equipment serial numbers, pricing codes) reference entities defined in other model packages.

## Notes for Developers

### Naming conventions

- **`EKK` prefix**: Used for equipment/service-related operations (機器・サービス関係).
- **`EDK` prefix**: Used for return/equipment-related operations (返品関係).
- **`A010` suffix on headers**: Indicates the primary search/inquiry variant.
- **`Bxxx` suffix on details**: Indicates specific processing detail variants (B001 = primary detail, B002 = change detail, etc.).

### Adding a new business function

1. Create a new `CBSMsg` header class following the existing pattern — define `CONTENTS` with the common header fields, declare `static final String` constants, and add any function-specific search key fields.
2. Create a `CBSMsg1List` detail class — define `CONTENTS` with the function-specific data columns.
3. Reference the `CBSMsg1List[]` type inside the `CBSMsg` `CONTENTS` array to establish the parent-child link.
4. Export column-name constants as `public static final String` for cross-module reference.

### Large schema classes

Some `CBSMsg1List` classes are exceptionally large (1,400+ lines for `EKK0341A010CBSMsg1List`). When working with these:

- Use the method list in this wiki to locate specific methods by line number rather than scrolling through the entire file.
- The field count grows organically over time — new business requirements add columns. Consider whether a split into sub-detail classes is warranted for very wide tables.
- Always check for `_nm` suffix columns, which are display-name variants maintained in parallel with code columns.

### Error handling pattern

Every header class includes error tracking fields:

| Pattern | Examples |
|---|---|
| `*_err` | Per-field validation error flags |
| `*_err_err` | Nested error for the error flag itself |
| `*_List_err` | Error for the embedded list data |

The UI layer reads these flags to render inline error messages next to form fields.

### Japanese source comments

All source files contain Japanese documentation in the header block and as inline comments on data columns. The field comments follow the pattern `{ fieldName, type }`, where the trailing comment is the Japanese business description (e.g., `// サービス契約番号`). These comments are authoritative for understanding field semantics when no additional documentation exists.