ระบบจัดการคืนสินค้าให้ซัพพลายเออร์สำหรับโรงงาน: เชื่อมจัดซื้อ สต็อก และบัญชี

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

การคืนสินค้าให้ผู้ขาย (RTV) ครอบคลุมอะไร

Return to Vendor หรือ RTV คือกระบวนการฝั่งจัดซื้อที่โรงงานส่งสินค้าที่ซื้อและรับแล้วกลับไปยังผู้ขาย ต่างจากลูกค้าส่งสินค้าสำเร็จรูปกลับโรงงาน ทั้งทิศทางของสินค้า เอกสาร และคู่บัญชี หากต้องจัดการสินค้าคืนจากลูกค้า โปรดอ่านเรื่อง การจัดการ RMA ของลูกค้า ประเด็นหลักของ RTV คือระบุให้ได้ว่าเป็นสินค้าจริงชิ้นใดจากผู้ขายรายใด ใบสั่งซื้อบรรทัดใด ใบรับใด จำนวนเท่าไร และคืนเพราะอะไร

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

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

ต้องกระทบยอดพร้อมกันสามด้าน

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

สถานะเดียวว่า “คืนแล้ว” อธิบายกรณี “ส่งแล้วแต่รอเครดิต” หรือ “รับของเปลี่ยนแล้วแต่ไม่มีหลักฐานส่งของเดิม” ไม่ได้ ควรแยกความคืบหน้าหน้างานกับการเงิน และปิดเคสเมื่อทั้งสองด้านกระทบยอดกัน

ขั้นตอนการคืนสินค้าให้ซัพพลายเออร์ 7 ขั้น

1. หา PO ใบรับ และล็อตต้นทาง

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

2. กักกันคุณภาพก่อนถูกนำไปใช้

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

3. อนุมัติการคืนและวิธีชดเชย

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

4. สร้าง PO คืนและคำสั่งส่ง

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

5. ตรวจสินค้าจริงและยืนยันการส่งคืน

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

6. ตกลงว่าจะเปลี่ยนสินค้าหรือออกเครดิต

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

7. กระทบยอดสต็อกและเจ้าหนี้ก่อนปิดเคส

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

สถานะสต็อกสี่แบบที่ไม่ควรปะปน

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

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

ข้อมูลสำหรับ PO คืนและการเชื่อม ERP

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

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

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

ใบลดหนี้และ VAT ไทยต้องพิจารณาตามเงื่อนไข

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

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

คำถาม RFP สำหรับระบบคืนสินค้าให้ซัพพลายเออร์

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

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

สถานการณ์ทดสอบ FAT และ SAT

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

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

เลือกวิธีจัดการก่อนตัดสินใจส่งคืน

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

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

ออกแบบข้อยกเว้นก่อนปล่อยให้แก้ยอดด้วยมือ

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

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

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

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

กำหนดผู้รับผิดชอบและวิธีทำงานก่อนออกแบบหน้าจอ

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

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

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

ใช้กรณีมูลค่าทดสอบการชดเชยซ้ำ

FAT ควรลองเงินด้วย ตัวเลขต่อไปนี้สมมติ: ราคาชิ้นละ 100 บาท รับ 100 ชิ้น คืน 8 มูลค่าคืนก่อนภาษีคือ 800 บาท หากตกลงเปลี่ยน 4 และเครดิต 4 มูลค่าที่แทนด้วยของเปลี่ยน 400 บาท และส่วนเครดิต 400 บาท หากลงเครดิตเต็ม 800 บาทแล้วยังรับของเปลี่ยน 4 ชิ้น จะได้เกินข้อตกลง ระบบควรเทียบผลรวมจำนวนและมูลค่าแต่ละวิธีกับเคสและเตือนส่วนเกิน ค่าขนส่งและภาษีต้องพิจารณาตามสัญญา/กฎ ไม่บวกอัตโนมัติในตัวอย่างง่ายนี้

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

ตรวจการย้ายข้อมูลและวันเริ่มใช้ระบบ

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

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

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

เริ่มเล็กและติดตาม KPI ที่ใช้ได้จริง

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

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

คำถามพบบ่อย: คืนสินค้าให้ผู้ขายและ ERP

RTV เหมือนการแก้ความคลาดเคลื่อนตอนรับเข้าหรือไม่

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

ระบบระบุล็อตต้นทางอัตโนมัติได้ทุกครั้งหรือไม่

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

สร้าง PO คืนแล้วสต็อกและเจ้าหนี้ตรงกันทันทีหรือไม่

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

กรณีเปลี่ยนสินค้าและเครดิตอยู่ในเคสเดียวได้หรือไม่

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

ฝั่งผู้ซื้อกดคืนแล้วออกใบลดหนี้ VAT ไทยอัตโนมัติหรือไม่

อย่าสมมติ มาตรา 86/10 กล่าวถึงผู้ขายจด VAT ออกเมื่อเข้าเงื่อนไข ฝั่งผู้ซื้อเทียบเอกสารผู้ขายกับใบกำกับเดิมและตรวจวิธีภาษีกับผู้เชี่ยวชาญ ระบบควรติดตามความจำเป็น การรับ และส่วนต่างของเอกสาร

ควรเริ่ม RFP, FAT และ SAT อย่างไร

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

สรุป

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

หากกำลังทบทวนงานคืนสินค้าของโรงงานในไทย เราช่วยวางภาพการเชื่อมระหว่างจัดซื้อ รับเข้า คลัง และบัญชีได้ตั้งแต่ขั้นประเมิน ติดต่อ TOMAS TECH

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

• Microsoft Learn: Create a purchase return order
• Microsoft Learn: Create purchase orders
• Oracle Fusion Cloud SCM: Using Receiving 26A
• SAP Help: Document Flow in Supplier Returns
• SAP Help: Credit Memo
• SAP Business Network: Order Collaboration Returns for Suppliers
• Thailand Revenue Department: Revenue Code, Sections 85–86

*บทความนี้ใช้ประกอบการออกแบบระบบ พฤติกรรมมาตรฐานขึ้นกับรุ่นและการตั้งค่า ส่วนภาษีต้องตรวจข้อเท็จจริงของธุรกรรมและกฎปัจจุบัน*