ระบบจัดการสินค้าคงคลังแบบ FIFO 2026: คู่มือโรงงานไทย

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

ข้อสรุป: FIFO ต้องเชื่อมเหตุการณ์รับ–จ่าย ไม่ใช่แค่เรียงวันที่รับเข้า

FIFO (First In, First Out) คือการจ่ายสินค้าที่รับเข้าก่อนเป็นหลัก ส่วน FEFO (First Expiry, First Out) คือการจ่ายสินค้าที่หมดอายุก่อน หากล็อตที่เพิ่งรับเข้ามีวันหมดอายุเร็วกว่าสต็อกเดิม ลำดับจ่ายของสองวิธีจะไม่เหมือนกัน สินค้าอาหาร ยา เวชภัณฑ์ กาว สี หรือวัตถุดิบที่มีอายุใช้งานจึงอาจเหมาะกับ FEFO มากกว่า

ระบบควรทำได้ 5 เรื่องต่อไปนี้

1. กำหนดกติกา FIFO, FEFO, ระบุล็อตเฉพาะ และห้ามจ่าย แยกตามสินค้า
2. บันทึกล็อต วันหมดอายุ ตำแหน่ง และสถานะคุณภาพตั้งแต่รับเข้า ไม่ใช่มีเพียงเวลา
3. แสดงสต็อกที่แนะนำบนอุปกรณ์ และเก็บเหตุผลกับการอนุมัติเมื่อหยิบล็อตอื่น
4. บันทึกการย้าย แบ่ง รวม คืน กักกัน และส่วนต่างจากการนับเป็นเหตุการณ์ทันที
5. ออกแบบลำดับหยิบทางกายภาพแยกจากวิธีตีมูลค่าสินค้าคงคลังทางบัญชี

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

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

คู่มือคลังสินค้าของ WHO ใช้ FEFO กับรายการที่มีวันหมดอายุ และ FIFO กับรายการที่ไม่มีวันหมดอายุ พร้อมเตือนว่าสินค้าที่รับใหม่อาจหมดอายุก่อนสินค้าที่รับไว้แล้ว เอกสาร WHO TRS 1025 Annex 7 เผยแพร่วันที่ 17 มิถุนายน 2020 และยังอยู่ในรายการแนวทางการกระจายผลิตภัณฑ์ปัจจุบันของ WHO เมื่อเราตรวจสอบวันที่ 28 สิงหาคม 2026 โดยกำหนดให้หมุนเวียนสต็อกอย่างเหมาะสมและใช้ FEFO กับผลิตภัณฑ์ทางการแพทย์ บทความนี้ใช้อ้างอิงด้านการปฏิบัติงานระหว่างประเทศ มิได้ใช้แทนกฎหมายไทย

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

FIFO ทางกายภาพกับ FIFO ทางบัญชีไม่ใช่ข้อกำหนดเดียวกัน

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

คำถามที่พบบ่อยเรื่องต้นทุนสินค้าคงคลังของ Microsoft Dynamics 365 อธิบาย FIFO ในฐานะโมเดลต้นทุนแบบเป็นงวดที่เกี่ยวกับการปิดและชำระธุรกรรมสต็อก ดังนั้น RFP ควรทดสอบการจัดสรรทางกายภาพ คำสั่งหยิบ ล็อตจริง วิธีตีมูลค่า และการปิดงวดแยกกัน ไม่ควรรับเพียงคำว่า “รองรับ FIFO”

ตัวอย่างข้อมูล 12 รายการสำหรับระบบจัดการสินค้าคงคลัง FIFO

ยอดคงเหลือปัจจุบันอย่างเดียวไม่พอ ต้องมีประวัติเหตุการณ์ GS1 Global Traceability Standard ซึ่งตรวจสอบหน้ามาตรฐานปัจจุบันเมื่อ 28 สิงหาคม 2026 ระบุแนวคิดข้อมูลหลัก ได้แก่ เวลาและเขตเวลา รหัสวัตถุระดับรายชิ้นหรือล็อต สถานที่ ขั้นตอนธุรกิจและสถานะ รวมถึงผู้รับผิดชอบเมื่อเกี่ยวข้อง

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

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

การจัดการตำแหน่งคลังสินค้า: บริหารสต็อกที่หยิบได้จริง

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

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

กติกาจัดลำดับที่เหมาะสมมักเป็นดังนี้

1. เลือกเฉพาะสต็อกสถานะพร้อมใช้
2. กรองตามลูกค้า คำสั่งผลิต คุณภาพ และสภาพเก็บ
3. เรียง FEFO ตามวันหมดอายุ และ FIFO ตามลำดับรับ
4. หากเท่ากัน ใช้เส้นทางหยิบ ของเปิดแล้ว จำนวนคงเหลือน้อย หรือประสิทธิภาพขนย้าย
5. บล็อกหรือขออนุมัติเมื่ออายุคงเหลือต่ำกว่าเกณฑ์

เอกสาร Oracle WMS Cloud 26A แยก FIFO ตามเวลา Create ของสต็อกหรือ LPN และ FEFO ตาม Priority Date อย่างชัดเจน จึงใช้เป็นตัวอย่างการเขียนคีย์จัดลำดับและกติกากรณีค่าเท่ากันใน RFP ได้

สต็อกแบบเรียลไทม์ต้องกำหนดจังหวะยืนยันธุรกรรม

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

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

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

อุปกรณ์มือถือควรเพิ่มหลักฐานโดยไม่เพิ่มการพิมพ์

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

อ่านแนวทางเพิ่มเติมได้ที่ คู่มือติดตั้งเครื่อง Handheld Terminal สำหรับโรงงานไทย ควรทดสอบหน้าจอภาษาไทยหรือภาษาที่ตกลง ถุงมือ แสง คุณภาพฉลาก จุดอับสัญญาณ การชาร์จ และเครื่องสำรอง

โฟลว์มาตรฐาน FIFO/FEFO ตั้งแต่รับเข้าถึงจ่ายออก

1. เทียบแผนรับกับสินค้าจริง

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

SOP เรื่อง FEFO ของ WHO แนะนำให้บันทึกเลขล็อต วันหมดอายุ และชั้น/ตำแหน่งตอนรับเข้า แม้จัดทำสำหรับเวชภัณฑ์ แต่ช่วยกำหนดความต้องการรับเข้าสินค้ามีอายุได้ดี

2. ใส่สถานะคุณภาพก่อนจัดเก็บ

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

3. บันทึกการเติมและย้าย

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

4. แยกการจัดสรรกับการจ่ายจริง

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

5. คืนวัสดุเหลือเข้าประวัติเดิม

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

สาเหตุและมาตรการแก้ไขส่วนต่างสต็อก: อย่าปิดเรื่องด้วยการปรับจำนวน

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

การนับหมุนเวียนไม่จำเป็นต้องหยุดทั้งคลัง เลือกของหมุนเร็ว มีส่วนต่างบ่อย ใกล้หมดอายุ และตำแหน่งว่างตามความเสี่ยง ออกแบบการนับแบบไม่เห็นยอด การอนุมัตินับซ้ำ และควบคุมธุรกรรมก่อนปรับ เอกสาร Cycle Count ของ Oracle ก็ครอบคลุมการนับตามตำแหน่ง

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

จัดการข้อยกเว้นโดยไม่หยุดโรงงาน

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

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

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

แบ่งบทบาท WMS ระบบผลิต และ ERP

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

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

งบประมาณต้องรวมฉลาก เครื่องมือถือ Wi-Fi เครื่องพิมพ์ การเตรียมมาสเตอร์ การเชื่อมระบบ การอบรม และบริการในประเทศ ไม่ใช่แค่ไลเซนส์ อ่านกรอบจัดซื้อได้ใน คู่มือต้นทุน WMS สำหรับโรงงานไทย

เช็กลิสต์ RFP และการทดสอบรับมอบ

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

มาสเตอร์และกติกา

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

งานหน้างาน

• แสดงคำสั่งสั้นเป็นภาษาไทยหรือภาษาที่ตกลง
• จัดการบาร์โค้ดเสีย จำนวนต่าง ล็อตอื่น และออฟไลน์ได้
• หยุด ยกเลิก และทำต่อโดยไม่บันทึกซ้ำ
• ส่งงานค้างไปเครื่องสำรองได้อย่างปลอดภัย
• คุมสิทธิ์อนุมัติข้อยกเว้นและปรับสต็อก

ตรวจสอบและกู้คืน

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

ตัวอย่างการทดสอบรับมอบ 10 สถานการณ์

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

1. สร้างการรับเก่าและใหม่ แล้วตรวจสต็อกที่ระบบแนะนำตาม FIFO
2. ให้ล็อตรับทีหลังหมดอายุก่อน แล้วตรวจสต็อกที่ระบบแนะนำตาม FEFO
3. กักล็อตอันดับแรก แล้วตรวจว่าระบบเลือกล็อตถัดไป
4. ตัดสต็อกที่ไม่ผ่านอายุคงเหลือขั้นต่ำของลูกค้า
5. แบ่งพาเลตและกระทบยอดจำนวนแม่–ลูกกับวันหมดอายุ
6. สแกนล็อตที่ไม่แนะนำและเก็บคำเตือน เหตุผล การอนุมัติ
7. ทำงานออฟไลน์แล้วตรวจลำดับส่งและการตัดซ้ำเมื่อออนไลน์
8. เชื่อมสินค้าคืนกับล็อตต้นทางและใช้ซ้ำหลังทบทวนสถานะ
9. นับซ้ำส่วนต่างและตรวจประวัติก่อน/หลังปรับ
10. ทำให้ ERP เชื่อมล้มหนึ่งครั้ง แล้วตรวจว่าส่งซ้ำไม่เพิ่มสต็อกสองเท่า

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

ตัวอย่างการนำไปใช้แบบ 90 วัน

90 วันเป็นตัวอย่างกรอบเวลานำระบบไปใช้ ไม่ใช่ระยะเวลาตามกฎหมายหรือมาตรฐานสากล ช่วงแรกกำหนดมาสเตอร์และโฟลว์ปัจจุบันในหนึ่งคลังและกลุ่มสินค้า ช่วงสองทดสอบเครื่อง ฉลาก การจัดสรร ข้อยกเว้น และการเชื่อม ช่วงสามทดสอบกะกลางคืน ออฟไลน์ นับสต็อก กู้คืน และกระทบยอดสิ้นเดือน

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

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

ระบบจัดการสินค้าคงคลังแบบ FIFO จัดการอะไรบ้าง

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

ควรเลือก FIFO หรือ FEFO

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

ตำแหน่งแบบ Fixed หรือ Free Location ดีกว่า

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

สต็อกเรียลไทม์ต้องออนไลน์ตลอดหรือไม่

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

เริ่มวิเคราะห์ส่วนต่างสต็อกตรงไหน

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

ติดตั้ง WMS แล้ว FIFO ทำงานอัตโนมัติหรือไม่

ไม่อัตโนมัติ มาสเตอร์ ฉลาก ผังชั้น การสแกน การอนุมัติ การอบรม และการเชื่อม ERP/ระบบผลิตต้องสอดคล้อง ควรทดสอบข้อยกเว้นจริง ไม่ใช่ดูเฉพาะเดโมปกติ

สรุป

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

หากกำลังวาง FIFO/FEFO ตำแหน่งคลัง เครื่องมือถือ หรือการเชื่อม ERP กับระบบผลิตสำหรับโรงงานไทย สามารถปรึกษา TOMAS TECH ได้ตั้งแต่ข้อกำหนดยังไม่สมบูรณ์ เราช่วยทบทวนโฟลว์ปัจจุบันและเลือกขอบเขตเริ่มต้นที่หน้างานดำเนินต่อได้

เอกสารอ้างอิง

• WHO TRS 1025 Annex 7 (เผยแพร่ 17 มิถุนายน 2020; ตรวจรายการปัจจุบัน 28 สิงหาคม 2026)
• WHO Guidelines: Distribution (ตรวจรายการปัจจุบัน 28 สิงหาคม 2026)
• WHO eManual: Warehouse and Stock Management (ตรวจ 28 สิงหาคม 2026)
• WHO FEFO standard operating procedure (ตรวจ 28 สิงหาคม 2026)
• GS1 Global Traceability Standard (ตรวจหน้ามาตรฐานปัจจุบัน 28 สิงหาคม 2026)
• Oracle WMS Cloud 26A: Allocation Method (ตรวจ 28 สิงหาคม 2026)
• Oracle WMS Cloud 25D: Expiration Dates (ตรวจ 28 สิงหาคม 2026)
• Microsoft Learn: Inventory costing FAQ (ตรวจ 28 สิงหาคม 2026)