# 業務邏輯與資料解析模組 (Business Logic & Parser) 深度分析

在 `CB_IMGPSScanImp.pas.bk` 中，「業務邏輯與資料解析模組」扮演了將底層掃描影像與上層銀行/保險業務需求結合的橋樑。它將前端網頁傳入的原始設定資料，轉換為系統可理解的「案件 (Case)」、「文件 (Document)」與「表單 (Form)」結構，並執行極度複雜的業務規則檢核 (OMR 檢核)。

若要將此模組進一步細拆，其內部組成可分為以下四大子分類：

---

## 1. 系統參數與組態儲存庫 (Config & Parameter Repository)

**職責**：負責解析由 Web 端透過字串傳入的各類系統設定表（通常以 `!@!` 等特殊符號分隔），並將其儲存於記憶體中供全局查詢。
**核心實作特性**：
*   **字串表解析**：大量使用 `TStringList` 作為輕量級的記憶體資料庫 (`SetSQLData`, `GetSQLData`, `FindSQLData`)。
*   **系統設定下載與維護** (`GetSetInf1` ~ `GetSetInf7`)：
    *   `DOC_INF`：文件設定檔（定義文件類型、是否需入庫等）。
    *   `FORM_INF`：表單設定檔（定義條碼對應、長寬、十字定位點、最大頁數）。
    *   `DM_FORM_INF`：相依與互斥規則檔。
    *   `CHECK_RULE_INF`：檢核規則錯誤訊息定義檔。
    *   `WORK_INF`：系統與硬體掃描的預設參數。

## 2. 領域實體對映與結構管理器 (Entity Mapping & Structure Manager)

**職責**：將抽象的條碼 (Barcode) 對映至具體的業務實體，並在檔案系統上維護「案件 -> 文件分份 -> 頁面」的實體目錄與虛擬樹狀結構 (`.dat` 索引檔)。
**核心實作特性**：
*   **條碼解析對映**：`BarCode2FormID`、`BarCode2CaseID`、`FormCode2DocNo`、`DocNo2DocName`。
*   **虛擬檔案系統維護**：
    *   處理文件是否需要拆分多份 (`DocNoNeedDiv`)。
    *   管理 `Context.dat`、`CaseDocNo.dat`、`CaseDocNo_Copies.dat` 等索引檔，以記錄掃描影像與業務文件的歸屬關係。
*   **封裝資訊產生器**：`CreateDocNo_Info`、`CreateCustDocNo_Info` (將目錄結構轉換回 Web 端所需的特定字串格式)。

## 3. OMR 與業務規則檢核引擎 (OMR & Business Rule Engine)

**職責**：整個系統最龐大且複雜的業務邏輯核心，負責確保掃描進來的影像完全符合進件規定，防止缺件或矛盾。
**核心實作特性** (`OMRCheckCase`)：
*   **文件級別檢核 (Document-Level Rules)**：
    *   **主文件檢核**：檢查主要文件是否齊全、頁數是否符合資料庫預期。
    *   **相依/互斥檢核**：依據 `DM_FORM_INF`，判斷若存在 A 文件，是否遺漏了必附的 B 文件，或錯誤附上了互斥的 C 文件。
    *   **生命週期檢核**：判斷表單條碼是否已超過停用日期、或超過允許的最大掃描頁數。
*   **OMR 畫記與欄位級別檢核 (Field-Level OMR Rules)** (透過 `Xmltool` 解析 `.xml` 設定檔，並計算指定 `(X, Y)` 座標的黑白像素點 `GetSiteOMR`)：
    *   `settype1` (必填檢核)：特定的 OMR 區塊必須有畫記。
    *   `settype3` (有值連動必填)：A 欄位有畫記時，相關的 B 欄位也必須畫記。
    *   `settype8` (有值連動互斥)：A 欄位有畫記時，相關的 B 欄位不能畫記。
    *   `settype4` (有值相依文件)：特定欄位有畫記時，系統必須檢查是否已附上指定的文件。
    *   `settype5` (有值互斥文件)：特定欄位有畫記時，系統必須檢查不能附上指定的文件。
    *   `settype6` (強制備註)：特定欄位有畫記時，要求使用者必須手動輸入備註說明。
    *   `settype7` (OMR 帶值提取)：讀取畫記並轉換為特定的業務數值 (`GetValue.xml`)，隨後傳回後端。

## 4. 案件異動與舊案引用處理器 (Case Modification & Legacy Handler)

**職責**：處理「補件 (ESCAN)」、「重掃 (RSCAN)」、「引用舊件」等極度複雜的邊界狀態與跨案件資料流動。
**核心實作特性**：
*   **文件引用管理**：`SetUseCase`、`GetUseCase` 記錄與追蹤不同案件之間文件的借用與引用關係 (記錄於 `UseCase.ini`)。
*   **版本相容與轉換**：`OldCasetoNewCase`、`ErrFormtoCurrentForm` (處理舊系統升級或表單版本更迭時的自動替換邏輯)。
*   **防呆與鎖定**：`DeleteDocNoFileForESCAN` 等邏輯，防止在補件模式下誤刪非當次掃描的既有影像。

---

## 💡 未來重構與微服務化建議

若要將此「業務邏輯模組」進行現代化重構，強烈建議引入以下設計模式：

1.  **Repository Pattern (儲存庫模式)**：將目前散落的 `FindSQLData` 與 `TStringList` 查詢，封裝為 `FormConfigRepository`、`DocConfigRepository` 等強型別介面，隔離底層字串處理細節。
2.  **Rule Engine (規則引擎)**：將 `OMRCheckCase` 內部數百行的 `if/else` 與 XML 巡覽，拆分為獨立的實體類別（例如 `RequiredFieldRule`, `DependencyDocumentRule`, `MutexFieldRule`），並透過統一的 `Validator` 介面依序執行，大幅提升可測試性 (Testability) 與維護性。
3.  **Domain Driven Design (領域驅動設計)**：將依賴實體 `.dat` 檔案的狀態管理，重構成記憶體中的 `TCase`, `TDocument`, `TPage` 領域物件，只有在最終儲存或打包時才寫入實體檔案系統。