17168ERP/data/memo/共同-沖帳流程.md

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

// 查詢條件：pay_mode == "共同" && status == "2" && check_status == "2"
[HttpGet]
[Route("api/transfer_register/group_reconcile_list")]

1.2 新增 get_activity_followers API

// 查詢指定法會中有未完成沖帳項目的信眾
[HttpGet]  
[Route("api/transfer_register/activity_followers")]

1.3 新增 group_follower_orders API

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

1.4 新增 group_reconcile API

// 處理共同沖帳，建立多筆 pro_order_record
[HttpPost]
[Route("api/transfer_register/group_reconcile")]

階段二：draft 欄位格式設計

2.1 擴充 draft-utils.js

// 新增 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清單來追蹤後續的測試和優化工作。現在可以開始測試功能了！

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