08.04 Order Rejection Workflow

---

📌 At a Glance

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

---

🎯 Learning Objectives

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

• เข้าใจขั้นตอนการจัดการรายการที่ถูกปฏิเสธ
• ออกแบบกระบวนการแก้ไขข้อมูลใน Client System
• ใช้ Order Rejection API ร่วมกับ Order Checking API ได้อย่างถูกต้อง
• ลดการเกิดรายการปฏิเสธซ้ำจากข้อมูลเดิม

---

Overview

เมื่อพนักงาน SISAHYGO ตรวจสอบรายการแล้วพบว่าข้อมูลไม่สามารถดำเนินการต่อได้ ระบบจะบันทึกรายการปฏิเสธ (Order Rejection) พร้อมเหตุผล

Client System สามารถเรียก Order Rejection API เพื่อตรวจสอบรายการที่ถูกปฏิเสธ นำเหตุผลไปแสดงให้ผู้ใช้งาน แก้ไขข้อมูลในระบบต้นทาง และส่งรายการใหม่ผ่าน Order Checking API

Workflow นี้ช่วยให้การแลกเปลี่ยนข้อมูลระหว่างระบบเป็นไปอย่างเป็นระบบ และลดการประสานงานผ่านช่องทางอื่น

---

Figure 8-4 Order Rejection Workflow

Figure 8-4 แสดงขั้นตอนการจัดการรายการที่ถูกปฏิเสธ ตั้งแต่การตรวจสอบโดยพนักงาน การแจ้งผลผ่าน Order Rejection API การแก้ไขข้อมูลใน Client System และการส่งรายการใหม่เข้าสู่ SISAHYGO

---

Workflow

Create Order Checking

        │

        ▼

Checker Review

        │

        ▼

Rejected

        │

        ▼

GET /order-rejections

        │

        ▼

Receive Rejection Reason

        │

        ▼

Correct Data

        │

        ▼

POST /order-checkings

        │

        ▼

Checker Review Again

---

Workflow Description

Step	Description
1	Client System ส่งข้อมูลผ่าน Order Checking API
2	พนักงาน SISAHYGO ตรวจสอบข้อมูล
3	ระบบบันทึกรายการปฏิเสธพร้อมเหตุผล
4	Client System เรียก Order Rejection API
5	ผู้ใช้งานแก้ไขข้อมูลในระบบต้นทาง
6	ส่งข้อมูลใหม่ผ่าน Order Checking API
7	ระบบเข้าสู่กระบวนการตรวจสอบอีกครั้ง

---

Rejection Handling Strategy

เมื่อได้รับข้อมูลการปฏิเสธ ควรดำเนินการดังนี้

1. ค้นหาเอกสารจาก client_reference_no
2. แสดง reason ให้ผู้ใช้งานทราบ
3. แก้ไขข้อมูลในระบบต้นทาง
4. ตรวจสอบข้อมูลก่อนส่งใหม่
5. ส่ง Request ใหม่ผ่าน POST /order-checkings

---

Common Rejection Scenarios

Problem	Recommended Action
ผู้รับสินค้าไม่ถูกต้อง	ตรวจสอบและเลือกผู้รับสินค้าใหม่
สินค้าไม่ถูกต้อง	ตรวจสอบ Product Master
จำนวนสินค้าไม่ถูกต้อง	แก้ไขจำนวนสินค้า
ข้อมูลไม่ครบถ้วน	เพิ่มข้อมูลที่จำเป็น
ส่งข้อมูลซ้ำ	ตรวจสอบ client_reference_no ก่อนส่งใหม่

---

Business Notes

• การปฏิเสธรายการไม่ได้หมายถึงความล้มเหลวของการเชื่อมต่อ API แต่เป็นผลจากการตรวจสอบข้อมูลตามกระบวนการธุรกิจ
• ควรใช้ client_reference_no เพื่อเชื่อมโยงกลับไปยังเอกสารในระบบต้นทาง
• หลังจากแก้ไขข้อมูลแล้ว ให้ส่งเป็นรายการใหม่ผ่าน Order Checking API
• ควรบันทึกเหตุผลการปฏิเสธไว้เพื่อใช้วิเคราะห์และปรับปรุงคุณภาพข้อมูลในระยะยาว

---

Implementation Notes

• ใช้ client_reference_no เป็น Primary Reference
• แสดง reason ให้ผู้ใช้งานแก้ไขได้ทันที
• บันทึกประวัติการปฏิเสธใน Local Database
• ตรวจสอบข้อมูลก่อนส่งใหม่ทุกครั้ง

---

Best Practices

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

---

Related APIs

• POST /order-checkings
• GET /order-rejections
• GET /shipments

---

Summary

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

---

Next Step

➡️ 08.05 Order Rejection Best Practices