ในโลกของการพัฒนาซอฟต์แวร์ แม้ว่าเราจะออกแบบระบบและวาง Logic ตาม Requirement เบื้องต้นมาอย่างสมบูรณ์แบบและถูกต้องร้อยเปอร์เซ็นต์ แต่เมื่อระบบถูกนำไปใช้งานจริง (Real-world Scenarios) เรามักจะได้พบกับ Use Case ที่หลากหลายและคาดไม่ถึงเสมอ

นี่คือหนึ่งในความท้าทายที่น่าสนใจที่สุดของการพัฒนาระบบ CRM และระบบ Membership LINE LIFF Ecosystem เมื่อระบบผ่อนชำระต้องเผชิญกับพฤติกรรมจริงของลูกค้าและข้อจำกัดหน้างาน ซึ่งทำให้เราต้องเรียนรู้และวางแผนสถาปัตยกรรมระบบในเฟสถัดไปเพื่อรองรับความยืดหยุ่นที่มากขึ้น ดังนี้ครับ:

1. ความยืดหยุ่นของการชำระเงิน: เมื่อลูกค้าขอ "แบ่งจ่ายในงวดเดียว" (Partial Payments)

สิ่งที่ระบบคิด: ระบบถูกออกแบบมาด้วยสมมติฐานที่ว่า ลูกค้าจะชำระเงิน "เต็มจำนวน" ตามยอดที่เรียกเก็บในแต่ละงวด

สิ่งที่เกิดขึ้นจริง: ลูกค้ามีความประสงค์ที่จะแบ่งจ่ายย่อยๆ ภายในงวดเดียวกัน (เช่น งวดนี้ต้องจ่าย 1,000 บาท แต่ขอโอนเข้ามาก่อน 500 บาท) ซึ่งโครงสร้างระบบในเฟสแรกยังไม่รองรับสถานะการแบ่งจ่ายย่อยลักษณะนี้ ทำให้ทีมงานต้องแก้ปัญหาเบื้องต้น (Workaround) ด้วยการทำ Manual Tracking เก็บยอดไว้ชั่วคราวนอกระบบ และรอจนกว่าลูกค้าจะจ่ายครบเต็มจำนวนจึงจะคีย์ข้อมูลเข้าระบบ

เเนวทางการพัฒนาระบบในอนาคต:

Partial Payment Support: ปรับโครงสร้างให้ระบบรองรับการกรอกยอดเงินที่ "ต่ำกว่า" ยอดเรียกเก็บได้ โดยระบบจะทำการหักลบยอดคงเหลือ และแสดงสถานะของงวดนั้นเป็น "รอชำระบางส่วน (Partially Paid)"

Dynamic Penalty Logic: แม้จะมีการชำระเข้ามาบางส่วน หากพ้นกำหนดชำระ ระบบ Worker จะยังคงสามารถคำนวณค่าปรับและดอกเบี้ยจาก "ยอดคงเหลือ" ที่ยังชำระไม่ครบได้อย่างถูกต้องและเป็นธรรม

2. กับดักของเวลา: ปัญหาการสร้าง Sales Order ย้อนหลัง (Backdated Billing Date)

สิ่งที่ระบบคิด: โครงสร้างระบบเดิมถูกออกแบบให้ผูก "วันครบกำหนดชำระงวดถัดไป (Next Due Date)" ไว้กับ "วันที่เปิดบิล" โดยอัตโนมัติ โดยคิดตามเงื่อนไขการชำระเงิน (เช่น กำหนดเงื่อนไขการชำระเงินรายเดือน วันที่จ่ายงวดแรกจะต้องเป็นวันสุดท้ายของเดือนถัดไป)

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

ผลกระทบที่ตามมา: ความน่ากลัวคือ ทันทีที่แอดมินคีย์ข้อมูลเสร็จ ระบบจะมองว่างวดวันที่ 28 กุมภาพันธ์ นี้ "ค้างชำระ" ทันที และเมื่อ Worker Service มารัน Cron Job คำนวณระบบตอนเที่ยงคืน ลูกค้าก็จะโดนชาร์จ "ค่าปรับ (Late Fees)" ก้อนโตแบบไม่รู้ตัว ทั้งๆ ที่บิลเพิ่งถูกสร้างเข้าระบบ

เเนวทางการพัฒนาระบบในอนาคต:

Future-Proof Due Date Logic: ปรับ Logic การสร้างงวดชำระใหม่ โดยตั้งกฎเกณฑ์ (Validation) ให้รัดกุมขึ้นว่า "ไม่ว่าวันที่เปิดบิล (Sales Order Date) จะถูกคีย์ย้อนหลังไปในอดีตไกลแค่ไหน วันครบกำหนดชำระงวดแรก (หรือครั้งถัดไป) จะต้องถูกประมวลผลให้เป็นวันในอนาคต (Future Date) เมื่อเทียบกับวันปัจจุบันเสมอ" เพื่อป้องกันไม่ให้ระบบมองว่าเป็นการผิดนัดชำระตั้งแต่ Day 1 และป้องกันการเกิดค่าปรับที่ไม่เป็นธรรมกับลูกค้า

ในโลกของการพัฒนา CRM และระบบ LINE LIFF สำหรับธุรกิจผ่อนชำระ เราพบว่า Requirement ที่สมบูรณ์บนกระดาษไม่ได้การันตีว่าระบบจะรับมือกับความเป็นจริงบนหน้างานได้เสมอไป

บทเรียนหลักคือ Edge Case ที่น่ากลัวที่สุดคือสิ่งที่ระบบทำ "ถูกต้อง" ตาม Logic เดิม แต่ผิดในบริบทจริง การออกแบบที่ดีต้องคิดจากสิ่งที่ "อาจเกิดขึ้น" ไม่ใช่แค่สิ่งที่ "ควรเกิดขึ้น"

เมื่อ Requirement ปะทะ Reality: บทเรียนจากการรับมือ Edge Cases บนหน้างานจริง