ออเดอร์ถูกส่งซ้ำจากต้นทาง: ตรวจตัวอ้างอิงก่อนเพิ่มยอด

1. แยกคำถามก่อนแตะยอด

เมื่อ worker ส่งคำสั่งเดิมซ้ำ เลขคำขอใหม่ไม่ได้ทำให้เกิดการขายใหม่ ต้องใช้ตัวอ้างอิงเหตุการณ์ที่คงที่เพื่อแยก retry จากออเดอร์คนละใบ

Microsoft เตือนว่าคำตอบที่หายไปอาจตามหลังงานที่สำเร็จแล้ว จึงต้องตรวจผลข้างเคียงก่อนส่งซ้ำ

2. ลำดับตรวจสำหรับกรณีนี้

เลือกข้อมูลของลูกค้าและช่วงที่เกี่ยวข้องเท่านั้น รักษาเลขอ้างอิงที่ใช้ตรวจกลับก่อนเปลี่ยนรายการ

• จับคู่ order_code และ source ของออเดอร์กับต้นทาง
• ตรวจ payload ว่าเป็นการส่งซ้ำเหมือนเดิมหรือขอแก้ข้อมูล
• เก็บผลตอบกลับเดิมและยอดเครดิตก่อนหลังทุกครั้งที่ตรวจ

3. ตัวอย่างสมมติที่ตรวจย้อนกลับได้

ตัวอย่างนี้ไม่มีข้อมูลลูกค้าจริง ใช้หน่วยเครดิตตามสมมติฐานที่ระบุ ไม่ใช่การกำหนดมูลค่าของทุกระบบ

4. ขอบเขตและสิ่งที่ห้ามสรุปข้าม

Business API มีพฤติกรรม replay ตามตัวอ้างอิง แต่ต้องอ่านผลรายรายการ ไม่ถือว่า timeout แปลว่าล้มเหลวและไม่สร้างรหัสใหม่เพื่อบังคับผ่าน

5. ปิดงานด้วยหลักฐานที่คนถัดไปตรวจได้

ตรวจ Business Ledger คู่กับ API Logs ที่ตัดข้อมูลลับแล้ว ก่อนเลือก retry หรือส่งให้คนแก้ mapping

บันทึกยอดก่อนและหลัง พร้อมรายการที่ยังไม่แน่ชัด อย่าสร้างเงินรับหรือเครดิตเพิ่มเพียงเพื่อให้ตัวเลขสรุปตรงกัน

แหล่งอ้างอิงและขอบเขตเนื้อหา

แหล่งต่อไปนี้อธิบายหลักการทั่วไป ส่วนขั้นตอนของ MeeTang ตรวจจากฟีเจอร์ในระบบ ณ วันที่อัปเดต ตัวเลขในตัวอย่างไม่ใช่ข้อมูลผู้ใช้งานจริง

• Microsoft: Retry pattern — จำกัดการส่งซ้ำและพิจารณาผลข้างเคียงเมื่อคำตอบสูญหาย

จัดทำด้วย AI ช่วยเรียบเรียงและตรวจเทียบกับโค้ด ไม่ใช่คำแนะนำภาษีหรือการรับรองผลทางบัญชี เงื่อนไขฟีเจอร์และโควตาขึ้นกับแพ็กเกจและสิทธิ์ที่ได้รับ