กลุ่มบริษัทที่มีทั้งบริษัทการค้า โรงงานผลิต และบริษัทให้บริการอยู่ภายใต้ร่มเดียวกัน มักเริ่มต้นด้วยการแยกฐานข้อมูล Odoo คนละชุดต่อหนึ่งนิติบุคคล วิธีนี้ใช้ได้ดีจนกว่าจะมีคนขอให้ทำงบดุลรวมในเช้าวันจันทร์ ฟีเจอร์ Odoo multi-company ช่วยให้บริหารหลายนิติบุคคลในฐานข้อมูลเดียว โดยแต่ละบริษัทมีบัญชีของตัวเอง เลขที่เอกสารของตัวเอง และมีกฎที่กำหนดได้ชัดเจนว่าแต่ละนิติบุคคลจะเห็นข้อมูลของกันและกันได้แค่ไหน เราวางระบบลักษณะนี้อย่างสม่ำเสมอให้กับกลุ่มบริษัทที่มีนิติบุคคลกระจายอยู่ในไทย สหรัฐฯ และอินเดีย และการตัดสินใจเรื่องการคอนฟิกในสัปดาห์แรกมักส่งผลต่อเนื่องไปอีกหลายปีหลังขึ้นระบบ
นี่ไม่ใช่ฟีเจอร์ที่เปิดใช้แล้วปล่อยทิ้งไว้ได้ เพราะมันเปลี่ยนวิธีทำงานของสิทธิ์การเข้าถึง รอบบัญชี และแม้แต่ข้อมูลหลักของสินค้า ด้านล่างนี้คือแนวทางที่เราใช้ สิ่งที่เราตรวจสอบก่อนขึ้นระบบจริง และจุดที่ต้องชั่งน้ำหนักข้อดีข้อเสีย
Odoo multi-company ควบคุมอะไรบ้าง
ทุกเรคคอร์ดใน Odoo ตั้งแต่ใบสั่งขายไปจนถึงรายการบันทึกบัญชี จะมีฟิลด์บริษัทติดอยู่เสมอ โหมด multi-company เพิ่มชั้นของกฎขึ้นมาเหนือสิทธิ์การเข้าถึงมาตรฐาน ผู้ใช้ที่ถูกกำหนดให้สังกัดบริษัทหนึ่งจะเห็นเฉพาะเรคคอร์ดของบริษัทนั้น เว้นแต่จะอนุญาตให้เห็นมากกว่านั้นอย่างชัดเจน เรื่องนี้แยกจากสิทธิ์การทำงานของผู้ใช้ (ทำอะไรได้บ้าง) และควบคุมเฉพาะว่าผู้ใช้จะมองเห็นอะไรได้บ้าง
องค์ประกอบหลักในทางปฏิบัติมีดังนี้
- บริษัท (Companies): แต่ละนิติบุคคล พร้อมที่อยู่ เลขประจำตัวผู้เสียภาษี การปรับใช้ตามกฎหมายท้องถิ่น (fiscal localization) และสกุลเงินของตัวเอง
- สาขาหรือโครงสร้างลำดับชั้นหลายบริษัท: โครงสร้างแม่-ลูก กรณีที่นิติบุคคลหนึ่งรายงานขึ้นไปยังบริษัทโฮลดิ้ง
- ผังบัญชี: จะใช้ร่วมกันหรือแยกกัน ขึ้นอยู่กับว่านิติบุคคลเหล่านั้นยื่นภาษีร่วมกันหรือแยกกัน
- คลังสินค้าและสต็อก: แต่ละบริษัทมักมีคลังสินค้าของตัวเอง แม้สินค้าที่ใช้ร่วมกันจะปรากฏในแคตตาล็อกของหลายบริษัทได้
- กฎ inter-company: การสร้างเอกสารขายและซื้อที่ตรงกันโดยอัตโนมัติ เมื่อนิติบุคคลหนึ่งค้าขายกับอีกนิติบุคคลหนึ่งในเครือ
การตัดสินใจทั้งห้าข้อนี้ให้ถูกต้องตั้งแต่แรก ช่วยหลีกเลี่ยงปัญหาที่พบบ่อยที่สุดในช่วงหลัง นั่นคือการพบภายหลังขึ้นระบบว่าเลขที่เอกสาร รหัสภาษี หรือการมองเห็นข้อมูลของผู้ใช้ถูกกำหนดขอบเขตผิดระดับ
ผังบัญชีแยกหรือใช้ร่วมกัน
นี่คือการตัดสินใจแรกที่สำคัญจริง ๆ และส่งผลมากกว่าที่คิด หากนิติบุคคลของคุณอยู่คนละประเทศ เช่น แห่งหนึ่งอยู่ไทยและอีกแห่งอยู่สหรัฐฯ ก็จำเป็นต้องมีผังบัญชีแยกกันอยู่แล้ว เพราะโมดูลการปรับใช้ตามกฎหมายของแต่ละประเทศแตกต่างกัน บัญชีของแต่ละบริษัทจะเป็นอิสระต่อกัน มีสมุดรายวันแยก รายงานภาษีแยก และการยื่น VAT หรือภาษีขายแยกกัน
หากนิติบุคคลของคุณอยู่ในประเทศเดียวกันและยื่นภาษีร่วมกัน หรือฝ่ายหนึ่งเป็นบริษัทโฮลดิ้งที่มีธุรกรรมน้อยมาก การใช้ผังบัญชีร่วมจะช่วยลดภาระการดูแลรักษา ตั้งค่าบัญชีครั้งเดียวแล้วทั้งสองบริษัทบันทึกรายการบนโครงสร้างเดียวกัน ข้อเสียคือจะสูญเสียความแยกส่วนที่ชัดเจนซึ่งผู้สอบบัญชีมักต้องการเห็นแยกรายนิติบุคคล ดังนั้นเราแนะนำวิธีนี้เฉพาะกับโครงสร้างโฮลดิ้งที่เรียบง่ายจริง ๆ เท่านั้น
ทางเลือกตรงกลางที่ใช้ได้ผลดีในทางปฏิบัติคือ แยกผังบัญชีแต่ทำการแมปโครงสร้างไว้ ให้บัญชีเลข 4000 ของบริษัทหนึ่งตรงกับแนวคิดของบัญชีเลข 4000 ในอีกบริษัทหนึ่ง แม้การเรียงเลขท้องถิ่นจะต่างกันเล็กน้อยด้วยเหตุผลทางภาษี วิธีนี้ทำให้รายงานรวมยังใช้งานได้โดยไม่ต้องบังคับให้บัญชีเหมือนกันทุกประการทั้งที่แต่ละนิติบุคคลมีข้อผูกพันด้านการปฏิบัติตามกฎหมายต่างกัน
สินค้าใช้ร่วมกัน สต็อกแยกกัน
บริษัทผลิตกับบริษัทจัดจำหน่ายในกลุ่มเดียวกัน มักขายสินค้าสำเร็จรูปแคตตาล็อกเดียวกัน Odoo ให้คุณตั้งค่าสินค้าให้ใช้งานได้หลายบริษัท จึงไม่ต้องดูแล SKU ซ้ำซ้อนพร้อมคำอธิบาย ราคา และบาร์โค้ดที่ซ้ำกันข้ามฐานข้อมูล นี่เป็นหนึ่งในประโยชน์ของ multi-company ที่มักถูกมองข้ามเมื่อเทียบกับการแยกระบบต่างหาก
สิ่งที่ไม่ถูกแชร์โดยอัตโนมัติคือ จำนวนสต็อก การตีมูลค่า และคลังสินค้า แต่ละบริษัทยังคงมีจำนวนคงเหลือของตัวเอง วิธีคิดต้นทุนของตัวเอง (เช่น FIFO หรือต้นทุนถัวเฉลี่ย) และตำแหน่งคลังสินค้าของตัวเอง เกือบทุกครั้งนี่คือสิ่งที่ถูกต้องตามที่ต้องการ เพราะสต็อกของบริษัทผลิตและสต็อกของบริษัทจัดจำหน่ายแยกกันทั้งในแง่กฎหมายและการเงิน แม้ข้อมูลสินค้าจะเป็นเรคคอร์ดเดียวกัน ทีมที่เข้าใจผิดว่าสินค้าใช้ร่วมกันแปลว่าสต็อกใช้ร่วมกันด้วย มักแปลกใจในครั้งแรกที่เช็กสต็อกคงเหลือจากบัญชีผู้ใช้ของบริษัทที่ผิด
ส่วนราคาสินค้าอาจกำหนดเฉพาะบริษัทหรือใช้ร่วมกันก็ได้ ขึ้นอยู่กับว่านิติบุคคลเหล่านั้นขายในราคาเดียวกันหรือเจรจาราคาแยกกัน โดยทั่วไปเรากำหนดขอบเขตราคาสินค้าแยกตามบริษัท เว้นแต่จะมีเหตุผลชัดเจนที่ต้องรวมศูนย์การตั้งราคา
การตั้งค่าธุรกรรมระหว่างบริษัทในเครือ
นี่คือจุดที่ multi-company แสดงคุณค่าของมันอย่างแท้จริง เมื่อนิติบุคคลหนึ่งในเครือซื้อขายกับอีกนิติบุคคลหนึ่ง เช่น บริษัทการค้าซื้อสินค้าสำเร็จรูปจากบริษัทผลิต Odoo สามารถสร้างเอกสารคู่กันโดยอัตโนมัติได้ดังนี้
- ใบสั่งขายที่ยืนยันในบริษัทผู้ขาย จะสร้างใบสั่งซื้อที่ตรงกันในบริษัทผู้ซื้อโดยอัตโนมัติ
- การยืนยันใบส่งของฝั่งผู้ขายสามารถยืนยันใบรับสินค้าที่ตรงกันในฝั่งผู้ซื้อโดยอัตโนมัติ ทำให้การเคลื่อนไหวของสต็อกตรงกัน
- การบันทึกใบแจ้งหนี้ลูกค้าสามารถสร้างบิลผู้ขายที่ตรงกันได้ ช่วยลดการคีย์ข้อมูลซ้ำและข้อผิดพลาดจากการคัดลอกข้อมูลระหว่างชุดบัญชีทั้งสอง
เราตั้งค่ากฎเหล่านี้อย่างตั้งใจ ไม่ใช่เปิดใช้เป็นค่าเริ่มต้นทุกอย่าง เพราะการสร้างกฎอัตโนมัติสำหรับทุกธุรกรรมภายในอาจทำให้ทั้งสองบริษัทมีเอกสารรกเกินความจำเป็นที่ทีมบัญชีไม่ได้ต้องการตรวจดูด้วยตนเองจริง ๆ แนวทางที่ใช้บ่อยคือทำการเชื่อมโยงขาย-ซื้อให้อัตโนมัติ แต่ปล่อยให้การออกใบแจ้งหนี้เป็นงานแบบชุดที่รันตามกำหนดช่วงปิดบัญชีสิ้นเดือน เพื่อให้ทีมการเงินควบคุมจังหวะเวลาและตรวจสอบได้ก่อนบันทึกจริง
ข้อจำกัดที่ควรพูดถึงตรงนี้คือ ระบบอัตโนมัติของธุรกรรมระหว่างบริษัทจัดการขั้นตอนเอกสารได้ดี แต่ไม่ได้แก้ปัญหาเรื่องราคาโอนภายในกลุ่ม (transfer pricing) ความแตกต่างในการกระทบยอดระหว่างบริษัทที่เกิดจากจังหวะเวลาของอัตราแลกเปลี่ยน หรือรายการตัดรายการระหว่างกัน (elimination entries) ที่จำเป็นสำหรับงบการเงินรวมอย่างแท้จริง สิ่งเหล่านี้ยังต้องให้ผู้ควบคุมบัญชีตรวจทานทุกรอบบัญชี โดยเฉพาะเมื่อนิติบุคคลค้าขายกันในคนละสกุลเงินและอัตราแลกเปลี่ยนเปลี่ยนแปลงระหว่างวันที่ออกใบแจ้งหนี้กับวันที่ชำระเงิน
การทำรายงานข้ามนิติบุคคล
รายงานบัญชีของ Odoo รองรับการเลือกหลายบริษัทพร้อมกัน จึงสามารถดึงงบดุลหรืองบกำไรขาดทุนของนิติบุคคลเดียว หลายนิติบุคคล หรือรวมทั้งหมดได้ วิธีนี้ทำงานได้ราบรื่นเมื่อผังบัญชีของบริษัทที่เลือกมีโครงสร้างเข้ากันได้ แต่จะยากขึ้นเมื่อนิติบุคคลหนึ่งใช้การปรับใช้ตามกฎหมายเฉพาะประเทศที่มีรหัสบัญชีไม่ตรงกันแบบหนึ่งต่อหนึ่งกับผังบัญชีของอีกนิติบุคคล
สำหรับกลุ่มบริษัทที่ต้องการการรวมงบตามกฎหมายอย่างแท้จริง การตัดรายการยอดคงเหลือระหว่างกัน และการแปลงค่าหลายสกุลเงินเป็นสกุลเงินรายงานเดียว ควรวางแผนเรื่องนี้เป็นงานคอนฟิกแยกต่างหาก มากกว่าจะสันนิษฐานว่ารายงานการเงินมาตรฐานจะแก้ปัญหานี้ได้ทันที โดยทั่วไปเราจะใช้รายงานของ Odoo เองคู่กับมุมมองการรวมงบเฉพาะหรือการส่งออกข้อมูลสำหรับบัญชีบริหารของกลุ่มบริษัท โดยเฉพาะเมื่อนิติบุคคลกระจายอยู่ในไทย สหรัฐฯ และอินเดีย ซึ่งมีสกุลเงินในการดำเนินงานสามสกุลและปฏิทินบัญชีตามกฎหมายสามแบบที่แตกต่างกัน
| ความต้องการ | Odoo multi-company รองรับโดยตรง | งานเพิ่มเติมที่มักต้องทำ |
|---|---|---|
| ยื่น VAT หรือภาษีขายแยกรายนิติบุคคล | ใช่ ออกแบบมาให้ทำได้ | ไม่มี หากโมดูล localization ตรงกับประเทศ |
| แคตตาล็อกสินค้าใช้ร่วมกัน | ใช่ | ตัดสินใจเรื่องขอบเขตราคาสินค้า |
| สร้างเอกสารระหว่างบริษัทอัตโนมัติ | ใช่ ตั้งค่าได้ | เลือกว่าขั้นตอนใดควรทำอัตโนมัติ |
| มุมมองงบดุลรวม | ใช่ หากผังบัญชีสอดคล้องกัน | การแมปบัญชีข้าม localization |
| การรวมงบตามกฎหมายแบบเต็มรูปแบบพร้อมตัดรายการระหว่างกัน | บางส่วน | ต้องตั้งค่าการรวมงบเฉพาะหรือส่งออกข้อมูล |
สิทธิ์การเข้าถึงและต้นทุนของความผิดพลาด
กฎความปลอดภัยของ multi-company กำหนดว่าผู้ใช้คนไหนเห็นข้อมูลของบริษัทไหนได้บ้าง พฤติกรรมเริ่มต้นจะจำกัดให้ผู้ใช้เห็นเฉพาะบริษัทที่ตนสังกัด เว้นแต่จะให้สิทธิ์เข้าถึงหลายบริษัทอย่างชัดเจน นี่เป็นค่าเริ่มต้นที่ถูกต้อง แต่ต้องทดสอบก่อนขึ้นระบบจริง ไม่ใช่หลังจากนั้น
ความเสี่ยงเกิดขึ้นได้ทั้งสองทาง หากจำกัดมากเกินไป ทีมการเงินที่ใช้ร่วมกันจะทำงานข้ามนิติบุคคลไม่ได้โดยไม่ต้องสลับบริษัทตลอดเวลา หากเปิดกว้างเกินไป ผู้ใช้ในทีมขายของนิติบุคคลหนึ่งอาจเห็นอัตรากำไรหรือต้นทุนซัพพลายเออร์ของอีกนิติบุคคลหนึ่ง ซึ่งเป็นปัญหาจริงในกลุ่มบริษัทที่มีผู้ถือหุ้นหรือพาร์ตเนอร์ส่วนน้อยต่างกัน เราทดสอบเรื่องนี้ด้วยบัญชีผู้ใช้จริงก่อนขึ้นระบบจริง โดยล็อกอินด้วยแต่ละบทบาทและตรวจสอบว่าเห็นอะไรได้บ้าง แทนที่จะอนุมานจากหน้าจอการตั้งค่าเพียงอย่างเดียว
Multi-company เทียบกับการแยกฐานข้อมูล
หากกลุ่มบริษัทของคุณกำลังชั่งใจระหว่างแนวทางนี้กับการแยกฐานข้อมูลต่อนิติบุคคล ปัจจัยตัดสินใจหลักมักอยู่ที่ว่านิติบุคคลเหล่านั้นค้าขายกันเองมากแค่ไหนและใช้ข้อมูลหลักร่วมกันมากเพียงใด การค้าขายระหว่างกันที่หนาแน่นและแคตตาล็อกที่ใช้ร่วมกัน สนับสนุนให้ใช้ฐานข้อมูล multi-company เดียว ส่วนนิติบุคคลที่ดำเนินงานเกือบเป็นอิสระต่อกัน ด้วยอุตสาหกรรมต่างกัน แผนการเติบโตต่างกัน หรือแนวทางถอนตัวในอนาคตต่างกัน บางครั้งการแยกฐานข้อมูลไว้ก็ดีกว่า แม้จะหมายถึงการมีข้อมูลหลักซ้ำซ้อนบ้างก็ตาม
เราจะพิจารณาข้อดีข้อเสียนี้ร่วมกับโครงสร้างผู้ถือหุ้นและทีมการเงินก่อนตัดสินใจ เพราะการย้ายจากแนวทางหนึ่งไปอีกแนวทางหนึ่งภายหลัง มีภาระงานมากกว่าการตัดสินใจให้ถูกต้องตั้งแต่ต้นมาก หน้า บริการวางระบบ Odoo ของเราอธิบายวิธีที่เรากำหนดขอบเขตการตัดสินใจลักษณะนี้เป็นระยะ ๆ และภาพรวม บริการ Odoo ERP อธิบายสิ่งที่มักเกิดขึ้นหลังขึ้นระบบจริงสำหรับกลุ่มบริษัทที่มีหลายนิติบุคคล
สำหรับกลุ่มบริษัทที่ใช้งาน Odoo แบบบริษัทเดียวอยู่แล้วและกำลังจะเพิ่มนิติบุคคลที่สองในภายหลัง นี่ก็เป็นจังหวะที่ดีในการทบทวนผังบัญชีและการตั้งค่าบัญชีของคุณ แทนที่จะเพิ่มบริษัทที่สองเข้าไปบนการตัดสินใจที่ทำไว้สำหรับนิติบุคคลเดียวเท่านั้น การปรับโครงสร้างบัญชีใหม่หลังบันทึกรายการมาแล้วหนึ่งปี สร้างความปั่นป่วนมากกว่าการวางแผนรองรับการเติบโตไว้ตั้งแต่ช่วง ที่ปรึกษา Odoo เริ่มต้นมาก หากทั้งสองนิติบุคคลจะค้าขายกันเองมากด้วย ควรเริ่มทบทวนผังบัญชีร่วมกับทีม รับสมัครนักพัฒนา Odoo ของเราตั้งแต่เนิ่น ๆ เพื่อให้กฎ inter-company ถูกสร้างไปพร้อมกับบริษัทใหม่ แทนที่จะต้องย้อนกลับมาทำทีหลัง
