ก่อนเชื่อมข้อมูลเข้า Acc Flow ใครเป็นเจ้าของข้อเท็จจริง

กำหนด Source of Truth ระดับ field ไม่ใช่แค่ระดับระบบ

ระบบขายอาจเป็น authority ของเลข order และยอดสินค้า PMS อาจเป็น authority ของ reservation event ธนาคารเป็นหลักฐานของ cash movement ขณะที่ฝ่ายบัญชีเป็นผู้ยืนยัน account/tax treatment ในบางรายการ อย่าประกาศว่าระบบหนึ่งเป็น source of truth ของ “ทุกอย่าง” ถ้าแต่ละ field มีเจ้าของต่างกัน

ทำ data contract ที่ระบุ field name, business meaning, source system, owner, edit permission, effective time และสิ่งที่เกิดเมื่อค่าเปลี่ยนหลังส่งไปแล้ว ตารางนี้ควรถูก review ก่อนเขียน integration code

แยกหลักฐานต้นทางออกจากคำตัดสินทางบัญชี

ภาพใบเสร็จ statement, receiving record หรือ PMS transaction เป็นหลักฐานของเหตุการณ์ ไม่จำเป็นต้องเท่ากับรายการบัญชีที่อนุมัติแล้ว ระบบอาจช่วยอ่านหรือเสนอ mapping ได้ แต่ควรเก็บ source evidence และ proposed values แยกจาก approved accounting values

เมื่อผู้ตรวจแก้ proposed account หรือ tax mapping ให้เก็บผู้แก้ เวลา เหตุผล และค่าก่อนแก้ ไม่ควร overwrite จนย้อนดูไม่ได้ว่าระบบต้นทางส่งอะไรมาและคนตัดสินใจอะไรภายหลัง

ทุก transaction handoff ต้องมี identity ที่ป้องกันการส่งซ้ำ

กำหนด external transaction ID หรือ composite key ที่คงที่สำหรับเหตุการณ์เดียวกัน พร้อม source system และ version/event time ถ้า request เดิมถูก retry หลัง timeout ปลายทางควรตรวจได้ว่าเป็นเหตุการณ์เดิม ไม่สร้าง transaction ซ้ำเพียงเพราะได้รับข้อความอีกครั้ง

ถ้าข้อมูลถูกแก้ ให้ตัดสินใจชัดว่าเป็น update ของ record เดิม, reversal + new entry, adjustment หรือ new version ตามความหมายของธุรกิจ อย่าใช้การ delete/recreate โดยไม่มี audit trailเป็นทางลัด

เตรียมกติกาเมื่อสองระบบให้ข้อมูลไม่ตรงกัน

ตัวอย่างสมมติ: ระบบจัดซื้อบอก supplier A แต่เอกสาร invoice ระบุ supplier B หรือยอดรับของ 10 แต่ invoice เรียกเก็บ 12 อย่าเลือกค่าที่ใหม่กว่าหรือมาจาก API โดยอัตโนมัติ ให้เปิด exception พร้อมหลักฐานและ owner ที่มีสิทธิ์ตัดสิน

ความขัดแย้งบางอย่างแก้ได้ด้วย master mapping บางอย่างต้องให้คนตรวจ และบางอย่างต้องย้อนกลับไปแก้ต้นทาง Data contract ควรบอก conflict policy ล่วงหน้า เพื่อไม่ให้ logic ถูกซ่อนอยู่ในโค้ดหรือความจำของเจ้าหน้าที่

Acc Flow ควรรับข้อมูลที่มี lineage มากกว่ารับยอดรวมที่อธิบายไม่ได้

Linda แยก Acc Flow และกลุ่ม Vertex ออกจากบริการวาง ERP และระบุในหน้า Applications ว่าต้องยืนยัน module, permissions, data handoff และ service scope ก่อน onboarding แนวทางนี้สอดคล้องกับการเชื่อมแบบมีขอบเขต: ให้แต่ละระบบส่งข้อเท็จจริงที่ตนรับผิดชอบพร้อม reference แล้วให้ accounting workflow ตรวจต่อ

ก่อนเปิดใช้จริง ให้ทดสอบ source record ปกติ รายการซ้ำ update หลังอนุมัติ ข้อมูลขัดกัน และการ replay หลังระบบล่ม พร้อม control total และ reconciliation ถ้าการส่งต่อปัจจุบันเป็น file import ที่คนตรวจ อย่าเรียกว่า real-time API; อธิบายตามสิ่งที่รองรับจริง

แหล่งอ้างอิง: [1]

นำไปใช้กับธุรกิจของคุณ

Integration ที่ดีไม่ได้เริ่มจากจำนวน endpoint แต่เริ่มจากความชัดว่าใครเป็นเจ้าของข้อเท็จจริง เมื่อเกิดความขัดแย้งใครตัดสิน และปลายทางย้อนกลับไปหาหลักฐานต้นทางได้หรือไม่