เมื่อเอกสารเปลี่ยนหลังอนุมัติ ต้องตรวจอะไรใหม่

แยก Cosmetic Change ออกจาก Material Change

เริ่มจากแบ่ง field เป็นอย่างน้อยสามกลุ่ม: ข้อมูลแสดงผลที่ไม่เปลี่ยนสาระ, ข้อมูลปฏิบัติการที่อาจกระทบการส่งต่อ และข้อมูลสาระสำคัญที่กระทบราคา คู่ค้า ปริมาณ สิทธิ์ การจ่าย หรือบัญชี ตัวอย่าง material change อาจเป็น supplier, quantity, price, bank account หรือ UoM ขึ้นอยู่กับเอกสาร

อย่าใช้กฎ “แก้หลังอนุมัติไม่ได้ทั้งหมด” จนผู้ใช้หาทางแก้นอกระบบ และอย่าเปิด “แก้ได้ทุก field” จน approval ไม่มีความหมาย เป้าหมายคือกำหนดว่าการเปลี่ยนชนิดใดต้อง review ระดับใด

รักษา Version เดิมแทนการเขียนทับประวัติ

ERPNext อธิบายว่าการแก้ submitted document โดยทั่วไปต้อง Cancel แล้ว Amend เอกสารใหม่ และหากมีเอกสารลูกที่อ้างอยู่ อาจต้องจัดการ dependency ก่อน หลักคิดที่นำมาใช้ได้คือเอกสารอนุมัติแล้วควรมี version/lineage มากกว่าถูกแก้จนไม่รู้ว่าอะไรเคยได้รับอนุมัติ

หากระบบรองรับการแก้บาง custom field หลัง submit ก็ควรใช้เฉพาะข้อมูลที่องค์กรจัดว่าไม่เปลี่ยนสาระ และยังต้องเก็บว่าใครแก้ เมื่อใด และจากค่าอะไรเป็นอะไร

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

เขียน Re-approval Rules ให้ผูกกับชนิดการเปลี่ยน

ตัวอย่างกติกา: เปลี่ยนคำอธิบาย → ไม่ต้อง re-approve; เปลี่ยนวันที่ส่งมอบ → แจ้งผู้รับผิดชอบ; เปลี่ยน supplier หรือ bank account → กลับไป review คู่ค้า; เปลี่ยนราคาเกิน tolerance → re-approve ตามวงเงิน; เปลี่ยน UoM/pack quantity → ทบทวน comparison และ cost basis ใหม่

กติกาควรคำนวณจาก before/after values และ policy version ที่ใช้ในเวลานั้น ไม่ใช่ใช้เพียง flag ว่า document ถูกแก้ เพราะการเปลี่ยน 1 ตัวอักษรกับการเปลี่ยนบัญชีผู้รับเงินไม่ควรถูกจัดเป็นความเสี่ยงระดับเดียวกัน

หลังแก้ ต้องรู้ว่าเอกสารปลายทางใดได้รับผลกระทบ

ถ้า PO ถูกแก้หลังมี receipt หรือ invoice แล้ว ให้ตรวจว่า linked documents ยังสอดคล้องหรือไม่ เช่น quantity/rate/UoM, supplier identity, payment terms หรือ allocation ถ้าระบบปล่อยให้ต้นทางแก้โดยปลายทางไม่รู้ จะเกิด drift ที่เห็นชัดตอนกระทบยอดภายหลัง

ทำ impact list ว่า change นี้ต้อง invalidate quotation comparison, approval decision, receipt expectation, invoice match, payment request หรือ report ใดบ้าง จากนั้นให้แต่ละ downstream state เปลี่ยนเป็น Need Review แทนการถือว่าผ่านต่ออัตโนมัติ

หลักฐานการแก้ต้องตอบได้ว่า “ใครเปลี่ยนอะไร เพราะอะไร และใครยอมรับผล”

Change record ควรเก็บ document/version, before/after, field group, reason, evidence, requester, approver, timestamp และ policy/rule ที่ใช้ตัดสินใจ ถ้ามีการ override ให้บันทึกผู้มีอำนาจและเหตุผลแยกจากคำขอปกติ

UAT ควรทดสอบอย่างน้อยการแก้ field ที่ไม่สาระ, การเปลี่ยน supplier, price เกิน tolerance, bank account หลัง payment approval และการแก้เอกสารที่มี downstream documents อยู่แล้ว เพื่อให้มั่นใจว่าระบบไม่รักษา Approved แบบผิดบริบท

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

Approval ที่ตรวจสอบได้ต้องผูกกับสิ่งที่ถูกอนุมัติใน version นั้น เมื่อข้อมูลสาระเปลี่ยน ระบบจึงควรถามใหม่ว่า approval เดิมยังใช้ได้หรือไม่ แทนการรักษาป้าย Approved ไว้โดยไม่ดูบริบท