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

在 CB_IMGPSScanImp.pas 中，「業務邏輯與資料解析模組」扮演了將底層掃描影像與上層銀行/保險業務需求結合的橋樑。它將前端網頁傳入的原始設定資料，轉換為系統可理解的「案件 (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 領域物件，只有在最終儲存或打包時才寫入實體檔案系統。