yiming/17168ERP
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

migrate to new git

Browse Source
This commit is contained in:
yiming
2025-08-29 01:27:25 +08:00
parent 946eb9961e
commit af2c152ef6
8623 changed files with 1000453 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

191
data/memo/DRAFT_FIELD_IMPROVEMENT.md Normal file
View File

@@ -0,0 +1,191 @@
# Draft 欄位改進方案
## 問題描述
原本的 `draft` 欄位被用於兩種不同目的，導致資料結構混亂：
1. **暫存沖帳分配** - 在個人沖帳流程中暫存使用者的沖帳金額分配
2. **歷史沖帳記錄** - 記錄已完成的沖帳明細
這導致兩種不同用途的資料互相覆蓋，造成資料不一致的問題。
## 改進方案
將原本的純陣列格式改為物件格式，包含兩個子陣列：
### 新的 draft 欄位格式
```json
{
"transfer_draft": [
{
"pro_order_detail_num": "訂單明細編號",
"reconcile": "沖帳金額"
}
],
"pro_order_detail_items": [
{
"pro_order_detail_num": "訂單明細編號",
"reconcile": "沖帳金額",
"activity_name": "活動名稱",
"actitem_name": "項目名稱",
"price": "原始金額",
"register_date": "報名日期",
"order_no": "訂單編號"
}
]
}
```
### 1. `transfer_draft` - 暫存沖帳分配
**用途：**
- 在 `personal_reconcile.aspx` 中暫存使用者的沖帳金額分配
- 顯示 📝 圖示表示有暫存資料
- 支援「暫存」和「重新分配」功能
### 2. `pro_order_detail_items` - 沖帳明細記錄
**用途：**
- 在 `balance_reconcile.aspx` 中顯示歷史沖帳記錄
- 在 `balance_reconcile_query.aspx` 中顯示選取項目
- 包含完整的活動和項目資訊
## 向後相容性
程式碼會自動檢測格式並處理：
### 新格式（物件）
```json
{
"transfer_draft": [...],
"pro_order_detail_items": [...]
}
```
### 舊格式（陣列）
```json
[
{
"pro_order_detail_num": "12345",
"reconcile": 5000
}
]
```
## 修改的檔案
### personal_reconcile.aspx
- 更新 `loadFromDraftOrAutoDistribute()` 方法支援新舊格式
- 更新 `saveDraft()` 方法使用新格式
- 新增 `hasTransferDraft()` 方法檢查暫存資料
- 更新顯示邏輯使用新格式
### balance_reconcile.aspx
- 更新歷史記錄載入邏輯支援新格式
- 更新詳細資訊顯示邏輯支援新格式
- 保持向後相容性
### balance_reconcile_query.aspx
- 更新 `getDraftItems()` 方法支援新舊格式
- 更新項目顯示邏輯
## 資料安全保護機制
為了確保 `transfer_draft` 和 `pro_order_detail_items` 的操作互不影響，實作了以下保護機制：
### 1. 統一工具函數
所有頁面都使用統一的 `draft-utils.js` 工具函數：
- `window.DraftUtils.getDraftObject(draft)` - 安全解析 draft 欄位
- `window.DraftUtils.getDraftField(draft, fieldName)` - 安全取得特定欄位
- `window.DraftUtils.updateDraftField(draft, fieldName, newValue)` - 安全更新特定欄位
- `window.DraftUtils.hasTransferDraft(draft)` - 檢查是否有暫存資料
- `window.DraftUtils.hasProOrderDetailItems(draft)` - 檢查是否有歷史記錄
### 2. 操作範例
**更新 transfer_draft（不會影響 pro_order_detail_items）：**
```javascript
const currentDraft = this.dialog.selected.draft || '';
const newTransferDraft = this.dialog.items
.filter(item => Number(item.reconcile) > 0)
.map(item => ({
pro_order_detail_num: item.num,
reconcile: Number(item.reconcile)
}));
const newDraftObj = window.DraftUtils.updateDraftField(currentDraft, 'transfer_draft', newTransferDraft);
```
**更新 pro_order_detail_items（不會影響 transfer_draft）：**
```javascript
const currentDraft = item.draft || '';
const newDetailItems = [
{
pro_order_detail_num: "123",
reconcile: 5000,
activity_name: "法會",
actitem_name: "護持金"
}
];
const newDraftObj = window.DraftUtils.updateDraftField(currentDraft, 'pro_order_detail_items', newDetailItems);
```
**檢查是否有暫存資料：**
```javascript
if (window.DraftUtils.hasTransferDraft(item.draft)) {
console.log('有暫存資料');
}
```
**取得特定欄位：**
```javascript
const transferDraft = window.DraftUtils.getDraftField(item.draft, 'transfer_draft');
const detailItems = window.DraftUtils.getDraftField(item.draft, 'pro_order_detail_items');
```
### 3. 統一工具檔案
建立了 `draft-utils.js` 統一工具檔案，所有頁面都引用此檔案：
- 所有 draft 操作函數統一管理
- 格式驗證功能
- 向後相容性處理
- 詳細的使用範例
- 避免程式碼重複，提升維護性
### 4. 頁面引用方式
每個 `.aspx` 頁面都在 `<script>` 標籤前加入：
```html
<script src="draft-utils.js"></script>
```
然後使用 `window.DraftUtils` 來呼叫工具函數，確保所有頁面使用相同的邏輯。
### 5. 完整工具函數清單
`draft-utils.js` 提供以下工具函數：
**基本操作：**
- `getDraftObject(draft)` - 解析 draft 欄位，返回標準化物件
- `getDraftField(draft, fieldName)` - 安全取得特定欄位
- `updateDraftField(draft, fieldName, newValue)` - 安全更新特定欄位
- `clearDraftField(draft, fieldName)` - 清除特定欄位
**檢查函數：**
- `hasTransferDraft(draft)` - 檢查是否有暫存資料
- `hasProOrderDetailItems(draft)` - 檢查是否有歷史記錄
**工具函數：**
- `mergeDraftObjects(draft1, draft2)` - 合併兩個 draft 物件
- `validateDraftFormat(draft)` - 驗證 draft 格式
- `getDraftSummary(draft)` - 取得 draft 摘要資訊
- `migrateLegacyFormat(draft)` - 將舊格式轉換為新格式
- `cleanEmptyDraft(draft)` - 清理空的 draft 欄位
- `formatDraftJson(draft)` - 格式化 draft JSON 為可讀字串
## 優點
1. **職責分離** - 每個子陣列有明確的用途
2. **資料一致性** - 避免不同用途的資料互相覆蓋
3. **向後相容** - 支援舊格式，無需資料庫變更
4. **易於維護** - 程式碼邏輯更清晰
5. **擴展性** - 未來可以添加更多子陣列
6. **資料安全** - 確保各欄位操作互不影響
7. **程式碼統一** - 所有頁面使用相同的工具函數
8. **功能完整** - 提供豐富的工具函數支援各種操作需求

79
data/memo/memo-0606.txt Normal file
View File

@@ -0,0 +1,79 @@
http://localhost:33051/admin/transfer/register.aspx
法會名稱 --> 活動名稱, (或帶活動ID, 只顯示, 不選)
要有"不確定, 待查"選項, 區隔出空值
"匯款"帳號後五碼 (註明: 若無免填)
付款 -> 支付
http://localhost:33051/admin/transfer/verify.aspx
狀態:
己確認: 人/錢 , 分開
增加: 查詢功能, 狀態過濾, 期間
(經查詢, 可把作廢資料調回, 注意: 帳已完成不可回溯)
階段1: 也要輸入核對記錄, 值:共用
階段12 -> 程序1,2
2-> 2A, 2B :
2A : 有報名 (目前)
2B : 無報名 (待討論, 屬於勸募活動及一般性捐款)
"已"確認, 作廢 -> 不要"已"
--
## 11:19 🥬ྀྀི 鈺
請問複製以往報名為什麼沒有清明法會的紀錄
## 19:46 Allen Wang (王振邦)
請確認複製信眾以往報名資料，是否只會帶入信眾最近一次參加的法會
(例如沒參加今年清明法會，但有參加過去年梁皇法會，所以只出現梁皇法會)。
請再確認協助讓同仁釐清邏輯。
### 翻頁問題
## 19:55 Allen Wang (王振邦)
明日會議一樣維持10：30，討論項目如下：
1. 法會功德款收款及對帳功能進度。
2. 不是講堂法會報名，僅列印牌位的處理方式。
(稍晚再將今日齋僧大會列印牌位問題詳列)
## 20:27 Allen Wang (王振邦)
今日處理齋僧大會僅列印牌位議題說明如下：
### 一、有關處理僅列印牌位，
信眾報名法會帶入過往報名法會資料，系統功能待查問題：
1. 複製過往法會信眾報名資料，只出現信眾前次報名法會，無法彈性選擇過往法會。(確認邏輯)
2. 選擇過往法會報名信眾後，信眾的親友資料會有不完整現象。（查是否因只出現前次資料）
3. 複製過往信眾報名資料後，功德項目的牌位上功德項目與編號不要帶入，例如總功德主複製後總功德主及編號不要帶入。
4. 複製過往報名資料，牌位類型變更後，牌位內容版面需要調整，例如大牌位變更為隨喜牌位，版面需要人工修改。
### 二、基金會處理信眾報名的親友牌位資料問題：
再次重申取得信眾報名時親友稱謂是重要的，若不完整，
親屬、員工、其他等等混雜難以區分，當信眾要再次報名或只印牌位，只能人工確認，
若舊親友資料太多乾脆重建新建親友資料。
### 三、法會報名順序涉及系統功能及邏輯，
要再與各位說明清楚，目前順序如下：
1. 選擇法會
選擇要參加的法會（如果不是法會就要另建類似法會的活動）
2. 選擇功德項目
選擇要參加法會的功德項目，包含功德主及牌位類型。
3. 選擇或新建親友資料（同時校正親友存歿資料）。
### 四、有關只印牌位處理方式：
如果只要產出牌位，就不要在正常的法會報名程序處理，
目前用例行性牌位處理要再思考合理性及便利性。
---
# 因應調整:
https://demo2.eztrust.tw/17168erp_e/admin/order/reg.aspx?order_no=AA2506130012
編輯牌位 , "可選" , 加上"稱謂"
https://demo2.eztrust.tw/17168erp_e/admin/follower/reg.aspx?num=17691
親友名單, 載入
https://demo2.eztrust.tw/17168erp_e/admin/order/reg.aspx?order_no=AA2506130012
複製以往報名 : 訂單編號/牌位項目/活動: 合一欄,
加一欄:標題/陽上

41
data/memo/memo-0714.md Normal file
View File

@@ -0,0 +1,41 @@
# localhost
url: http://localhost:33051/admin/index.aspx
path: D:\dev\ez\17168erp\git_gitea\web\index.htm
sql: localhost, 17168erp_e2
# demo2: /17168erp , 測試資料, 最新DB(20250714)
sql: demo2, 17168ERP_2022
# demo2: /17168erp_e , 正式資料
sql: demo2, 17168ERP_e2
結構:待更新為最新結構
# demo2: /17168erp_t
sql: demo2, 17168ERP_t
--
#GITEE
https://git.hcu.edu.tw/user/login
yiming
XrxCAdgX3BwMc6r
----
新程式上傳:
https://demo2.eztrust.tw/17168erp_t/admin
此區: 新程式測試區, DB為新架構, 測試資料
新功能: 權限設定進行中
https://demo2.eztrust.tw/17168erp_e/admin/
此區: 正式資料, 前版程式,
等"新程式測試區"設定好, 此區更新結構, 不動現有資料
GIT:
己合併各分支於:main
最新結構不含資料:
~\data\SQL\17168_db_schema.sql
最新結構含測試資料:
另傳雲端連結給開杰
https://drive.google.com/file/d/1eefpyIdGjbQInSSDp7FrNGiFSD1sQ4q6/view?usp=sharing

218
data/memo/memo_plan_pay.md Normal file
View File

@@ -0,0 +1,218 @@
# DOCS
## files
D:\dev\ez\17168erp\git_gitea\web\admin\activity\index.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\follower\index.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\follower\reg.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\order\index.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\order\reg.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\accounting\kind_reg.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\accounting\kind_reg2.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\accounting\index.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\admin\accounting\news_reg.aspx.cs
D:\dev\ez\17168erp\git_gitea\web\App_Code\api\orderController.cs
## DESC
### 檔案主要功能說明
1. `activity/index.aspx.cs`：活動管理系統主頁，負責活動分類建立、管理及活動資料匯出Excel。
2. `follower/index.aspx.cs`：信眾管理系統主頁，負責信眾資料查詢、管理及匯出。
3. `order/index.aspx.cs`、`order/reg.aspx.cs`：訂單管理系統，負責訂單查詢與登記。
4. `accounting/index.aspx.cs`：會計系統主頁。
5. `accounting/kind_reg.aspx.cs`、`kind_reg2.aspx.cs`：會計科目分類登記。
6. `accounting/news_reg.aspx.cs`：會計相關新聞或公告登記。
系統採用 ASP.NET Web Forms 與 Entity Framework，涵蓋信眾、活動、訂單、會計等模組。
---
### 訂單收款記錄管理作業流程
1. 使用者點擊「收款紀錄」按鈕，開啟對話框並呼叫 `payOrderList2()` 載入資料。
2. 前端檢查訂單編號與明細編號，設定分頁參數，呼叫API取得收款記錄。
3. 後端API接收查詢條件，查詢 `pro_order_record`，回傳付款日期、方式、金額、機構、銀行代碼等資訊。
4. 前端以Vuetify資料表格顯示收款記錄，支援搜尋、分頁、排序。
5. 支援新增、編輯、刪除收款記錄。
6. 表格排序或分頁設定改變時自動重新載入資料。
用途：追蹤訂單收款狀況、管理多筆收款記錄、查詢與管理介面、支援多種付款方式。
---
# 功能延伸
## 信眾-登錄匯款
### TABLE結構
新增暫存表 `remittance_register_tmp`：
| 欄位名稱 | 型態 | 說明 |
|------------------|----------------|----------------------------|
| id | int, PK, AI | 主鍵，自動編號 |
| activity_id | int | 對應法會/活動ID（可選） |
| name | nvarchar(50) | 姓名/暱稱/法號 |
| phone | nvarchar(30) | 聯絡電話 |
| pay_type | nvarchar(20) | 付款方式（現金/匯款等） |
| account_last5 | nvarchar(10) | 帳號後五碼 |
| amount | decimal(12,2) | 付款金額 |
| pay_mode | nvarchar(10) | 付款型態（個人/共同） |
| note | nvarchar(200) | 備註 |
| proof_img | nvarchar(200) | 憑證圖檔路徑 |
| status | nvarchar(20) | 狀態（待核對/已入帳/作廢） |
| create_time | datetime | 建立時間 |
| verify_time | datetime | 核對/入帳時間 |
| verify_user | nvarchar(50) | 核對人員 |
| verify_note | nvarchar(200) | 核對說明 |
| recaptcha_token | nvarchar(200) | reCAPTCHA驗證（可選） |
---
### 畫面設計說明
1. 進入方式：法會/活動頁面連結或QRcode進入，可帶入活動ID參數。
2. 表單欄位：姓名（可匿名/暱稱/法號）、電話、付款方式、帳號後5碼、付款金額、付款型態、備註、匯款憑證上傳、reCAPTCHA驗證。
3. 操作流程：填寫表單送出，資料以JSON送API，成功後顯示訊息或QRcode，所有資料進入暫存表，不直接入帳，後台人工核對後正式入帳。
4. 設計重點：手機友善、圖片上傳、送出後明確回饋、不強制檢查資料正確性但利於後續人工核對、加reCAPTCHA防灌單。
---
## 核對入帳資訊
### TABLE結構說明
主表 `remittance_check`，記錄每筆待核對與已核對入帳資料。
| 欄位名稱 | 型態 | 說明 |
|------------------|----------------|----------------------------------------|
| id | int, PK, AI | 主鍵，自動編號 |
| tmp_id | int | 對應暫存登錄表（remittance_register_tmp）的ID |
| match_signup_id | int | 自動或人工比對到的報名信眾ID |
| match_status | nvarchar(20) | 比對狀態（自動/人工/未比對） |
| pay_type | nvarchar(20) | 付款方式（登錄資料） |
| account_last5 | nvarchar(10) | 帳號後五碼（登錄資料） |
| amount | decimal(12,2) | 付款金額（登錄資料） |
| payer_name | nvarchar(50) | 付款人/登錄人（登錄資料） |
| phone | nvarchar(30) | 電話（登錄資料） |
| proof_img | nvarchar(200) | 憑證圖檔路徑 |
| check_amount | decimal(12,2) | 實際入帳金額（出納填寫） |
| check_date | datetime | 入帳日期（出納填寫） |
| check_type | nvarchar(20) | 入帳方式（出納填寫） |
| check_note | nvarchar(200) | 入帳備註（出納填寫） |
| status | nvarchar(20) | 狀態（待核對/已確認/無效/沖帳） |
| create_time | datetime | 建立時間 |
| update_time | datetime | 最後更新時間 |
| verify_user | nvarchar(50) | 核對人員 |
---
### 畫面設計說明
1. 資料來源與自動比對：左側顯示信眾登錄匯款資訊，系統自動比對報名信眾，結果顯示於DE欄，若失敗可手動選擇。
2. 付款資訊與核對欄位：F~J欄顯示報名者填寫的付款資訊，K~O欄由出納填寫實際入帳資料。
3. 核對狀態管理：O欄標註「確認」或「無效」後，該筆資料完成核對，下次不再顯示，未完成資料持續顯示。
4. 輔助說明與操作提示：下方提供人工核對重點、注意事項、歷史紀錄查詢、憑證比對等輔助說明，支援人工補正、標註特殊狀況。
5. 沖帳與分攤明細：支援沖帳與分攤金額明細管理，方便人工確認。
---
## 個人-沖帳流程
### TABLE結構說明
沖帳結果寫入 `pro_order_record`：
| 欄位名稱 | 型態 | 說明 |
|------------------|----------------|----------------------------------------|
| num | int, PK, AI | 主鍵，自動編號 |
| detail_num | int | 對應訂單明細（pro_order_detail）的ID |
| price | decimal(12,2) | 沖帳金額 |
| payment | int | 付款方式（對應會計科目細分類ID） |
| reg_time | datetime | 沖帳登記時間 |
| pay_date | datetime | 實際付款日期 |
| organization | nvarchar(100) | 匯款機構/銀行名稱 |
| bank_code | nvarchar(20) | 銀行代碼 |
| status | nvarchar(20) | 狀態（有效/作廢等） |
| note | nvarchar(200) | 備註 |
---
### 畫面設計說明
1. 信眾沖帳清單：左側顯示所有待沖帳信眾及其入帳金額與沖帳狀態，點選信眾後彈出沖帳分配視窗。
2. 彈窗內容：顯示信眾所有有報名但尚未完成繳費的項目清單，可自動分配入帳金額，也可人工調整分攤金額，支援部分繳費、溢繳、未繳等情境，並即時顯示分攤結果。
3. 沖帳操作：可調整每個項目的沖帳金額，總金額需與入帳金額一致才能送出，確認後寫入 `pro_order_record`，完成核銷，沖帳完成後狀態更新避免重複處理。
4. 輔助說明與彈性設計：下方提供沖帳規則、人工調整注意事項、分攤原則等輔助說明，支援查詢歷史沖帳紀錄。
---
# TABLE CREATE SQL
```
-- 信眾-登錄匯款暫存表
CREATE TABLE remittance_register_tmp (
id INT IDENTITY(1,1) PRIMARY KEY COMMENT '主鍵，自動編號',
activity_id INT NULL COMMENT '對應法會/活動ID（可選）',
name NVARCHAR(50) NOT NULL COMMENT '姓名/暱稱/法號',
phone NVARCHAR(30) NULL COMMENT '聯絡電話',
pay_type NVARCHAR(20) NOT NULL COMMENT '付款方式（現金/匯款等）',
account_last5 NVARCHAR(10) NULL COMMENT '帳號後五碼',
amount DECIMAL(12,2) NOT NULL COMMENT '付款金額',
pay_mode NVARCHAR(10) NOT NULL COMMENT '付款型態（個人/共同）',
note NVARCHAR(200) NULL COMMENT '備註',
proof_img NVARCHAR(200) NULL COMMENT '憑證圖檔路徑',
status NVARCHAR(20) NOT NULL DEFAULT '待核對' COMMENT '狀態（待核對/已入帳/作廢）',
create_time DATETIME NOT NULL DEFAULT GETDATE() COMMENT '建立時間',
verify_time DATETIME NULL COMMENT '核對/入帳時間',
verify_user NVARCHAR(50) NULL COMMENT '核對人員',
verify_note NVARCHAR(200) NULL COMMENT '核對說明',
recaptcha_token NVARCHAR(200) NULL COMMENT 'reCAPTCHA驗證（可選）'
);
-- 入帳核對主表
CREATE TABLE remittance_check (
id INT IDENTITY(1,1) PRIMARY KEY COMMENT '主鍵，自動編號',
tmp_id INT NOT NULL COMMENT '對應暫存登錄表（remittance_register_tmp）的ID',
match_signup_id INT NULL COMMENT '自動或人工比對到的報名信眾ID',
match_status NVARCHAR(20) NOT NULL DEFAULT '未比對' COMMENT '比對狀態（自動/人工/未比對）',
pay_type NVARCHAR(20) NOT NULL COMMENT '付款方式（登錄資料）',
account_last5 NVARCHAR(10) NULL COMMENT '帳號後五碼（登錄資料）',
amount DECIMAL(12,2) NOT NULL COMMENT '付款金額（登錄資料）',
payer_name NVARCHAR(50) NULL COMMENT '付款人/登錄人（登錄資料）',
phone NVARCHAR(30) NULL COMMENT '電話（登錄資料）',
proof_img NVARCHAR(200) NULL COMMENT '憑證圖檔路徑',
check_amount DECIMAL(12,2) NULL COMMENT '實際入帳金額（出納填寫）',
check_date DATETIME NULL COMMENT '入帳日期（出納填寫）',
check_type NVARCHAR(20) NULL COMMENT '入帳方式（出納填寫）',
check_note NVARCHAR(200) NULL COMMENT '入帳備註（出納填寫）',
status NVARCHAR(20) NOT NULL DEFAULT '待核對' COMMENT '狀態（待核對/已確認/無效/沖帳）',
create_time DATETIME NOT NULL DEFAULT GETDATE() COMMENT '建立時間',
update_time DATETIME NULL COMMENT '最後更新時間',
verify_user NVARCHAR(50) NULL COMMENT '核對人員'
);
-- 個人沖帳紀錄表
CREATE TABLE pro_order_record (
num INT IDENTITY(1,1) PRIMARY KEY COMMENT '主鍵，自動編號',
detail_num INT NOT NULL COMMENT '對應訂單明細（pro_order_detail）的ID',
price DECIMAL(12,2) NOT NULL COMMENT '沖帳金額',
payment INT NOT NULL COMMENT '付款方式（對應會計科目細分類ID）',
reg_time DATETIME NOT NULL DEFAULT GETDATE() COMMENT '沖帳登記時間',
pay_date DATETIME NULL COMMENT '實際付款日期',
organization NVARCHAR(100) NULL COMMENT '匯款機構/銀行名稱',
bank_code NVARCHAR(20) NULL COMMENT '銀行代碼',
status NVARCHAR(20) NOT NULL DEFAULT '有效' COMMENT '狀態（有效/作廢等）',
note NVARCHAR(200) NULL COMMENT '備註'
);
```
# HTML 檔名及路徑規劃
| 功能 | 建議檔名/路徑 | 說明 |
|----------------------|----------------------------------------------------|--------------------------|
| 信眾-登錄匯款 | `/web/transfer/register.html` | 信眾匯款登錄前台 |
| 核對入帳資訊 | `/web/admin/finance/remit_check.html` | 後台入帳核對作業 |
| 個人-沖帳流程 | `/web/admin/finance/personal_offset.html` | 後台個人沖帳分攤 |
| 共同-沖帳流程 | `/web/admin/finance/group_offset.html` | 後台多人/批次沖帳 |
| 訂單收款紀錄 | `/web/admin/order/reg.aspx` | 現有訂單收款紀錄 |
前台頁面可用 `.html` 或 `.aspx`，依現有架構調整。後台建議統一於 `/web/admin/finance/` 目錄下，便於管理。API建議集中於 `/web/App_Code/api/`。

299
data/memo/共同-沖帳流程.md Normal file
View File

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

45
data/memo/掛單區樓層範例.json Normal file
View File

@@ -0,0 +1,45 @@
{
"東區": {
"慈悲樓": {
"慈悲樓1F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"慈悲樓2F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"慈悲樓3F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"慈悲樓4F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"慈悲樓5F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"]
},
"智慧舍": {
"智慧舍1F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"智慧舍2F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"智慧舍3F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"智慧舍4F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"智慧舍5F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"]
},
"禪悅樓": {
"禪悅樓1F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"禪悅樓2F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"禪悅樓3F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"禪悅樓4F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"],
"禪悅樓5F": ["R01", "R02", "R03", "R04", "R05", "R06", "R07", "R08", "R09", "R10", "R11", "R12", "R13", "R14", "R15", "R16", "R17", "R18", "R19", "R20"]
}
},
"西區": {
"淨心樓": { "淨心樓1F": [...], "淨心樓2F": [...], "淨心樓3F": [...], "淨心樓4F": [...], "淨心樓5F": [...] },
"安忍舍": { "安忍舍1F": [...], "安忍舍2F": [...], "安忍舍3F": [...], "安忍舍4F": [...], "安忍舍5F": [...] },
"悲願樓": { "悲願樓1F": [...], "悲願樓2F": [...], "悲願樓3F": [...], "悲願樓4F": [...], "悲願樓5F": [...] }
},
"南區": {
"寧靜樓": { "寧靜樓1F": [...], "寧靜樓2F": [...], "寧靜樓3F": [...], "寧靜樓4F": [...], "寧靜樓5F": [...] },
"法雨舍": { "法雨舍1F": [...], "法雨舍2F": [...], "法雨舍3F": [...], "法雨舍4F": [...], "法雨舍5F": [...] },
"覺林樓": { "覺林樓1F": [...], "覺林樓2F": [...], "覺林樓3F": [...], "覺林樓4F": [...], "覺林樓5F": [...] }
},
"北區": {
"圓滿樓": { "圓滿樓1F": [...], "圓滿樓2F": [...], "圓滿樓3F": [...], "圓滿樓4F": [...], "圓滿樓5F": [...] },
"正念舍": { "正念舍1F": [...], "正念舍2F": [...], "正念舍3F": [...], "正念舍4F": [...], "正念舍5F": [...] },
"法華樓": { "法華樓1F": [...], "法華樓2F": [...], "法華樓3F": [...], "法華樓4F": [...], "法華樓5F": [...] }
},
"中區": {
"福慧樓": { "福慧樓1F": [...], "福慧樓2F": [...], "福慧樓3F": [...], "福慧樓4F": [...], "福慧樓5F": [...] },
"慈恩舍": { "慈恩舍1F": [...], "慈恩舍2F": [...], "慈恩舍3F": [...], "慈恩舍4F": [...], "慈恩舍5F": [...] },
"妙樂樓": { "妙樂樓1F": [...], "妙樂樓2F": [...], "妙樂樓3F": [...], "妙樂樓4F": [...], "妙樂樓5F": [...] }
}
}