299 lines
11 KiB
Markdown
299 lines
11 KiB
Markdown
# 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清單來追蹤後續的測試和優化工作。現在可以開始測試功能了！
|
||
|
||
您想要先測試哪個部分？或者有什麼需要調整的地方嗎？ |