Blog

2026.10.16

ระบบ VMI และสต็อกฝากของซัพพลายเออร์ | กฎการโอนกรรมสิทธิ์ การชำระเงิน และการเติมสต็อกสำหรับโรงงานในไทย

ระบบ VMI และสต็อกฝากของซัพพลายเออร์ | กฎการโอนกรรมสิทธิ์ การชำระเงิน และการเติมสต็อกสำหรับโรงงานในไทย

บทนำ: สิ่งที่ต้องตัดสินใจก่อนนำระบบ VMI และสต็อกฝากมาใช้

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

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

  1. จุดโอนกรรมสิทธิ์และการรับภาระความเสี่ยง: โอนตอนรับเข้า ตอนเบิกจ่ายหรือเบิกใช้ หรือหลังผ่านไประยะหนึ่ง และใครเป็นผู้รับภาระเมื่อของสูญหาย เสียหาย หรือล้าสมัย
  2. ขั้นตอนการบันทึกการเบิกใช้และการชำระบัญชี: อะไรถือเป็นการเบิกใช้ ชำระเมื่อไร ด้วยราคาต่อหน่วยใด และด้วยเอกสารใด โดยแยกใบสรุปการชำระบัญชีของ ERP ออกจากเอกสารภาษีของไทย
  3. กฎการเติมสต็อกและสต็อกค้างนาน: ใครกำหนด min max และใครเป็นผู้เติมสต็อก จะให้ซัพพลายเออร์เห็นข้อมูลอะไร ระยะเวลาฝากสูงสุดคือเท่าไร และจะรับซื้อเมื่อครบกำหนดอย่างไร

นอกจากนี้ ต้องตัดสินใจเรื่อง ข้อมูลหลักราคา (price master) การแยกประเภทสต็อก และการแบ่งความรับผิดชอบในการตรวจนับสต็อก ไปพร้อมกัน เพราะทั้ง 3 เรื่องนี้เป็นเงื่อนไขพื้นฐานของกฎข้อ 1 ถึง 3

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

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

ทำไมโรงงานในไทยจึงควรทบทวนสต็อกฝากและ VMI ในตอนนี้

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

ตาม Trading Economics ยอดผลิตรถยนต์เดือนสิงหาคมที่สภาอุตสาหกรรมแห่งประเทศไทย (FTI) ประกาศเมื่อวันที่ 28 กันยายน 2026 อยู่ที่ 124,646 คัน เพิ่มขึ้น +10.93% เมื่อเทียบกับเดือนเดียวกันของปีก่อน และตาม MarkLines ทาง FTI อธิบายว่าการผลิตรถยนต์นั่ง BEV ที่เพิ่มขึ้นและการผลิตรถกระบะเพื่อส่งออกที่เพิ่มขึ้นมีส่วนช่วย ตัวเลขนี้เป็นยอดผลิตรถยนต์สำเร็จรูป ไม่ได้สะท้อนปริมาณคำสั่งซื้อของโรงงานชิ้นส่วนโดยตรง

สำหรับดัชนีผลผลิตอุตสาหกรรม (MPI) ตามบทความที่เผยแพร่ผ่านรอยเตอร์ ค่าของเดือนสิงหาคม 2026 ที่สำนักงานเศรษฐกิจอุตสาหกรรม กระทรวงอุตสาหกรรม ประกาศเมื่อวันที่ 30 กันยายน เพิ่มขึ้น 4.44% เมื่อเทียบกับเดือนเดียวกันของปีก่อน ผู้อำนวยการสำนักงานอธิบายว่ากระทรวงอุตสาหกรรมได้ปรับวิธีคำนวณ MPI โดยเพิ่มผลิตภัณฑ์อิเล็กทรอนิกส์ใหม่และเปลี่ยนค่าน้ำหนัก และตาม Trading Economics การปรับนี้ทำให้ค่าของเดือนกรกฎาคมเปลี่ยนไปจากค่าที่ประกาศก่อนการปรับด้วย เวลาเปรียบเทียบกับเดือนก่อนๆ จึงต้องเทียบค่าหลังการปรับจากแหล่งเดียวกัน

มาดูความเคลื่อนไหวของบริษัทญี่ปุ่นในไทยด้วย ในการสำรวจภาวะธุรกิจครึ่งปีแรกของปี 2026 ของหอการค้าญี่ปุ่น กรุงเทพฯ (JCC) (ประกาศเมื่อวันที่ 30 มิถุนายน 2026 มีผู้ตอบ 504 บริษัท) บริษัทที่ตอบว่า “ทบทวนการบริหารสต็อกและระบบโลจิสติกส์” เป็นมาตรการรับมือความไม่แน่นอนของสถานการณ์ตะวันออกกลาง (ตอบได้หลายข้อ) มีสัดส่วน 36% คำตอบนี้หมายถึงการทบทวนสต็อกและโลจิสติกส์โดยรวม ไม่ใช่สัดส่วนของบริษัทที่มีแผนจะนำ VMI หรือสต็อกฝากมาใช้

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

สต็อกฝาก (consignment stock) คืออะไร VMI คืออะไร: ความแตกต่างและการใช้ร่วมกัน

สต็อกฝากคืออะไร: เรื่องของกรรมสิทธิ์

สต็อกฝากเป็นเรื่องของ “ใครเป็นเจ้าของ” เนื้อหาการเรียนรู้ของ SAP อธิบายว่า consignment คือสภาพที่สินค้าซึ่งซัพพลายเออร์ส่งมาถูกเก็บไว้ในคลังของบริษัทผู้ซื้อ แต่กรรมสิทธิ์ยังเป็นของซัพพลายเออร์ และหนี้ต่อซัพพลายเออร์จะเกิดขึ้นเมื่อเบิกสินค้าออกจากสต็อกฝากเท่านั้น เอกสารของ Microsoft ก็อธิบายว่าสต็อกฝากคือสต็อกที่ซัพพลายเออร์เป็นเจ้าของและเก็บไว้ที่ไซต์ของบริษัทผู้ซื้อ โดยผู้ซื้อจะรับโอนกรรมสิทธิ์เมื่อพร้อมจะเบิกใช้หรือใช้งาน ส่วนเอกสารของ Oracle อธิบายว่ากรรมสิทธิ์จะโอนเมื่อหน่วยงานผลิตนำไปใช้ และเรียกสิ่งนี้ว่าการเบิกใช้ (consumption)

ในหน้างานของญี่ปุ่นบางครั้งเรียกว่า Yotaku Zaiko บทความนี้จะเรียกสต็อกที่วางไว้ในโรงงานของผู้ซื้อหรือคลังสินค้าใกล้เคียงโดยที่กรรมสิทธิ์ยังเป็นของซัพพลายเออร์ว่า สต็อกฝาก (consignment stock)

VMI คืออะไร: เรื่องของความรับผิดชอบในการเติมสต็อก

VMI เป็นเรื่องของ “ใครเป็นผู้บริหารการเติมสต็อก” ตามนิยามในพจนานุกรมของ APICS ที่บทความของ MONOist (23 ตุลาคม 2015) อ้างอิง VMI คือวิธีที่ซัพพลายเออร์ดูข้อมูลสต็อกของลูกค้า และรับผิดชอบรักษาระดับสต็อกตามที่ลูกค้าต้องการ เอกสารของ Infor อธิบายว่า VMI คือวิธีที่ซัพพลายเออร์บริหารสต็อกของลูกค้า มีทั้งแบบที่ซัพพลายเออร์รับผิดชอบการวางแผนอุปทาน (supply planning) ด้วย และแบบที่ลูกค้าบริหารสต็อกเองโดยซัพพลายเออร์รับผิดชอบเฉพาะการวางแผนอุปทาน

การใช้ร่วมกันและ supplier hub

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

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

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

ขอบเขตกับวัตถุดิบที่ลูกค้าจัดหาให้

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

ใครรับผิดชอบอะไร: 3 คำถามเรื่องการบริหารคลัง การวางแผนเติมสต็อก และกรรมสิทธิ์

เอกสารของ Infor จัดระเบียบสถานการณ์ VMI โดยใช้ 3 คำถามต่อไปนี้เป็นแกน ใครเป็นผู้บริหารคลัง ใครเป็นผู้วางแผนอุปทาน และใครเป็นเจ้าของสินค้าทางการเงิน และอธิบายว่าใน LN ต้องกำหนดความรับผิดชอบของบริษัทเรา ซัพพลายเออร์ และฝ่ายอื่นๆ ไว้

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

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

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

ภาพรวมฟังก์ชันที่ระบบ VMI และสต็อกฝากต้องมี

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

ขอบเขตฟังก์ชันเนื้อหาหลักกฎที่เกี่ยวข้อง
การรับเข้าและการแยกประเภทสต็อกรับของฝากเข้าโดยแยกตามซัพพลายเออร์ มีสถานะระหว่างตรวจคุณภาพและสถานะระงับเงื่อนไขพื้นฐาน (การแยกประเภทสต็อก)
การเบิกใช้และการโอนกรรมสิทธิ์ตั้งค่าว่าอะไรถือเป็นการเบิกใช้ และโอนกรรมสิทธิ์เมื่อเบิกใช้ รวมถึงวิธีจัดการเมื่อยกเลิกกฎข้อ 1
การชำระบัญชีรวบรวมการเบิกใช้ แล้วจัดทำใบสรุปการชำระบัญชีหรือใบแจ้งการเบิกใช้ โดยดึงราคาต่อหน่วยจากข้อมูลหลักราคากฎข้อ 2 และเงื่อนไขพื้นฐาน (ข้อมูลหลักราคา)
การเติมสต็อกและการมองเห็นข้อมูลมี min max ให้ซัพพลายเออร์เห็นสต็อกและความต้องการใช้ และแจ้งเตือนตามเกณฑ์กฎข้อ 3
การจัดการสต็อกค้างนานติดตามจำนวนวันนับจากการเคลื่อนไหวครั้งล่าสุดหรือระยะเวลาฝาก และดึงรายการที่ครบกำหนดออกมากฎข้อ 3
การตรวจนับสต็อกกำหนดว่าใครนับของฝาก และจัดการส่วนต่างอย่างไรเงื่อนไขพื้นฐาน (การแบ่งความรับผิดชอบในการตรวจนับสต็อก)
EDI และพอร์ทัลแลกเปลี่ยนข้อมูลสต็อก การเบิกใช้ และการเรียกเก็บเงินกับซัพพลายเออร์กฎข้อ 2 และข้อ 3

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

ระบบ VMI และสต็อกฝากของซัพพลายเออร์ | กฎการโอนกรรมสิทธิ์ การชำระเงิน และการเติมสต็อกสำหรับโรงงานในไทย - figure 1

กฎข้อ 1: กำหนดจุดโอนกรรมสิทธิ์

อะไรถือเป็น “การเบิกใช้”

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

ทริกเกอร์ที่เป็นตัวเลือกหลักๆ มี 4 แบบ

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

วิธีรองรับของแต่ละผลิตภัณฑ์

ERP แต่ละตัวรองรับทริกเกอร์เหล่านี้ต่างกัน

ตามเนื้อหาการเรียนรู้ของ SAP ใน S/4HANA สต็อกฝากจะถูกบริหารเป็น special stock K แยกตามซัพพลายเออร์ และอธิบายว่าหนี้ต่อซัพพลายเออร์จะเกิดขึ้นทั้งเมื่อจ่ายออกเพื่อเบิกใช้ (ตามคำอธิบายใน KBA คือ movement type 201K) และเมื่อโอนเข้าเป็นสต็อกของบริษัทเราด้วย movement type 411 ร่วมกับ special stock indicator K

เอกสารของ Oracle E-Business Suite 12.2 อธิบายว่า การจัดส่งตามใบสั่งขาย การเบิกจ่ายเข้า WIP การโอนระหว่างองค์กร และการจ่ายออกเบ็ดเตล็ด ถือเป็นการเบิกใช้เสมอ ส่วนการโอนระหว่าง subinventory, move order และ backflush transfer เป็นต้น จะกำหนดผ่านกฎการตั้งค่ารายการเบิกใช้ว่าจะถือเป็นการเบิกใช้หรือไม่

เอกสารของ Infor LN อธิบายการโอนแบบอิงการเบิกใช้ (consumption-based) และการโอนแบบอิงเวลา (time-based) ส่วนการย้ายระหว่างคลังจะถือเป็นการเบิกใช้หรือไม่ ตั้งค่าได้ที่ “Usage at Warehouse Transfer” เช่น ถ้าเลือก “Only between Clusters” การย้ายภายใน cluster เดียวกัน กรรมสิทธิ์จะยังเป็นของซัพพลายเออร์ แต่ถ้าย้ายไปยังคลังหน้างานของ cluster อื่นจะถือเป็นการเบิกใช้

เอกสารของ Microsoft Dynamics 365 Supply Chain Management อธิบายว่าการเปลี่ยนกรรมสิทธิ์ทำโดยการ post “inventory ownership change journal” รายการในสมุดรายวันนี้ป้อนด้วยมือ หรือสร้างจากความต้องการวัตถุดิบของใบสั่งผลิต และโดยปกติหัวหน้างานในพื้นที่ผลิตเป็นผู้ทำ เอกสารเดียวกันระบุชัดว่าไม่รองรับการประมวลผลสมุดรายวันกรรมสิทธิ์แบบอัตโนมัติ การตั้งค่าแล้วไม่ได้หมายความว่ากรรมสิทธิ์จะโอนอัตโนมัติเสมอไป จึงต้องออกแบบการปฏิบัติงานว่าใครจะสร้างสมุดรายวันเมื่อไร

กรณีถือว่าการเบิกจ่ายคือการเบิกใช้

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

วิธีจัดการเมื่อยกเลิก

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

กฎข้อ 1 (ต่อ): การรับภาระความเสี่ยงและสถานะคุณภาพ

เรื่องที่ต้องตกลงในสัญญา

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

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

บทความวิจัยของ Valentini & Zavanella (2003) กล่าวว่า ข้อตกลงขั้นสุดท้ายของสต็อกฝากมีพารามิเตอร์ที่เกี่ยวข้องใกล้ชิดกับภาษีและกฎระเบียบ ซึ่งอาจแตกต่างกันในบริบทระหว่างประเทศ สัญญากับซัพพลายเออร์ข้ามประเทศจึงยิ่งต้องตรวจสอบล่วงหน้า

การแยกสถานะคุณภาพ

ควรใส่สถานะคุณภาพไว้ในการแยกประเภทสต็อกด้วย ตามเนื้อหาการเรียนรู้ของ SAP สต็อกฝากมีสต็อก 3 ประเภท คือ พร้อมใช้ (unrestricted) ระหว่างตรวจคุณภาพ และระงับ (blocked) และการจ่ายออกเพื่อเบิกใช้ทำได้จากสต็อกพร้อมใช้เท่านั้น สต็อกที่อยู่ระหว่างตรวจคุณภาพหรือถูกระงับต้องโอนเป็นพร้อมใช้ก่อน

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

การแยกประเภทสต็อกและการจัดวางจริง: จะแยกถือสต็อกฝากอย่างไร

วิธีแยกประเภทของแต่ละผลิตภัณฑ์

การแยกสต็อกฝากออกจากสต็อกของบริษัทเรา แต่ละผลิตภัณฑ์มีแนวคิดต่างกัน

ผลิตภัณฑ์วิธีแยกประเภท (ตามคำอธิบายในเอกสารของแต่ละบริษัท)
SAP S/4HANAspecial stock K แยกตามซัพพลายเออร์ อัปเดตที่ระดับ storage location และถือแบบไม่ตีมูลค่า
Microsoft Dynamics 365แยกเจ้าของด้วย dimension Owner
Oracle E-Business Suiteแยกด้วย owning party
Infor LNกำหนดเป็นคลัง VMI และฝ่ายที่ไม่ได้บริหารคลังจะถือเป็น administrative warehouse

เอกสารของ Infor อธิบายว่า ให้กำหนดคลัง VMI ไว้ใน ERP ของทั้งลูกค้าและซัพพลายเออร์ ฝ่ายที่บริหารคลังกำหนดเป็นคลังปกติ ส่วนฝ่ายที่ไม่ได้บริหารคลังกำหนดเป็น administrative warehouse เอกสารของ Microsoft อธิบายว่าฟิลด์ Owner ซัพพลายเออร์ก็มองเห็นได้ จึงอาจเปลี่ยนเป็นชื่อที่เข้าใจง่ายได้

จะแยกพื้นที่จริงหรือไม่

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

แต่ก็มีข้อควรระวัง เอกสารของ Oracle อธิบายว่า สต็อกฝากกับสต็อกปกติวางปะปนใน subinventory หรือ locator เดียวกันได้ แต่ตอนเบิกจ่ายจะไม่มีฝ่ายใดได้รับความสำคัญก่อน และระบบจะเลือกแบบ FIFO ถ้ามีการปฏิบัติงานที่ต้องการใช้สต็อกของบริษัทเราก่อน หรือต้องการใช้สต็อกฝากก่อน ก็ต้องตัดสินใจไว้ว่าจะวางปะปนกัน หรือจะแยกพื้นที่จริง

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

กฎข้อ 2: ขั้นตอนการบันทึกการเบิกใช้และการชำระบัญชี

กำหนดรอบการชำระบัญชี

เมื่อบันทึกการเบิกใช้แล้ว ก็นำมารวมเพื่อชำระบัญชี รอบมีตั้งแต่รายวันถึงรายเดือน บทความวิจัยของ Valentini & Zavanella กล่าวถึงกฎพื้นฐานของสต็อกฝากว่า ผู้ซื้อเบิกของออกตามความจำเป็นในแต่ละวัน การชำระเงินเป็นไปตามข้อตกลงซึ่งในทางทฤษฎีทำได้ถึงระดับรายวัน และข้อมูลการเบิกใช้จะแจ้งให้ซัพพลายเออร์ทราบทันที เอกสารของ Infor อธิบายว่า โดยทั่วไปลูกค้าจะทำ self-billing และชำระรวมกัน เช่น เดือนละครั้ง ส่วนเอกสารของ Oracle อธิบายว่า รายการเบิกใช้จะถูกรวบรวมตามรอบการเรียกเก็บเงิน (จำนวนวัน) ใน Approved Supplier List (ASL)

เอกสารการชำระบัญชี 3 รูปแบบ

เอกสารการชำระบัญชีแบ่งได้กว้างๆ เป็น 3 รูปแบบ

รูปแบบเนื้อหาตัวอย่างในเอกสาร
ใบแจ้งการเบิกใช้ผู้ซื้อแจ้งจำนวนและมูลค่าการเบิกใช้ให้ซัพพลายเออร์ เพื่อใช้เป็นหลักฐานในการเรียกเก็บเงินConsumption Advice ของ Oracle
การออกเอกสารเรียกเก็บเงินแทนโดยผู้ซื้อ (self-billing)ผู้ซื้อจัดทำเอกสารการจ่ายเงินตามการเบิกใช้MRKO ของ SAP, Pay On Use ของ Oracle, ERS ของ SAP Business Network SCC
ใบแจ้งหนี้จากซัพพลายเออร์ซัพพลายเออร์ดูการเบิกใช้แล้วออกใบแจ้งหนี้ ผู้ซื้อตรวจทานขั้นตอนของ Microsoft Dynamics 365

ตามเนื้อหาการเรียนรู้ของ SAP ของฝากจะชำระบัญชีโดยไม่ต้องรับใบแจ้งหนี้ เหตุผลคือซัพพลายเออร์ไม่สามารถติดตามการจ่ายออกได้โดยตรง โดยใช้ MRKO ชำระบัญชีรายการจ่ายออกที่ยังไม่ได้ชำระ และใช้ message type KONS แจ้งรายการจ่ายออกที่ชำระแล้วและยอด credit memo ให้ซัพพลายเออร์

เอกสารของ Oracle อธิบายว่า ใบแจ้งการเบิกใช้ (Consumption Advice) คือเอกสารทางการที่แจ้งจำนวนและมูลค่าของของฝากที่เบิกใช้ในคลังให้ซัพพลายเออร์ทราบ ใบแจ้งการเบิกใช้ฉบับใหม่จะถูกสร้างเมื่อ “วันที่ของระบบเลยวันที่ได้จากวันเรียกเก็บครั้งล่าสุดบวกจำนวนวันของรอบการเรียกเก็บเงิน” และอธิบายว่า Pay On Use เป็นวิธี self-billing ที่ลงทะเบียนใบแจ้งหนี้อัตโนมัติแทนซัพพลายเออร์ ช่วยย่นเวลาตั้งแต่การเบิกใช้จนถึงการจ่ายเงิน

ในเอกสารของ Microsoft อธิบายขั้นตอนที่ซัพพลายเออร์ดูการเบิกใช้แล้วเรียกเก็บเงิน และผู้ซื้อตรวจทานใบแจ้งหนี้นั้นกับใบสั่งซื้อที่ระบบสร้างอัตโนมัติแล้วจึงจ่ายเงิน

Odette อธิบายว่า ลูกค้าบางรายในอุตสาหกรรมยานยนต์ใช้ Self-Billing ซึ่งลูกค้าจัดทำใบแจ้งหนี้เองตามสิ่งที่รับหรือเบิกใช้ไป

แหล่งอ้างอิงราคา (ข้อมูลหลักราคา)

ต้องตัดสินใจไปพร้อมกันด้วยว่า จะดึงราคาต่อหน่วยสำหรับการชำระบัญชีมาจากที่ใด ตามเนื้อหาการเรียนรู้ของ SAP ให้สร้าง purchasing info record สำหรับ consignment ตามคู่ของซัพพลายเออร์สต็อกฝากกับสินค้า และตีมูลค่าด้วยราคาใน info record ณ วันที่จ่ายออก (วันที่โอน) รวมถึงตั้งราคาสกุลเงินต่างประเทศหรือราคาตามช่วงเวลาได้ เอกสารของ Oracle อธิบายว่า ระบบจะอ้างอิงราคาของ blanket purchase agreement ณ เวลาที่เบิกใช้ และถ้าสกุลเงินหรือหน่วยต่างกันจะแปลงค่า ณ เวลาที่เบิกใช้ และยังอธิบายว่า หากตั้งค่าไม่ครบ เช่น ไม่มี blanket agreement ที่มีผลอยู่ จะเบิกใช้ไม่ได้

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

ภาษีของไทยและ BOI: แยกจุดโอนใน ERP ออกจากเอกสารภาษี

ใบสรุปการชำระบัญชีของ ERP กับใบกำกับภาษีของไทย

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

มาตรา 78(1) แห่งประมวลรัษฎากรของไทย กำหนดให้ความรับผิดในการเสีย VAT จากการขายสินค้าเกิดขึ้นเมื่อส่งมอบสินค้าเป็นหลัก แต่ถ้ามีการโอนกรรมสิทธิ์ การได้รับชำระราคา หรือการออกใบกำกับภาษีก่อนหน้านั้น ให้ถือเวลานั้น ส่วนมาตรา 77/1(8) กำหนดให้ “ขาย” รวมถึงการส่งมอบสินค้าให้ตัวแทนเพื่อขาย เป็นต้น

หนังสือตอบข้อหารือของกรมสรรพากร (กค 0702/7981 ลงวันที่ 27 ตุลาคม 2014) ตอบว่า การที่ผู้ผลิตส่งมอบสินค้าให้ห้างสรรพสินค้าหรือร้านสะดวกซื้อเพื่อฝากขาย ถือเป็นการขาย ความรับผิดในการเสียภาษีเกิดขึ้น และมีหน้าที่ต้องออกใบกำกับภาษีตามมาตรา 86 อย่างไรก็ตาม นี่เป็นข้อหารือเกี่ยวกับการฝากขายในธุรกิจค้าปลีก ส่วนรูปแบบที่วางชิ้นส่วนซึ่งซัพพลายเออร์เป็นเจ้าของไว้ในโรงงานของผู้ซื้อ และผู้ซื้อนำไปใช้ในการผลิตของตัวเอง การค้นคว้าครั้งนี้ไม่พบหนังสือตอบข้อหารือทางการที่ระบุถึงรูปแบบนี้โดยตรง

มาตรา 86 กำหนดหน้าที่ของผู้ประกอบการจดทะเบียน VAT ให้ออกใบกำกับภาษีเมื่อความรับผิดในการเสียภาษีเกิดขึ้น และส่งมอบให้ผู้ซื้อ ในขณะที่ MRKO, Pay On Use และ ERS ที่ดูไปในบทก่อน เป็นกลไกการชำระบัญชีที่ฝ่ายผู้ซื้อเป็นผู้จัดทำ

บทความนี้แนะนำให้ออกแบบใบสรุปการชำระบัญชีของ ERP (หลักฐานการจ่ายเงิน) แยกจากใบกำกับภาษีของไทย (เอกสารภาษี) ส่วนเรื่องใครจะออกเอกสารใดเมื่อไร ขอให้สอบถามที่ปรึกษาภาษีก่อนตัดสินใจเรื่องสัญญาและการตั้งค่า ERP

ความสัมพันธ์กับสิทธิประโยชน์ BOI

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

กฎข้อ 3: กฎการเติมสต็อกและ min max

ใครกำหนด min max ในการเติมสต็อกแบบ VMI

พื้นฐานของการเติมสต็อกคือ min max บทความวิจัยของ Valentini & Zavanella ยกกฎอย่างง่ายของสต็อกฝากว่า ซัพพลายเออร์รับประกันสต็อกระหว่างขั้นต่ำ s ถึงขั้นสูง S ในคลังวัตถุดิบใกล้สายการผลิตของผู้ซื้อ โดยสินค้าเป้าหมายคือสินค้าที่มีการเบิกใช้คงที่ ไม่รวมสินค้าที่ไม่ใช่มาตรฐานและสินค้าต้นแบบ และประมาณ s เป็นสต็อกเผื่อ (safety stock) ที่ครอบคลุมการผลิตในช่วงเวลานำการจัดส่ง (supply lead time)

เอกสารของ SAP อธิบายว่า ใน SAP Business Network Supply Chain Collaboration ผู้ซื้อแบ่งปันความต้องการ การพยากรณ์ สต็อกปัจจุบัน และข้อกำหนด min max แล้วซัพพลายเออร์วางแผนและดำเนินการเติมสต็อกเทียบกับเป้าหมายสต็อก min max ได้ และยังอธิบายว่าซัพพลายเออร์คำนวณ min max แบบไดนามิกจากความต้องการรวมในช่วงวางแผนของผู้ซื้อ และสร้างคำสั่งขายเพื่อเติมสต็อกได้โดยไม่ต้องรอคำสั่งซื้อ SupplyOn อธิบายว่า ใน VMI จะให้ซัพพลายเออร์เห็นระดับสต็อกในคลังของผู้ซื้อ และรักษาไว้ในช่วงขั้นต่ำถึงขั้นสูงที่ตกลงกัน

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

การจัดการเมื่อเกินขั้นสูงและเมื่อของขาด

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

ความแตกต่างจากจุดสั่งซื้อของบริษัทเรา

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

จะให้ซัพพลายเออร์เห็นอะไร: การมองเห็นข้อมูลและพอร์ทัล

เฉพาะสต็อกปัจจุบัน หรือรวมสต็อกคาดการณ์ด้วย

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

ข้อมูลที่อาจให้เห็นมีดังนี้

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

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

ตัวอย่างพอร์ทัล

เอกสารของ Microsoft อธิบายว่า ใน vendor collaboration ของ Dynamics 365 ซัพพลายเออร์ตรวจสอบการเบิกใช้และสต็อกได้จาก 3 หน้า คือ ใบสั่งซื้อที่เบิกใช้สต็อกฝาก สินค้าที่รับจากสต็อกฝาก และสต็อกฝากคงเหลือ เอกสารของ Oracle อธิบายว่า ใน iSupplier Portal ซัพพลายเออร์สอบถามข้อมูลสต็อกฝาก ใบแจ้งการเบิกใช้ การรับเข้าและการคืนของฝาก เป็นต้น และเริ่มขั้นตอนการเรียกเก็บเงินได้ เอกสารของ Oracle Cloud อธิบายว่า Supplier Portal เวอร์ชัน Redwood มี 3 แท็บ คือ สต็อกฝาก รายการเคลื่อนไหว และใบแจ้งการเบิกใช้

การออกแบบพอร์ทัลสำหรับซัพพลายเออร์โดยรวมได้สรุปไว้ใน “บทความการนำพอร์ทัลซัพพลายเออร์มาใช้“

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

ระบบ VMI และสต็อกฝากของซัพพลายเออร์ | กฎการโอนกรรมสิทธิ์ การชำระเงิน และการเติมสต็อกสำหรับโรงงานในไทย - figure 2

กฎข้อ 3 (ต่อ): สต็อกค้างนาน ระยะเวลาฝากสูงสุด และการรับซื้อเมื่อครบกำหนด

ตกลงระยะเวลาฝากสูงสุดในสัญญา

เรื่องที่มักเกิดข้อขัดแย้งในสต็อกฝากคือสินค้าที่ไม่ถูกใช้ บทความวิจัยของ Valentini & Zavanella กล่าวว่า อาจตกลงกันได้ว่าเมื่อผ่านไประยะหนึ่ง ผู้ซื้อจะจ่ายเงินแม้ยังไม่ได้เบิกใช้ ในวิธีใช้ (help) ของ SAP AFS รุ่นเก่า (ผลิตภัณฑ์รุ่นเก่าสำหรับอุตสาหกรรมเครื่องนุ่งห่ม) ก็มีแนวคิดว่าสามารถตกลงกับซัพพลายเออร์เรื่องระยะเวลาที่จะโอนของฝากที่ไม่ได้ใช้เข้าเป็นสต็อกของบริษัทเรา

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

วิธีรองรับของแต่ละผลิตภัณฑ์

เอกสารของ Oracle E-Business Suite อธิบายว่า มีความสัมพันธ์ทางสัญญาที่ต้องซื้อสต็อกฝากที่ไม่ถูกเบิกใช้ภายในระยะเวลาที่กำหนด โดยกำหนด aging period ไว้ใน ASL แล้วแสดงสต็อกที่ครบกำหนดในหน้าสอบถามข้อมูลเพื่อโอนกรรมสิทธิ์ หน้าสอบถามนี้ค้นหาได้ตาม “ครบกำหนดแล้ว” “ภายใน 1 สัปดาห์” “ภายใน 15 วัน” และ “ภายใน 1 เดือน” เอกสารของ Oracle Cloud อธิบายว่า ในแท็บสต็อกฝากของ Supplier Portal สามารถเรียงตาม aging period เป็น “Expired” “Today and Next 7 Days” “Today and Next 30 Days” และ “All” ได้

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

ในทางกลับกัน จากเนื้อหาการเรียนรู้ของ S/4HANA และเอกสารเรื่องสต็อกฝากของ Dynamics 365 ที่อ้างอิงในครั้งนี้ ไม่พบฟังก์ชัน aging (ระยะเวลาฝากสูงสุด) ในกรณีเช่นนี้ จะต้องเสริมด้วยการปฏิบัติงาน คือทำรายงานแสดงจำนวนวันนับจากการเคลื่อนไหวครั้งล่าสุด และตรวจสอบรายการที่ครบกำหนดในการประชุมประจำเดือน

การจัดการรายการที่ครบกำหนด

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

การตรวจนับสต็อกและส่วนต่าง: ใครนับ และจัดการส่วนต่างอย่างไร

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

เอกสารของ Microsoft อธิบายว่า การตรวจนับสต็อกฝากทำผ่าน Item counting journal และถ้ามีสิทธิ์ ซัพพลายเออร์ก็สามารถอัปเดตสต็อกคงเหลือผ่านการตรวจนับได้ เอกสารข้อกำหนด INVRPT ของ Volvo Group แยกรหัสเหตุผลของการเคลื่อนไหวสต็อก เช่น รับเข้า จ่ายออก ทำลายทิ้ง ส่วนต่างจากการตรวจนับ การโอนกรรมสิทธิ์ภายในคลัง และการเบิกใช้

เรื่องที่ต้องตกลงไว้มีดังนี้

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

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

ข้อมูลสต็อกและการเบิกใช้ที่ส่งผ่าน EDI

การแลกเปลี่ยนข้อมูลกับซัพพลายเออร์ บางครั้งใช้ข้อความมาตรฐานของ EDI

มาตรฐานข้อความคำอธิบาย (ตามเอกสารขององค์กรหรือบริษัทแต่ละแห่ง)
ANSI X12852 Product Activity Dataแจ้งความเคลื่อนไหวของสินค้า เช่น สต็อกและยอดขาย ให้คู่ค้า และใช้เสนอจำนวนเติมสต็อกได้
ANSI X12846 Inventory Inquiry/Adviceใช้ให้ข้อมูลสต็อกหรือสอบถามสต็อกที่พร้อมใช้
ANSI X12847 Material Claimแจ้งต้นทุนของวัสดุที่ถูกระบุว่าเสียหาย ใช้ไม่ได้ หรือล้าสมัย
UN/EDIFACTINVRPTส่งข้อมูลเกี่ยวกับสต็อกที่ถืออยู่ ใช้ได้ทั้งสองทิศทางระหว่างคู่ค้า
UN/EDIFACTINVOICใบแจ้งหนี้ Odette เผยแพร่แนวทางของข้อความใบแจ้งหนี้สำหรับอุตสาหกรรมยานยนต์

เว็บไซต์ทางการของ X12 อธิบายว่า ข้อมูลความเคลื่อนไหวของสินค้าที่ได้รับผ่าน 852 ช่วยให้คู่ค้าเสนอจำนวนเติมสต็อกได้

ตัวอย่างการใช้งานจริงในอุตสาหกรรมยานยนต์ เอกสารข้อกำหนด INVRPT ของ Volvo Group (7 มิถุนายน 2021) แยกสต็อกของบริษัทกับสต็อกฝากด้วย ID ของสถานที่จัดเก็บ และแยกแต่ละส่วนเป็นพร้อมใช้ ระหว่างตรวจคุณภาพ และอยู่ในเขตปลอดอากร (bonded) รหัสเหตุผลของการเคลื่อนไหวมีทั้งการเบิกใช้ การโอนกรรมสิทธิ์ภายในคลัง และส่วนต่างจากการตรวจนับ เป็นต้น หมายความว่ามีการใช้งานจริงที่แยกบนข้อความว่าเป็นของฝากหรือของบริษัท สถานะคุณภาพ การเบิกใช้ และการโอนกรรมสิทธิ์

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

ฟังก์ชันที่ยืนยันได้จากเอกสารของผลิตภัณฑ์และ ERP

ส่วนนี้แสดงขอบเขตที่ยืนยันได้จากเอกสารสาธารณะของแต่ละบริษัท ไม่ได้แสดงว่าผลิตภัณฑ์ใดดีกว่ากัน และคำว่า “ไม่พบในเอกสารที่อ้างอิง” ไม่ได้หมายความว่าไม่มีฟังก์ชันนั้น แต่หมายความว่าเอกสารที่อ้างอิงในครั้งนี้ไม่มีคำอธิบายเรื่องนั้น

ผลิตภัณฑ์การโอนกรรมสิทธิ์การชำระบัญชีการเติมสต็อกและการมองเห็นข้อมูลสต็อกค้างนาน (aging)
SAP S/4HANAอธิบายว่าหนี้เกิดขึ้นเมื่อจ่ายออกเพื่อเบิกใช้จาก special stock K หรือเมื่อโอนเข้าสต็อกของบริษัทด้วย 411 ร่วมกับ special stock indicator Kอธิบายว่าใช้ MRKO ชำระบัญชีโดยไม่ต้องรับใบแจ้งหนี้ และแจ้งซัพพลายเออร์ด้วย KONSอธิบายว่าสำหรับสินค้าที่จัดหาแบบฝากเสมอ MRP จะสร้างใบขอซื้อแบบฝาก ส่วนการมองเห็นข้อมูลสำหรับซัพพลายเออร์ไม่พบในเอกสารที่อ้างอิงไม่พบในเอกสารที่อ้างอิง (วิธีใช้ของ AFS รุ่นเก่ามีแนวคิดเรื่องการตกลงระยะเวลา)
SAP Business Network SCCอธิบายว่าในกรณีสต็อกฝากจะส่งสัญญาณการเบิกใช้เมื่อจ่ายออกและเมื่อโอนกรรมสิทธิ์อธิบายว่าผู้ซื้อทำ self-billing ด้วย ERS และส่งผ่านเครือข่ายได้อธิบายเป้าหมายสต็อก min max สต็อกปัจจุบันและสต็อกคาดการณ์ และการแจ้งเตือนไม่พบในเอกสารที่อ้างอิง
Oracle EBS 12.2 และ Cloudอธิบายว่ามีรายการที่ถือเป็นการเบิกใช้เสมอ และรายการที่ตั้งค่าด้วยกฎอธิบาย Consumption Advice และ Pay On Useอธิบายว่าสอบถามสต็อกฝากและใบแจ้งการเบิกใช้ได้ใน iSupplier Portal และ Supplier Portalอธิบาย aging period ใน ASL และหน้าสอบถาม รวมถึงการแสดง Expired, 7 วัน และ 30 วัน ใน Cloud
Microsoft Dynamics 365โอนด้วยสมุดรายวันเปลี่ยนกรรมสิทธิ์ ระบุชัดว่าไม่รองรับการประมวลผลอัตโนมัติอธิบายว่าซัพพลายเออร์ดูการเบิกใช้แล้วเรียกเก็บเงิน และผู้ซื้อตรวจทานกับใบสั่งซื้ออธิบาย consignment replenishment order และ 3 หน้าของ vendor collaborationไม่พบในเอกสารที่อ้างอิง
Infor LNอธิบายว่าตั้งค่าแบบอิงการเบิกใช้ แบบอิงเวลา และการจัดการการย้ายระหว่างคลังได้อธิบายว่าขั้นตอนการจ่ายเงินเริ่มจากบันทึกการเบิกใช้ และโดยทั่วไปเป็น self-billing เช่น เดือนละครั้งอธิบายการแบ่งบทบาทใน VMI รวมถึงแบบที่ซัพพลายเออร์รับผิดชอบการวางแผนอุปทานอธิบายการโอนแบบอิงเวลานับจากรายการครั้งล่าสุด
Odoo 17อธิบายขั้นตอนระบุ Owner ตอนรับเข้าแล้วจัดเก็บ (เป็นคำอธิบายขั้นตอนการขาย)ไม่พบในหน้าที่อ้างอิงไม่พบในหน้าที่อ้างอิงไม่พบในหน้าที่อ้างอิง

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

สิ่งที่ตารางนี้บอกคือ การเลือกว่ากฎข้อ 1 ถึง 3 ข้อใดจะใช้ฟังก์ชันของระบบ และข้อใดจะเสริมด้วยรายงานและการปฏิบัติงาน จะต่างกันไปตามผลิตภัณฑ์ บทความนี้จึงมองว่าลำดับที่สำคัญคือ ตกลงกฎในสัญญาก่อน แล้วจึงตรวจสอบใน RFP

ข้อกำหนดใน RFP เกณฑ์ PoC และการทดสอบรับมอบ ค่าใช้จ่าย และการประมาณการตัวอย่าง

ข้อกำหนดที่ควรเขียนใน RFP

สรุปเนื้อหาที่ผ่านมาเป็นตารางข้อกำหนดของ RFP

หมวดข้อกำหนดสิ่งที่ต้องตรวจสอบ
กรรมสิทธิ์ทริกเกอร์การโอนถือการจ่ายออกเพื่อเบิกใช้ การโอนเข้าสต็อกของบริษัท เวลาที่ผ่านไป หรือการย้ายระหว่างคลัง ข้อใดเป็นการเบิกใช้ได้บ้าง
กรรมสิทธิ์การออกเอกสารโอนและระบบอัตโนมัติโอนอัตโนมัติหรือไม่ ใครเป็นผู้สร้างสมุดรายวัน
กรรมสิทธิ์วิธีจัดการเมื่อยกเลิกเมื่อแก้กลับการเบิกจ่ายที่ผิด จะสะท้อนไปยังการชำระบัญชีอย่างไร
การแยกประเภทสต็อกวิธีแยกสต็อกฝากแยกตามซัพพลายเออร์ได้หรือไม่ การวางปะปนใน location เดียวกันและลำดับการเบิกจ่าย
การแยกประเภทสต็อกสถานะคุณภาพแยกพร้อมใช้ ระหว่างตรวจคุณภาพ และระงับ และจำกัดการเบิกใช้ไว้เฉพาะสต็อกพร้อมใช้ได้หรือไม่
ราคาแหล่งอ้างอิงราคาต่อหน่วยสำหรับการชำระบัญชีช่วงเวลามีผล การแปลงสกุลเงิน และการจัดการการเบิกใช้ที่คร่อมวันปรับราคา
การชำระบัญชีรอบการชำระบัญชีและการปิดยอดเลือกรายวัน รายสัปดาห์ หรือรายเดือนได้หรือไม่
การชำระบัญชีรูปแบบเอกสารการชำระบัญชีจัดทำใบแจ้งการเบิกใช้ การออกเอกสารเรียกเก็บเงินแทนโดยผู้ซื้อ (self-billing) หรือใบแจ้งหนี้จากซัพพลายเออร์ แบบใดได้บ้าง
การชำระบัญชีเอกสารภาษีของไทยปฏิบัติงานเรื่องผู้ออกและเวลาออกใบกำกับภาษีให้สอดคล้องกับผลการตรวจสอบของที่ปรึกษาภาษีได้หรือไม่
การเติมสต็อกmin max และผู้ออกเอกสารหน่วยในการตั้งค่า ความถี่ในการทบทวน และใครเป็นผู้ออกเอกสารเติมสต็อก
การเติมสต็อกการมองเห็นข้อมูลและการแจ้งเตือนให้เห็นเฉพาะสต็อกปัจจุบันหรือรวมสต็อกคาดการณ์ ความถี่ในการอัปเดต และการแจ้งเตือนเมื่อต่ำกว่า min
สต็อกค้างนานระยะเวลาฝากสูงสุดดึงรายการที่ครบกำหนดออกมาได้หรือไม่ ถ้าไม่มีฟังก์ชันนี้จะออกเป็นรายงานได้หรือไม่
การตรวจนับสต็อกผู้ตรวจนับและส่วนต่างสิทธิ์ตรวจนับของซัพพลายเออร์ และการบันทึกเหตุผลของส่วนต่าง
การแบ่งปันข้อมูลEDI และพอร์ทัลการรองรับ 852, 846, INVRPT, INVOIC เป็นต้น และหน้าจอพอร์ทัล
การวินิจฉัยข้อผิดพลาดของการเบิกใช้และการชำระบัญชีตรวจพบและแจ้งเตือนได้หรือไม่ เมื่อการเบิกใช้หรือการชำระบัญชีหยุดชะงัก เช่น เพราะยังไม่ได้ตั้งราคา

เอกสารของ Oracle อธิบายว่า Consigned Inventory Diagnostics ตรวจพบข้อผิดพลาดของการเบิกใช้หรือของใบแจ้งการเบิกใช้ และแจ้งผู้จัดซื้อได้ ข้อกำหนดด้านการวินิจฉัยมักถูกมองข้าม จึงควรใส่ไว้ในตาราง

เกณฑ์ PoC และการทดสอบรับมอบ

ในการทดสอบรับมอบ ขอแนะนำการทดสอบที่เป็นรูปธรรมดังนี้

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

การทำ PoC ที่เป็นไปได้ในทางปฏิบัติคือ เริ่มจากซัพพลายเออร์หลัก 1 รายกับสินค้าไม่กี่รายการที่มีการเบิกใช้คงที่ ซึ่งสอดคล้องกับแนวคิดที่บทความวิจัยของ Valentini & Zavanella ยกไว้ว่าให้ใช้สินค้าที่มีการเบิกใช้คงที่เป็นเป้าหมาย

แนวคิดเรื่องค่าใช้จ่าย

เรื่องค่าใช้จ่าย ไม่พบราคาที่เปิดเผยต่อสาธารณะ หน้าผลิตภัณฑ์ VMI ของ SupplyOn ต้องเข้าสู่ระบบก่อนจึงจะเห็นราคา และเอกสารฟังก์ชันสต็อกฝากของ SAP, Oracle, Microsoft และ Infor ก็ไม่มีการระบุราคา ค่าใช้จ่ายเปลี่ยนไปตามโครงสร้างไลเซนส์ จำนวนผู้ใช้ จำนวนซัพพลายเออร์ที่เชื่อมต่อ และการเชื่อมต่อ EDI จึงต้องเปรียบเทียบจากใบเสนอราคา

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

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

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

ความสูญเสียปัจจุบัน (ค่าฐาน ต่อปี) มี 3 รายการต่อไปนี้ ทั้ง 3 รายการเป็นความสูญเสียคนละเรื่องกัน ไม่ได้นับเรื่องเดียวกันซ้ำ 2 ครั้ง

รายการความสูญเสียการคำนวณจำนวนเงิน (THB/ปี)
ชั่วโมงงานกระทบยอดการเบิกใช้และปรับส่วนต่างตอนสิ้นเดือนปีละ 1,200 ชั่วโมง × 250 THB300,000
การรับมือฉุกเฉินจากของฝากขาด (ขนส่งด่วน เปลี่ยนการตั้งเครื่อง)ปีละ 12 ครั้ง × 25,000 THB300,000
ความสูญเสียจากการรับซื้อของฝากที่ไม่มีแนวโน้มจะใช้แล้วหลังครบกำหนด แล้วนำไปจำหน่ายทิ้งค่าสมมติ180,000
รวม780,000

มาตรการคือ การจัดระเบียบสัญญาเรื่องจุดโอนกรรมสิทธิ์และรอบการชำระบัญชี การแยกประเภทสต็อกฝากใน ERP และการโอนอัตโนมัติเมื่อเบิกใช้หรือการปฏิบัติงานด้วยสมุดรายวัน การให้ซัพพลายเออร์มองเห็นสต็อกและการแจ้งเตือนเมื่อต่ำกว่า min และรายงานการจัดการวันครบกำหนด

รายละเอียดค่าใช้จ่ายเริ่มต้นจำนวนเงิน (THB)
การตั้งค่าและการแยกประเภทสต็อกฝากใน ERP300,000
การมองเห็นข้อมูลสำหรับซัพพลายเออร์ (พอร์ทัลหรือ EDI)350,000
การจัดระเบียบสัญญา ขั้นตอนการชำระบัญชี และขั้นตอนเอกสารภาษี (รวมการตรวจสอบโดยที่ปรึกษาภาษี)110,000
การฝึกอบรม การตรวจนับสต็อก และการทดสอบรับมอบ200,000
รวม960,000

ค่าดำเนินการรายปีสมมติไว้ที่ 120,000 THB

ถ้าสมมติว่าลดความสูญเสียข้างต้นได้ครึ่งหนึ่ง (50%) ผลลัพธ์จะเป็น 780,000 × 50% = 390,000 THB/ปี ผลลัพธ์สุทธิคือ 390,000 − 120,000 = 270,000 THB/ปี และระยะเวลาคืนทุนคือ 960,000 ÷ 270,000 = ประมาณ 3.6 ปี

มาดูกรณีที่ผลลัพธ์อยู่ที่เพียงหนึ่งในสี่ (25%) ด้วย ผลลัพธ์คือ 780,000 × 25% = 195,000 THB/ปี ผลลัพธ์สุทธิคือ 195,000 − 120,000 = 75,000 THB/ปี ระยะเวลาคืนทุนคือ 960,000 ÷ 75,000 = 12.8 ปี

กรณีผลลัพธ์ (THB/ปี)ผลลัพธ์สุทธิ (THB/ปี)ระยะเวลาคืนทุน
กรณีฐาน (50%)390,000270,000ประมาณ 3.6 ปี
การวิเคราะห์ความอ่อนไหว (25%)195,00075,00012.8 ปี
ระบบ VMI และสต็อกฝากของซัพพลายเออร์ | กฎการโอนกรรมสิทธิ์ การชำระเงิน และการเติมสต็อกสำหรับโรงงานในไทย - figure 3

วิธีอ่านการประมาณการ

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

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

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

คำถามที่พบบ่อยและสรุป

สต็อกฝากกับ VMI ต่างกันอย่างไร

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

กรรมสิทธิ์ในสต็อกฝากโอนเมื่อไร

ตกลงในสัญญา เอกสารของ Infor อธิบายว่า ในหลายกรณีกรรมสิทธิ์จะโอนเมื่อเบิกใช้ แต่ก็มีจุดโอนแบบอื่นที่กำหนดในสัญญาได้ ตัวเลือกคือ การจ่ายออกเพื่อเบิกใช้ การโอนเข้าสต็อกของบริษัทเรา เวลาที่ผ่านไป และการย้ายระหว่างคลัง ERP แต่ละตัวรองรับต่างกัน และบางผลิตภัณฑ์ เช่น Dynamics 365 ระบุชัดว่าไม่รองรับการประมวลผลสมุดรายวันกรรมสิทธิ์แบบอัตโนมัติ

ใครออกใบกำกับภาษีของสต็อกฝาก และออกเมื่อไร

บทความนี้จะไม่เขียนข้อสรุป มาตรา 78(1) แห่งประมวลรัษฎากรของไทยกำหนดให้ถือเวลาส่งมอบเป็นหลัก และกรมสรรพากรมีหนังสือตอบข้อหารือที่ถือว่าการฝากขายในธุรกิจค้าปลีกเป็นการขาย ส่วนสต็อกฝากในรูปแบบที่นำไปใช้ในโรงงาน ครั้งนี้ไม่พบหนังสือตอบข้อหารือทางการที่ระบุถึงโดยตรง ขอให้ออกแบบใบสรุปการชำระบัญชีของ ERP แยกจากใบกำกับภาษี และสอบถามที่ปรึกษาภาษีก่อนทำสัญญา

ใครกำหนด min max ของ VMI

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

ของฝากที่ไม่ถูกใช้จะเป็นอย่างไร

ตกลงในสัญญาเรื่องระยะเวลาฝากสูงสุด และวิธีจัดการเมื่อครบกำหนด (รับซื้อ คืน หรือขยายเวลา) เอกสารของ Oracle อธิบาย aging period และหน้าสอบถามสต็อกที่ครบกำหนด ส่วนเอกสารของ Infor อธิบายการโอนแบบอิงเวลานับจากรายการครั้งล่าสุด สำหรับผลิตภัณฑ์ที่ไม่พบฟังก์ชันนี้ในเอกสารที่อ้างอิง ให้เสริมด้วยรายงานและการตรวจสอบรายเดือน

VMI ช่วยลดต้นทุนสต็อกได้หรือไม่

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

ระบบ VMI และสต็อกฝากมีค่าใช้จ่ายเท่าไร

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

สรุป

  • VMI เป็นเรื่องการบริหารการเติมสต็อก สต็อกฝากเป็นเรื่องกรรมสิทธิ์ ทั้งสองเป็นคนละแกน และมักใช้ร่วมกัน
  • สิ่งที่ต้องตัดสินใจก่อนคือกฎ 3 ข้อ ได้แก่ ข้อ 1 จุดโอนกรรมสิทธิ์และการรับภาระความเสี่ยง ข้อ 2 ขั้นตอนการบันทึกการเบิกใช้และการชำระบัญชี ข้อ 3 กฎการเติมสต็อกและสต็อกค้างนาน พร้อมกันนั้นให้ตัดสินใจเรื่องข้อมูลหลักราคา การแยกประเภทสต็อก และการแบ่งความรับผิดชอบในการตรวจนับสต็อก
  • ความลึกของฟังก์ชันต่างกันไปในแต่ละ ERP ให้ตกลงในสัญญาก่อน แล้วเลือกว่าจะใช้ฟังก์ชันของระบบ หรือเสริมด้วยรายงานและการปฏิบัติงาน
  • ออกแบบใบสรุปการชำระบัญชีของ ERP แยกจากใบกำกับภาษีของไทย สอบถามที่ปรึกษาภาษีก่อนทำสัญญา และสอบถาม BOI เรื่องความสัมพันธ์กับสิทธิประโยชน์ BOI
  • ในการประมาณการ (ตัวเลขสมมติ) ถ้าลดความสูญเสียได้ 50% จะคืนทุนในประมาณ 3.6 ปี ถ้าได้เพียง 25% จะใช้ 12.8 ปี สิ่งที่มักมีผลต่อผลลัพธ์คือการจัดระเบียบสัญญาว่าอะไรถือเป็นการเบิกใช้และจะชำระบัญชีเมื่อไร
  • ก่อนนำระบบมาใช้ ถ้าเริ่มจากนำบันทึกการเบิกจ่ายย้อนหลัง 6-12 เดือนมาวางเทียบกับใบแจ้งหนี้ของซัพพลายเออร์แล้วนับ จะทำให้ข้อกำหนดและผลลัพธ์ที่คาดไว้ชัดเจนขึ้น

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

แหล่งอ้างอิง