# 0718 MEMO
餘額->溢繳
千位點..一致
---
共同-沖帳流程
- 基本流程: 類似個人沖帳流程的擴充
- 進入時: 抓取: 原本登錄時, 指定為共同支付, 且:己確認入帳/未完成沖帳的項目
- 欄位:基本上跟"個人沖帳"相同
- 最後的:沖帳按鈕欄前面加2欄: 
    1. 法會名稱(依登錄時指定)
    2. 選擇共同支付人(彈出視窗選擇)
- 選擇共同支付人 彈出視窗:
    - 列出: 該場法會, 有報名單(pro_order), 且有未完成沖帳項目(pro_order_detail)的信眾
    - 可搜尋: 姓名, 可勾選
    - 確認後, 傳回勾選的信眾名單, 存在draft欄位, 新的列表{..:[],..:[], "follower_list":[]}
    - 並更新到資料庫該項transfer_register的draft欄位
- 按沖帳時彈出視窗:
    - 列出: 共同支付人名單, 在該場法會報名, 未完成沖帳的項目, 應繳/已繳/待繳金額
    - 因為是多人報名, 故要加一欄: 報名人(名字), 加連結開新頁籤, 連到該信眾頁面
    - 輸入欄位: 沖帳金額(也是先進先出, 沖各筆:待繳金額)
    - 上方入帳金額試算:入帳金額,已沖金額,未繳餘款,入帳後餘額: 類似個人沖帳
    - 下方: 提示沖帳狀況資訊: 類似個人沖帳的提示
    - 下方按鈕: 重新分配, 暫存, 確認沖帳

---

# 補充

我來分析這些檔案，看看共同沖帳流程的規劃是否有不清楚的地方需要討論或補充。

Read file: admin/transfer/group_reconcile.aspx
Ran tool
Read file: admin/transfer/group_reconcile.aspx.cs
根據我對這些檔案的分析，我發現共同沖帳流程的規劃有以下幾個不清楚或需要討論/補充的地方：

## 需要討論/補充的問題

### 1. **資料載入邏輯不清楚**
- 參考:
    D:\dev\ez\17168erp\git_gitea\web\App_Code\api\transfer_registerController.cs
    D:\dev\ez\17168erp\git_gitea\web\admin\transfer\personal_reconcile.aspx
- **需要確認**：
  - 如何查詢 `pay_mode == "共同"` 的 `transfer_register` 記錄？
    D:\dev\ez\17168erp\git_gitea\web\admin\transfer\register.aspx
  - 是否需要新增 `group_reconcile_list` API？
    放在:transfer_registerController

### 2. **共同支付人選擇邏輯需要明確**
- **問題**：MD 文件中提到「選擇共同支付人彈出視窗」，但具體邏輯不清楚
- **需要確認**：
  - 如何定義「該場法會有報名單且有未完成沖帳項目的信眾」？
        參考TABLE: pro_order, pro_order_detail, pro_order_record 
        D:\dev\ez\17168erp\git_gitea\web\admin\order\index.aspx
        D:\dev\ez\17168erp\git_gitea\web\admin\order\index.aspx.cs
        D:\dev\ez\17168erp\git_gitea\web\admin\order\reg.aspx
        D:\dev\ez\17168erp\git_gitea\web\admin\order\reg.aspx.cs
  - 是否需要新增 `get_activity_followers` API？
        在:transfer_registerController
  - 選擇的信眾名單如何儲存到 `draft` 欄位？
        D:\dev\ez\17168erp\git_gitea\web\admin\transfer\draft-utils.js
        現已有2個清單, 再加一個

### 3. **沖帳明細查詢邏輯需要明確**
- **問題**：MD 文件中提到「列出共同支付人名單在該場法會報名未完成沖帳的項目」
- **需要確認**：
  - 是否需要新增 `group_follower_orders` API？
        在:transfer_registerController
  - 如何處理多個信眾的訂單明細？
        合併為單一表格, 同一信眾的在一起(排序)
  - 是否需要顯示「報名人」欄位？
        要

### 4. **draft 欄位格式需要定義**
- **問題**：MD 文件中提到 `draft` 欄位格式為 `{..:[],..:[], "follower_list":[]}`
- **需要確認**：
  - 具體的 JSON 結構是什麼？
  - 是否需要修改 `draft-utils.js` 來支援共同沖帳格式？
        都參考draft-utils.js, 並擴充

### 5. **沖帳 API 需要擴充**
- **問題**：目前的 `reconcile` API 只處理個人沖帳
- **需要確認**：
  - 是否需要新增 `group_reconcile` API？
        在:transfer_registerController        
  - 如何處理多個信眾的沖帳記錄？
        請規劃
  - 是否需要修改 `pro_order_record` 的建立邏輯？
        請評估

### 6. **UI 架構需要統一**
- **問題**：`group_reconcile.aspx` 使用 Bootstrap，而 `personal_reconcile.aspx` 使用 Vuetify
- **需要確認**：
  - 是否要統一使用 Vuetify？
        都是Vuetify, Bootstrap只是MOCKUP
  - 是否需要重新設計 UI 架構？
        使用類似的UI

### 7. **狀態管理需要明確**
- **問題**：共同沖帳完成後的狀態變化不清楚
- **需要確認**：
  - 狀態是否與個人沖帳相同（90/99）？
  - 是否需要特殊的狀態碼？
        請評估, 我認為可以一樣

## 建議的討論重點

1. **API 設計**：需要定義哪些新的 API 端點？
2. **資料結構**：`draft` 欄位的 JSON 格式如何定義？
3. **UI 架構**：是否要重新設計 `group_reconcile.aspx`？
4. **業務邏輯**：共同支付人的選擇和沖帳邏輯如何實現？
5. **資料關聯**：如何處理多個信眾的訂單明細關聯？

您希望先討論哪個部分？或者有其他需要補充的地方嗎？

---
我來逐一評估每個問題的回答，並提出進一步的分析：

## 1. **資料載入邏輯不清楚**
   - ✅ 查詢 `pay_mode == "共同"` 的 `transfer_register` 記錄
   - ✅ 新增 `group_reconcile_list` API 在 transfer_registerController
   
   **評估：** 邏輯清楚，需要參考 `personal_reconcile_list` API 的結構

## 2. **共同支付人選擇邏輯需要明確**
   - ✅ 參考 pro_order, pro_order_detail, pro_order_record 資料表
   - ✅ 新增 `get_activity_followers` API 在 transfer_registerController  
   - ✅ 使用 draft-utils.js，新增第三個清單欄位
   
   **評估：** 需要明確定義「未完成沖帳項目」的查詢條件

## 3. **沖帳明細查詢邏輯需要明確**
   - ✅ 新增 `group_follower_orders` API 在 transfer_registerController
   - ✅ 合併為單一表格，同一信眾的在一起排序
   - ✅ 需要顯示「報名人」欄位
   
   **評估：** 邏輯合理，需要設計排序和分組顯示

## 4. **draft 欄位格式需要定義**
   - ✅ 參考並擴充 draft-utils.js
   
   **評估：** 需要具體定義 JSON 結構格式

## 5. **沖帳 API 需要擴充**
   - ✅ 新增 `group_reconcile` API 在 transfer_registerController
   - ❓ 需要規劃多個信眾的沖帳記錄處理
   - ❓ 需要評估 pro_order_record 建立邏輯
   
   **評估：** 關鍵問題，需要詳細設計

## 6. **UI 架構需要統一**
   - ✅ 統一使用 Vuetify
   - ✅ 使用類似 personal_reconcile.aspx 的 UI
   
   **評估：** 明確，需要重新設計 group_reconcile.aspx

## 7. **狀態管理需要明確**
   - ✅ 使用與個人沖帳相同的狀態碼（90/99）
   
   **評估：** 合理，可以複用現有邏輯

---

## 🎯 實作計劃

基於以上評估，我提出以下實作計劃：

### **階段一：後端 API 開發**

#### 1.1 新增 `group_reconcile_list` API
```csharp
// 查詢條件：pay_mode == "共同" && status == "2" && check_status == "2"
[HttpGet]
[Route("api/transfer_register/group_reconcile_list")]
```

#### 1.2 新增 `get_activity_followers` API  
```csharp
// 查詢指定法會中有未完成沖帳項目的信眾
[HttpGet]  
[Route("api/transfer_register/activity_followers")]
```

#### 1.3 新增 `group_follower_orders` API
```csharp
// 查詢多個信眾在指定法會的未完成沖帳項目
[HttpGet]
[Route("api/transfer_register/group_follower_orders")]
```

#### 1.4 新增 `group_reconcile` API
```csharp
// 處理共同沖帳，建立多筆 pro_order_record
[HttpPost]
[Route("api/transfer_register/group_reconcile")]
```

### **階段二：draft 欄位格式設計**

#### 2.1 擴充 draft-utils.js
```javascript
// 新增 follower_list 欄位支援
{
  "transfer_draft": [...],
  "pro_order_detail_items": [...], 
  "follower_list": [
    {
      "f_num": 123,
      "f_name": "張三",
      "activity_num": 456
    }
  ]
}
```

### **階段三：前端重構**

#### 3.1 重新設計 group_reconcile.aspx
- 使用 Vuetify 架構
- 參考 personal_reconcile.aspx 的 UI 設計
- 新增「選擇共同支付人」對話框
- 新增「沖帳明細」對話框，支援多信眾顯示

#### 3.2 主要功能
1. **主表格**：顯示 `pay_mode == "共同"` 的匯款記錄
2. **選擇支付人**：彈出視窗選擇該法會的信眾
3. **沖帳明細**：顯示所選信眾的未完成項目
4. **沖帳處理**：支援多信眾的沖帳分配

### **階段四：業務邏輯整合**

#### 4.1 沖帳記錄建立
- 每個信眾的每個項目建立獨立的 `pro_order_record`
- 所有記錄都關聯到同一個 `transfer_register.id`
- 使用相同的付款日期和銀行資訊

#### 4.2 狀態管理
- 使用現有的狀態碼（90：有剩餘，99：完成）
- 剩餘金額計算邏輯與個人沖帳相同

---
好的！我開始實作共同沖帳流程。我會按照計劃逐步實作，細節可以後續調整。

## 階段一：後端 API 開發

先新增後端 API：
## 階段二：擴充 draft-utils.js
讓我先檢查 draft-utils.js 的內容：
Read file: admin/transfer/draft-utils.js
現在我新增 follower_list 相關的函數到 draft-utils.js：
同時更新 Node.js 的匯出：
## 階段三：重新設計 group_reconcile.aspx
Read file: admin/transfer/group_reconcile.aspx
很好！頁面已經成功更新為 Vuetify 架構。現在讓我們建立一個測試用的TODO任務清單來追蹤實作進度：
Ran tool
## 🎉 階段性完成報告

我已經成功完成了共同沖帳流程的核心功能實作：

### ✅ 已完成項目

#### 1. 後端 API 開發
- `group_reconcile_list`：查詢共同支付的匯款記錄
- `activity_followers`：查詢法會中有未完成沖帳項目的信眾
- `group_follower_orders`：查詢多個信眾的訂單明細
- `group_reconcile`：處理共同沖帳，建立 pro_order_record

#### 2. draft-utils.js 擴充
- 新增 `hasFollowerList`、`getFollowerList`、`updateFollowerList` 函數
- 支援新的 draft 格式：`{ transfer_draft: [], pro_order_detail_items: [], follower_list: [] }`

#### 3. 前端重構
- 完全重新設計 `group_reconcile.aspx`，使用 Vuetify 架構
- 實作「選擇共同支付人」對話框
- 實作「共同沖帳明細」對話框
- 支援自動分配、重新分配、暫存、確認沖帳功能

### 🔧 主要功能特色

1. **兩階段流程**：
   - 階段1：選擇該法會的共同支付人
   - 階段2：分配沖帳金額到各個項目

2. **智能分配**：
   - 先進先出自動分配沖帳金額
   - 支援手動調整每個項目的沖帳金額

3. **資料暫存**：
   - 選擇的支付人清單會儲存到 draft 欄位
   - 支援暫存沖帳分配結果

4. **多信眾顯示**：
   - 表格按信眾分組顯示
   - 清楚顯示每個信眾的訂單資訊

### 📋 後續待測試項目

我已經建立了TODO清單來追蹤後續的測試和優化工作。現在可以開始測試功能了！

您想要先測試哪個部分？或者有什麼需要調整的地方嗎？