FIFO inventory in detail

“ต้นทุนเป็นมายา” คำสรุปที่ผมบอกกับทีมพัฒนา ตอนนั้นก็นึกอยู่ในใจว่า เรากำลังแถอยู่หรือเปล่า?

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

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

ต้นทุนมาตรฐาน เพิ่งเจอรายเดียวเพราะใช้มาแต่เดิม

ต้นทุนล่าสุด นี่ไม่ค่อยเจอใครใช้ 

ที่นิยมกันมากคือ เฉลี่ย กับ FIFO 

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

ไม่ต้องกล่าวถึงพวกที่มีพันไปถึงหมื่น SKUs ถ้าถึงระดับนี้ใช้รายงานต้นทุนออกแต่ละรายการมาตรวจไม่ได้แล้ว

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

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

บนจอ หรือ บนกระดาษ

ที่จริงโปรแกรมสามารถทำรายงานได้อยู่แล้ว ไม่ยากเลย เพียงแต่ไม่ได้เป็นรายงานเอาไว้พิมพ์อีกแล้ว 

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

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

พฤติกรรมผู้ใช้จะเริ่มเปลี่ยนจากพิมพ์รายงานไปเป็น capture จอ ยิ่งโปรแกรมสามารถแชร์ link อะไรที่ยาวหลายหน้าก็ให้เข้ามาดูในโปรแกรมเอง ไม่จำเป็นต้องเสียเวลาพิมพ์ออกกระดาษ

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

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

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

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

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

วิธีคำนวณต้นทุน FIFO

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

1. รายงานพิสูจน์จำนวนคงเหลือ เหมือน Stock card ที่เอาไว้ตรวจ transaction ว่าครบถ้วนถูกต้อง

2. รายงานพิสูจน์ต้นทุน แสดงเฉพาะ lot เข้าสต็อคทั้งหมด​ (รวมยกมา)​ พร้อมต้นทุนสินค้า

   
   

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

ต้นทุนสินค้าที่ขายหรือออกไปทั้งหมด จึงคิดย้อนกลับด้วยสมการ มูลค่าเข้าทั้งหมด(รวมยกมา)​ ลบด้วย มูลค่าคงเหลือปลายงวด 

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

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

รายงานพิสูจน์ต้นทุน FIFO

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

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

• เราไม่สามารถเอารายการเข้า-ออกมาเรียงตามวันที่ เหมือน Stock card ปกติ หากมี lot เข้า วันที่ 1, 3, 5 แล้วมีรายการที่ออกวันที่ 4, 5, 6 แล้วรายการออกเหล่านั้นไปตัดยอดของ lot วันไหน (ใช้ต้นทุน lot ไหน)​ ทำอย่างไรจึงจะดูรู้เรื่อง 

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

FIFO transaction model

เรื่องนี้ต้องให้เครดิตทีมออกแบบของเรา ข้ามพ้นข้อจำกัดของตาราง 2 มิติมาได้ โดยนำเสนอโมเดล “ตารางซ้อนตาราง” 

• ตารางชั้นนอกเรียงตามวันที่ เป็นการนำเสนอว่า เกิดอะไรขึ้นในวันนั้น มี lot เข้ากี่ lot และโดนตัดสต็อคออกกี่ lot 

• ตารางที่ซ้อนอยู่ภายใน แสดงรายละเอียดเข้าและออกที่สมบูรณ์ในตัวเอง

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

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

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

หลังจากพยายามคิดออกแบบรายงานนี้กว่า 10 ปี สำหรับผม model นี้เป็นท่าจบที่เล่าเรื่อง Inventory movement ได้หมดจด เป็นหนึ่งมายาที่งดงาม แต่พึงระลึกว่า Inventory ในภาคปฏิบัติอาจไม่ได้ดูดีเช่นนั้น