อนุมัติซื้อกับอนุมัติจ่าย ทำไมควรแยกกัน

อนุมัติซื้อ: ตรวจความจำเป็น ผู้ขาย ปริมาณ ราคา และเงื่อนไขก่อนผูกพัน

ก่อนส่ง Purchase Order ควรรู้ว่าใครร้องขอ ซื้ออะไร ปริมาณเท่าไร ราคาหรือฐานราคาใด ใช้งบหรืองานใด และเงื่อนไขส่งมอบหรือชำระเป็นอย่างไร ถ้าข้อมูลเหล่านี้เปลี่ยนสาระสำคัญหลังอนุมัติ ต้องมีกติกาว่าระดับใดต้องกลับมาทบทวนใหม่

เอกสาร ERPNext อธิบาย Purchase Order ว่าเป็นข้อตกลงกับผู้ขายสำหรับรายการและเงื่อนไขการซื้อ และรองรับ payment terms ที่อาจกำหนดจ่ายบางส่วนก่อนส่งของหรือหลังรับของได้ นี่ช่วยให้เห็นว่าการอนุมัติซื้อเกิดก่อนหลักฐานการปฏิบัติงานครบทั้งหมด

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

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

ก่อนเงินออก ให้ตรวจเอกสารที่เกี่ยวข้องตามลักษณะรายการ เช่น PO หรือข้อตกลง หลักฐานรับของ/รับบริการ ใบแจ้งหนี้ การหักลดหรือคืนของ และข้อมูลบัญชีผู้รับเงิน ถ้าเป็นมัดจำต้องมีเหตุผลและเงื่อนไขที่อนุมัติไว้ ไม่จำเป็นต้องรอรับของเต็มจำนวนทุกกรณี

ERPNext Payment Request แยกคำขอชำระจากผลของการชำระจริง และระบุว่าการ submit Payment Request ไม่ได้ทำให้ invoice ถูกชำระหรือสร้าง bank transaction โดยตัวมันเอง จึงเป็นตัวอย่างที่ชัดว่าการขอจ่ายกับการเกิดเงินออกไม่ใช่สถานะเดียวกัน

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

ออกแบบสถานะให้บอกว่าตัดสินใจอะไรไปแล้ว

ตัวอย่างสถานะ: Draft Request → Purchase Approved → Ordered → Partially Received → Ready for Payment Review → Payment Approved → Paid → Reconciled แต่ไม่จำเป็นต้องใช้ชื่อเดียวกันทุกองค์กร จุดสำคัญคือผู้ใช้มองแล้วรู้ว่ารายการผ่านการตัดสินใจเรื่องใดและหลักฐานอะไรยังขาด

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

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

ข้อยกเว้นต้องไม่บังคับให้คนโกงสถานะ

กรณีของด่วน มัดจำ รายการบริการที่ไม่มีการรับสต็อก หรือยอดใบแจ้งหนี้ต่างจาก PO อาจมีเส้นทางเฉพาะได้ แต่ต้องระบุเหตุผล ผู้อนุมัติ และหลักฐานชดเชย เช่น contract, service acceptance หรือคำอธิบายส่วนต่าง

ถ้าระบบยอมให้จ่ายเฉพาะเมื่อสถานะ “รับครบ” ผู้ใช้อาจกดรับครบทั้งที่ของยังไม่มาเพื่อให้กระบวนการเดิน ซึ่งทำลายความหมายของข้อมูล วิธีที่ดีกว่าคือสร้าง exception path ที่ตรวจได้แทนการบังคับให้ข้อมูลไม่ตรงความจริง

เริ่มจากตารางสิทธิ์ขั้นต่ำก่อนออกแบบหน้าจอ

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

เมื่อออกแบบระบบ ให้ทดสอบกรณีผู้อนุมัติไม่อยู่ การแก้ supplier bank account หลังอนุมัติ ยอดจ่ายเกิน PO และการจ่ายหลายบิลรวมกัน เกณฑ์ผ่านคือระบบบอกได้ว่าใครตัดสินใจอะไรเมื่อใด ไม่ใช่เพียงรายการจ่ายสำเร็จ

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

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