08.05 Order Rejection Best Practices

---

📌 At a Glance

รายการ	รายละเอียด
Topic	Order Rejection Best Practices
Difficulty	⭐⭐ Intermediate
Reading Time	8 นาที
Target	Developer, System Integrator

---

🎯 Learning Objectives

หลังจากศึกษาหัวข้อนี้แล้ว ผู้อ่านจะสามารถ

• ลดจำนวนรายการที่ถูกปฏิเสธ
• ออกแบบ Validation ใน Client System ได้อย่างเหมาะสม
• ปรับปรุงคุณภาพข้อมูลก่อนส่งเข้าสู่ SISAHYGO
• พัฒนาระบบ Integration ที่รองรับการใช้งานจริง

---

Overview

แม้ว่าระบบ SISAHYGO จะรองรับการแจ้งเหตุผลของการปฏิเสธผ่าน Order Rejection API แต่แนวทางที่ดีที่สุดคือการลดโอกาสเกิดรายการปฏิเสธตั้งแต่ต้นทาง

การตรวจสอบข้อมูลก่อนส่ง การใช้ Master Data ที่เป็นปัจจุบัน และการออกแบบ Validation ที่เหมาะสม จะช่วยให้รายการเข้าสู่กระบวนการขนส่งได้รวดเร็ว ลดการทำงานซ้ำ และเพิ่มประสิทธิภาพของระบบโดยรวม

---

Figure 8-5 Order Rejection Best Practices

Figure 8-5 แสดงแนวทางการลดการเกิด Order Rejection ตั้งแต่การเตรียมข้อมูล การตรวจสอบความถูกต้อง การส่งข้อมูล และการติดตามผลผ่าน Order Rejection API

---

Recommended Workflow

Synchronize Master Data

        │

        ▼

Validate Request

        │

        ▼

Submit Order Checking

        │

        ▼

Checker Review

        │

        ├────────────► Approved

        │

        ▼

Rejected ?

        │

   No ─────────────► Complete

        │

       Yes

        ▼

Analyze Reason

        │

        ▼

Correct Source Data

        │

        ▼

Submit New Order

---

Recommended Practices

Practice	Recommendation
Synchronize Master Data	อัปเดตข้อมูลผู้รับ สินค้า และหน่วยนับให้เป็นปัจจุบัน
Validate Before Submit	ตรวจสอบข้อมูลก่อนเรียก API ทุกครั้ง
Use Unique Reference	ใช้ client_reference_no ที่ไม่ซ้ำกัน
Review Rejections	ตรวจสอบรายการที่ถูกปฏิเสธเป็นประจำ
Improve Source Data	แก้ไขข้อมูลที่ระบบต้นทางก่อนส่งใหม่

---

Validation Recommendations

Client System ควรตรวจสอบข้อมูลต่อไปนี้ก่อนเรียก API

Validation	Description
Receiver	ตรวจสอบ customer_rec_id
Product	ตรวจสอบ product_id
Unit	ตรวจสอบ unit_id
Quantity	จำนวนสินค้ามากกว่า 0
Required Fields	ตรวจสอบข้อมูลที่จำเป็นครบถ้วน
Reference Number	client_reference_no ไม่ซ้ำกัน

---

Handling Rejection Reasons

เมื่อได้รับข้อมูลจาก Order Rejection API

1. ค้นหาเอกสารจาก client_reference_no
2. อ่านข้อความใน reason
3. แจ้งผู้ใช้งานให้แก้ไขข้อมูล
4. แก้ไขข้อมูลในระบบต้นทาง
5. ส่ง Order Checking ใหม่

ควรสร้างรายการใหม่หลังจากแก้ไขข้อมูลเรียบร้อย ไม่ควรแก้ไขข้อมูลโดยตรงในระบบ SISAHYGO

---

Monitoring Recommendations

ควรตรวจสอบรายการที่ถูกปฏิเสธเป็นประจำ เช่น

Frequency	Recommendation
ทุกวัน	ตรวจสอบรายการที่ถูกปฏิเสธใหม่
ทุกสัปดาห์	วิเคราะห์สาเหตุที่เกิดซ้ำ
ทุกเดือน	สรุปสถิติและปรับปรุงกระบวนการ

---

Common Mistakes

Problem	Prevention
ใช้ Master Data เก่า	Synchronize ข้อมูลเป็นประจำ
client_reference_no ซ้ำ	ใช้เลขอ้างอิงที่ไม่ซ้ำกัน
ข้อมูลไม่ครบ	Validate Required Fields
ส่งข้อมูลซ้ำโดยไม่แก้ไข	วิเคราะห์ reason ก่อนส่งใหม่
ไม่ตรวจสอบ Order Rejection	เรียก API และติดตามรายการอย่างสม่ำเสมอ

---

Performance Recommendations

• ลดการเรียก Master Data APIs ซ้ำโดยใช้ Local Cache
• ใช้ Filter วันที่เมื่อเรียก Order Rejection API
• จัดเก็บประวัติการปฏิเสธในฐานข้อมูลของ Client
• วิเคราะห์ข้อมูลการปฏิเสธเพื่อลดข้อผิดพลาดในอนาคต

---

Integration Checklist

ก่อนนำระบบขึ้น Production

• [x] Synchronize Master Data
• [x] Validate Request ก่อนส่ง
• [x] ใช้ client_reference_no ที่ไม่ซ้ำกัน
• [x] รองรับ Order Rejection API
• [x] แสดง reason ให้ผู้ใช้งาน
• [x] บันทึกประวัติการปฏิเสธ
• [x] รองรับการส่งรายการใหม่หลังแก้ไขข้อมูล

---

Related APIs

• GET /products
• GET /receivers
• GET /units
• POST /order-checkings
• GET /order-rejections

---

Summary

การป้องกันการเกิด Order Rejection เป็นแนวทางที่มีประสิทธิภาพมากกว่าการแก้ไขภายหลัง โดย Client System ควรตรวจสอบข้อมูลก่อนส่ง ใช้ Master Data ที่เป็นปัจจุบัน วิเคราะห์เหตุผลการปฏิเสธจาก Order Rejection API และปรับปรุงข้อมูลในระบบต้นทางอย่างต่อเนื่อง เพื่อให้กระบวนการเชื่อมต่อกับ SISAHYGO มีความถูกต้อง รวดเร็ว และพร้อมใช้งานในระดับ Production

---

Next Step

➡️ 08.06 Chapter Summary