ระบบจัดการยอดค้างรับตามใบสั่งซื้อสำหรับโรงงาน

เมื่อโรงงานต้องการนำระบบจัดการยอดค้างรับตามใบสั่งซื้อมาใช้ คำถามแรกไม่ใช่หน้าจอสวยเพียงใด แต่คือคำว่า “ค้างรับ” หมายถึงอะไร สมมติสั่งวัตถุดิบ 100 ชิ้น ซัพพลายเออร์ยืนยันส่งสองงวด คือ 60 และ 40 ชิ้น งวดแรก 60 ชิ้นมาถึงแล้ว ตรวจผ่าน 50 ชิ้นและพักตรวจ 10 ชิ้น ส่วนงวดหลัง 40 ชิ้นยังไม่มาถึง ฝ่ายจัดซื้อ คลังสินค้า วางแผนการผลิต และบัญชีเจ้าหนี้เห็นตัวเลขเดียวกันพร้อมเหตุผลเดียวกันหรือไม่ บทความนี้อธิบายวิธีออกแบบยอดค้างรับฝั่งจัดซื้อสำหรับโรงงานในไทย โดยเชื่อมการส่งมอบบางส่วน การยืนยันวันส่ง การรับเข้า การตรวจคุณภาพ ใบแจ้งหนี้ และการคำนวณ MRP ใหม่

นิยามยอดค้างรับฝั่งจัดซื้อก่อนเลือกซอฟต์แวร์

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

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

เอกสาร Microsoft เรื่องตารางส่งมอบของ PO แสดงการแยกหนึ่งบรรทัด PO เป็นหลายบรรทัดกำหนดส่งพร้อมจำนวนและวันที่ต่างกัน ส่วนเอกสารการอนุมัติและยกเลิก PO ชี้ว่าจำนวนที่ยังยกเลิกได้ไม่เท่ากับจำนวนที่รับหรือออกใบแจ้งหนี้ไปแล้ว เอกสารเหล่านี้เป็นคุณสมบัติของผลิตภัณฑ์หนึ่ง ไม่ใช่กฎของทุก ERP แต่ช่วยให้เห็นว่าต้องแยก PO line, delivery line, receipt และ cancellation อย่างชัดเจน

ตัวอย่างสมมติ: PO 100 ชิ้นเปลี่ยนสถานะอย่างไร

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

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

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

โครงสร้างข้อมูลต้องเริ่มจากบรรทัด PO และเหตุการณ์

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

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

กำหนดระบบต้นทางของแต่ละข้อเท็จจริง

โรงงานอาจเก็บ PO ที่อนุมัติแล้วใน ERP คำตอบของซัพพลายเออร์ในระบบจัดซื้อ การเคลื่อนไหวจริงใน WMS ผลคุณภาพใน QMS และแผนอุปทานใน MRP หรือรวมหลายส่วนไว้ในระบบเดียว ไม่ว่ารูปแบบใด ต้องเขียน data contract ว่าใครยืนยันเหตุการณ์ ใช้รหัสใดโยงกับ PO ส่งต่อเมื่อใด และแก้ไขโดยอ้างเหตุการณ์เดิมอย่างไร ไม่ควรมีสองหน้าจอให้แก้จำนวนรับเดียวกันโดยอิสระ

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

แยกวันที่ต้องการ วันที่ซัพพลายเออร์ยืนยัน และวันที่พร้อมใช้

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

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

สามวันของการแบ่งส่ง

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

ตัวอย่างตารางแบ่งส่งของ Microsoft แสดงจำนวนและวันที่แยกกันใน PO เดียว ใน RFP ต้องถามต่อว่าแต่ละบรรทัดเชื่อมฉบับคำตอบ ใบรับ การยกเลิก และใบแจ้งหนี้ได้หรือไม่ ระบบที่เก็บวันที่ได้สองวันแต่แยกจำนวนรับของแต่ละรอบไม่ได้ ยังไม่พอสำหรับการจัดการยอดค้างรับ

แยกของมาถึงจากของที่ใช้ผลิตได้

การลงของจากรถ การลงทะเบียนรับ การผ่านตรวจ และการบันทึก product receipt ใน ERP อาจคนละเวลา คำอธิบาย Microsoft เรื่องการรับสินค้าตาม PO แยกการแจ้งก่อนมาถึง การลงทะเบียน การตรวจคุณภาพ และการรับทางระบบ ใช้เป็นรายการตรวจในการออกแบบ ไม่ใช่กฎบัญชีสากล ต้องนิยามว่ายอดยังไม่มาถึง ของกำลังตรวจ และสต็อกพร้อมใช้เปลี่ยนสถานะกันอย่างไรในโรงงานนี้

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

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

ยอดไม่มาถึงกับยอดรับแล้วแต่ยังไม่ถูกวางบิลเป็นคนละเรื่อง

จำนวนที่ยังไม่ส่งกับจำนวนที่ได้รับแล้วแต่ยังไม่มีใบแจ้งหนี้ตอบคนละคำถาม เอกสาร Microsoft เรื่องจับคู่ใบแจ้งหนี้เจ้าหนี้ อธิบายการเทียบ PO ใบรับ และใบแจ้งหนี้ทั้งจำนวนและราคา ส่วนเอกสาร SAP เรื่อง quantity variance แยกจำนวนรับแล้วแต่ยังไม่ออกใบแจ้งหนี้กับส่วนต่างที่วางบิล เอกสารสองแห่งเป็นคำอธิบายระบบของตน ไม่ใช่กฎทั่วไปด้านภาษีหรือการรับรู้บัญชี

ตัวอย่างสมมติสั่ง 100 ชิ้น รับทางระบบ 60 ชิ้น แต่มีใบแจ้งหนี้เพียง 50 ชิ้น ยอด PO ที่ยังไม่มาคือ 40 ชิ้น และของรับแล้วแต่ยังไม่ถูกวางบิลคือ 10 ชิ้น หากใบแจ้งหนี้ 60 ชิ้นมาถึงก่อนบันทึกรับ ก็ห้ามลดยอด PO ที่ยังไม่มาด้วยตัวเลขในใบแจ้งหนี้โดยอัตโนมัติ กฎพักจ่ายและอนุมัติส่วนต่างขึ้นกับนโยบายบริษัทและการตั้งค่า ERP ข้อกำหนดต้องโยงบรรทัด PO รับเข้า และใบแจ้งหนี้ รวมถึงแบ่งส่ง แบ่งวางบิล คืน เครดิต และส่งเกิน

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

ส่งอุปทานที่น่าเชื่อถือให้ MRP ไม่ใช่แค่ยอดคงเหลือ

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

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

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

ตรวจสาเหตุของยอดค้างปัจจุบันก่อนย้ายข้อมูล

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

ให้ความสำคัญตามผลกระทบ ไม่ใช่จำนวนบรรทัดอย่างเดียว บางบรรทัดของอะไหล่ที่ทำให้การผลิตหยุดสำคัญกว่าหลายบรรทัดที่ปิดได้ง่าย ตรวจชิ้นส่วน lead time ยาว หาจากเจ้าเดียว นำเข้า หรือพักตรวจบ่อย และถามผู้ทำ Excel ทุกเช้าว่าเขาแก้ตัวเลขด้วยกฎใด การแก้เหล่านั้นคือข้อกำหนดระบบที่ซ่อนอยู่

หากประวัติรับเก่าหาย ให้ตกลงยอดเปิด ณ เวลาตัดระบบพร้อมหลักฐาน ผู้อนุมัติ และวันที่ จากนั้นติดตามเหตุการณ์ใหม่ในระบบใหม่ หากพบเอกสารเก่าทีหลัง ให้เพิ่มรายการปรับปรุง ไม่แก้ประวัติเงียบ ๆ เทียบระบบเก่ากับใหม่ ณ เวลาเดียวกันตามสินค้า ซัพพลายเออร์ และ PO line ยอดรวมตรงกันอาจซ่อน +10 ของชิ้นส่วน A และ −10 ของชิ้นส่วน B ซึ่งมีผลต่อแผนต่างกัน

RFP ต้องระบุเหตุการณ์ทดสอบ ไม่ใช่เพียงช่องฟังก์ชัน

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

FAT ทดสอบการคำนวณ สิทธิ์ ประวัติ และการส่งซ้ำในสภาพควบคุม SAT ทดสอบอุปกรณ์ เครือข่าย ฉลาก รหัสของซัพพลายเออร์ หน้าจอไทยและอังกฤษ และสายอนุมัติจริงของโรงงาน ระบบที่อ่านอีเมลคำตอบได้ แต่ปล่อยข้อมูลเข้า MRP ก่อนอนุมัติ ยังไม่ผ่านข้อกำหนด ผู้รับผิดชอบข้อยกเว้นต้องมีคิวงานใช้งานจริง ไม่ใช่เพียง log ของผู้ดูแล

เทียบต้นทุนบนขอบเขตเดียวกัน

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

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

จุดที่โรงงานในไทยต้องกำหนดชัด

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

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

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

เริ่มจากกลุ่มชิ้นส่วนหนึ่ง สาขาหนึ่ง และกฎปิดยอดหนึ่งชุด

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

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

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

ระบบจัดการยอดค้างรับตาม PO เหมือนระบบจัดซื้อหรือไม่

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

ยอดค้างคำนวณจากจำนวนสั่งลบจำนวนรับเท่านั้นได้หรือไม่

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

ทำไมยอดยังไม่มาถึงจึงไม่เท่ายอดรับแล้วแต่ยังไม่วางบิล

ของและใบแจ้งหนี้มาคนละเวลา บางครั้งรับของก่อน บางครั้งใบแจ้งหนี้มาก่อน เก็บจำนวน PO ใบรับ และใบแจ้งหนี้แยกพร้อมลิงก์ระดับบรรทัด การรับรู้และการจ่ายใช้กฎของบริษัท

ถ้าซัพพลายเออร์แก้วันยืนยันบ่อย MRP ควรใช้วันใด

ใช้คำยืนยันล่าสุดที่อนุมัติเป็นตัวเลือกหลัก พร้อมสถานะชั่วคราว ยืนยัน หรือช้า เก็บฉบับก่อนหน้าและแสดงว่า MRP รอบไหนรับการเปลี่ยน ให้ผู้วางแผนดูของที่ความแน่นอนต่ำ

อะไรเป็นตัวกำหนดต้นทุน

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

สรุป: ตกลงการเปลี่ยนสถานะก่อนซื้อแดชบอร์ด

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

หากโรงงานในไทยของคุณกำลังเทียบยอด PO ใน Excel หรือพบยอดต่างกันระหว่าง ERP กับ MRP สามารถปรึกษา TOMAS TECH ได้ตั้งแต่ขั้นสำรวจงาน เพียงมีตัวอย่าง PO ใบรับ และคำตอบวันส่ง ก็เริ่มร่างตารางสถานะและกรณีรับมอบที่ใช้เปรียบเทียบระบบได้

แหล่งข้อมูล

• Microsoft Learn — PO delivery schedules
• Microsoft Learn — Approve and confirm purchase orders
• Microsoft Learn — Product receipt against purchase orders
• Microsoft Learn — Requested and confirmed PO dates
• Microsoft Learn — Accounts payable invoice matching
• SAP Help Portal — Quantity Variance
• Microsoft Learn — Master planning performance
• Microsoft Learn — Master plans overview
• Microsoft Learn — Physical remaining quantity error