ระบบบริหารยอดคำสั่งซื้อค้างส่งในโรงงานไทย: ส่งบางส่วนและกำหนดส่งที่ยืนยัน

การนำระบบบริหารยอดคำสั่งซื้อค้างส่งมาใช้ในโรงงานไม่ได้มีเป้าหมายเพียงสร้างหน้าจอรายการออเดอร์ เมื่อส่งสินค้าจากคำสั่งซื้อบรรทัดเดียวหลายครั้ง ยอดค้างส่ง วันที่สัญญากับลูกค้า การจองสต็อก ใบสั่งผลิต และคำตอบจากฝ่ายขายต้องตรงกัน โรงงานในไทยอาจมี Excel ของฝ่ายขาย, ERP ที่มองตามเอกสาร, MES ที่มองตามใบสั่งผลิต และ WMS ที่มองตามเที่ยวส่ง บทความนี้เปลี่ยนปัญหาดังกล่าวเป็นข้อกำหนด RFP และการทดสอบ FAT/SAT ที่ตรวจรับได้

เริ่มจากสมการปริมาณของแต่ละบรรทัดคำสั่งซื้อ

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

ตัวเลขทุกตัวต่อไปนี้เป็นตัวอย่างสมมติ ไม่ใช่ผลดำเนินงานจริง ลูกค้าสั่ง 1,000 ชิ้น ยืนยันส่งแล้ว 600 ชิ้น และยกเลิกอย่างเป็นทางการ 100 ชิ้น ยอดยังไม่ส่งเท่ากับ 300 ชิ้น แม้คลังหยิบสินค้าเพิ่ม 200 ชิ้น ยอดยังไม่ส่งก็ยังเป็น 300 ชิ้น หน้าจอควรบอกว่า “จากยอดค้าง 300 ชิ้น มี 200 ชิ้นอยู่ระหว่างเตรียมส่ง” หากหักยอดเมื่อหยิบสินค้า แล้วการส่งถูกยกเลิก จะอธิบายส่วนต่างได้ยาก

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

แยกยอดค้าง การจอง และคำมั่นกับลูกค้า

ยอดค้าง 300 ชิ้นไม่ได้แปลว่าส่งได้พรุ่งนี้ 300 ชิ้น หน้าจอควรแยกยอดยังไม่ส่ง จำนวนที่จองจากสต็อก จำนวนที่มีแผนผลิตรองรับ จำนวนที่ยังไม่ยืนยันวันส่ง และจำนวนที่กำลังเตรียมส่ง คำมั่นกับลูกค้าคือการตัดสินใจที่ผ่านอนุมัติ ไม่ใช่ตัวเลขสต็อกจริง เอกสาร Microsoft เรื่องการจองสต็อกแยกวิธีจองอัตโนมัติ/ด้วยมือ และสต็อกจริง/จำนวนที่สั่งซื้อไว้ รวมทั้งการจัดการล็อต [2]

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

บทความนี้จำกัดขอบเขตที่สถานะยอดค้างหลังส่งบางส่วน ขั้นตอนแก้ไขจำนวน วันส่ง หรือสเปกของคำสั่งซื้ออยู่ในคู่มือการจัดการการเปลี่ยนแปลงคำสั่งซื้อ ส่วน RFP ด้านกำหนดส่งทั้งโรงงานอยู่ในคู่มือระบบบริหารกำหนดส่ง

ใช้บรรทัดคำสั่งซื้อหนึ่งรายการกับแผนส่งหลายบรรทัด

เมื่อส่งสินค้าเป็นงวด ควรรักษาบรรทัดการค้าต้นทางแล้วผูกบรรทัดกำหนดส่งและรายการส่งจริงไว้ข้างใต้ Microsoft Dynamics 365 อธิบายการแบ่งจำนวนในบรรทัดต้นทางเป็นหลายบรรทัดส่ง ซึ่งแต่ละบรรทัดมีวัน จำนวน วิธีส่ง และคลังต่างกันได้ [1] เอกสาร Microsoft ว่าด้วยการส่งตรงอธิบายการแยกจำนวนที่เหลือเป็นบรรทัดใหม่เมื่อคำสั่งซื้อเดิมได้ส่งบางส่วนแล้ว [3] จุดประสงค์คือความหมายทางธุรกิจที่สอดคล้องกัน ไม่ใช่บังคับให้ใช้การตั้งค่าผลิตภัณฑ์ใด

สมมติยอดยังไม่ส่ง 300 ชิ้น โดยยืนยันกับลูกค้าว่า 200 ชิ้นวันที่ 12 ตุลาคม และ 100 ชิ้นวันที่ 20 ตุลาคม ผลรวมกำหนดส่งสองบรรทัดต้องเท่ากับ 300 ไม่เอา 600 ชิ้นที่ส่งแล้วหรือ 100 ชิ้นที่ยกเลิกมานับซ้ำ หากงวดแรกส่งจริงเพียง 150 ชิ้น ให้คงส่วนที่ยังไม่ส่ง 50 ชิ้น แล้วตกลงวันใหม่กับลูกค้า ไม่ควรดึงงวดถัดไปมาเติมตัวเลขบนหน้าจอโดยไม่บันทึกการเปลี่ยนคำมั่น

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

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

กำหนดระบบหลักของ ERP, MES และ WMS ตามเหตุการณ์

รูปแบบหนึ่งคือ ERP ดูแลคำสั่งซื้อเชิงการค้า MES ดูแลใบสั่งผลิตและผลผลิตจริง ส่วน WMS ดูแลการจอง การหยิบ และการยืนยันส่ง แต่ระบบจริงอาจมีฟังก์ชันทับซ้อน จึงต้องระบุว่าระบบใดเป็นผู้ยืนยันเหตุการณ์แต่ละชนิดเป็นรายแรก ISA-95 เป็นกรอบอ้างอิงสำหรับการแลกเปลี่ยนข้อมูลระหว่างงานระดับองค์กรกับการปฏิบัติการผลิต [6] ไม่ได้กำหนดตำแหน่งของทุกฟังก์ชัน WMS โดยอัตโนมัติ

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

ทำให้ backorder มองเห็นและมีผู้รับผิดชอบ

การมียอดค้างไม่ได้แปลว่ามีแผนส่งครั้งถัดไป ตัวอย่าง Oracle แสดงคำสั่งซื้อ 10 ชิ้น ส่งจริง 6 ชิ้น และสร้างแผนการเคลื่อนย้าย/ส่งอีกชุดสำหรับ 4 ชิ้นที่เหลือ รวมถึงกรณีที่ต้องทำด้วยมือเมื่อเหตุการณ์ backorder ไม่ส่งผ่านระหว่างระบบ [4] หากระบบได้รับเพียงผลการส่ง แต่ไม่มีงานติดตามยอดที่เหลือ ภาระต่อลูกค้าอาจถูกทิ้งไว้โดยไม่มีเจ้าของ

คู่มือ Oracle Order Management ก็มีตัวอย่างการส่งบางส่วนแล้วคงส่วนที่เหลือเป็น backorder [5] นี่เป็นตัวอย่างผลิตภัณฑ์ ไม่ใช่ค่าเริ่มต้นของโรงงานไทย ข้อกำหนดที่ตรวจรับได้คือยอดที่เหลือต้องโยงกับคำสั่งซื้อเดิม มีผู้รับผิดชอบยืนยันวันใหม่ และยอดที่ยังไม่ยืนยันปรากฏในคิวข้อยกเว้น

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

ผูกการจองสต็อกและใบสั่งผลิตกับงวดที่เกี่ยวข้อง

ระบุว่าจะจองสต็อกทั้งบรรทัดคำสั่งซื้อหรือแยกตามงวด เมื่อยอดค้าง 300 และจองไว้ 200 ให้แสดง “ยอดค้าง 300, จองแล้ว 200, ยังไม่จอง 100” ไม่ใช่ “ยอดค้าง 100” เพราะลูกค้ายังไม่ได้รับอีก 200 หากล็อตที่จองถูกระงับคุณภาพ พบผลต่างสต็อก หรือหมดอายุ ต้องแก้การจองและทบทวนวันส่งที่ยืนยัน

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

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

ให้ฝ่ายขายตอบลูกค้าได้จากหน้าจอเดียวที่ตรวจย้อนกลับได้

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

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

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

ทำให้การส่งซ้ำไม่เพิ่มยอดและจัดการข้อความผิดลำดับ

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

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

สัญญาเชื่อมต่อระบุเหตุการณ์ เงื่อนไขการส่ง คีย์ หน่วย ระบบหลัก การตอบรับ timeout การลองใหม่ ลำดับ คิวข้อผิดพลาด สิทธิส่งใหม่ การกระทบยอดรายวัน และ audit log หากเป็น batch ให้หน้าจอแสดงความสดของข้อมูล หน้าจอที่ดูเหมือน real time แต่แสดงยอดเมื่อวานเสี่ยงต่อการตอบลูกค้าผิด

กระทบยอดทุกวันและอธิบายส่วนต่างได้

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

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

แยกการแบ่งส่ง การยกเลิก และการคืนสินค้า

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

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

ให้รหัสถาวรกับทุกบรรทัดกำหนดส่ง

หากใช้เพียงลำดับบนหน้าจอ เมื่อฝ่ายขายสลับวันส่ง ระบบปลายทางอาจเข้าใจว่าเป็นคนละงวด ใช้รหัสกำหนดส่งที่ไม่เปลี่ยน รหัสบรรทัดคำสั่งซื้อแม่ และฉบับ หากงวด 200 ถูกแยกเป็น 150 กับ 50 ให้แสดงว่าปิดงวดเก่าและงวดใหม่สองบรรทัดอ้างอิงงวดเดิมอย่างไร ห้ามนำรหัสกลับมาใช้หรือเคลียร์ประวัติ รายการส่งจริงต้องอ้างอิงฉบับที่มีผลตอนส่ง แม้แก้แผนภายหลัง หลักฐานเดิมต้องไม่เปลี่ยน

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

คำนวณยอดค้างใหม่เมื่อย้ายข้อมูล

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

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

ยอดค้าง 50 เท่ากัน แต่ต้องทำคนละอย่าง

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

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

ใส่แผนภาพสถานะและข้อมูลจริงใน RFP

ข้อความ “แสดงยอดค้างได้” ทำให้ผู้ขายแต่ละรายเสนอของคนละอย่าง แนบตัวอย่างบรรทัดคำสั่งซื้อ กำหนดส่ง การจอง ใบสั่งผลิต และรายการส่ง พร้อมการเปลี่ยนสถานะปกติและข้อยกเว้น หากเกี่ยวข้องหลายโรงงานหรือคลัง ให้ใส่กรณีนั้นด้วย ในการสาธิตใช้ลำดับตัวอย่างเดียวกัน: สั่ง 1,000 ส่ง 600 ยกเลิก 100 เหลือ 300 จอง 200 แล้วส่งอีก 150 ยอดค้างสุดท้ายต้องเป็น 150 ทั้งหมดเป็นตัวเลขทดสอบสมมติ

ให้ผู้ขายตอบว่าข้อกำหนดแต่ละข้อทำได้ด้วยฟังก์ชันมาตรฐาน การตั้งค่า การพัฒนาเพิ่ม การเชื่อมต่อ หรือขั้นตอนคน พร้อมหลักฐานหน้าจอ API รายงาน audit log หรือผลทดสอบ ระบุว่าเมื่อเกิดข้อยกเว้น ฝ่ายขาย วางแผน หรือคลังเป็นเจ้าของงานต่อไป เปรียบเทียบต้นทุนข้อมูลต้นทาง การเชื่อมต่อ การทดสอบ การอบรมหน้างาน และการสนับสนุนช่วงแรก ไม่ใช่เฉพาะค่าไลเซนส์

คำถามสิบข้อที่ใช้ใน RFP

1. เหตุการณ์ใดเปลี่ยนสมการปริมาณ และเก็บประวัติแก้ไขอย่างไร
2. หลังส่งบางส่วน ยอดค้างผูกกับบรรทัดแม่และกำหนดส่งอย่างไร
3. แยกวันที่ลูกค้าขอ วันที่ยืนยัน วันที่คาดการณ์ และวันที่วางแผนส่งได้หรือไม่
4. การจองและใบสั่งผลิตผูกกับงวดส่งอย่างไร
5. ใครได้รับแจ้งเมื่อคุณภาพหรือเครื่องจักรกระทบวันสัญญา
6. เหตุการณ์ยืนยันส่งที่เป็นหลักเพียงหนึ่งแห่งของ ERP/MES/WMS อยู่ที่ไหน
7. จัดการข้อความซ้ำ ผิดลำดับ และเครือข่ายขัดข้องอย่างไร
8. อนุมัติและเก็บคำตอบลูกค้าภาษาไทย ญี่ปุ่น อังกฤษอย่างไร
9. โมเดลการคืน การยกเลิก สินค้าทดแทน และเปลี่ยนปลายทางอย่างไร
10. หลักฐาน FAT/SAT และหลังใช้งานใดพิสูจน์ว่ายอดค้างถูกต้อง

ทดสอบกรณีขอบเขตใน FAT/SAT

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

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

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

รูปที่ 3 แสดง FAT/SAT ของการส่งบางส่วนและการเชื่อมต่อขาด ข้อความส่งซ้ำจาก WMS ต้องปรับยอดค้างใน ERP เพียงครั้งเดียวและคำตอบลูกค้าต้องตรงกัน

กำหนดทางออกของโครงการนำร่องและช่วงเสถียรภาพ

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

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

สรุป: รักษายอดที่ยังต้องส่งไว้ตลอดทุกเที่ยวส่ง

ระบบบริหารยอดคำสั่งซื้อค้างส่งต้องรักษาความสัมพันธ์ระหว่างจำนวนสั่ง ส่งแล้ว ยกเลิก และยังไม่ส่ง ทุกครั้งที่ส่งบางส่วน ยอดที่เหลือต้องยังมีวันที่สัญญา การจอง การผลิต และงานส่งครั้งต่อไป กำหนดผู้ยืนยันเหตุการณ์และรหัสของ ERP/MES/WMS เพื่อไม่ให้นับซ้ำแม้เครือข่ายขัดข้อง และเก็บหลักฐานคำตอบลูกค้า จุดเริ่มที่ทำได้ทันทีคือเลือกออเดอร์ที่เคยส่งหลายครั้งหนึ่งรายการ แล้วเทียบจำนวนกับวันที่ระหว่าง Excel, ERP, MES และ WMS

TOMAS TECH ช่วยโรงงานในไทยกำหนดข้อกำหนดยอดค้างและส่งแบ่งงวด ขอบเขตเหตุการณ์ ERP/MES/WMS รวมถึง RFP และ FAT/SAT แม้ยังไม่ได้เลือกระบบก็สามารถปรึกษาโครงการบริหารยอดคำสั่งซื้อค้างส่งพร้อมแผนผังคำสั่งซื้อถึงการส่งที่ใช้อยู่

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

ระบบยอดค้างต่างจากระบบบริหารกำหนดส่งอย่างไร

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

ส่งบางส่วนแล้วคำนวณยอดค้างอย่างไร

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

Backorder หมายความว่าส่งช้าทุกครั้งหรือไม่

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

การเชื่อม ERP, MES, WMS ที่สำคัญที่สุดคืออะไร

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

FAT/SAT ของระบบยอดค้างต้องพิสูจน์อะไร

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

แหล่งข้อมูลหลัก

1. Microsoft Learn, Delivery schedules.
2. Microsoft Learn, Reserve inventory quantities.
3. Microsoft Learn, Direct deliveries.
4. Oracle Help Center, Backorder/Partial Ship.
5. Oracle, Ship Order Lines in Shipment Sets.
6. ISA, ISA-95 Standard.

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