ทีมบัญชีส่วนใหญ่มักพบช่องโหว่ของระบบอนุมัติจัดซื้อแบบยากลำบาก ใบแจ้งหนี้ผู้ขายถูกบันทึกเกินกว่าจำนวนที่รับสินค้าจริง คำสั่งซื้อมูลค่าสูงหลุดออกไปโดยไม่มีใครเหนือผู้จัดซื้อเห็นเลย การวางระบบอนุมัติจัดซื้อ Odoo ให้ถูกต้องไม่ใช่แค่เปิดการตั้งค่าใดการตั้งค่าหนึ่ง แต่คือการตัดสินใจอย่างตั้งใจ ว่าจุดตรวจสอบควรอยู่ตรงไหนระหว่างใบขอราคา (RFQ) จนถึงใบแจ้งหนี้ผู้ขายที่ชำระเงินแล้ว
นี่คือการวางระบบที่เราใช้เป็นแนวทางในงานจัดซื้อส่วนใหญ่ ไม่ว่าลูกค้าจะมีคลังสินค้าเดียวหรือเป็นกลุ่มบริษัทหลายนิติบุคคล งานส่วนใหญ่ใช้แค่การตั้งค่า ไม่ต้องเขียนโค้ดเพิ่ม
ขั้นตอน RFQ ในระบบอนุมัติจัดซื้อ Odoo
RFQ ใน Odoo คือใบสั่งซื้อที่อยู่ในสถานะร่าง ยังไม่ใช่ข้อผูกพัน ความแตกต่างนี้สำคัญกว่าที่หลายทีมให้ความสำคัญ ข้อผิดพลาดที่พบบ่อยคือการข้ามขั้นตอน RFQ ไปเลย แล้วสร้างใบสั่งซื้อที่ยืนยันแล้วทันที วิธีนี้ทำให้เสียจุดเดียวที่ผู้จัดซื้อสามารถเปรียบเทียบใบเสนอราคาจากผู้ขายหลายราย ก่อนที่จะผูกพันเงิน
เราแนะนำให้แยกขั้นตอนเหล่านี้ให้ชัดเจนในงานประจำวันของผู้จัดซื้อ:
- สร้าง RFQ จากคำขอจัดซื้อ กฎการสั่งซื้อซ้ำ (reorder rule) หรือความต้องการที่สร้างด้วยมือ
- ส่งให้ผู้ขายหนึ่งรายหรือมากกว่า และบันทึกราคาและระยะเวลาส่งมอบที่เสนอ
- เปรียบเทียบตัวเลือกก่อนยืนยัน โดยเฉพาะสินค้าที่ไม่ใช่สต็อกหรือการซื้อสินทรัพย์ถาวร
- ยืนยันหลังจากเปรียบเทียบแล้วเท่านั้น การยืนยันจะเปลี่ยน RFQ เป็นใบสั่งซื้อและกระตุ้นกฎการอนุมัติหากถึงวงเงินที่ตั้งไว้
การข้ามขั้นตอนเปรียบเทียบไม่ได้ทำให้ระบบ Odoo พัง แต่จะค่อย ๆ เปลี่ยนขั้นตอน RFQ ให้กลายเป็นแค่เอกสาร ไม่ใช่จุดควบคุม
ตั้งวงเงินอนุมัติจัดซื้อ Odoo โดยไม่สร้างคอขวด
การตั้งค่าอนุมัติจัดซื้อพื้นฐานของ Odoo เป็นค่าตัวเลขเดียว คำสั่งซื้อที่เกินจำนวนนี้ต้องให้ผู้ใช้ที่มีสิทธิ์ผู้จัดการจัดซื้อเป็นผู้ยืนยัน ต่ำกว่านั้นผู้จัดซื้อสามารถยืนยันเองได้ วิธีนี้มีประโยชน์แต่ค่อนข้างหยาบ และส่วนที่หยาบนี้เองคืองานปรับแต่งส่วนใหญ่ที่เราทำ
สิ่งที่เราตรวจสอบก่อนตั้งตัวเลขวงเงิน:
- วงเงินควรแตกต่างกันตามบริษัทหรือไม่ หากธุรกิจมีหลายนิติบุคคลอยู่ในฐานข้อมูลเดียว
- หมวดหมู่สินค้าบางประเภท เช่น สินทรัพย์ถาวร บริการ งานรับเหมาช่วง ควรมีวงเงินต่ำกว่าการเติมสต็อกตามปกติหรือไม่
- ผู้อนุมัติที่แท้จริงคือใคร และบุคคลนั้นพร้อมทำงานทุกวันหรือไม่ วงเงินที่ไม่มีผู้อนุมัติสำรองจะกลายเป็นแค่คิวรออนุมัติ
ตัวเลขเดียวที่ใช้ทั่วทั้งองค์กรอธิบายให้ผู้ตรวจสอบบัญชีฟังง่าย แต่มักไม่เหมาะกับธุรกิจจริง การตั้งต่ำเกินไปจะทำให้ผู้จัดการกลายเป็นคอขวดของการสั่งซื้อซ้ำตามปกติ การตั้งสูงเกินไปก็ทำลายจุดประสงค์ของการมีจุดตรวจสอบไปเลย โดยทั่วไปเราเริ่มจากตัวเลขที่ดึงมาจากประวัติใบสั่งซื้อย้อนหลังสิบสองเดือน ไม่ใช่ตัวเลขกลม ๆ ที่มีคนเลือกในที่ประชุม
สำหรับองค์กรที่ต้องการการอนุมัติหลายระดับอย่างแท้จริง โมดูลจัดซื้อของ Odoo รองรับเรื่องนี้ในตัวอยู่แล้ว สามารถกำหนดระดับการอนุมัติหลายชั้นผูกกับตำแหน่งงาน โดยแต่ละผู้อนุมัติมีวงเงินขั้นต่ำและขั้นสูงเป็นของตัวเอง หัวหน้าทีมอาจอนุมัติได้ถึงจำนวนหนึ่ง หัวหน้าแผนกอนุมัติได้สูงกว่านั้น และฝ่ายบัญชีอนุมัติส่วนที่เกินไปจากนั้น ระบบจะจัดเส้นทางอนุมัติตามมูลค่าและหมวดหมู่โดยอัตโนมัติ ไม่ต้องใช้โมดูลกำหนดเองในการตั้งค่าส่วนนี้ แต่การจับคู่สายอนุมัติให้ตรงกับผังองค์กรจริงต้องใช้การวางแผนอย่างจริงจัง และเรามักสร้างส่วนนี้เป็นส่วนหนึ่งของงานปรับแต่งระบบ Odooที่กว้างขึ้น เมื่อตรรกะการอนุมัติต้องเชื่อมโยงกับโมดูลอื่นด้วย
ข้อสังเกตเรื่องการมอบอำนาจ
สิทธิ์การอนุมัติใน Odoo ขึ้นอยู่กับกลุ่มผู้ใช้และตำแหน่งงาน ไม่ใช่เพียงรายบุคคล การให้สิทธิ์ระดับผู้จัดการแก่ใครสักคนเพื่ออนุมัติคำสั่งซื้อมูลค่าสูงเพียงครั้งเดียว อาจทำให้คนนั้นมองเห็นข้อมูลจัดซื้อเกินขอบเขตของคำสั่งซื้อนั้น รวมถึงราคาที่ผู้จัดซื้อคนอื่นต่อรองไว้ด้วย นี่คือข้อแลกเปลี่ยนที่ควรพูดถึงให้ชัดเจน ก่อนให้สิทธิ์นี้เป็นทางลัดในช่วงที่มีคนลาพักร้อน
3-Way Matching: ใบสั่งซื้อ ใบรับสินค้า และใบแจ้งหนี้
นี่คือการควบคุมที่ป้องกันการจ่ายเงินเกินได้จริง และขึ้นอยู่กับการให้เอกสารสามฉบับตรงกัน:
| เอกสาร | บันทึกอะไร | ใครเป็นผู้สร้าง |
|---|---|---|
| ใบสั่งซื้อ | จำนวนและราคาที่ตกลงกัน | ผู้จัดซื้อ |
| ใบรับสินค้า (incoming transfer) | จำนวนที่รับเข้าคลังจริง | ฝ่ายคลังสินค้า |
| ใบแจ้งหนี้ผู้ขาย | จำนวนเงินที่ผู้ขายต้องการให้ชำระ | ฝ่ายบัญชี จากใบแจ้งหนี้ของผู้ขาย |
Odoo จะเปรียบเทียบเอกสารเหล่านี้โดยอัตโนมัติ เมื่อนโยบายควบคุมการออกบิลของสินค้าหรือใบสั่งซื้อถูกตั้งให้ออกบิลตามจำนวนที่รับจริง แทนที่จะออกตามจำนวนที่สั่งซื้อ ด้วยการตั้งค่านี้ ใบแจ้งหนี้ผู้ขายจะดึงจำนวนมาได้ไม่เกินกว่าที่ใบรับสินค้ายืนยัน รายการในบิลจะแสดงจำนวนที่รับจริงเป็นค่าเริ่มต้น ไม่ใช่จำนวนที่สั่งซื้อ หากผู้ขายออกใบแจ้งหนี้ก่อนสินค้ามาถึง บิลนั้นจะค้างอยู่ที่จำนวนศูนย์จนกว่าจะมีการบันทึกใบรับสินค้า นี่คือจุดเสียดทานที่ตั้งใจให้เกิดขึ้น ไม่ใช่ข้อบกพร่องของระบบ
การออกบิลตามจำนวนที่สั่งซื้อแทน จะตัดการตรวจสอบนี้ออกไปทั้งหมด ฝ่ายบัญชีจะบันทึกบิลได้ทันทีที่ยืนยันใบสั่งซื้อ ไม่ว่าสินค้าจะมาถึงจริงหรือไม่ การตั้งค่านี้มีไว้สำหรับกรณีบริการหรือการส่งตรงจากผู้ขาย (drop-ship) ที่ไม่มีขั้นตอนรับสินค้าแยกต่างหาก แต่หากใช้กับสินค้าที่เป็นสต็อก จะทำลายจุดประสงค์ของ 3-Way Matching ไปเลย
ข้อจำกัดที่ควรรู้ไว้: การจับคู่ของ Odoo เปรียบเทียบที่จำนวน ส่วนความต่างของราคาระหว่างใบสั่งซื้อกับใบแจ้งหนี้ไม่ได้ถูกบล็อกการบันทึกโดยค่าเริ่มต้น ผู้ขายอาจออกบิลด้วยราคาต่อหน่วยที่ต่างจากที่เสนอไว้ Odoo จะแสดงเพียงคำเตือนบนบิลเท่านั้น ไม่ได้หยุดการบันทึก การจับความคลาดเคลื่อนของราคายังต้องอาศัยคนในฝ่ายบัญชีอ่านคำเตือนนั้นจริง หรือมีนโยบายกระทบยอดที่ตรวจสอบรายงานความคลาดเคลื่อนเป็นระยะ
สร้าง Audit Trail ที่ผ่านการตรวจสอบได้จริง
การเปลี่ยนสถานะทุกครั้งในใบสั่งซื้อ และบิลที่บันทึกทุกใบ จะมีการบันทึกเวลาและผู้ใช้ไว้ มองเห็นได้ใน chatter log ของเรคคอร์ดนั้น สิ่งนี้มีประโยชน์แต่เป็นลักษณะตั้งรับ ไม่มีใครเข้าไปดู chatter log จนกว่าจะมีปัญหาเกิดขึ้นแล้ว audit trail ที่ผ่านการตรวจสอบจริงต้องสร้างจากพฤติกรรมเพิ่มเติมเหล่านี้:
- กำหนดให้ต้องระบุเหตุผลในช่องบันทึกภายใน เมื่อมีการยืนยันคำสั่งซื้อเกินวงเงินปกติผ่านข้อยกเว้นที่ได้รับอนุมัติ
- กระทบยอด journal items ของใบแจ้งหนี้ผู้ขายกับวันที่รับสินค้า ไม่ใช่แค่วันที่ของบิล เพื่อให้ตรวจสอบข้อพิพาทเรื่องระยะเวลาส่งมอบได้
- ล็อกงวดบัญชีเมื่อปิดบัญชีสิ้นเดือน เพื่อไม่ให้บิลถูกย้อนวันที่เข้าไปในงวดที่ปิดแล้วโดยไม่มีการกลับรายการอย่างชัดเจน
- จัดทำรายงานความคลาดเคลื่อนของราคาผู้ขายอย่างน้อยเดือนละครั้ง หากไม่ได้บังคับการจับคู่ราคาตอนบันทึกบัญชี
ไม่มีข้อไหนที่เป็นเรื่องแปลกใหม่ สิ่งเหล่านี้ใกล้เคียงกับสุขอนามัยทางบัญชีมากกว่าการตั้งค่า Odoo แต่การตั้งค่าคือสิ่งที่ทำให้สุขอนามัยนี้เกิดขึ้นได้ หรือเป็นไปไม่ได้เลย
เมื่อการตั้งค่าอนุมัติจัดซื้อ Odoo แบบพื้นฐานยังไม่พอ
การอนุมัติหลายระดับตามตำแหน่งงานที่มีมาให้ครอบคลุมผังองค์กรส่วนใหญ่ แต่ไม่ครอบคลุมการแบ่งอนุมัติตามศูนย์ต้นทุน การส่งผู้ขายบางรายให้ผ่านการตรวจสอบเพิ่มเติม หรือวงเงินแบบหลายสกุลเงินที่แปลงค่าตามอัตราแลกเปลี่ยนสด ช่องว่างเฉพาะจุดเหล่านี้คือสิ่งที่เรามักเพิ่ม server actions หรือกฎอัตโนมัติเฉพาะเจาะจงเข้าไป มากกว่าจะสร้างโมดูลกำหนดเองทั้งหมด เพราะงานหลักของขั้นตอนจัดซื้อพื้นฐานทำไว้ให้แล้ว หากกำลังวางแผนเรื่องนี้เป็นส่วนหนึ่งของการขึ้นระบบที่กว้างขึ้น หน้าบริการวางระบบ Odooของเราอธิบายวิธีที่เราจัดลำดับการควบคุมจัดซื้อควบคู่ไปกับการขึ้นระบบคลังสินค้าและบัญชี
ข้อควรระวังที่ต้องพูดตรง ๆ อีกข้อหนึ่ง การเข้มงวดการควบคุมอนุมัติจัดซื้อจะเพิ่มขั้นตอนให้ผู้จัดซื้อเสมอ คนที่ทำหน้าที่จัดซื้อจะรู้สึกถึงผลกระทบนี้ก่อนคนที่ร้องขอให้มีการควบคุม เราแนะนำให้ทดสอบวงเงินและนโยบายการจับคู่กับใบสั่งซื้อจริงบางส่วนก่อน เป็นเวลาสองถึงสามสัปดาห์ ก่อนนำไปใช้ทั่วทั้งบริษัท เพื่อให้จุดเสียดทานถูกปรับให้พอดี ไม่ใช่บังคับใช้ทั้งหมดในครั้งเดียว
หากงานจัดซื้อเป็นส่วนหนึ่งของการขึ้นระบบ ERP ที่กว้างขึ้น ซึ่งครอบคลุมถึงรูปแบบ ERP ตามแต่ละอุตสาหกรรมและการเริ่มงานกับผู้ขายรายใหม่ด้วย ควรกลับมาทบทวนกฎการอนุมัติอีกครั้งเมื่อระบบขึ้นใช้งานจริงและเริ่มมีปริมาณการสั่งซื้อจริงไหลเข้าสู่ระบบ ปริมาณสั่งซื้อจริงจะเผยให้เห็นกรณีปลีกย่อยที่การประเมินช่วงออกแบบมองข้ามไป สำหรับรูปแบบจัดซื้อเฉพาะอุตสาหกรรม งานปรับแต่งระบบ Odoo ตามอุตสาหกรรมของเรามักเริ่มต้นจากการทบทวนลักษณะนี้เอง
