Multi Branch Inventory

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

สมัยที่ยังไม่มี Cloud ERP โปรแกรมส่วนใหญ่ไม่จำเป็นต้องออกแบบให้ใช้งานข้ามสาขา เพราะความเป็นสาขามักถูกแยกทางกายภาพอยู่แล้ว 

ระบบงานภายในก็ถูกแยกออกจากกันโดยปริยาย ทั้งพนักงานและซอฟต์แวร์ที่ใช้ อย่างดีก็มี computer server ทำงานร่วมกันเป็น multi user ภายในสาขาเดียวกัน แต่ละสาขาจึงติดตั้งโปรแกรมของใครของมัน แยกเก็บข้อมูล ดูแลกันเอง และนำส่งข้อมูลในรูปแบบรายงานสรุปรวมยอดมาแล้ว 

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

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

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

ภาพที่เราเห็นชัดที่สุดคือ การแตกหน่วยงานคลังสินค้าและจัดส่ง (Warehouse & Logistic) ออกไป ทำเลที่ดีสำหรับคลังสินค้า อาจไม่ใช่ทำเลที่ดีสำหรับการตลาด, การเงินหรืองานออฟฟิศก็ได้

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

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

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

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

ความยากลำบากอย่างหนึ่งอยู่ที่ นิยามของ "สาขา" ของแต่ละองค์กรรวมไปถึงคนทำงานแต่ละฝ่ายอาจไม่เหมือนกัน

สาขาภาษีมูลค่าเพิ่ม

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

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

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

สาขาบัญชีภาษี

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

ตัวเลขที่สำคัญมีอยู่สามตัว คือ มูลค่าที่ขายออกไป, มูลค่าที่ซื้อเข้ามาเพิ่ม และมูลค่าคงค้างที่เหลืออยู่

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

กิจการที่มีสาขา รายงานสินค้าเข้า-ออก หรือสรุปยอดคงเหลือสำหรับบัญชี จึงไม่เหมือนรายงานสำหรับภาษีมูลค่าเพิ่ม แต่เป็นรายงานที่เอา transaction มารวมกันไม่ต้องแยกสาขา การคำนวณมูลค่าสต็อคคงเหลือ ขึ้นอยู่กับนโยบายบัญชีที่ประกาศไว้ อาจเป็น FIFO, เฉลี่ย หรืออื่นๆ ตรงนี้โปรแกรม ERP อาจต้องลงทุนทำการบ้านว่า จะออกแบบให้โปรแกรมรองรับการคำนวณต้นทุนแบบไหนได้บ้าง

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

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

ต้นทุนขาย เท่ากับ มูลค่ายกมาต้นงวด บวก ซื้อระหว่างงวด ลบ คงเหลือปลายงวด

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

สาขาบริหาร

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

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

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

เพราะใช้ Cloud ERP ในการทำงานจริงฝ่ายต่างๆ นอกเหนือจากสโตร์ ยังคงอยู่ออฟฟิศสำนักงานใหญ่ ไม่ได้ย้ายไปประจำสาขา 

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

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

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

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

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

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

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

คลังย่อย

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

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

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

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

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

บริษัทย่อย

ตัวอย่างสุดท้ายที่จะเล่า เป็นกรณีของโครงสร้างองค์กรแบบพิเศษ การทำงานภายในใช้แค่ทีมเดียว เสมือนบริษัทเดียว แต่ทางนิตินัยจำเป็นต้องจดทะเบียนแยกบริษัท เพราะต้องกระจายถือ license ตัวแทนสินค้า brand ต่างๆ

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

รูปแบบการทำงานจึงเป็นบริษัทเดียวทางพฤตินัย แต่เป็นบริษัทย่อยทางนิตินัย

ใน ERP สาขา จึงถูกใช้เป็น บริษัทย่อย แทน

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

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

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

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

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

การตัด lot FIFO ที่ใช้สาขาเป็นบริษัทย่อย จึงไม่เหมือนกับ การตัด lot รวมสาขาของบริษัทเดียว ดังที่เรียกว่า "The devil is in the details"