Sangwijit Portal

Sangwijit ERP Web Portal Skill — Knowledge Base (v2.1)

Last Updated: เมษายน 2026 เจ้าของโปรเจกต์: Peerapat (พีรพัฒน์) — GM, กลุ่มแสงวิจิตร ธุรกิจ: จำหน่ายเครื่องใช้ไฟฟ้า (ยอดขาย 450M+/ปี) — ค้าปลีก, ค้าส่ง, ส่งออก, ศูนย์บริการ Reference Folder: /Design Ai/ ใน Workspace

⚙️ กฎการทำงาน (RULES — บังคับทุกครั้ง)

Rule 1: อ่าน Flowchart ก่อนออกแบบทุก Module

ก่อนออกแบบหน้าจอ หรือเขียน Spec ใด ๆ ต้องอ่าน Flowchart ที่เกี่ยวข้องจาก folder ก่อนเสมอ

Flow Design Folder: /Design Ai/Flow Design/

ขั้นตอนการอ่านก่อนออกแบบ:

1. ระบุ Module ที่จะทำ
2. เปิด Flow PDF ที่เกี่ยวข้องจาก subfolder ด้านบน
3. ทำความเข้าใจ Status Flow + BC365 Entity ใน Flow
4. ตรวจ Document Template PDF (ถ้ามี) เพื่อดู Field ที่ต้องแสดง
5. จึงเริ่ม Spec / Screen Design

Rule 2: ไฟล์ซ้ำ — ถามก่อนเสมอ

ถ้าพบว่า folder มีไฟล์ชื่อคล้ายกันหรือเลขซ้ำกัน ต้องหยุด เปรียบเทียบ และถามผู้ใช้ก่อน ห้ามเลือกเองโดยไม่แจ้ง

ไฟล์ซ้ำที่ตัดสินใจแล้ว (ห้ามถามซ้ำ):

🧠 Mental Model ที่ถูกต้อง (CRITICAL — อ่านก่อนทุกอย่าง)

Portal = UI Layer เท่านั้น — BC365 = System of Record

User (Browser)
    ↓
Sangwijit Web Portal  ← React/Vue + TypeScript + Tailwind CSS
    ↓ REST API
BC365 Business Central ← Ledger, Posting, Stock, Document Number
    ↓
Azure / SQL (BC Database)

WRONG (ห้ามคิดแบบนี้):

• ❌ Portal มี Database ของตัวเอง (ไม่มี — ดึงข้อมูลจาก BC ทั้งหมด)
• ❌ Portal Post Transaction เองโดยไม่ผ่าน BC
• ❌ UI ออกแบบอิสระโดยไม่ดู BC Entity / Field

CORRECT:

• ✅ Portal = Smart Frontend + Workflow Engine ที่ call BC REST API
• ✅ ทุก Post / Confirm → ส่งไป BC แล้วค่อย Refresh หน้าจอ
• ✅ Status, เลขที่เอกสาร, ราคา → มาจาก BC เสมอ

Service Account Strategy

• ใช้ BC Service Account 1 บัญชี (ลดค่า License)
• Portal ทำ RBAC เอง (ไม่พึ่ง BC Permission ต่อ User)
• Retry + Queue เมื่อ BC API ช้าหรือ Error

📦 Modules Overview

9 Core Modules + Extensions (v2.1 — Confirmed)

กฎแยก Master Data vs System Config:

• Master Data (MD) = ข้อมูลอ้างอิงที่ User สร้างขึ้น (Item, Customer, Vendor, Employee, Branch)
• System Config (CF) = ตั้งค่าระบบโดย Admin (Tax Code, Number Series, Posting Group, Bin Policy)
• Promotion Scheme อยู่ใน Promotion module ไม่ใช่ Config → เพราะเกี่ยวข้องกับ Business Logic การขาย

🎨 UI Design Principles (7 หลักการ — ห้ามละเมิด)

1. BC-First Data — ทุก Field ต้องมาจาก BC Entity ที่ระบุในเอกสาร
2. Progressive Disclosure — แสดงข้อมูลตาม Role และ Context
3. Status-Driven UI — สีและ ActionBar เปลี่ยนตาม Document Status เสมอ
4. Shared Component First — ดู SC1-SC9 ก่อนสร้าง Component ใหม่
5. Bilingual Ready — ทุก Label มี Key ทั้งไทยและอังกฤษ
6. Error Recovery — ทุก API Error ต้องมี User-readable Message + Retry
7. RBAC Everywhere — Field, Button, Route ต้องเช็ค Permission

📐 ERP Transaction Form — Standard Structure (7 Sections)

ห้ามเปลี่ยนลำดับ Section เด็ดขาด

┌─────────────────────────────────────────────────┐
│  1. PAGE HEADER                                  │
│     Module Title | Document Type | Status Badge  │
│     Breadcrumb | Action Bar (context-sensitive)  │
├─────────────────────────────────────────────────┤
│  2. DOC HEADER                                   │
│     Document No. | Date | Reference | Branch     │
│     (Read-only ถ้า Posted/Confirmed)             │
├─────────────────────────────────────────────────┤
│  3. PARTY                                        │
│     SC1/CustomerSearch หรือ Vendor Search        │
│     Auto-fill: Price Group, Credit, Address      │
├─────────────────────────────────────────────────┤
│  4. LINE ITEMS                                   │
│     SC2/ItemSearch | Qty | Price | Discount | VAT│
│     Serial Panel (SC8) | Inline Edit | Add Row   │
├─────────────────────────────────────────────────┤
│  5. TABS (ตามประเภทเอกสาร)                      │
│     Payment | Delivery | Reference | Notes | Log │
├─────────────────────────────────────────────────┤
│  6. SUMMARY                                      │
│     Subtotal | Discount | VAT 7% | Total (THB)   │
│     Deposit Applied | Net Due                    │
├─────────────────────────────────────────────────┤
│  7. ACTION BAR (ล่าง — sticky)                  │
│     ปุ่มตาม Status + Role Permission             │
└─────────────────────────────────────────────────┘

ActionBar Modes ตาม Status

🏷️ Status System — สีมาตรฐาน (ห้ามใช้สีอื่น)

🔧 Shared Components SC1-SC9 (Full Spec)

ตาราง Usage Matrix — 130+ Screens (v2.1)

SC1 — SharedCustomerSearch

Search Fields (v2 — เพิ่มจากเดิม):
  รหัสลูกค้า, ชื่อ (TH), นามสกุล (TH), ชื่อ (EN), เบอร์โทร, Email,
  เลขผู้เสียภาษี, รหัสบัตรประชาชน (ID Card), ที่อยู่ (partial search)

Filter:
  ประเภทลูกค้า: บุคคลธรรมดา / นิติบุคคล / ราชการ / Walk-in
  กลุ่มลูกค้า:  ค้าปลีก / ค้าส่ง / ดีลเลอร์ / ออนไลน์
  กลุ่มราคา:    A / B / C / VIP (Price List Group)
  สาขาที่สังกัด: HQ / สาขา 1 / สาขา 2 / ...
  สถานะ:        Active / Blocked / Overdue
  มียอดค้าง:    All / มี AR ค้าง / ไม่มี

Search:   Real-time ≥ 2 ตัวอักษร; Keyboard + ID Card Scan (Post GoLive)
Result:   รหัส, ชื่อ-นามสกุล, ประเภท, กลุ่มราคา, วงเงิน, คงเหลือ, เบอร์, สาขา, Overdue Badge
Auto-fill: Party Section + ดึง Price List/โปร ตามกลุ่มลูกค้า
Blocked:  สถานะ Blocked → Warning + ขออนุมัติก่อนเปิดบิล (ห้ามผ่าน)
Quick-Create: สร้างลูกค้าใหม่จาก popup (Draft status, รอ KYC ภายหลัง)
Customer 3 Address: ที่อยู่บัตรปชช / ที่อยู่จัดส่ง / ที่อยู่ออกใบกำกับ
API:  GET /customers?$filter=..., GET /customers/{id}, POST /customers

SC2 — SharedItemSearch

Search Fields (v2 — เพิ่มจากเดิม):
  รหัสสินค้า, ชื่อ (TH), ชื่อ (EN), ยี่ห้อ/แบรนด์, รุ่น/Model, Barcode/QR

Filter:
  หมวดสินค้า:    แอร์ / พัดลม / เครื่องซักผ้า / ตู้เย็น / TV / เครื่องครัว / อื่นๆ
  ยี่ห้อ/แบรนด์:  Daikin / Mitsubishi / Samsung / LG / Toshiba / ...
  ช่วงราคา:      0-5K / 5K-15K / 15K-50K / 50K+
  สถานะ:         Active / Discontinued / Pending
  สต็อก:         All / มี Stock > 0 / หมดสต็อก / สต็อกต่ำ (< Min)
  สาขา/คลัง:     เฉพาะคลังที่ระบุ (Stock by Location)
  Serial Flag:   All / มี Serial / ไม่มี Serial

Search:   Keyboard + Barcode Scan; แสดงสต๊อก real-time แยกตามคลัง
Result:   รหัส, ชื่อ, หมวด, ยี่ห้อ, รุ่น, UOM, ราคาตามกลุ่มลูกค้า, สต๊อก, สต๊อกจอง, Serial Flag
Alt Items: แสดงสินค้าทดแทน + Bundle แนะนำเมื่อสต๊อกหมด
Serial:   Serial Flag = true → เปิด SC8 อัตโนมัติใน line
Inline Edit: แก้ไขข้อมูล line ได้เลย ห้ามใช้ Popup
Import/Export: Serial No. Import/Export CSV ที่ระดับ Line
API:  GET /items?$expand=itemVariants, GET /items/{id}/stockByLocation
      GET /priceLists?customerId=&date=
      GET /itemCategories → ดึงหมวดสินค้า

SC3 — SharedPaymentPanel

ยอด:     ยอดสุทธิ, ยอดมัดจำที่หัก, ยอดคงเหลือ, VAT, ส่วนลดท้ายบิล
VAT Options: รวม VAT / ไม่รวม VAT / ไม่แสดง VAT (กลมยอด) — เลือกต่อเอกสาร
วิธีชำระ: เงินสด, โอน, เช็ค, บัตรเครดิต/เดบิต, QR Payment, เครดิต, บางส่วน
Split:   เลือกหลายวิธีต่อบิลได้ (split payment)
เครดิต:  ตรวจวงเงิน real-time → เกิน → Auto trigger Approval Flow
Status:  ยังไม่ชำระ / ชำระบางส่วน / ชำระครบ / เกินกำหนด / รออนุมัติวงเงิน

QR Payment (2 layers) — EMVCo PromptPay via Biller ID (SWT):
  • ชั้น 1 — Invoice QR  : Ref1 = เลขที่บิล, ยอด fix → ลูกค้าจ่ายตรงบิลเดียว
  • ชั้น 2 — Customer QR : Ref1 = รหัสลูกค้า, ยอด open/ค้างรวม/ระบุ
    → ส่งลูกค้าทาง LINE, จ่ายได้หลายบิลพร้อมกัน, แยก FI-1Q Apply Queue
  • เงินเข้า → bank statement → IA-Q sync → URC → FI-1Q Queue → auto-apply

SC4 — SharedDeliveryPanel

จัดส่ง: ที่อยู่จัดส่ง, ผู้รับ, เบอร์, วันที่-ช่วงเวลา, วิธีจัดส่ง
ติดตั้ง: ต้องการติดตั้ง (Y/N) → auto-create Service Work Order หลัง Post
Status:  รอจัดส่ง → กำลังจัดส่ง → ส่งแล้ว → ติดตั้งเสร็จ
QR Track: ลูกค้าดูสถานะผ่าน QR Code บนใบเสร็จ

SC5 — SharedDocRefPanel

ดึงเอกสาร: แต่ละประเภทกำหนด Source ที่ดึงได้:
  บิลขาย ← Quote, ใบจอง, มัดจำ
  PO ← PR, RFQ
  Service ← บิลขาย (serial ref)
  GR ← PO
Partial:  ดึงบางส่วนได้; ติดตามยอดที่ดึงไปแล้ว vs. เหลือ
Cascade:  ดึงมา → auto-fill รายการสินค้า + ลูกค้า
Chain Link: กด PO → เห็น PR ต้นทาง / กด Invoice → เห็น Shipment ปลายทาง

SC6 — SharedDepositPanel

ค้นหา:   เลขมัดจำ / เลขจอง / ลูกค้า — แสดงเฉพาะที่ยังตัดได้
ตัดมัดจำ: ยอดทั้งหมด, ใช้แล้ว, คงเหลือ, จะตัดในบิลนี้
หลายใบ:  รองรับหลายใบมัดจำต่อบิลเดียว
Auto:    ตัดครบ → สถานะมัดจำ = Fully Applied → บันทึก AR Ledger
สร้างใหม่: จากใบจองหรือ Stand-alone → auto generate เลขที่, พิมพ์ได้ทันที

SC7 — SharedTimeline (Audit Log)

Document Chain: แสดง Quote→จอง→มัดจำ→Invoice→Shipment→Payment
                คลิกเอกสารใดก็ข้ามไปได้
Reverse Link:  บิลขายรู้ว่ามี Shipment/Payment ไหนอ้างอิงมา
Activity Log:  ทุก Action อัตโนมัติ (สร้าง/แก้/อนุมัติ/ปฏิเสธ/พิมพ์) — ลบไม่ได้
Comment:       Internal note + mention @พนักงาน → Notification; ไม่แสดงลูกค้า
PDPA:          Phase 1 ต้องมี Audit Log ทุก Access

SC8 — SharedSerialPanel

กรอก/สแกน: กรอก Manual หรือ Scan Barcode; validate ไม่ซ้ำ real-time
Bulk:      Upload CSV (กรณีจำนวนมาก)
ประวัติ:   กด "ดูประวัติ" → lifecycle ทั้งหมด: รับเข้า→ขาย→ซ่อม→เคลม
Status:    ว่าง / ใช้งานอยู่ / ซ่อม / เคลม
Serial Policy: ไม่บังคับตอนขาย — บังคับตอนคลัง "เบิก" เท่านั้น

SC9 — SharedPromoPrice

ราคา:     ดึง Price List ตามกลุ่มลูกค้า + ช่องทาง + วันที่บิล; ใช้ Priority สูงสุด
โปร Badge: แสดง badge บน line item; คลิกดูเงื่อนไขได้
ของแถม:   auto-add Free Item Line (ราคา 0, flag Gift) เมื่อครบเงื่อนไข
Price Alert: แจ้งเมื่อราคาจะเปลี่ยนภายใน N วัน
Override:  แก้ราคาต่ำกว่า Floor → Auto Approval Flow + บันทึก Override Log
Accrual:   ขายสินค้าที่มี Vendor Sale-In → บันทึก Accrual Entry อัตโนมัติ
Commission: บันทึก PC Commission record แนบกับบิล
Priority:  Contract Price > Step Discount > Bundle > Trade-in > Normal
Block [T6]: คำนวณที่ Portal หรือ BC? — ยังไม่ตัดสินใจ

SC10 — SharedVendorSearch (NEW)

Search Fields:
  รหัส Vendor, ชื่อบริษัท (TH/EN), เบอร์โทร, Email, เลขผู้เสียภาษี,
  ชื่อผู้ติดต่อ (Contact Person)

Filter:
  ประเภท Vendor:  สินค้า / บริการ / ค่าเช่า / ค่าขนส่ง / อื่นๆ
  WHT Category:   1% / 2% / 3% / 5% / ไม่หัก
  สถานะ:          Approved / Pending Approval / Blocked
  Credit Term:    Cash / 30 วัน / 60 วัน / 90 วัน
  มี AP ค้าง:     All / มี AP ค้าง / ไม่มี

Search:    Real-time ≥ 2 ตัวอักษร
Result:    รหัส, ชื่อ, ประเภท, WHT Category, Credit Term, AP Outstanding, สถานะ
Auto-fill: Vendor Section + ดึง WHT Rate + Credit Term + Price List
Blocked:   Vendor ยังไม่ Approve → ห้ามสร้าง PO (ต้องผ่าน PO-3 Onboarding ก่อน)

ใช้ใน:
  PO-1 (PR), PO-4 (PO), PO-6 (AP Invoice), PO-7 (Accrual), PO-8 (Deposit Bill)
  FI-2 (AP Payment), FI-12 (WHT)

API:  GET /vendors?$filter=..., GET /vendors/{id}, POST /vendors
      GET /vendorLedgerEntries?vendorId=&open=true → AP ค้าง

🔌 BC365 API — Endpoints หลัก

Pattern มาตรฐาน

Base: https://{tenant}.api.businesscentral.dynamics.com/v2.0/{tenant}/Production/api/v2.0/
Auth: OAuth2 Client Credentials (Service Account)
Retry: Exponential Backoff (3 ครั้ง), Queue เมื่อ Timeout

Sales Module

GET    /salesQuotes              → SO Draft list
POST   /salesOrders              → สร้าง SO
PATCH  /salesOrders/{id}         → แก้ไข SO (ก่อน Post)
POST   /salesOrders/{id}/post    → Post SO → Invoice + Stock
POST   /salesCreditMemos         → CN
POST   /salesOrders/{id}/shipmentLines → Delivery

Warehouse

GET    /locations                → คลังทั้งหมด
GET    /items/{id}/stockByLocation
POST   /purchaseReceipts         → GRN
POST   /inventoryAdjustments     → Adjust
POST   /itemTransferOrders       → Transfer
GET    /serialNumbers?itemId=    → Serial Lookup

Purchase

POST   /purchaseOrders           → PO
POST   /purchaseOrders/{id}/receive → GRN (ตัด Stock)
POST   /purchaseInvoices/{id}/post  → AP + GL
POST   /purchaseCreditMemos      → Vendor Return/CN

Finance

POST   /cashReceiptJournals      → AR Receive
POST   /vendorPaymentJournals    → AP Payment
POST   /generalJournals          → JV / Accrual
POST   /bankAccounts/{id}/reconcile → Bank Recon
POST   /accountingPeriods/{id}/close → ปิดงวด

Service (BC Extension Required)

GET    /serviceOrders            → [?] Standard BC มีหรือต้อง Custom?
POST   /serviceOrders            → สร้าง Job Card
PATCH  /serviceOrders/{id}       → อัปเดตสถานะ
POST   /serviceOrders/{id}/complete → ปิดงาน → Auto AP ช่าง

👥 RBAC — Permission Matrix (28 Functions × 9 Roles)

🔍 = View Only (ผู้บริหาร) | ✅ = Full Access | ❌ = No Access

กฎ RBAC ที่ห้ามละเมิด:

• Maker ≠ Checker: ห้าม Approve งานตัวเอง (บังคับทุกโมดูลที่มี Approval)
• Field-Level: ราคาต้นทุน, วงเงิน Credit → ซ่อนตาม Role
• Route Guard: ป้องกัน URL ที่ไม่มีสิทธิ์
• Approval Matrix: กำหนดใน System Config ว่า Tier ไหน → Approver คนไหน

📅 Phase Plan

Phase 1 — Run ASAP

โมดูล: Sales, Warehouse, Purchase Basic, Price List P1, Finance Basic (AR/AP/JV), Master Data, System Config เงื่อนไข Go-Live: Master Data พร้อม + BC Sandbox ผ่าน Key Deliverables: SC1-SC9 ครบ → Sales SO/Invoice → WH GRN/Issue → PO/GRN/AP → AR/AP Basic

Phase 2 — Scale & Control

โมดูล: Step Discount/Bundle, Credit Memo, Service+Delivery (4.x), Claims, Finance 2.5 Expense Voucher, Finance 2.6 Credit Control, Bank Recon, Integration/API Monitor, e-Tax Invoice, Mobile App Group A (ช่าง) เงื่อนไข: Phase 1 UAT ผ่าน Key Deliverables:

• Service Queue/JobCard + Delivery & Installation sub-module (4.1-4.3)
• Expense & Payment Voucher (จ่ายค่าใช้จ่ายทั่วไป)
• Credit Control Dashboard (ติดตามวงเงิน + Alert ลูกหนี้เกิน)
• Integration API Monitor (สถานะ Sync BC / Error Log)
• e-Tax XML + RD API, Mobile Service Tech

Phase 3 — Automate

โมดูล: Finance Full (Period Close / Tax Report), Promotion Full, Accrual Auto, Real-time, Service Notification+Performance, Marketplace (Shopee/Lazada) เงื่อนไข: Phase 2 Stable Key Deliverables: Marketplace Tab ออนไลน์ใน Sales, Order Inbox, Stock Sync, Technician Performance Dashboard

Phase 4 — Optimize

โมดูล: Trade-in, Promo Simulator, Advanced SLA, Mobile App Group B (ผู้บริหาร), Marketplace Dashboard, BI/KPI Full, PDPA เงื่อนไข: Phase 3 Stable

🇹🇭 Thailand Compliance

e-Tax Invoice (Phase 2)

⚠️ [T9] ต้องตรวจก่อนว่า BC365 Standard Thailand Extension ครอบคลุมหรือต้อง Custom

VAT & WHT

• VAT 7% บังคับทุกใบกำกับภาษี
• WHT (ภ.ง.ด.3/53) ตัดเมื่อ AP Payment
• ทุก Posted Document ต้องมี Tax Invoice No. ที่ถูกต้อง

PDPA (Phase 4)

• Consent Record + Withdrawal Flow
• Data Retention Policy + Auto-Delete Hook
• Audit Log ทุก Access — SC7 ต้องมีตั้งแต่ Phase 1

🛒 Marketplace Integration (Phase 3)

Concept: POS-Style Tab ใน Sales Module

Sales Module
├── Tab: ขายหน้าร้าน   ← Sales Order ปกติ
└── Tab: ออนไลน์       ← Marketplace Orders (ใหม่ Phase 3)
    ├── Order Inbox (Shopee + Lazada)
    ├── SKU Mapping Manager
    ├── Auto-Create SO in BC
    ├── Stock Sync (BC → Marketplace)
    └── Shipping Tracking

Business Rules

• คำสั่งซื้อ Marketplace → Auto-create SO ใน BC (ยืนยันหรือ Auto)
• Stock Sync: BC คือ Source of Truth → Push ไป Marketplace [T12]
• Return จาก Marketplace → Credit Memo Flow ปกติ

⚠️ [T10] Shopee/Lazada Partner Account และ Production Key พร้อมหรือยัง?

📱 Mobile App (2 Groups)

Group A — Service Tech (Phase 2, เร่งด่วน)

• รับ Job Card / นัดหมาย
• บันทึกผลงาน + รูปถ่าย Before/After
• Check-in/out ที่หน้างาน
• บันทึกอะไหล่ที่ใช้
• [T1] Native / PWA / Responsive Web?
• [T2] Offline Mode?

Group B — Manager/Sales (Phase 4)

• Sales Dashboard + KPI ส่วนตัว
• อนุมัติ Quotation / SO จากมือถือ
• ดูสต็อก Real-time
• Service Performance Report

⚠️ Open Questions — ห้าม Implement จนกว่าจะได้คำตอบ

Technical

Business Rules

🤖 วิธีออกแบบ Module ใหม่ (Template)

เมื่อขอออกแบบ Module หรือหน้าจอใหม่ ให้ตอบครอบคลุม:

1. Module Brief

Module: [ชื่อ]
Phase: [P1/P2/P3/P4]
BC Entity: [API Endpoint ที่เชื่อม]
Trigger: [อะไร trigger หน้าจอนี้]
Output: [เอกสารหรือ Action ที่เกิดขึ้น]

2. Screen List

[Module Code]-1: [ชื่อหน้า List/Queue]
[Module Code]-2: [ชื่อหน้า Form/Detail]
[Module Code]-3: [หน้า Approval/Review ถ้ามี]

3. ERP Transaction Form Breakdown

ระบุ Field ทั้ง 7 Sections ว่ามีอะไรบ้าง + BC Field Mapping

4. Status Flow

Draft → Submitted → Approved → Posted/Confirmed → (Cancelled)

5. Shared Components ที่ใช้

ระบุ SC ที่ต้องใช้พร้อม Config

6. RBAC

ระบุ Role + Permission (Create/Edit/Approve/Post/Cancel)

7. BC API Calls

ระบุ GET/POST/PATCH ที่ต้องใช้

8. Open Questions ที่ Block

ระบุ Question Number จาก Section Open Questions

📂 Module Spec Files (รายละเอียดทีละเมนู)

อ่าน Module Spec ก่อนออกแบบหน้าจอใด ๆ ในโมดูลนั้น

📁 Reference Files ใน Workspace

ลำดับการอ่านเอกสาร (Document Reading Order)

1. research.md — เริ่มที่นี่เสมอ
2. plan.md — Task Status + Blocked Items
3. ui_design_pattern_guideline.md — Design Rules
4. uxui_field_knowledge.docx — Field Detail ทีละหน้าจอ
5. 1_component_fw_clean.docx — SC Technical Spec
6. Data Dictionary ตาม Phase
7. Workflow PDF — BC365 Mapping จริง

🔄 Status Transition Diagrams (ทุก Module)

Sales / Invoice / Promotion / Claims

Draft → รออนุมัติวงเงิน → อนุมัติ → ออกใบกำกับแล้ว → ชำระเงินแล้ว → ปิดงาน
              ↓
           ปฏิเสธ → Draft (แก้ไข/ส่งใหม่)

Purchasing (PR → PO → GRN → AP)

Draft → รออนุมัติ → อนุมัติแล้ว → PO Open → สินค้าเข้าแล้ว → รอวางบิล → ปิดรายการ
           ↓
       Rejected → Draft (แก้ไข/ส่งใหม่)

Warehouse

Draft → รอตรวจสอบ → อนุมัติ → สินค้าเข้า/ออกแล้ว → ปิดงาน

Service / ศูนย์บริการ

Draft → นัดหมายแล้ว → รอช่าง → ดำเนินงาน → ส่งงาน/รออนุมัติ → ปิดงาน
                                                                    ↓ (ช่างนอก)
                                                              ตั้งหนี้ช่าง

Promotion / Accrual Claim (Supplier)

Draft → รออนุมัติ → Active → Claim → รอเงินเข้า → รับเงินแล้ว
                     ↓
                  Expired
           ↓
       Rejected → Draft

AR / Credit

Draft → รออนุมัติ → อนุมัติ → วางบิล → ค้างชำระ → รับชำระแล้ว → ปิดบัญชี
           ↓
        ปฏิเสธ → Draft

Finance / Expense / AP / Tax

Draft → รออนุมัติ → อนุมัติ → จ่ายแล้ว → ปิดงาน
           ↓
        ปฏิเสธ → Draft

Online / Marketplace

Draft → รอตรวจสอบ → อนุมัติ → จัดส่งแล้ว → ปิดงาน

🎨 UX Rules — Confirmed Patterns (Oct 2025)

กฎ UX ที่ confirm แล้ว ห้ามละเมิด:

🗄️ BC365 API — Table Numbers Reference

🚚 Service Module — Delivery & Installation Sub-module (Phase 2)

Sub-module 4.x — บริการจัดส่งและติดตั้ง

Business Rules:

• ทริก: Sales Invoice ที่มี Delivery Flag = true → สร้าง Delivery Job อัตโนมัติ
• Serial ต้องบันทึกก่อนปิดงาน (SC8)
• Address ใช้ SC1 → 3 Address Types (ที่อยู่จัดส่ง)
• ช่างใช้ Mobile App Group A เพื่อ Check-in / ถ่ายรูป
• Status Flow: ใบแจ้งงาน → นัดหมาย → จัดส่ง → ติดตั้งสำเร็จ → ปิดงาน

💰 Finance Module — ส่วนที่เพิ่มใหม่ (Phase 2)

Finance 2.5 — Expense & Payment Voucher

วัตถุประสงค์: บันทึกค่าใช้จ่ายทั่วไป (ที่ไม่ผ่าน AP/PO) และออก Payment Voucher

หน้าจอ:
- Expense List: รายการค่าใช้จ่าย + สถานะ
- Expense Form: เจ้าหนี้ / ประเภทค่าใช้จ่าย / GL Account / Amount
- Payment Voucher: เลขที่ใบสำคัญ / วันที่จ่าย / วิธีชำระ (เช็ค/โอน)

Status Flow: Draft → รออนุมัติ → อนุมัติ → จ่ายแล้ว → ปิดงาน

BC API: POST /paymentJournals, POST /generalLedgerEntries
RBAC: Accountant (Create), Finance Manager (Approve+Post)

Finance 2.6 — Credit Control Dashboard

วัตถุประสงค์: ติดตามลูกหนี้ที่เกินวงเงินหรือเกินกำหนดชำระ

หน้าจอ:
- Credit Control List: ลูกหนี้ทั้งหมด + ยอดค้าง + เกินกำหนดกี่วัน + Alert
- Customer Credit Profile: ประวัติชำระ, วงเงิน, เอกสารค้าง
- Alert Actions: ปล่อยให้ขายต่อ / Hold / ส่ง Notice

Business Rules:
- ถ้า Outstanding > Credit Limit → ขึ้น Alert สีแดงทุก Module
- ถ้า Overdue > 30 วัน → Email/LINE Notify อัตโนมัติ (B5)
- SC1 ต้องแสดง Credit Status ก่อน User เปิดบิลใหม่

BC API: GET /customerLedgerEntries?customerId=, PATCH /customers (credit fields)

🔌 Integration & API Module (Phase 2+3) — Module #8

วัตถุประสงค์

ศูนย์กลางติดตามการเชื่อมต่อระหว่าง Portal ↔ BC365 ↔ ระบบภายนอก

หน้าจอหลัก

Business Rules

• ทุก API Call ต้องมี Retry (3 ครั้ง) ก่อน Error Log
• Error ร้ายแรง → Alert Admin ผ่าน LINE Notify
• Log เก็บ 90 วัน (PDPA)
• Admin Only — ซ่อน Module นี้จาก Non-Admin Role

📂 Master Data vs System Config — แนวทางออกแบบ

Master Data Module (MD) — ข้อมูลอ้างอิง

ใครสร้าง: User ทั่วไปที่มีสิทธิ์ (Sales Coordinator, Admin) ลักษณะ: เปลี่ยนบ่อย ตามธุรกิจ

System Config Module (CF) — ตั้งค่าระบบ

ใครสร้าง: System Admin เท่านั้น ลักษณะ: เปลี่ยนน้อย เป็น Base Setting ของระบบ

🔨 Development Checklist (ก่อนเริ่ม Implement ทุกหน้าจอ)

[ ] ⚠️ ตรวจ folder ว่ามีไฟล์ซ้ำไหม → ถ้ามี ต้องถามก่อนเสมอ
    (ดูตาราง "ไฟล์ซ้ำที่ตัดสินใจแล้ว" ใน Rule 2 เพื่อเทียบว่าเคยตัดสินใจแล้วหรือยัง)

[ ] 📄 อ่าน Flowchart ใน Flow Design/ ของ Module นั้นก่อน
    → ดู Status Flow, BC Entity, Document Format

[ ] อ่าน research.md + plan.md → ตรวจ Open Questions ที่เกี่ยวข้อง
    ⛔ ห้าม Implement ส่วนที่มี [?] จนกว่าจะตัดสินใจ

[ ] ดู Data Dictionary (dd_*.docx) — Field ครบหรือยัง?

[ ] ตรวจ Component Usage Matrix — SC ที่ยังไม่มีต้องพัฒนาก่อน Page

[ ] ยืนยัน RBAC: Role, Field Permission, ปุ่ม Disable

[ ] พัฒนาตาม ERP Form 7 Sections — ห้ามเปลี่ยนลำดับ

[ ] ใช้ StatusBadge สีตาม Standard — ห้ามใช้สีอื่น

[ ] ทุก Label มีทั้งไทยและอังกฤษ

[ ] Unit Test Coverage > 80%

[ ] TypeScript Strict + ESLint Airbnb + Prettier ก่อน PR

Sangwijit Group © 2024–2026 | Proprietary — ห้ามเผยแพร่ภายนอก Skill Version: 1.0 | เมษายน 2026