หลักการ สถานการณ์ และความเหมาะสม
การเชื่อม ERP เปลี่ยนผลตรวจหรือเหตุการณ์หน้างานให้เป็นธุรกรรมธุรกิจ จึงต้องจัดการรหัสหลัก สถานะอนุมัติ และการส่งซ้ำอย่างรอบคอบ การอ่านภาพไม่ควรสร้างเอกสารบัญชีหรือปรับยอดคลังทันทีโดยข้ามกฎธุรกิจ
ERP คือระบบข้อมูลธุรกิจที่เชื่อมงานผลิต คลัง และเอกสาร ผลภาพเป็นหลักฐานหนึ่ง ไม่ใช่การอนุมัติรับสินค้า master data คือรหัสวัสดุ หน่วย และสถานที่ที่ใช้ร่วมกัน หากกล้องอ่านถูกแต่ผูกกับรหัสเก่า ธุรกรรมก็ยังผิด การออกแบบควรทำให้คนตรวจทั้งความถูกต้องของผลอ่านและความหมายในธุรกิจก่อนมีผลต่อยอดจริง
idempotency หมายถึงส่งคำขอเดิมซ้ำแล้วไม่เพิ่มผลธุรกรรมซ้ำ ต่างจากการพยายามส่งให้สำเร็จเพียงอย่างเดียว คิว staging เป็นพื้นที่พักให้ตรวจข้อมูลก่อนเข้ากระบวนการจริง เพิ่มเวลาเล็กน้อยแต่ช่วยแก้รายการผิดอย่างเป็นระบบ ต้องกำหนดว่าใครอนุมัติ ใครแก้ และใครกระทบยอด โดยไม่ให้บัญชีบริการมีสิทธิ์มากกว่าที่จำเป็นเพราะต้องการเชื่อมให้สะดวก
เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน
ตัวอย่างเชิงออกแบบ
ตัวอย่างเชิงออกแบบ: ผลตรวจล็อตสร้างรายการรอทบทวนที่ผูกใบสั่งผลิต เมื่อผู้มีสิทธิ์ยืนยันจึงบันทึกสถานะคุณภาพ การส่งข้อความซ้ำต้องไม่สร้างรายการรับของหรือรายการตัดสต็อกซ้ำ
สถานการณ์สมมติ: ผลตรวจถูกส่งแล้วแต่คำตอบกลับหาย ผู้ส่งไม่รู้ว่าปลายทางรับหรือยัง ควรใช้รหัสเหตุเดิมตรวจสถานะหรือส่งซ้ำตามสัญญา ไม่สร้างรหัสใหม่ทุกครั้ง มิฉะนั้น ERP อาจเห็นเป็นงานคนละรายการ การตอบว่ารับแล้วต้องแยกจากสถานะอนุมัติและลงรายการสำเร็จให้ผู้ดูแลเข้าใจ
ทางเลือกคือส่งผลตรวจทันทีเข้าคิวรอหรือรวมเป็นชุดตามรอบงาน แบบแรกข้อมูลสดกว่าแต่มีรายการมาก แบบหลังลดภาระเชื่อมแต่แก้ปัญหาช้าลง เจ้าของผลิตและคลังต้องเลือกตามความต้องการ แล้วทดลองคำขอซ้ำ ข้อมูลหน่วยผิด และ ERP หยุดในระบบทดสอบ ไม่ลองตัดสต็อกจริงเพื่อพิสูจน์การเชื่อม
ข้อมูลนำเข้าและเงื่อนไขเริ่มต้น
เตรียม API contract master data หน่วยนับ รหัสโรงงานและล็อต พร้อมนโยบายอนุมัติ เก็บ correlation ID และเวอร์ชันข้อมูลเพื่อไล่กลับจากเอกสารไปยังเหตุการณ์ต้นทาง
API contract คือข้อตกลงรูปข้อมูลและความหมายคำตอบ correlation ID ใช้ตามงานเดียวกันข้ามระบบ ควรมีรหัสเหตุถาวรและเวลาแหล่งกำเนิด ไม่ใช้เวลาที่ส่งซ้ำเป็นตัวบ่งชี้งานใหม่
ผลควรมีสถานะรับ ตรวจ อนุมัติ และล้มเหลวแยกกัน พร้อมรหัสเอกสารปลายทางถ้ามีจริง หน่วยกล่องกับชิ้นต้องแปลงตามข้อมูลหลักที่อนุมัติ ไม่เดาจำนวนบรรจุจากข้อความทั่วไปบนภาพ
ขั้นตอนทดลองและเชื่อมงาน
- 1ตกลง mapping รหัสและหน่วยโดยเจ้าของข้อมูลธุรกิจ
- 2ส่งเข้า staging พร้อม validation และ idempotency key
- 3ทดสอบ retry การย้อนรายการ และการกระทบยอดเมื่อ ERP ปิดปรับปรุง
การประเมินและเกณฑ์ตรวจรับ
ตรวจจำนวนและยอดธุรกรรมเทียบเหตุการณ์ต้นทาง รวมกรณีซ้ำ ลำดับสลับ และตอบกลับช้า การตรวจรับต้องพิสูจน์ว่างานที่ล้มเหลวเข้าคิวแก้ไขได้และไม่เกิดผลทางบัญชีซ้ำจากการ retry
ใช้ข้อมูลทดสอบที่มีรายการซ้ำและเวอร์ชันแก้ไข แล้วตรวจยอดทั้งก่อนและหลังรันซ้ำ รวมกรณีงานล้มหลังปลายทางรับแต่ก่อนบันทึกสถานะผู้ส่ง เพื่อดูว่ากู้คืนได้โดยไม่เพิ่มยอด
ให้เจ้าของธุรกิจกระทบยอดเอกสารตัวอย่างกับภาพและคำอนุมัติ ตรวจคิวแก้ไขว่ามีผู้รับผิดชอบและเหตุผล ไม่ผ่านงานเพียงเพราะไม่มีข้อความผิดพลาดในบันทึกเทคนิค
เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน
กรณีล้มเหลวและข้อจำกัด
API ตอบสำเร็จอาจหมายถึงเพียงรับเข้าคิวไม่ใช่ลงรายการแล้ว หน่วยนับและรหัสวัสดุที่เปลี่ยนทำให้ข้อมูลถูกชนิดแต่ผิดความหมาย ต้องมีเจ้าของกระบวนการอนุมัติ ไม่ถือว่าการเชื่อมได้เท่ากับรับรองความถูกต้องทางบัญชี
การย้อนธุรกรรมอาจต้องสร้างรายการชดเชยตามกฎ ERP ไม่ใช่ลบหลักฐานเดิม ควรออกแบบร่องรอยการแก้และแยกสิทธิ์ผู้ตรวจจากผู้อนุมัติ เพื่อให้ตรวจย้อนหลังได้อย่างเป็นธรรม
เอกสารอาจมีข้อมูลคู่ค้าและบุคคล จำกัดเฉพาะฟิลด์ที่ธุรกิจต้องใช้และสิทธิ์ตามหน้าที่ การเสนอการเชื่อมระบบใดต้องตรวจ API และเวอร์ชันจริง ไม่ใช่คำอ้างว่ารองรับ ERP ทุกยี่ห้ออยู่แล้ว
รายการตรวจสอบก่อนใช้งาน
- ธุรกรรมส่งซ้ำมีผลเพียงครั้งเดียวหรือไม่
- มีรายงานกระทบยอดและคิวแก้ไขหรือไม่
- แยกการรับข้อมูลจากการอนุมัติธุรกิจหรือไม่