การนำระบบบริหารการปรับราคาซื้อในอุตสาหกรรมการผลิต: การออกแบบวันมีผล, PO คงค้าง และความแตกต่างของใบแจ้งหนี้

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

บทความนี้ออกแบบสำหรับโรงงานในประเทศไทย โดยจัดระเบียบตั้งแต่การแจ้งปรับราคาจากซัพพลายเออร์ การอนุมัติ การกำหนดวันมีผล การเปลี่ยนแปลงราคาสำหรับ PO คงค้าง ไปจนถึงการตรวจสอบใบแจ้งหนี้ ไม่ได้กล่าวถึงการเลือกระบบบริหารจัดซื้อโดยรวม หรือการคำนวณต้นทุนมาตรฐาน (อ่านเพิ่มเติมที่ การบริหารต้นทุนมาตรฐานในโรงงาน) แต่จะโฟกัสที่ “แม้เป็นชิ้นส่วนเดียวกัน ราคาที่ใช้จริงอาจต่างกันตามวันทำรายการและเงื่อนไขสัญญา” และระบบจะอธิบายข้อยกเว้นนี้ได้หรือไม่

สรุป: กำหนด “ขอบเขตการใช้ราคา” ก่อนมาสเตอร์ราคา

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

ในการออกแบบระบบ ควรเชื่อมโยง ①คำขอปรับราคาและหลักฐาน, ②ราคาเก่า-ใหม่ พร้อมสกุลเงินและหน่วย, ③เงื่อนไขการมีผล, ④PO คงค้างที่เกี่ยวข้อง, ⑤การอนุมัติและข้อตกลงกับซัพพลายเออร์, ⑥เวอร์ชันของ PO, ⑦การตรวจสอบกับการรับสินค้าและใบแจ้งหนี้ ด้วยรหัสปรับราคาเดียวกัน นี่คือโครงสร้างขั้นต่ำ Microsoft Business Central มีตารางราคาซื้อแยกตามซัพพลายเออร์และมีวันมีผล สามารถพิจารณาราคาตามรหัสสินค้า ปริมาณ หน่วย สกุลเงิน และวันที่ ส่วน SAP ก็มีแนวคิด “ช่วงเวลาที่มีผล” ในเงื่อนไขการซื้อ แต่ฟังก์ชันมาตรฐานเหล่านี้ไม่ได้กำหนดอัตโนมัติว่าจะจัดการกับ PO ที่ออกไปแล้วอย่างไร ต้องทดสอบแยกส่วนที่ใช้ฟังก์ชันมาตรฐาน กับส่วนที่ต้องอนุมัติ แก้ไข PO หรือจัดการข้อยกเว้น Microsoft Business Central: ราคาซื้อ / SAP: เงื่อนไขตามช่วงเวลา

ทำไมการปรับราคาซื้อจึงติดขัดในโรงงานบ่อย

หน่วยของ “ราคา” แตกต่างกันในแต่ละฝ่าย

ซัพพลายเออร์อาจแจ้งราคาเป็น “ต่อชิ้น”, “ต่อ 1,000 ชิ้น” หรือ “ต่อกิโลกรัม” ขณะที่มาสเตอร์จัดซื้อใช้หน่วยกล่อง สต็อกใช้จำนวนชิ้น ฝ่ายต้นทุนใช้หน่วยน้ำหนัก ใบแจ้งหนี้อาจเป็นเงินตราต่างประเทศ หากเปรียบเทียบแต่ตัวเลข อาจเข้าใจผิดว่าเป็นการขึ้นราคาจากการแปลงหน่วยผิด หรือมองข้ามการขึ้นราคาจริง คำขอปรับราคาควรระบุรหัสสินค้า รหัสซัพพลายเออร์ รหัสสินค้าของซัพพลายเออร์ หน่วยจัดซื้อ หน่วยฐาน อัตราแปลง สกุลเงิน ประเภทภาษี การคิดค่าขนส่งหรือค่าพิมพ์แม่พิมพ์ หากเปลี่ยนอัตราแปลงหน่วย ต้องเก็บประวัติและการอนุมัติด้วย

ข้อความ “เปลี่ยนราคา” อาจหมายถึง 4 กรณี ได้แก่ ราคาตามใบเสนอราคา ราคาตามสัญญาหรือมาสเตอร์ราคา ราคาที่เสนอใน PO ที่ยังไม่ออก และราคาที่ตกลงใน PO ที่ออกไปแล้ว หากระบบเปลี่ยนแค่ตารางราคาแต่ไปเขียนทับ PO ที่ออกไปแล้ว จะไม่สามารถอธิบายข้อตกลงในอดีตได้ ในทางกลับกัน หากไม่เปลี่ยน PO เลย แม้จะตกลงกับซัพพลายเออร์แล้ว ส่วนที่ยังไม่ได้ส่งมอบก็จะเกิดความแตกต่างในใบแจ้งหนี้ ต้องกำหนดเป็นกติกาว่าจะใช้ราคาใดกับเอกสารใด

ชื่อวันที่อย่างเดียวไม่พอสำหรับเงื่อนไขการใช้ราคา

แม้จะมีช่อง “วันมีผล” หากฝ่ายจัดซื้อเข้าใจว่าเป็นวันออก PO แต่ฝ่ายบัญชีเข้าใจว่าเป็นวันรับสินค้า ก็จะตรวจสอบกันไม่ตรง ต้องระบุให้ชัดว่า “วันมีผล” อ้างอิงเหตุการณ์ใด เช่น วันออก PO วันรับสินค้า ฯลฯ โดยใช้เวลาท้องถิ่นไทยเป็นหลัก หากสัญญากับซัพพลายเออร์ต่างประเทศใช้โซนเวลาอื่น ต้องบันทึกไว้ด้วย แยกกรณีที่ต้องใช้เวลานาทีชั่วโมงกับกรณีที่ใช้แค่วัน หลีกเลี่ยงการประมาณเวลาย้อนหลัง

ตัวอย่างเช่น แจ้งปรับราคาเป็นวันที่ 1 ตุลาคม แต่ได้รับแจ้งวันที่ 28 กันยายน ฝ่ายจัดซื้ออนุมัติวันที่ 3 ตุลาคม ซัพพลายเออร์ยืนยันวันที่ 5 ตุลาคม กรณีนี้ไม่ควรนำวันที่ 1 ตุลาคมไปใช้กับทุกรายการโดยอัตโนมัติ ต้องแยกว่ารายการที่ออก PO ก่อนอนุมัติจะย้อนหลังหรือไม่ หรือใช้กับเฉพาะ PO ใหม่หลังอนุมัติ หรือเจาะจง PO คงค้างแต่ละใบ ให้ผู้อนุมัติเลือกและบันทึกไว้ หากยอมให้ย้อนหลัง ต้องเก็บรายการที่เปลี่ยนแปลงทั้งหมด

PO คงค้างหนึ่งใบ อาจมีหลายสถานะ

ใน PO เดียวกัน อาจมี 100 ชิ้น รับเข้าแล้ว 40 ชิ้น อยู่ระหว่างขนส่ง 20 ชิ้น ยังไม่ได้ส่ง 40 ชิ้น แม้ในเอกสารจะมีราคาเดียว แต่ในทางธุรกิจอาจต้องแยกการใช้ราคาเดิมกับราคาใหม่ เช่น ส่วนที่รับเข้าแล้วใช้ราคาเดิม ส่วนที่ยังไม่ได้ส่งใช้ราคาใหม่ ต้องแยกบรรทัดหรือออกใบเปลี่ยนแปลง PO วิธีแบ่งขึ้นกับระบบและการเชื่อมโยงบัญชี ต้องทดสอบในแต่ละกรณี

Oracle Procurement อธิบายว่า การเปลี่ยนแปลง PO ที่อนุมัติแล้ว จะมีการเสนอ แก้ไข อนุมัติ และสะท้อนเป็นเวอร์ชันใหม่ ไม่ใช่แค่เปลี่ยนมาสเตอร์ราคาแล้ว PO ที่ออกไปแล้วจะเปลี่ยนตามโดยอัตโนมัติ ต้องตรวจสอบเงื่อนไขสัญญากับซัพพลายเออร์ของตนเอง Oracle Procurement: Change Orders

แปดสถานะของกระบวนการปรับราคาซื้อ

หากเริ่มออกแบบระบบจากชื่อหน้าจอ อาจตกหล่นขั้นตอนสำคัญ ควรนิยามสถานะของแต่ละกรณีปรับราคาไว้ก่อน โดยแนะนำให้ใช้ลำดับ “รับแจ้ง → ตรวจสอบเนื้อหา → ประเมินผลกระทบ → อนุมัติภายใน → ตกลงกับซัพพลายเออร์ → ลงทะเบียนเวอร์ชันราคา → เปลี่ยนแปลง PO ที่เกี่ยวข้อง → ตรวจสอบใบแจ้งหนี้” ต้องมีเส้นทางสำหรับการปฏิเสธ ส่งกลับ หรือพักไว้ด้วย โดยเฉพาะ “อนุมัติแล้วแต่รอซัพพลายเออร์ตกลง” และ “ลงทะเบียนเวอร์ชันราคาแล้วแต่ยังไม่ได้เปลี่ยน PO” ไม่ควรรวมเป็น “เสร็จสิ้น” เดียวกัน

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

โมเดลข้อมูลราคาซื้อ: ไม่เขียนทับแต่เก็บเป็นเวอร์ชัน

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

ฟิลด์แนะนำ ได้แก่ ซัพพลายเออร์, สินค้า, รหัสสินค้าซัพพลายเออร์, โรงงานที่ใช้, สกุลเงิน, หน่วยจัดซื้อ, อัตราแปลงหน่วย, ช่วงปริมาณ, ราคาเก่า, ราคาใหม่, วันเริ่ม-สิ้นสุด, เหตุการณ์อ้างอิง, เหตุผลปรับราคา, อ้างอิงเอกสารเจรจา/อนุมัติ, ผู้ขอ/ผู้อนุมัติ, หมายเลขเวอร์ชัน, วันเวลาบันทึก, เหตุผลยกเลิก เพิ่มเติมอาจมีการระบุว่ารวมค่าขนส่ง ภาษี อากร หรือส่วนลดในราคาหรือไม่ หากเปรียบเทียบราคาที่รวม/ไม่รวมรายการเหล่านี้จะรายงานความแตกต่างผิดพลาด

หากมีช่วงเวลาซ้ำกันในซัพพลายเออร์-สินค้า-สกุลเงิน-หน่วย-ปริมาณเดียวกัน ต้องกำหนดให้ระบบเตือนหรือระบุลำดับความสำคัญ ช่วงเวลาควรกำหนดชัดเจนว่ารวมวันเริ่ม/ไม่รวมวันสิ้นสุด หากไม่ชัดเจนจะเกิดกรณีราคาซ้อนกันในต้นเดือน Microsoft Business Central มีตารางราคาซื้อพร้อมวันมีผล และตัดสินใจใช้ราคาตามเงื่อนไขการซื้อ ในเดโมควรให้แสดงลำดับการเลือกเมื่อมีราคาหลายชุด Microsoft: Purchase Price Lists

หลีกเลี่ยงการลบเวอร์ชันเก่า หากต้องแก้ไขควรเพิ่มเวอร์ชันใหม่ ปิดช่วงเวลาเวอร์ชันเก่า และระบุว่า PO ใดใช้เวอร์ชันใด แม้ ERP ที่ใช้จะไม่ได้บังคับโครงสร้างนี้ สิ่งสำคัญคือสามารถย้อนดูว่า ณ วันและเอกสารใด มีการอนุมัติราคาใดไว้ การนำเข้า CSV หรือเชื่อมต่อ API ต้องตรวจสอบและบันทึก audit log เช่นเดียวกับการกรอกหน้าจอ หากเปิดให้เชื่อมต่อภายนอกเขียนทับราคาได้โดยตรงจะขาดการควบคุม

การจัดการ PO คงค้าง: ทดสอบ 4 กรณี

การออกแบบวันมีผลจะใช้ได้จริงก็ต่อเมื่อกำหนดวิธีจัดการ PO คงค้างแล้ว ทดสอบ 4 กรณีต่อไปนี้กับ PO ตัวอย่าง

กรณี A: ออก PO ก่อนวันมีผล และรับสินค้าครบก่อนวันมีผล โดยหลักจะคงราคาตาม PO เดิม หากซัพพลายเออร์เสนอเงื่อนไขใหม่ภายหลัง ไม่ควรนำไปรวมกับการปรับมาสเตอร์ราคา แต่ให้อนุมัติเป็นกรณีแก้ไข/เรียกเก็บเงินเพิ่มแยกต่างหาก หลีกเลี่ยงการอัปเดตรายการรับเข้าเป็นราคาใหม่โดยไม่มีหลักฐาน

กรณี B: ออก PO ก่อนวันมีผล และยังไม่ได้รับสินค้าเลย หากสัญญากำหนด “ใช้วันรับสินค้า” อาจต้องเปลี่ยนราคา หาก “ใช้วันออก PO” อาจคงราคาเดิม ต้องตัดสินใจตามข้อความในสัญญาและยืนยันกับซัพพลายเออร์ หากต้องออกใบเปลี่ยนแปลง PO ให้เก็บเวอร์ชันเก่าและใหม่ หากตกลงด้วยวาจาแต่ PO ยังเป็นราคาเดิม จะย้ายปัญหาไปเกิดในใบแจ้งหนี้

กรณี C: รับสินค้าแล้วบางส่วน เหลือค้างบางส่วน ให้แยกปริมาณที่รับแล้วกับที่ยังไม่รับ ระบุในระดับบรรทัดหรือแยกบรรทัด เช่น สั่ง 100 ชิ้น รับแล้ว 40 ชิ้น ค้าง 60 ชิ้น การปรับราคาจะมีผลกับไม่เกิน 60 ชิ้น ขึ้นกับเงื่อนไข หากมีสินค้าระหว่างขนส่งหรือรอตรวจรับต้องแยกเพิ่ม หากระบบไม่รองรับหลายราคาต่อบรรทัด PO ให้เปรียบเทียบระหว่างการแยกบรรทัด ยกเลิกคงค้างแล้วออก PO ใหม่ หรือออกใบเปลี่ยนแปลง PO ว่าแบบใดเหมาะกับการตรวจสอบและการปฏิบัติกับซัพพลายเออร์

กรณี D: ออก PO ใหม่หลังวันมีผล ให้แสดงเวอร์ชันราคาที่อนุมัติแล้วเป็นตัวเลือกอัตโนมัติ แต่หากเงื่อนไขเช่น สกุลเงิน หน่วย ปริมาณ โรงงาน ไม่ตรง ต้องให้จัดซื้อยืนยันเหตุผล หากอนุญาตให้สั่งซื้อชั่วคราวหรือเร่งด่วน ให้ระบุรหัสข้อยกเว้นและกำหนดเส้นตายการจัดการ

บันทึก 4 กรณีนี้เป็นตารางทดสอบ “วัน PO × สถานะรับเข้า × เงื่อนไขสัญญา” ไม่ใช่แค่ดูหน้าจอ แต่ต้องลองลงทะเบียน PO ตัวอย่าง ขอปรับราคา อนุมัติ ออกใบเปลี่ยนแปลง PO รับสินค้า ออกใบแจ้งหนี้ Oracle อธิบายการสร้างเวอร์ชันใหม่ของเอกสารที่อนุมัติแล้วด้วยการเปลี่ยนแปลง PO ในการเลือกผลิตภัณฑ์ ควรดูว่าการแจ้งซัพพลายเออร์ การจัดการปริมาณคงค้าง และการเชื่อมโยงบัญชีทำงานอย่างไร Oracle: Change Orders

ประวัติการอนุมัติ: ไม่ใช่แค่ “ใครกดอนุมัติ”

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

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

หากแก้ไขราคา/เงื่อนไขหลังอนุมัติ ต้องพิจารณาว่าต้องอนุมัติใหม่หรือไม่ หลีกเลี่ยงการแก้ไขค่าบนกรณีที่อนุมัติแล้วโดยตรง ให้เก็บความแตกต่างก่อน-หลัง ผู้แก้ไข วันเวลา เหตุผล และหากเกินเกณฑ์ต้องวนกลับไปอนุมัติใหม่ อีเมลกับซัพพลายเออร์ หนังสือข้อตกลง ใบเสนอราคาใหม่ การยืนยันการเปลี่ยนแปลง PO ต้องเชื่อมกับรหัสปรับราคา ไม่เก็บไว้ในอีเมลส่วนตัวของพนักงาน

การตรวจสอบใบแจ้งหนี้: แยกสาเหตุของความแตกต่างราคา

เมื่อใบแจ้งหนี้ที่ฝ่ายบัญชีได้รับมีราคาต่างจาก PO ไม่ควรแก้ไขทุกกรณีว่า “มาสเตอร์ราคาเก่า” สาเหตุอาจเป็น ①อนุมัติปรับราคาแล้วแต่ยังไม่ได้เปลี่ยน PO, ②ซัพพลายเออร์ออกใบแจ้งหนี้ด้วยราคาที่ยังไม่ตกลง, ③หน่วย/สกุลเงิน/ช่วงปริมาณไม่ตรงกัน, ④การคิดค่าขนส่ง/ภาษี/ส่วนลดต่างกัน, ⑤กรอกข้อมูลผิด, ⑥ตีความวันรับกับเงื่อนไขวันมีผลต่างกัน ควรมีรหัสสาเหตุและกำหนดว่าใครในฝ่ายจัดซื้อ คลัง หรือบัญชีจะดำเนินการต่อ

Microsoft Dynamics 365 Finance อธิบายการตรวจสอบใบแจ้งหนี้กับ PO และการรับสินค้า สามารถระบุความแตกต่างที่เกินขอบเขตที่กำหนดได้ การตรวจสอบ 2 จุดคือ PO กับใบแจ้งหนี้, 3 จุดคือรวมปริมาณรับเข้า วิธีที่เหมาะสมขึ้นกับสินค้าและกระบวนการ ต้องทดสอบทั้งอัตราส่วนขอบเขต วงเงินสูงสุด การแปลงสกุลเงิน การแบ่งจ่าย ค่าบริการเพิ่มเติม และการปัดเศษ หลีกเลี่ยงการเปลี่ยนราคา PO ย้อนหลังเพื่อให้ความแตกต่างอยู่ในขอบเขต เพราะจะลบประวัติปัญหา Microsoft: ภาพรวมการตรวจสอบใบแจ้งหนี้ / การตั้งค่าการตรวจสอบใบแจ้งหนี้

หากพักการจ่ายใบแจ้งหนี้ ต้องแสดงเหตุผลและผู้รับผิดชอบให้ชัดเจน ความแตกต่างที่ฝ่ายจัดซื้อเปลี่ยน PO แล้วจะหาย กับความแตกต่างที่ต้องให้ซัพพลายเออร์ออกใบแจ้งหนี้ใหม่ไม่เหมือนกัน หากปล่อยทิ้งไว้นานจะกลายเป็นปัญหาการจ่ายล่าช้า ควรติดตามจำนวนค้าง, วันค้าง, มูลค่า, แนวโน้มแยกตามซัพพลายเออร์ทุกสัปดาห์ และใช้ความแตกต่างที่เกิดขึ้นทบทวนจุดอ่อนของกระบวนการปรับราคา

ข้อควรระวังสำหรับโรงงานในไทย

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

ชื่อสินค้าบนใบเสนอราคา (ภาษาอังกฤษ) กับใบแจ้งหนี้ (ภาษาไทย) อาจไม่ตรงกัน ควรใช้รหัสสินค้าในบริษัท, รหัสสินค้าซัพพลายเออร์, หมายเลข PO, หมายเลขบรรทัดเป็นแกนเปรียบเทียบ หากรหัสสินค้าซัพพลายเออร์เปลี่ยน ต้องเชื่อมกับคำขอปรับราคาและเก็บความสัมพันธ์กับรหัสเก่า หากสรุปอีเมลแจ้งราคาเป็นภาษาญี่ปุ่น ควรเก็บต้นฉบับที่เกี่ยวกับเงื่อนไขวันมีผลควบคู่กับฉบับแปล ความสำคัญไม่ใช่การแสดงหลายภาษา แต่ต้องให้ต้นฉบับ เอกสารข้อตกลง และข้อมูลในระบบตรงกัน

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

12 คำถามสำคัญสำหรับ RFP ระบบจัดซื้อ

อย่าถามแค่ “มีฟังก์ชันปรับราคาซื้อหรือไม่” ให้ขอเดโมระบบโดยใช้ 12 ข้อดังนี้เป็นสถานการณ์เดียวกัน แล้วให้ผู้ขายระบุว่าใช้ฟังก์ชันมาตรฐาน, การตั้งค่า, การพัฒนาเพิ่ม, หรือการหลีกเลี่ยงด้วยกระบวนการ เพื่อเปรียบเทียบขอบเขตและค่าใช้จ่ายระหว่างข้อเสนอ

1. สามารถบริหารเวอร์ชันราคาเก่า-ใหม่แยกตามซัพพลายเออร์ สินค้า สกุลเงิน หน่วย ช่วงปริมาณได้หรือไม่
2. หากลงทะเบียนราคาที่ช่วงเวลาซ้อนกัน ระบบเตือน/ปฏิเสธ/จัดลำดับความสำคัญอย่างไร
3. สามารถเลือกเงื่อนไขวันมีผลจากวันออก PO, วันรับสินค้า ฯลฯ และบันทึกในเอกสารได้หรือไม่
4. สามารถเชื่อมโยงหนังสือแจ้งราคา ใบเสนอราคา อีเมลข้อตกลงกับรหัสปรับราคาเพื่อค้นหาได้หรือไม่
5. สามารถประเมินผลกระทบทางการเงินจาก PO คงค้างก่อนและหลังปรับราคาได้หรือไม่
6. สามารถเปลี่ยนเฉพาะส่วนที่ยังไม่ได้รับของในบรรทัด PO ที่รับเข้าแล้วบางส่วนได้หรือไม่
7. การอนุมัติใบเปลี่ยนแปลง PO การแจ้งซัพพลายเออร์ การยืนยันรับทราบ ใช้เวอร์ชันใดบริหาร
8. หากแก้ไขราคา/เงื่อนไขหลังอนุมัติ ระบบจะวนกลับไปอนุมัติใหม่และบันทึก audit log อย่างไร
9. สามารถตรวจสอบความแตกต่างราคาระหว่างการรับเข้าและใบแจ้งหนี้ในสกุลเงิน/หน่วยตามสัญญาได้หรือไม่
10. สามารถแยกความแตกต่างตามรหัสสาเหตุและกำหนดผู้รับผิดชอบ/เส้นตายได้หรือไม่
11. การนำเข้า CSV/API/เชื่อมต่อ ERP ภายนอก ใช้การตรวจสอบเดียวกับการกรอกหน้าจอหรือไม่
12. สามารถย้อนดูความสัมพันธ์ระหว่างราคาอนุมัติในอดีต, เวอร์ชัน PO, การรับเข้า, ใบแจ้งหนี้ได้หรือไม่

ข้อ 6 และ 7 มักถูกมองข้าม เดโมส่วนใหญ่จะโชว์แค่การสร้าง PO ใหม่ แต่ปัญหาจริงอยู่ที่ PO คงค้าง ให้เตรียมข้อมูลตัวอย่างที่มีหลายสกุลเงิน หน่วย รับเข้าบางส่วน อยู่ระหว่างขนส่ง ออกใบแจ้งหนี้แล้ว หรือรออนุมัติ ให้ผู้ขายแสดงหน้าจอและรายงานจริงก่อนตัดสินใจ

ลำดับการนำระบบไปใช้แบบเริ่มเล็ก

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

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

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

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

กรณีทดสอบและเงื่อนไขผ่านการนำระบบไปใช้

การทดสอบระบบต้องไม่ดูแค่ “ทำรายการเสร็จ” แต่ต้องดูว่าหลักฐานใดปรากฏในหน้าจอและรายงานด้วย กรณีแรก ให้เตรียม PO ที่ออกในเดือนกันยายน 100 ชิ้น รับเข้า 40 ชิ้นในกันยายน รับอีก 60 ชิ้นในตุลาคม แจ้งปรับราคาในปลายกันยายน ระบุชัดว่า “ใช้กับสินค้าที่รับเข้าในตุลาคม” ฝ่ายจัดซื้อบันทึกแจ้งเตือน ดึง PO ที่เกี่ยวข้อง ดูค้าง 60 ชิ้นแล้วขออนุมัติ หลังอนุมัติ ออกใบเปลี่ยนแปลง PO แจ้งซัพพลายเออร์ และบันทึกการยืนยัน ฝ่ายบัญชีจะเห็นใบแจ้งหนี้ 40 ชิ้นราคาเดิม 60 ชิ้นราคาใหม่ หากทำได้ครบถือว่าเกินกว่าฟังก์ชันตารางราคาทั่วไป

กรณีที่สอง ใช้ PO 100 ชิ้นที่ออกในกันยายนเหมือนกัน แต่เปลี่ยนเงื่อนไขเป็น “ใช้กับ PO ใหม่ที่ออกหลัง 1 ตุลาคม” กรณีนี้ 60 ชิ้นที่รับเข้าในตุลาคมอาจยังใช้ราคาเดิม แม้จะกรอกวันมีผลเหมือนกันแต่ผลลัพธ์ต่างกัน ต้องดูว่าระบบแสดงผลต่างนี้อย่างไร หากต้องให้ผู้ใช้กรอกราคาใหม่เองทุกครั้ง แสดงว่าระบบไม่มีฟังก์ชันบริหารเงื่อนไขวันมีผลจริง ในทางกลับกัน หากระบบเปลี่ยนราคาใหม่อัตโนมัติโดยไม่สนใจสัญญา จะเกิดการเปลี่ยนแปลงที่ไม่ได้ตกลงไว้ ทางที่ดีควรเก็บทั้งตัวเลือกอัตโนมัติและข้อยกเว้นพร้อมหลักฐาน

กรณีที่สาม “แก้ไขราคาที่อนุมัติแล้ว” เช่น อนุมัติราคาเก่า 120 ใหม่ 130 แล้วซัพพลายเออร์แจ้งคำนวณผิดขอเปลี่ยนเป็น 128 ต้องไม่ลบประวัติ 130 แต่แนบแจ้งแก้ไขและดึง PO กับใบแจ้งหนี้ที่เกี่ยวข้องใหม่ หากระบบแก้ไขตัวเลขในกรณีที่อนุมัติแล้วโดยไม่มีประวัติ จะไม่สามารถตรวจสอบการตัดสินใจในอดีตได้ การวนกลับไปอนุมัติใหม่หรือไม่ขึ้นกับเกณฑ์บริษัท แต่ต้องเก็บค่าก่อน-หลังและเหตุผลเสมอ

กรณีที่สี่ ใบแจ้งหนี้มีความแตกต่างราคาแต่ไม่เกี่ยวกับการปรับราคา เช่น PO ใช้หน่วยกล่อง ใบแจ้งหนี้ใช้หน่วยชิ้น กรอกอัตราแปลงผิด ต้องไม่สรุปว่าเป็น “การปรับราคา” แต่แยกเป็นปัญหาหน่วย ให้ฝ่ายจัดซื้อหรือบัญชีแก้ไขที่มาสเตอร์หรือการกรอกใบแจ้งหนี้ เหตุผลที่ต้องแยกรหัสสาเหตุเพราะหากจัดหมวดผิดจะเสียเวลาต่อรองราคาโดยไม่จำเป็นและมองข้ามปัญหาปรับราคาจริง

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

ในตารางประเมิน ให้บันทึกแต่ละกรณีว่า “ทำรายการได้หรือไม่”, “ต้องพัฒนาเพิ่มหรือไม่”, “เอกสารที่แจ้งซัพพลายเออร์”, “หลักฐานที่ตรวจสอบย้อนหลังได้”, “ยอดเงินหลังเชื่อมบัญชี” แม้หน้าจอจะทำงานได้แต่ถ้ารายงานหรือ API ไม่รองรับเวอร์ชันใหม่จะเกิดปัญหาในการปฏิบัติ อย่าให้ฝ่ายจัดซื้อทดสอบคนเดียว ให้ฝ่ายคลังและบัญชีดูเอกสารตัวอย่างเดียวกันและให้คะแนนร่วมกัน จะลดความเสี่ยงที่แต่ละฝ่ายใช้ราคาคนละชุดหลังนำระบบไปใช้

ความเชื่อมโยงกับต้นทุนมาตรฐานและระบบจัดซื้อโดยรวม

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

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

ตัวอย่างขอบเขตสามกรณีที่การดำเนินงานล้มเหลวหลังการปรับราคา

กรณีแรก คือ การโอนยอดสั่งซื้อบางส่วนไปยังโรงงานอื่น เดิมในใบสั่งซื้อ (PO) ระบุส่งของ 100 ชิ้นไปยังโรงงานกรุงเทพฯ ในราคาก่อนปรับ แต่หากมีการส่งตรง 50 ชิ้นไปยังโรงงานอื่น อาจทำให้ตารางราคาและเงื่อนไขค่าขนส่งที่ใช้เปลี่ยนแปลง หากโอนเฉพาะจำนวนโดยคงราคาต่อหน่วยเดิม ฝ่ายรับของอาจไม่พบข้อตกลงที่สอดคล้องกัน จำเป็นต้องเก็บข้อมูลโรงงานก่อนและหลังการโอน เงื่อนไขราคา สถานที่รับสินค้า และการยืนยันกับผู้ขายไว้เป็นชุดเดียวกัน และตรวจสอบว่าสามารถติดตามความสัมพันธ์ระหว่าง PO เดิมกับ PO ที่ย้ายไปได้หรือไม่ แม้การโอนจะไม่ถือเป็นการปรับราคา ก็ต้องมีเหตุผลรองรับว่าทำไมจึงยังใช้ราคาเดิม

กรณีที่สอง คือ การปรับราคาหลายครั้งในช่วงเวลาสั้น ๆ เช่น ปรับครั้งแรกวันที่ 1 ตุลาคม และปรับอีกครั้งวันที่ 1 พฤศจิกายน ขณะที่ผู้ขายยังไม่ได้วางบิลของเดือนตุลาคม หากเหลือไว้เฉพาะราคาล่าสุด อาจจับคู่ใบแจ้งหนี้ของสินค้าที่ส่งในเดือนตุลาคมผิดไปใช้ราคาของเดือนพฤศจิกายนได้ ตารางราคาต้องสามารถอ้างอิงตามช่วงเวลาทำธุรกรรม และต้องสามารถย้อนกลับไปดูเวอร์ชันที่ใช้ได้จากวันที่รับสินค้าและเงื่อนไขที่ตกลงกันไว้ เมื่อบันทึกการปรับราคาของเดือนพฤศจิกายน ต้องระบุวันสิ้นสุดของเวอร์ชันเดือนตุลาคมให้ชัดเจน และตรวจสอบว่าช่วงเวลาระหว่างเวอร์ชันไม่มีซ้อนทับหรือเว้นว่าง หากการอนุมัติล่าช้าและต้องย้อนวันที่ ต้องแสดงรายการผลกระทบต่อเอกสารที่ได้ยืนยันไปแล้วให้ผู้อนุมัติรับทราบ

กรณีที่สาม คือ ผู้ขายเปลี่ยนรหัสสินค้า หรือหน่วยบรรจุพร้อมกับการปรับราคา ในช่วงเปลี่ยนผ่านที่ยังมีสต็อกของรหัสเก่าและเริ่มสั่งรหัสใหม่ ต้องแยกให้ชัดเจนว่าความแตกต่างของราคามาจากสเปกหรือหน่วยนับ หากเร่งรวมรหัสสินค้า อาจประเมินล็อตเก่าด้วยราคาต่อหน่วยใหม่ผิดพลาดได้ ต้องเชื่อมโยงข้อมูลการจับคู่รหัสเก่า-ใหม่ อัตราแปลง วันที่เปลี่ยน การอนุมัติทดแทน และนโยบายการระบายสต็อกเข้ากับกรณีปรับราคา และให้ฝ่ายจัดซื้อกับฝ่ายวางแผนการผลิตตรวจสอบร่วมกัน เงื่อนไขการปิดกรณีปรับราคาต้องรวมถึงการตรวจสอบว่าไม่มีใบสั่งซื้อที่ยังไม่ได้ส่งของและไม่มีใบแจ้งหนี้ของรหัสเก่าค้างอยู่ด้วย

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

คำถามที่พบบ่อย

ถ้าอัปเดตมาสเตอร์ราคาแล้ว PO ที่ออกไปจะเปลี่ยนตามอัตโนมัติหรือไม่

ขึ้นกับฟังก์ชันและการตั้งค่าระบบ แต่ไม่ควรออกแบบกระบวนการให้เปลี่ยนอัตโนมัติ PO ที่ออกไปแล้วถือเป็นข้อตกลงกับซัพพลายเออร์ ต้องระบุชัดเจนว่ารายการใดจะเปลี่ยนและต้องอนุมัติ/แจ้งซัพพลายเออร์ หลังเปลี่ยนมาสเตอร์ราคา ให้แสดงรายการ PO คงค้างที่ได้รับผลกระทบและตัดสินใจออกใบเปลี่ยนแปลงตามเงื่อนไขสัญญา

วันมีผลควรใช้วันออก PO หรือวันรับสินค้า

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

ถ้าใบแจ้งหนี้ใช้ราคาใหม่แต่ PO ยังเป็นราคาเดิมควรทำอย่างไร

ให้ตรวจสอบเวอร์ชัน PO, วันรับสินค้า, รหัสปรับราคา, หนังสือข้อตกลง หากอนุมัติเปลี่ยนราคาแล้วแต่ยังไม่ได้เปลี่ยน PO ให้ฝ่ายจัดซื้อดำเนินการ หากยังไม่ตกลงกับซัพพลายเออร์ให้ขอแก้ไขใบแจ้งหนี้ หากเป็นปัญหาหน่วยหรือสกุลเงินให้แก้ไขการแปลงหรือการกรอกข้อมูล หลีกเลี่ยงการเปลี่ยนราคา PO เพื่อให้บัญชีตรงกับใบแจ้งหนี้โดยไม่มีหลักฐาน

โรงงานขนาดกลาง-เล็กจำเป็นต้องมีระบบเฉพาะหรือไม่

ขึ้นกับความถี่ในการปรับราคา ปริมาณ PO คงค้าง จำนวนซัพพลายเออร์ และข้อกำหนดการตรวจสอบ เริ่มจากการจัดระเบียบกระบวนการให้ติดตามแจ้งเตือน อนุมัติ PO และใบแจ้งหนี้ด้วยรหัสปรับราคาเดียวกัน แล้วดูว่า ERP เดิมรองรับหรือไม่ หากต้องแบ่ง PO คงค้างหรือเก็บหลักฐานด้วยมือเป็นประจำจึงค่อยพิจารณาระบบเฉพาะ

สรุป: ใช้รหัสปรับราคาเดียวกันเพื่อย้อนดู “ทำไมใช้ราคานี้”

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

TOMAS TECH พร้อมช่วยโรงงานในไทยจัดระเบียบขอบเขตงานจัดซื้อ-วางแผนการผลิต-บัญชี วิเคราะห์การเพิ่มระบบใหม่ เชื่อมต่อ ERP หรือพัฒนาใหม่ หากนำตัวอย่างแจ้งปรับราคา PO คงค้าง และความแตกต่างใบแจ้งหนี้มาให้ จะช่วยจัดระเบียบขอบเขตการใช้ราคาและบันทึกที่จำเป็นได้ ติดต่อเราได้ที่นี่

แหล่งข้อมูลอ้างอิง

• Microsoft Learn: Record special purchase prices and discounts — ราคาซื้อแยกตามสินค้า ปริมาณ หน่วย สกุลเงิน และวันที่
• Microsoft Learn: Purchase Price Lists — ตารางราคาซื้อและวันมีผล
• SAP Help Portal: Time-Dependent Conditions — ช่วงเวลาที่มีผลของเงื่อนไขการซื้อ
• SAP Help Portal: Conditions in Info Records — การเปลี่ยนแปลงเงื่อนไขในข้อมูลการซื้อ
• Oracle Fusion Cloud Procurement: Change Orders — เวอร์ชันใหม่ของเอกสารจัดซื้อที่อนุมัติแล้ว
• Microsoft Learn: Accounts payable invoice matching overview — การตรวจสอบ PO การรับเข้า และใบแจ้งหนี้กับความแตกต่างราคา
• Microsoft Learn: Set up Accounts payable invoice matching validation — การตั้งค่าขอบเขตและการตรวจสอบ 2/3 จุด