PMaxx · Process Flows

Sequence & Swimlane Diagrams

แผนภาพ flow ของ PMaxx (pharmacy / health e-marketplace) เรียบเรียงจาก PMaxx-BRD-Working-Draft.md และ PMaxx-Implementation-Plan.md — ครอบคลุมเส้นทางหลักของ Core Go-live: สั่งซื้อ→จัดส่ง, สมัคร/เข้าผ่าน LINE, sync สต๊อก/ราคากับ Navision, checkout ยาที่ต้องใบสั่ง และการกระทบยอดรายวัน

🎯 Scope: Core Go-live (~3 เดือน) 🔌 Navision · ChillPay · Shippop · LINE OA 🧩 3 Sequence + 3 Swimlane
ℹ️
เป็น flow ตามที่ออกแบบไว้ (as-designed) จากเอกสาร BRD/PRD — ยังไม่ได้ตรวจสอบเทียบกับโค้ดจริงใน repo ทีละบรรทัด และหลายจุดขึ้นกับ Open Decisions (เช่น รุ่น Navision, เปิด COD ไหม, single vs multi-vendor) ที่ยังต้องเคาะใน Phase 0

Sequence Diagrams

ลำดับการรับส่งข้อความระหว่างระบบ/ผู้เกี่ยวข้องตามเวลา

1 · สั่งซื้อ → จัดส่ง End-to-End (Journey A)

เส้นทางหลักของ core go-live: ลูกค้าซื้อยา/วิตามินผ่าน LINE → จ่ายเงิน ChillPay → order เข้า Navision ผ่าน middleware (กันซ้ำด้วย External Document No.) → เภสัชกรตรวจ/แพ็ก → Shippop ออกเลขพัสดุ → แจ้งเตือนกลับทาง LINE

sequenceDiagram
  autonumber
  actor C as ลูกค้า
  participant L as LINE / LIFF
  participant P as PMaxx
  participant CP as ChillPay
  participant M as Middleware
  participant N as Navision ERP
  actor RX as เภสัชกร
  participant SP as Shippop
  C->>L: เปิดร้านผ่าน LINE (LIFF)
  L->>P: เข้าหน้าร้าน (บัญชีผูกไว้แล้ว)
  P-->>C: แสดงสินค้า + ราคา/สต๊อก (sync จาก NAV)
  C->>P: เลือกสินค้า + checkout
  P->>CP: สร้างรายการจ่าย (QR / บัตร)
  CP-->>C: หน้าชำระเงิน
  C->>CP: ชำระเงิน
  CP-->>P: webhook: paid
  P->>M: ส่ง order
  M->>N: สร้าง Sales Order
External Doc No = Order ID (idempotent) N-->>RX: ออเดอร์ใหม่ให้ตรวจ/แพ็ก RX->>RX: ตรวจ flag ยาที่ต้องใบสั่ง + แพ็ก RX->>SP: สร้าง shipment + label SP-->>P: tracking no. (webhook สถานะ) P->>N: อัปเดตสถานะ (shipped / invoiced) P-->>L: แจ้งเตือน + เลขพัสดุ L-->>C: "จัดส่งแล้ว" ทาง LINE

2 · สมัคร / เข้าใช้งานผ่าน LINE OA (Journey B)

ล้าง technical debt ของเดิม (2 ทางเชื่อมที่ไม่ work) เหลือทางเดียวที่สะอาด: LIFF + Messaging API — สมัคร/login ผ่าน LINE แล้วผูก LINE userId กับบัญชี PMaxx ครั้งต่อไปเข้าได้เลย

sequenceDiagram
  autonumber
  actor C as ลูกค้าใหม่
  participant LN as LINE Platform
  participant LF as LIFF App
  participant P as PMaxx Backend
  C->>LN: กดลิงก์ร้านใน LINE
  LN->>LF: เปิด LIFF app
  LF->>LN: ขอ profile / ID token
  LN-->>LF: LINE userId + ID token
  LF->>P: ส่ง userId + token
  P->>LN: verify ID token
  LN-->>P: token ถูกต้อง
  alt ผู้ใช้ใหม่
    P->>P: สร้าง account + ผูก LINE userId
  else มีบัญชีแล้ว
    P->>P: login ด้วย LINE userId
  end
  P-->>LF: session (เข้าใช้งานได้)
  Note over P,LN: ครั้งต่อไปเข้าได้เลย ไม่ต้อง login ซ้ำ
  P->>LN: (ภายหลัง) แจ้งเตือนออเดอร์ผ่าน Messaging API
    

3 · Sync สินค้า / สต๊อก / ราคา (Navision → PMaxx)

กรณี classic NAV on-prem ต้อง poll เป็นรอบ (ไม่มี webhook) พร้อม logic กัน oversell — ถ้าเป็น Business Central ใช้ webhook push แทน (ตัดงาน connectivity/รอบ polling)

sequenceDiagram
  autonumber
  participant SC as Scheduler
  participant M as Middleware
  participant N as Navision ERP
  participant P as PMaxx
  loop ทุก X นาที (classic NAV on-prem)
    SC->>M: trigger sync
    M->>N: query item / price / stock-by-location
    N-->>M: ข้อมูลสินค้า / ราคา / สต๊อก
    M->>P: อัปเดตราคา + สต๊อก
    P->>P: กัน oversell / reservation
  end
  Note over N,M: Business Central → ใช้ webhook push
แทน polling

Swimlane Diagrams

กระบวนการแบ่งตาม "เลน" ของแต่ละผู้รับผิดชอบ (ใครทำอะไร ส่งต่อกันยังไง)

1 · Order Fulfillment ข้ามระบบ

ภาพเดียวกับ Sequence #1 แต่มองเป็นเลนความรับผิดชอบ — เห็นชัดว่าออเดอร์ถูกส่งต่อระหว่าง ลูกค้า → PMaxx → ChillPay → Middleware → Navision → เภสัชกร → Shippop แล้ววนสถานะกลับ

flowchart LR
  subgraph LC["🧑 ลูกค้า"]
    a1["เลือกสินค้า + checkout"]
    a2["ชำระเงิน"]
    a9["รับแจ้งเตือน + เลขพัสดุ"]
  end
  subgraph PM["🛒 PMaxx"]
    b1["สร้าง order"]
    b2["รับ webhook: paid"]
    b7["อัปเดตสถานะ + แจ้ง LINE"]
  end
  subgraph CP["💳 ChillPay"]
    c1["รับชำระเงิน"]
  end
  subgraph MW["🔀 Middleware"]
    d1["ส่ง order → NAV (idempotent)"]
    d2["ดึงสถานะกลับ"]
  end
  subgraph NV["🏭 Navision"]
    e1["สร้าง Sales Order"]
    e2["Posted Shipment / Invoice"]
  end
  subgraph RX["💊 เภสัชกร"]
    f1["ตรวจ / แพ็ก"]
  end
  subgraph SH["🚚 Shippop"]
    g1["shipment + label + tracking"]
  end
  a1 --> b1
  a2 --> c1
  c1 --> b2
  b2 --> d1
  d1 --> e1
  e1 --> f1
  f1 --> g1
  g1 --> d2
  d2 --> e2
  d2 --> b7
  b7 --> a9
    

2 · Checkout ยาที่ต้องมีใบสั่ง (Compliance)

จุด compliance สำคัญของธุรกิจขายยา — SKU ที่ flag ว่าเป็นยาอันตราย/ยาควบคุม ต้องมี flow อัปโหลด + เภสัชกรตรวจใบสั่งก่อน checkout (อ้างอิง Gap Analysis 1.1 ในแผน)

flowchart TB
  subgraph C["🧑 ลูกค้า"]
    c1["เพิ่มสินค้าในตะกร้า"]
    c4["อัปโหลดใบสั่งยา"]
    c6["ชำระเงิน + สั่งซื้อ"]
    cX["สั่งซื้อไม่ได้
(ต้องมีใบสั่งที่ถูกต้อง)"] end subgraph P["🛒 PMaxx"] p1{"SKU เป็นยา
ที่ต้องใบสั่ง?"} p2["ไปหน้า checkout"] p3["ขอใบสั่งยา"] p5["ส่งใบสั่งให้เภสัชกร"] end subgraph RX["💊 เภสัชกร"] r1{"ตรวจใบสั่ง
ผ่านไหม?"} end c1 --> p1 p1 -->|ไม่ใช่ ยาทั่วไป| p2 p1 -->|ใช่| p3 p3 --> c4 c4 --> p5 p5 --> r1 r1 -->|ผ่าน| p2 r1 -->|ไม่ผ่าน| cX p2 --> c6

3 · Reconciliation กระทบยอดรายวัน

จุดแข็งของทีม (Gap 1.5) — ทำเป็น first-class ตั้งแต่วันแรก: จับคู่ count & sum ระหว่าง PMaxx ↔ NAV ↔ ChillPay ↔ Shippop ให้ตรง ≥ 99.5%/วัน อะไรไม่ตรงให้ flag แล้วทีม data ตามแก้

flowchart LR
  subgraph SRC["📥 แหล่งข้อมูล"]
    s1["PMaxx orders"]
    s2["NAV Sales Order"]
    s3["ChillPay payment"]
    s4["Shippop shipment / COD"]
  end
  subgraph REC["🔀 Reconciliation Layer"]
    r1["ดึงข้อมูลรายวัน"]
    r2{"count & sum
ตรงกันไหม?"} r3["ทำเครื่องหมาย OK"] r4["flag ความต่าง
(order / เงิน / สต๊อก)"] end subgraph OUT["📊 ทีม Data"] o1["Dashboard กระทบยอด
เป้า ≥ 99.5%/วัน"] o2["ตรวจสอบ + แก้ไข"] end s1 --> r1 s2 --> r1 s3 --> r1 s4 --> r1 r1 --> r2 r2 -->|ตรง| r3 --> o1 r2 -->|ไม่ตรง| r4 --> o2 o2 --> o1

ผู้เกี่ยวข้อง (Actors)

🧑 ลูกค้า — ซื้อผ่าน LINE/LIFF 🛒 PMaxx — แพลตฟอร์ม e-marketplace 🔀 Middleware — ตัวกลางเชื่อม NAV 🏭 Navision — ERP (source of truth) 💊 เภสัชกร — ตรวจ/จ่ายยา/แพ็ก 💳 ChillPay — payment gateway 🚚 Shippop — ขนส่ง + COD 💬 LINE — LIFF + Messaging API