# Business Logic — JKKKeiNewCmnLogicUtil.getIdoDiv() [14 LOC]

| Field | Value |
|-------|-------|
| Fully Qualified Name | `eo.web.webview.commonOneStop.JKKKeiNewCmnLogicUtil` |
| Layer | Utility (Static common logic helper) |
| Module | `commonOneStop` (Package: `eo.web.webview.commonOneStop`) |

## 1. Role

### JKKKeiNewCmnLogicUtil.getIdoDiv()

The `getIdoDiv` method is a **routing/dispatch utility** that resolves a subscription type code (`mskmSbtCd`) into a standardized **transfer classification code** (`idoDiv`). In the K-Opticom telecom order fulfillment domain, every service contract change — whether it is a new contract, a service addition, a cancellation, or a modification — is categorized under a transfer classification that downstream processing (data mapping, database persistence, billing setup) uses to determine the correct operational path. This method implements a simple **factory mapping pattern**: given a compact code representing the order subtype (new vs. addition), it returns a canonical two-character classification code (`00001` for new contract, `00002` for service addition) that is consumed by DB mappers and form beans across the entire webview layer. The method is a **shared static utility** called from multiple screen mappers (KKSV0080, KKSV0081, KKSV0082, KKSV0568, KKSV0675, KKSV0749, KKSV0182, KKSV0895) and business logic classes (KKW00121SFLogic), ensuring a single point of consistency for transfer classification resolution.

## 2. Processing Pattern (Detailed Business Logic)

```mermaid
flowchart TD
    START(["getIdoDiv(mskmSbtCd)"])
    COND_SHINKI{MSKM_SBT_CD_SHINKI equals mskmSbtCd?}
    COND_TSUIKA{MSKM_SBT_CD_TSUIKA equals mskmSbtCd?}
    RETURN_NEW["Return CD00576_00001"]
    RETURN_ADD["Return CD00576_00002"]
    RETURN_EMPTY["Return empty string"]
    END_NODE(["Return String idoDiv"])

    START --> COND_SHINKI
    COND_SHINKI -->|MSKM_SBT_CD_SHINKI = 1 New Contract| RETURN_NEW
    COND_SHINKI -->|False| COND_TSUIKA
    COND_TSUIKA -->|MSKM_SBT_CD_TSUIKA = 2 Service Addition| RETURN_ADD
    COND_TSUIKA -->|Default| RETURN_EMPTY
    RETURN_NEW --> END_NODE
    RETURN_ADD --> END_NODE
    RETURN_EMPTY --> END_NODE
```

**CRITICAL — Constant Resolution:**

| Constant | Resolved Value | Business Meaning |
|----------|---------------|-----------------|
| `MSKM_SBT_CD_SHINKI` | `"1"` | New Contract (新垣契約) — a brand-new service subscription |
| `MSKM_SBT_CD_TSUIKA` | `"2"` | Service Addition (サービス追加) — adding a new service line to an existing contract |
| `JKKStrConst.CD00576_00001` | `"00001"` | Transfer Classification: New Contract |
| `JKKStrConst.CD00576_00002` | `"00002"` | Transfer Classification: Service Addition |

## 3. Parameter Analysis

| No | Parameter Name | Type | Business Description |
|----|---------------|------|---------------------|
| 1 | `mskmSbtCd` | `String` | **Subscription Subtype Code** (申込種別コード) — a compact code that identifies the type of subscription transaction being performed. It acts as a discriminator in the routing logic: `"1"` triggers the new-contract classification path, `"2"` triggers the service-addition path, and any other value (e.g., cancellation code `00027`, modification code `00035`) falls through to return an empty string. This code originates from the screen-side data bean (e.g., `KKW00121SFConst.MSKM_SBT_CD` or `KKW00101SFConst.MSKM_FLG`) and is set by the user-facing screen logic before being passed to the DB mapper layer. |

## 4. CRUD Operations / Called Services

This method performs **no database or service component interactions**. It is a pure transformation utility — a constant-value lookup table implemented as an if-else chain. No SC Code, CBS, or Entity/DB table is involved.

| CRUD | SC / CBS | SC Code | Entity / DB | Operation Description |
|------|----------|---------|-------------|----------------------|
| (none) | — | — | — | Pure in-memory constant mapping; no data access |

## 5. Dependency Trace

| # | Caller (Screen/Batch) | Call Chain (Full Path to this Method) | Terminal (SC / CRUD / Entity) |
|---|----------------------|--------------------------------------|-------------------------------|
| 1 | Screen:KKSV0080 | `KKSV0080_KKSV0080OPDBMapper` (static import `getIdoDiv`) -> resolves `mskmFlg` -> calls `getIdoDiv(mskmFlg)` | `getIdoDiv [R] (no DB)` |
| 2 | Screen:KKSV0081 | `KKSV0081_KKSV0081OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean[0].sendMessageString(KKW00121SFConst.MSKM_SBT_CD, GET))` | `getIdoDiv [R] (no DB)` |
| 3 | Screen:KKSV0082 | `KKSV0082_KKSV0082OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean[0].sendMessageString(KKW00121SFConst.MSKM_SBT_CD, GET))` | `getIdoDiv [R] (no DB)` |
| 4 | Screen:KKSV0568 | `KKSV0568_KKSV0568OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean[0].sendMessageString(KKW00101SFConst.MSKM_FLG, GET))` | `getIdoDiv [R] (no DB)` |
| 5 | Screen:KKSV0675 | `KKSV0675_KKSV0675OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean.sendMessageString(KKW00101SFConst.MSKM_FLG, GET))` | `getIdoDiv [R] (no DB)` |
| 6 | Screen:KKSV0749 | `KKSV0749_KKSV0749OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean.sendMessageString(KKW00121SFConst.MSKM_SBT_CD, GET))` | `getIdoDiv [R] (no DB)` |
| 7 | Screen:KKSV0182 | `KKSV0182_KKSV0182OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(bean[0].sendMessageString(KKW00121SFConst.MSKM_SBT_CD, GET))` | `getIdoDiv [R] (no DB)` |
| 8 | Screen:KKSV0895 | `KKSV0895_KKSV0895OPDBMapper` (static import `getIdoDiv`) -> calls `getIdoDiv(reqMap)` with multiple field mappings (`kk0111_ido_div`, `kk0191_ido_div`, `kk0371_ido_div`, `kk0371cmn_ido_div`, `kk0381_ido_div`, `kk0431_ido_div`, `kk0101_ido_div`) | `getIdoDiv [R] (no DB)` |
| 9 | Logic:KKW00121SFLogic | `KKW00121SFLogic` (static import `getIdoDiv`) -> calls `getIdoDiv(dataBean.sendMessageString(KKW00121SFConst.MSKM_SBT_CD, GET))` | `getIdoDiv [R] (no DB)` |

## 6. Per-Branch Detail Blocks

**Block 1** — [IF] `(MSKM_SBT_CD_SHINKI equals mskmSbtCd)` `[MSKM_SBT_CD_SHINKI="1"]` (L11366–L11369)

> Business description: When the subscription subtype code equals `"1"` (new contract / 新垣契約), return the transfer classification code for "new contract" (`00001`). This is the primary path for brand-new service subscriptions.

| # | Type | Code |
|---|------|------|
| 1 | SET | `result = JKKStrConst.CD00576_00001` // [-> CD00576_00001 = "00001" Transfer Classification: New Contract] |
| 2 | RETURN | `return result;` |

**Block 2** — [ELSE-IF] `(MSKM_SBT_CD_TSUIKA equals mskmSbtCd)` `[MSKM_SBT_CD_TSUIKA="2"]` (L11371–L11374)

> Business description: When the subscription subtype code equals `"2"` (service addition / サービス追加), return the transfer classification code for "service addition" (`00002`). This handles cases where an additional service line is added to an existing contract.

| # | Type | Code |
|---|------|------|
| 1 | SET | `result = JKKStrConst.CD00576_00002` // [-> CD00576_00002 = "00002" Transfer Classification: Service Addition] |
| 2 | RETURN | `return result;` |

**Block 3** — [ELSE] (default branch) (L11375–L11377)

> Business description: For any subscription subtype code that is neither `"1"` (new contract) nor `"2"` (service addition) — such as cancellation codes (`00027`), telephone change codes (`00035`), etc. — return an empty string. This acts as a catch-all that signals "no classification" to the caller, which typically then performs its own fallback logic or skips the transfer classification field.

| # | Type | Code |
|---|------|------|
| 1 | SET | `result = ""` // empty string for unclassified/unsupported subtype codes |
| 2 | RETURN | `return result;` |

## 7. Glossary

| Term | Type | Business Meaning |
|------|------|------------------|
| `mskmSbtCd` | Field | Subscription Subtype Code (申込種別コード) — identifies the type of subscription action: new contract, service addition, cancellation, modification, etc. |
| `idoDiv` | Field | Transfer Classification (異動区分) — a standardized code used throughout the order fulfillment pipeline to distinguish between new-contract processing and addition/cancellation processing paths. |
| `MSKM_SBT_CD_SHINKI` | Constant | Subscription Subtype: New Contract = `"1"` (新垣契約). Used as the discriminator for first-time service subscriptions. |
| `MSKM_SBT_CD_TSUIKA` | Constant | Subscription Subtype: Service Addition = `"2"` (サービス追加). Used when adding a service line to an existing customer contract. |
| `CD00576_00001` | Constant | Transfer Classification Code = `"00001"`. The canonical code for "new contract" operations. |
| `CD00576_00002` | Constant | Transfer Classification Code = `"00002"`. The canonical code for "service addition" operations. |
| KKSVxxxx | Acronym | KK Screen View xxx — screen mapper class naming convention for K-Opticom view-layer DB mapping logic. |
| KKW00121SF | Acronym | K-Opticom Web Service Form — screen logic class for a specific customer-facing form (service subscription detail screen). |
| OPDBMapper | Acronym | Operation Database Mapper — the layer responsible for transforming screen/form data beans into database operation parameters. |
| MSKM_FLG | Field | Subscription Flag (申込フラグ) — an alias for the subscription subtype code, used interchangeably with `mskmSbtCd` in some mappers. |
| Mskm | Abbreviation | MakuShimasu (幕します) — internal telecom abbreviation for "subscription/order" (contract initiation). |
| SbtCd | Abbreviation | Subtype Code (種別コード) — a code that narrows down the general transaction type into a specific sub-category. |