คู่มือตั้งค่า Odoo e-Tax Invoice สำหรับบริษัทไทย
บริษัทไทยเกือบทุกรายที่เราเคยทำงานด้วยมองเรื่อง Odoo e-Tax Invoice เป็นแค่ช่องที่ต้องติ๊กให้ครบตามกฎหมายในตอนแรก แต่พอทำโปรเจกต์ไปได้ครึ่งทางก็พบว่าเรื่องนี้เกี่ยวพันกับหลายเรื่องพร้อมกัน ทั้งลำดับเลขที่เอกสาร เทมเพลต PDF ลายมือชื่อดิจิทัล และบริการส่งข้อมูลจากผู้ให้บริการภายนอก การตั้งค่า Odoo e-Tax Invoice ให้ถูกต้องหมายถึงการทำให้ทั้งสี่ส่วนนี้สอดคล้องกัน ไม่ใช่แค่ติดตั้งโมดูลแล้วหวังว่ากรมสรรพากรจะยอมรับสิ่งที่ออกมา
นี่คือลำดับขั้นตอนที่เราใช้จริงในโปรเจกต์ลูกค้า รวมถึงจุดที่มักผิดพลาดในรอบแรก
Odoo e-Tax Invoice: สิ่งที่กรมสรรพากรกำหนดไว้จริง
ประเทศไทยมีสองระบบแยกจากกัน การเข้าใจสับสนระหว่างสองระบบนี้คือความผิดพลาดในการวางแผนที่เราพบบ่อยที่สุด ระบบแรกคือ e-Tax Invoice by Email สำหรับธุรกิจขนาดเล็กที่มีรายได้ต่อปีไม่เกิน 30 ล้านบาท ระบบนี้ตรวจสอบความถูกต้องด้วย time stamp จาก ETDA แทนการใช้ลายมือชื่อดิจิทัล ระบบที่สองคือ e-Tax Invoice & e-Receipt ซึ่งเปิดให้ธุรกิจทุกขนาดใช้งานได้ ไม่มีข้อจำกัดเรื่องขนาดกิจการ ระบบนี้กำหนดให้ทุกเอกสารต้องมีลายมือชื่อดิจิทัล
ทั้งสองระบบกำหนดให้เอกสารขายที่เข้าเงื่อนไขต้องถูกส่งข้อมูลทางอิเล็กทรอนิกส์ ไม่ว่าจะส่งตรงหรือผ่านผู้ให้บริการที่ได้รับอนุญาต ภายในรอบเวลาที่กำหนด ตัวเอกสารเองต้องมีโครงสร้างตายตัว ได้แก่ เลขประจำตัวผู้เสียภาษี รหัสสาขา เลขที่เอกสารเรียงตามลำดับในแต่ละชุดเอกสาร และรายละเอียดภาษีมูลค่าเพิ่ม ขึ้นอยู่กับระบบที่เลือก เอกสารจะมี time stamp หรือลายมือชื่อดิจิทัลที่ผูกกับนิติบุคคลผู้ยื่น
เรามักบอกลูกค้าตั้งแต่ต้นว่าต้องยืนยันก่อนว่าบริษัทมีสิทธิ์เข้าร่วมระบบใด และต้องการลงทะเบียนภายใต้ระบบไหน ก่อนที่จะเริ่มตั้งค่าใน Odoo สองแนวทางนี้มีการตั้งค่าปลายทางที่ต่างกัน การเปลี่ยนใจภายหลังหมายถึงต้องทำเลขที่เอกสารและการตั้งค่าลงลายมือชื่อใหม่ทั้งหมด
เรื่องเลขที่เอกสาร: จุดที่ทุกคนมักประเมินต่ำเกินไป
ใบกำกับภาษีอิเล็กทรอนิกส์ของไทยต้องมีระบบเลขที่เอกสารที่เรียงลำดับต่อเนื่อง ไม่มีช่องว่างในแต่ละชุดเอกสาร และตรวจสอบย้อนกลับไปยังสาขาที่ออกเอกสารได้ ระบบเลขที่เอกสารมาตรฐานของ Odoo รองรับการเรียงลำดับได้ดีอยู่แล้ว แต่บริษัทไทยมักมีชุดเอกสารหลายชุดทำงานคู่ขนานกัน เช่น หนึ่งชุดต่อสาขา หรือบางครั้งหนึ่งชุดต่อจุดขาย ทันทีที่มีใครรีเซ็ตเลขที่เอกสารด้วยมือ หรือสองสาขาใช้ prefix ซ้ำกันโดยไม่ตั้งใจ ไฟล์ส่งออกจะถูกปฏิเสธที่ขั้นตอนตรวจสอบของผู้ให้บริการ ไม่ใช่ที่ Odoo เอง
เช็กลิสต์ที่เราใช้ก่อนขึ้นระบบจริงมีดังนี้
- กำหนดชุดเลขที่เอกสารเฉพาะหนึ่งชุดต่อหนึ่งสาขาตามกฎหมาย ให้ตรงกับรหัสสาขาที่จดทะเบียนกับกรมสรรพากร ไม่ใช่ตามชื่อเรียกภายในของ Odoo
- ห้ามมีช่องว่างในเลขที่เอกสารเด็ดขาด ใบแจ้งหนี้ที่ยกเลิกต้องออกใบลดหนี้ ไม่ใช่ลบหรือออกเลขใหม่
- ล็อกสิทธิ์การแก้ไข prefix และการรีเซ็ตไว้ในระบบสิทธิ์การเข้าถึง เพราะการแก้ไขผิดเพียงครั้งเดียวจะทำให้ไฟล์ยื่นทั้งเดือนเสียหาย
- ทดสอบกับ sandbox ของผู้ให้บริการก่อนเสมอ ก่อนส่งชุดข้อมูลจริงชุดแรก
การเลือกผู้ให้บริการสำหรับการยื่น e-Tax Invoice
Odoo เองไม่ได้ส่งข้อมูลไปยังกรมสรรพากรโดยตรง Odoo จะสร้างเอกสารในรูปแบบที่ถูกต้องเท่านั้น จากนั้นระบบจะลงลายมือชื่อเอง หรือส่งต่อให้ผู้ให้บริการที่ได้รับการรับรองเพื่อลงลายมือชื่อและส่งข้อมูล การเลือกแนวทางไหนขึ้นอยู่กับปริมาณเอกสารและความสัมพันธ์ที่มีอยู่เดิมเป็นหลัก ทีมบัญชีไทยหลายแห่งทำงานกับผู้ให้บริการรายเดิมสำหรับงานยื่นภาษีอื่นอยู่แล้ว และมักต้องการใช้ผู้ให้บริการรายเดียวกันสำหรับ e-Tax ด้วย
เมื่อเรากำหนดขอบเขตงานนี้ร่วมกับลูกค้าผ่านบริการวางระบบ Odoo เรามักเปรียบเทียบผู้ให้บริการในสามประเด็นจริง ประเด็นแรกคือระยะเวลาดำเนินการของชุดข้อมูลที่ส่งรายวันหรือรายเดือน ประเด็นที่สองคือวิธีที่ API หรือระบบส่งไฟล์ของผู้ให้บริการเชื่อมต่อกับการส่งออกข้อมูลของ Odoo ประเด็นที่สามคือสิ่งที่เกิดขึ้นเมื่อชุดข้อมูลถูกปฏิเสธ ผู้ให้บริการบางรายแจ้งข้อผิดพลาดรายบรรทัดชัดเจน บางรายส่งกลับมาเป็นข้อความคลุมเครือที่ต้องเปิดตั๋วซัพพอร์ตเพื่อถอดรหัส ประเด็นที่สามนี้สำคัญกว่าการเปรียบเทียบฟีเจอร์ส่วนใหญ่ เมื่อยื่นแบบจริงมาแล้วสามเดือน
ขั้นตอนการอนุมัติภายใน Odoo
ขั้นตอนการทำงานที่เราวางระบบให้โดยทั่วไปเป็นดังนี้ ใบแจ้งหนี้ถูกยืนยันโดยทีมบัญชีตามปกติก่อน การยืนยันนั้นจะไปกระตุ้นให้ระบบสร้างเอกสาร e-Tax แบบ XML หรือ PDF/A-3 ในพื้นหลัง เอกสารนั้นจะอยู่ในสถานะรอดำเนินการจนกว่าผู้อนุมัติที่กำหนดไว้จะตรวจสอบ ผู้อนุมัติปกติคือผู้จัดการฝ่ายการเงิน บางครั้งมีบุคคลที่สองร่วมด้วยเพื่อแบ่งแยกหน้าที่ เมื่อผู้ให้บริการยืนยันว่าส่งสำเร็จแล้วเท่านั้น Odoo จึงจะบันทึกว่าเอกสารได้ยื่นแล้ว
เรายังคงให้ขั้นตอนอนุมัตินี้เป็นแบบมนุษย์ตรวจสอบ ไม่ใช่อัตโนมัติเต็มรูปแบบ แม้เทคโนโลยีจะรองรับการทำงานแบบต่อเนื่องได้ก็ตาม เหตุผลนั้นง่ายมาก ช่วงสองสามเดือนแรกของการเริ่มใช้ e-Tax มักเจอกรณีพิเศษที่ไม่คาดคิด เช่น ลูกค้าที่มีเลขผู้เสียภาษีล้าสมัย ใบลดหนี้ที่ออกอ้างอิงเอกสารก่อนวันขึ้นระบบ หรือรหัสสาขาพิมพ์ผิด กรณีเหล่านี้ดักจับได้ง่ายกว่ามากถ้าตรวจก่อนส่ง ไม่ใช่หลังส่งไปแล้ว
จุดที่งาน e-Tax Invoice เชื่อมกับกฎหมายไทยด้านอื่น
e-Tax Invoice แทบไม่เคยทำงานอยู่ลำพัง บริษัทไทยส่วนใหญ่ที่เราดูแลผ่านบริการพัฒนาระบบ ERP ต้องจัดการรายงานภาษีมูลค่าเพิ่ม หนังสือรับรองภาษีหัก ณ ที่จ่ายสำหรับ PND 3 และ PND 53 และการกระทบยอด PromptPay ในรอบปิดงวดเดียวกันด้วย หากเลขที่เอกสาร e-Tax ผิดพลาด มักจะปรากฏเป็นปัญหายื่นภาษีมูลค่าเพิ่มที่ยอดไม่ตรงก่อน ไม่ใช่การถูกปฏิเสธการยื่นโดยตรง นี่คือเหตุผลที่เรามองเรื่องนี้เป็นงานดูแลระบบต่อเนื่องหนึ่งเดียวที่เชื่อมโยงกัน ไม่ใช่แค่การติดตั้งโมดูลเดี่ยว ๆ
บริษัทที่ขายผ่าน Shopee, Lazada หรือ TikTok Shop จะมีอีกชั้นหนึ่งที่ต้องดูแล ยอดโอนเงินจากมาร์เก็ตเพลสต้องจับคู่กลับไปยังเอกสาร e-Tax แต่ละฉบับต่อออเดอร์ให้ถูกต้อง จุดจับคู่นี้เองที่การตั้งค่า Odoo ทั่วไปมักมีปัญหา เพราะการเชื่อมต่อมาร์เก็ตเพลสและโมดูล e-Tax มักถูกตั้งค่าโดยคนละคนในคนละช่วงเวลา งานลักษณะนี้มักดึงบริการเชื่อมต่อ API ของ Odoo ของเราเข้ามาร่วมกลางโปรเจกต์
ไทม์ไลน์โปรเจกต์ตามความเป็นจริง
สำหรับบริษัทเดียวที่มีหนึ่งหรือสองสาขา เรามักวางแผนตามตารางนี้
| ระยะ | ระยะเวลา | สิ่งที่เกิดขึ้น |
|---|---|---|
| รวบรวมความต้องการและเลือกผู้ให้บริการ | 1-2 สัปดาห์ | ยืนยันรูปแบบการยื่น เลือกผู้ให้บริการ ขอสิทธิ์เข้าใช้ sandbox |
| ตั้งค่าระบบ | 1-2 สัปดาห์ | ชุดเลขที่เอกสาร เทมเพลต เส้นทางอนุมัติ การตั้งค่าลงลายมือชื่อ |
| ทดสอบคู่ขนาน | 2-4 สัปดาห์ | รัน e-Tax ควบคู่กับกระบวนการเดิมแบบกระดาษหรือแบบมือ |
| ขึ้นระบบจริง | 1 รอบยื่นภาษี | ส่งชุดข้อมูลจริงชุดแรก พร้อมติดตามผลอย่างใกล้ชิด |
บริษัทที่มีหลายสาขาหรือหลายนิติบุคคลจะใช้เวลานานกว่านี้ ส่วนใหญ่เพราะสิทธิ์การเข้าถึงระดับสาขาและเลขที่เอกสารต้องได้รับการอนุมัติจากหัวหน้าบัญชีของแต่ละสาขาก่อนขึ้นระบบจริง
ข้อจำกัดที่ควรพูดตรง ๆ
นี่คือข้อจำกัดที่ต้องยอมรับตรง ๆ e-Tax Invoice & e-Receipt เพิ่มขั้นตอนอนุมัติจริงเข้ามา และเพิ่มการพึ่งพาความเสถียรกับความเร็วในการดำเนินการของผู้ให้บริการภายนอก นี่ไม่ใช่กระบวนการที่ทำงานเบื้องหลังแบบไร้การแตะต้องทั้งหมด บริษัทที่คาดหวังว่าจะยื่นได้ในวันเดียวกันโดยไม่ต้องแตะต้องอะไรเลยตั้งแต่วันแรก มักผิดหวังภายในเดือนแรก ตอนที่ชุดข้อมูลชุดแรกถูกปฏิเสธ ทุกคนจะได้เรียนรู้ว่ากรณีพิเศษจริง ๆ มีอะไรบ้าง ควรตั้งงบสำหรับช่วงเรียนรู้นี้ไว้ ไม่ใช่คิดว่าการตั้งค่ารอบแรกจะเป็นรอบสุดท้าย
หากบริษัทของท่านกำลังใกล้ถึงเกณฑ์บังคับ หรือยื่นด้วยมืออยู่แล้วและกำลังมองหาทางทำให้เป็นอัตโนมัติ ควรเริ่มด้วยการพูดคุยกำหนดขอบเขตงานสั้น ๆ ก่อนตัดสินใจเลือกผู้ให้บริการ การตัดสินใจเรื่องเลขที่เอกสารและขั้นตอนอนุมัติให้ถูกต้องตั้งแต่ใบแรกนั้นถูกกว่าการแก้ไขย้อนหลังมาก โดยเฉพาะหลังจากยื่นจริงไปแล้วสามเดือน ทีมงานของเราที่บริการปรับแต่งระบบ Odoo เคยรื้อระบบแบบนี้ใหม่มาแล้วมากกว่าหนึ่งครั้ง หลังจากผู้ให้บริการรายอื่นตั้งเลขที่เอกสารผิดตั้งแต่รอบแรก ทุกครั้งที่ต้องทำรอบสองย่อมมีต้นทุนสูงกว่าเสมอ ทีมบริการดูแลระบบ Odoo ของเราจะอยู่ต่อเพื่อติดตามรอบยื่นภาษีสองสามรอบแรกให้