# 04 — วิเคราะห์เชื่อมโยงทั้งหมด + ประเมินความเป็นไปได้ ("ทำได้ครบหรือไม่")

> วิเคราะห์จาก: โจทย์ POC (`01-...md`) · API doc (`02-...md`) · เอกสารเคสจริง (`03-...md`)

## 1. ระบบ/ชิ้นส่วนทั้งหมดเชื่อมกันอย่างไร

| ชิ้นส่วน | บทบาท | หลักฐาน |
|---|---|---|
| **Maycur (每刻)** | ระบบต้นทางที่พนักงานยื่นเรื่องเบิก/报销 — รหัส flow เช่น `DGTL26041869` | โจทย์ xlsx + ใบกำกับที่ถูก upload เข้าระบบ (rc-upload-*.pdf ใน pdf_11) |
| **Sanhua OA** (`oa-new.sanhuagroup.com`) | ระบบอนุมัติภายในของ Sanhua (report approval + 逾期报销流程) | pdf_11 พิมพ์จาก OA · ฟอร์ม 报告审批单 ทุกใบ |
| **Maycur Open API** | ช่องทางให้ AI ดึงข้อมูลจาก Maycur อัตโนมัติ | `03 API.docx` (endpoints + appCode/appSecret, token 30 นาที) |
| **เอกสาร 9 ชุด (Test Documents)** | วัตถุดิบทดสอบของโจทย์ — 9 กระบวนการ | โฟลเดอร์ `02 测试文件-Test Documents\` |
| **Manuel.AI** | ผู้พัฒนา POC — pipeline อ่าน/สกัด/ตรวจสอบ | โปรเจ็คนี้ |

### วงจรเอกสารของเคส #8 (`DGTL26041869` — 行政-家具采购)

```
[อนุมัติจัดซื้อ]
 pdf_01 C栋 635,537 THB (2025-12-19)
 pdf_07 精测室 102,968 CNY (2025-09-23)
 pdf_10 试验室 154,250 CNY (2025-09-26)
        ↓
[เทียบราคา/คัดเลือกผู้ขาย]
 pdf_03 ใบเสนอราคาเดิม D&R (~88,358)
 pdf_04 เทียบ 京东/D&R/光明 → D&R 82,090 → 97折 79,627 (2026-02-10)
 pdf_08 双层柜: D&R 47,520 → 46,094.40 vs 光明 50,080 (2026-03-10/12)
        ↓
[ใบกำกับ]
 pdf_05 TI-6902023 = 89,201.23  ┐
 pdf_06 TI-6902024 = 201,342.92 ┘ รวม 290,544.15 THB (20/02/2026)
        ↓
[ใบลดหนี้]  pdf_02 CN6903002 = 3,026.42 · CN6903003 = 776.04 (31/03/2026)
        ↓
[ทรัพย์สิน]  pdf_09 石英石平台 BG20260005 = 35,682.24 THB
        ↓
[การเบิก]   pdf_11 OA 逾期报销 62 วัน → ยอดเบิก 290,544.15 THB = 58,108.83 CNY (30/07/2026)
```

## 2. สิ่งที่ตรวจสอบได้จริงจากเคสนี้ (ตัวอย่างที่พิสูจน์แล้ว)

| การตรวจ | ผล | หลักฐาน |
|---|---|---|
| ชื่อผู้รับใบกำกับ vs 引用1 | ✓ ตรง (สาขา 00001 ชลบุรี, Tax ID 0215567014145) | TI-6902023/24 (pdf_05/06) |
| คำนวณส่วนลด 3% + VAT 7% | ✓ ตรวจได้ครบทั้ง 2 ใบ | 85,943.95→83,365.63→89,201.23 · 193,990.67→188,170.95→201,342.92 |
| ยอดข้ามระบบ (ใบกำกับ ↔ OA) | ✓ ตรงกัน + FX 5.0 | pdf_11: 290,544.15 THB = 58,108.83 CNY |
| เอกสารอนุมัติ/เทียบราคา | ✓ มีครบตามโจทย์ข้อ 8 | pdf_01/04/07/08/10 |
| หา "ใบกำกับซ้ำ" | ⚠️ ต้องแยกสำเนา (3 ชุด/ใบ) ออกจากเบิกซ้ำจริง | pdf_05/06 + คู่ folder `DGTL26071314 - 1` |
| CN กับยอดเบิก | ⚠️ ยอดเบิกยังใช้ยอดเต็มก่อนหัก CN | pdf_02 vs pdf_11 |

## 3. ตอบคำถาม: "จากโจทย์ test ที่ให้มา ทำได้ครบหรือไม่"

**คำตอบสั้น: ทำได้ครบในระดับ POC (offline จากเอกสารที่มี) — สาธิตได้ทันทีด้วยเครื่องมือปัจจุบัน; ระดับ production/integration ต้องเติม 2 อย่าง (credential + กฎคู่มือฉบับเต็ม) และมี 3 จุดที่ควรตั้งกลไก human-review**

### ✅ ทำได้แล้ว / พร้อมทำ (พิสูจน์แล้วบางส่วน)

- **อ่าน+เข้าใจเอกสารทุกแบบ**: สแกนจีน/ไทย/อังกฤษ, ถ่ายรูป CamScanner, PDF export — อ่านครบ 30/30 หน้า + ภาพฝัง xlsx 7 ภาพ ด้วย vision (พิสูจน์แล้วในโปรเจ็คนี้)
- **สกัดข้อมูลเป็นโครงสร้าง**: เลขใบกำกับ, ชื่อ/เลขภาษีนิติ, ยอด (ก่อน/หลังส่วนลด, VAT, รวม), วันที่, ลายเซ็น — ทำได้ต่อเอกสาร
- **ตรวจตามโจทย์ข้อ 1–3**: ชื่อผู้รับ (2 นิติ), คำนวณยอด, ใบกำกับซ้ำ, เอกสารครบตาม checklist, สถิติ VAT
- **เอกสารครบทุก flow**: ทั้ง 9 โฟลเดอร์มีไฟล์ครบตามที่โจทย์ระบุไว้ว่า "涉及附件" (ตรวจ inventory แล้ว)

### ⚠️ ข้อจำกัด / ต้องเตรียมเพิ่ม

| # | ประเด็น | ผลกระทบ | ทางแก้ |
|---|---|---|---|
| 1 | **ยังไม่มี Maycur credential (appCode/appSecret) + ยืนยัน env** | ต่อ API จริง/UAT ตอนนี้ไม่ได้ | ขอจากลูกค้า; ระหว่างนี้ใช้ offline replay จากชุดเอกสาร |
| 2 | **คู่มือ threshold ใน引用2 เป็น "ตัดตอน"** (เฉพาะงาน动力设备/EHS/行政 >10万) | ตรวจ "ลายเซ็นครบตามวงเงิน" ครบทุกกรณีไม่ได้ | ขอคู่มือฉบับเต็ม (หรือ matrix วงเงิน×ผู้อนุมัติของแต่ละนิติ) |
| 3 | **ลายเซ็น/ตัวเลขเขียนมือ** อ่านได้ไม่ 100% (เช่น ชื่อ pdf_10, ปี 2024/2025 ใน pdf_07) | เสี่ยง false positive/negative ในผลตรวจ | confidence score + human-in-the-loop สำหรับเคส low-confidence |
| 4 | **WHT (预扣税) ยังไม่พบในชุดนี้** | ตรวจสถิติ WHT ไม่ได้จากเคส #8 | เปิดดู flow กลุ่มบริการ (ค่าขนส่ง/ค่าเช่า) ในชุดอื่น; ยืนยันกับลูกค้า |
| 5 | **สกุลเงินผสม (THB/CNY) + รูปแบบไฟล์หลากหลาย** | ต้อง normalize ก่อนคำนวณ | กำหนด JSON schema + นโยบาย FX (เคสนี้ใช้ 5.0) ล่วงหน้า |
| 6 | **ยังไม่ได้เปิดอ่านอีก 8 flow โดยละเอียด** (มี inventory ครบ) | ยังไม่ validate ขั้นละเอียดของส่วนที่ 1 (3 flows) | เฟสถัดไป: รัน pipeline เดียวกันทุก flow — เทคนิคใช้ชุดเดิมได้ |
| 7 | **报关单/B/L (โจทย์ 2.2 a,c) ยังไม่ตรวจในเอกสาร** | ต้องดูใน `DGTL26071314` (SHHSIDT260416Y = 报关单?) | เปิดอ่านโฟลเดอร์ DGTL26071314 ในเฟสถัดไป |

### 🎯 ข้อเสนอสำหรับ POC demo (ขั้นถัดไปแบบเป็นรูปธรรม)

1. **ขอ**: `appCode`/`appSecret` + ยืนยัน env (PROD www/www2 หรือ UAT) + คู่มือ threshold ฉบับเต็ม + รูปแบบรายงานที่ลูกค้าต้องการ
2. **สร้าง pipeline**: 
   - Fetch: Maycur API (flows + attachments) — หรือโหมด folder scan สำหรับ replay
   - Convert: PDF→PNG (PyMuPDF 200–300 DPI) · xlsx: unzip DISPIMG
   - Extract (AI vision → JSON schema): ประเภทเอกสาร, นิติ, Tax ID, เลขใบกำกับ, วันที่, ยอด net/VAT/WHT/total, รายการ, ลายเซ็น/ผู้อนุมัติ, หมายเหตุเขียนมือ
   - Rules: title match (fuzzy) · amount recompute · duplicate invoice (ข้าม flow) · approval completeness vs threshold · docs checklist (合同/验收单/报关单) · CN reconcile · tax stats
   - Report: รายงานต่อ flow (issues + confidence) + dashboard สรุป VAT/WHT/ซ้ำ
3. **Demo flow แรก**: `DGTL26041869` (วัสดุพร้อม 100% — ใช้เอกสารในโฟลเดอร์นี้สาธิตได้เลย) → จากนั้น scale ไปทั้ง 9 เคส
4. **ตัวชี้วัด POC**: % เอกสารที่อ่าน/สกัดสำเร็จ, จำนวน issues ที่ตรวจพบ (ซ้ำ/ยอดผิด/ลายเซ็นขาด), เวลาที่ประหยัดเทียบ manual

## 4. ข้อสังเกตที่ควรแจ้งลูกค้า (จากเคสจริง)

- ยอดเบิกใน OA (290,544.15 THB) ยังไม่หักใบลดหนี้ CN รวม 3,802.46 THB → ยืนยันนโยบายการปรับปรุง
- **CN เป็นแบบ aggregate-only** (ปรับที่ยอดสรุปอย่างเดียว ไม่ระบุการลดรายบรรทัด + เหตุผล "บอกรายการสินค้าผิด" ขัดกับเนื้อหาที่ซ้ำใบกำกับ 100%) → ควรขอเอกสารที่มาของส่วนต่าง และระบบไม่ควรพยายาม allocate เอง (ดู 05-Q3)
- เอกสารอนุมัติออกโดยนิติในจีน (浙江三花/绍兴三花) แต่ค่าใช้จ่ายอยู่ที่โรงงานไทย → ควรกำหนดว่าตรวจ approval ของนิติใด
- พบความต่อเนื่องของวันที่ผิด (pdf_07: เอกสาร 2025.9.23 แต่ลายเซ็นเขียน 2024.09.24) → ระบบควร flag ความผิดปกติของวันที่
- ไฟล์แนบชื่อไม่สื่อ (getCorsFile, rc-upload-*) ตามที่โจทย์เตือน → ต้อง classify ประเภทเอกสารจากเนื้อหาเท่านั้น

---

## 5. ผลทดสอบจริง: Extract → ตรวจไขว้ (Test-Demo · 2026-09-17)

สร้างตาราง extract 6 ชุดจากเอกสารจริง (11 ไฟล์) และรันชุดตรวจไขว้ 18 รายการ → **PASS 11 · FLAG 6 · N/A 1**
(ไฟล์ผลลัพธ์: `test-demo/sanhua_extract.xlsx` + CSV 6 ไฟล์ · เทมเพลต: `test-demo/00-template-and-schema.md`)

| ผล | รายการ |
|---|---|
| **PASS (11)** | ชื่อผู้ซื้อตรง引用1 · คำนวณ 3%+VAT ใหม่ทั้ง 2 ใบ · ผลรวมรายบรรทัด · CN math+refs · ยอด 2 ใบ = OA 290,544.15 · FX = 5.0000 · ราคา SKU ซ้ำตรงกัน · สถิติ VAT 19,007.57 / สุทธิ 271,536.58 · ความครบของชุดเอกสาร |
| **FLAG (6)** | CN 3,802.46 ไม่หักจากยอดเบิก · `TH-` vs `TI-6902024` · ลายเซ็นเขียนปี 2024 · ช่องการเงินว่าง · CN aggregate-only · ผู้รับ CN ไม่เซ็น |
| **N/A (1)** | WHT — ไม่มีในเคสซื้อสินค้า (ส่วนลด 3% เป็น discount ไม่ใช่ WHT) |

- **ยืนยัน**: pipeline "import → extract → ตรวจไขว้" ทำงานกับข้อมูลจริงครบทุกข้อตามโจทย์ และเป็น **เทมเพลตเดียวใช้ซ้ำได้กับทุก flow** (คิวทดสอบถัดไป: `DGTL26071314` ที่มี B/L + Freight Invoice + 报关单)
- รายละเอียดบนคู่มือ: section "จำลองเทสจริง" ใน `index.html` · implementation pattern เดียวกับ demo เดิม: `src/cases/sanhua/` (+ `src/data/sanhua/`) — `npx tsc --noEmit` ผ่าน (รอลงทะเบียนเข้า App)