Skip to main content

PAR68-IT-007 รหัสพนักงานขายไม่ได้ถูกล็อกการตัด CID

วันที่ 23/12/68

แก้ไขปัญหา  
ชื่อ/สกุล/แผนก
คอมพิวเตอร์
เกิดเหตุการณ์อะไร (อธิบาย)
              เนื่องจากได้รับแจ้งปัญหาเรื่องพนักงานขายโครงการ นางสาวพรรณิภา เก็บเจริญ ได้ขายสินค้าสินค้าเชือกผ้าแบนคละสี ลูกค้ารับสินค้าไป 4 แต่พนักงานตัด CID ลูกค้าแค่ 1 ซึ่งหากตัดไม่ตรงจะมีการแจ้งเตือนในระบบแต่บังเอิญรหัสพนักไม่ได้ถูกล็อก CID ไว้จึงสามารถทำได้ จึงขอให้ทางคอมพิวเตอร์หากแนวทางป้องกันและแก้ไข

สาเหตุของปัญหา มาตรการแก้ไขปัญหา


 

       ณ วันที่ มีปัญหาโปรแกรม การตัดเครดิตใช้งานไม่ได้ แผนก IT ได้ทำการเลือกวิธีการใช้ fallback โดยการ ignored การตรวจสอบการตัด CID   เพื่อให้กระบวนการขายเงินเชื่อ สามารถทำงานต่อ ณ ช่วงเวลานั้นได้ และไม่ได้มีการปรับคืนการตรวจสอบ CID และยอดเงิน ณ สิ้นวัน (หลังจากแก้ไขปัญหาแล้ว) 

       มีผลทำให้ user ที่ ignored ไว้ไม่ได้มีการปรับสถานะคืนจึงสามารถ บันทึกขายเงินเชื่อโดยไม่ได้ตรวจสอบยอดเงินใน CID จึงเกิดปัญหาไม่มีการแจ้งเตือน ดังที่กล่าวมา 


           


แก้ไขเบื้องต้น 


   - ปรับ status ให้กลับมาเช็ค CID และยอดเงิน กับ user ทุกคน

      ... แก้ไขเรียบร้อยแล้ว


การป้องกัน 
  • ตรวจสอบสาเหตุ ปัญหาการตัด CID
    • (api merchant error)
  • แก้ไขและเพิ่ม test case พร้อมสร้าง  unit test 
  • ทำ JOB Schedule ในการปรับให้กับพนักงานที่โดนปลดล๊อก และพนักงานใหม่ที่เข้ามา
สถานะการป้องกัน 

       จัดทำ JOB Schedule ตรวจสอบเรียบร้อยแล้ว 

 

image.png

วิเคราะห์ 

 

กรณีนี้เป็น เคสคลาสสิกของ Distributed System + Human Override + Missing Guardrail
ผมขอสรุปและแนะนำเป็น เชิงสถาปัตยกรรม + เชิงกระบวนการ (Process/QA) แบบจับต้องได้นะครับ


สรุปปัญหา (Root Cause แบบตรงประเด็น)

ไม่ใช่ bug ธรรมดา แต่เป็น System Design Gap

  1. ERP สามารถ bypass credit validation ได้

  2. credit9 down → มีการทำ manual ignore / exception

  3. ไม่มีระบบบังคับ revert / auto-heal

  4. การ override ผูกกับ user-level → ลืมเปิดกลับ

  5. ไม่มี ระบบตรวจจับความผิดปกติ (Mismatch Detection)

  6. QA ตรวจ feature แต่ ไม่ได้ test “Failure Mode”

👉 ผลลัพธ์:

  • ERP ออกบิลเงินเชื่อ

  • credit9 ไม่ถูกตัด

  • ยอดไม่ตรง → CAR

แนวคิดหลักที่ควรใช้แก้ (Key Principles)

ผมขอวางกรอบก่อน 5 ข้อนี้ แล้วค่อยลงวิธีปฏิบัติ

  1. Credit validation ต้องเป็น “Hard Gate” ไม่ใช่ Optional

  2. Override ต้องมีอายุ (TTL) และ Audit

  3. Failure ต้อง fail-safe (หยุด) ไม่ใช่ fail-open

  4. ระบบต้อง detect inconsistency เอง

  5. Human error ต้องถูกกันด้วยระบบ ไม่ใช่ความจำ

 

 

Override Policy (ใช้ตอบ PAR )

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

รองรับกรณี Credit9 Down โดยไม่ทำให้ข้อมูลเพี้ยน

🔐 กฎ Override (บังคับ)

หัวข้อ กำหนด
Scope ระดับ Incident (ห้ามผูก user)
TTL ต้องมีวันหมดอายุ
Approval อย่างน้อย 2 คน (IT + Manager)
Audit Log ครบ WHO / WHEN / WHY
Default หมดเวลา = block อัตโนมัติ

SOP เมื่อ Credit9 Down (Operational Ready)

STEP 1: Incident Declaration
  • เปิด Incident ID

  • แจ้งทุกฝ่าย (Sales / Finance)

STEP 2: System Behavior
  • ERP → Block credit invoice

  • Cash only allowed

STEP 3: (ถ้าจำเป็นจริง)
  • เปิด Override แบบ TTL

  • ระบุ impact scope ชัดเจน

STEP 4: Recovery
  • Credit9 กลับมา → Override ปิดอัตโนมัติ

  • Run Reconciliation Job