Odoo e-Tax Invoice: คู่มือตั้งค่าระบบใบกำกับภาษีสำหรับบริษัทไทย
บริษัทไทยเกือบทุกรายที่ยอดขายแตะเกณฑ์ที่กรมสรรพากรกำหนด ถามคำถามเดียวกัน Odoo รองรับเรื่อง e-Tax invoice ได้จริงหรือต้องต่อระบบภายนอกแยกเข้ามา เราวางระบบ Odoo e-Tax invoice และ e-Receipt ให้บริษัทไทยมาหลายราย คำตอบคือทำได้จริง แต่รายละเอียดสำคัญกว่าที่ผู้ให้บริการหลายรายพูดถึง หากตั้งค่ารูปแบบเลขที่เอกสารผิด หรือเชื่อมต่อผู้ให้บริการผิดขั้นตอน ผลที่ตามมาคือชุดเอกสารถูกปฏิเสธตอนปิดงบสิ้นเดือน ซึ่งเป็นช่วงเวลาที่แย่ที่สุดที่จะมาเจอช่องโหว่ของการตั้งค่า
บทความนี้อธิบายว่าเราตั้งค่า Odoo e-Tax invoice และ e-Receipt ให้ลูกค้าไทยจริงอย่างไร กรมสรรพากรต้องการข้อมูลแบบไหน และจุดที่มักเกิดปัญหาตอนขึ้นระบบใช้งานจริงอยู่ตรงไหน
Odoo e-Tax invoice ต้องมีข้อมูลอะไรบ้างตามที่กรมสรรพากรกำหนด
ระบบใบกำกับภาษีอิเล็กทรอนิกส์และใบรับอิเล็กทรอนิกส์ต้องการเอกสารที่ลงลายมือชื่อดิจิทัลแล้ว ส่งให้กรมสรรพากรโดยตรงหรือผ่านผู้ให้บริการที่ได้รับใบอนุญาต ไฟล์ XML ที่ลงนามแล้วต้องมีเลขประจำตัวผู้เสียภาษีที่ถูกต้อง เลขที่เอกสารเรียงลำดับต่อเนื่อง รายละเอียด VAT และประทับเวลาที่เชื่อมโยงกับใบรับรองหรือบริการประทับเวลาของบริษัท
มีสองแนวทางหลัก ขึ้นอยู่กับขนาดบริษัทและปริมาณธุรกรรม
- e-Tax Invoice by Time Stamp เหมาะกับปริมาณธุรกรรมน้อย ใช้บริการประทับเวลาของสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) เพื่อยืนยันความถูกต้อง แทนที่จะต้องมีใบรับรองดิจิทัลจาก Certification Authority
- e-Tax Invoice & e-Receipt แบบเต็มรูปแบบ ต้องมีใบรับรองดิจิทัล ส่วนใหญ่ดำเนินการผ่านผู้ให้บริการที่ได้รับใบอนุญาต เหมาะกับบริษัทที่ออกใบกำกับภาษีและใบรับจำนวนมาก
การเลือกแนวทางไม่ใช่การตัดสินใจในฝั่ง Odoo แต่เป็นการตัดสินใจตอนลงทะเบียนกับกรมสรรพากรก่อน การตั้งค่า Odoo จึงตามหลังการเลือกนั้นเสมอ
เชื่อมข้อกำหนด e-Tax เข้ากับ Odoo อย่างไร
Odoo ไม่ได้ลงลายมือชื่อหรือส่งเอกสารให้กรมสรรพากรเอง สิ่งที่ Odoo ทำคือสร้างใบกำกับภาษีหรือใบรับตามโครงสร้างที่ถูกต้อง จัดการเลขที่เอกสารให้เรียงลำดับ แล้วส่งต่อให้ตัวเชื่อมต่อหรือโมดูลของผู้ให้บริการทำหน้าที่ลงนามและส่งเอกสาร เราทำงานร่วมกับผู้ให้บริการหลายราย รูปแบบการตั้งค่าฝั่ง Odoo มักคล้ายกันในแต่ละครั้ง
- ข้อมูลบริษัท: เลขประจำตัวผู้เสียภาษี รหัสสาขา ที่อยู่จดทะเบียน ต้องตรงกับข้อมูลที่จดทะเบียนไว้กับกรมสรรพากร
- เลขที่เอกสาร (sequence): แยกเลขที่ไม่ซ้ำกันตามประเภทเอกสารแต่ละแบบ เช่น ใบกำกับภาษี ใบลดหนี้ ใบรับ และในบางกรณีแยกตามสาขาด้วย
- การตั้งค่าสมุดรายวัน: กำหนดสมุดรายวันขายเฉพาะสำหรับขั้นตอน e-Tax เพื่อไม่ให้เอกสารภายในทั่วไปถูกส่งไปลงนามโดยไม่ตั้งใจ
- ตัวเชื่อมต่อผู้ให้บริการ: ข้อมูล API credential การอ้างอิงใบรับรองหรือบริการประทับเวลา และโหมดทดสอบก่อนใช้งานจริง
- การจับคู่แม่แบบ PDF/XML: ต้องมั่นใจว่าใบกำกับภาษีที่พิมพ์ออกมาตรงกับเอกสารที่ลงนามและส่งจริง เพราะผู้ตรวจสอบบัญชีไทยจะเทียบสองฉบับนี้
งานทั้งหมดนี้ไม่ต้องแตะโค้ดหลักของระบบใบกำกับภาษีใน Odoo เราทำผ่านการตั้งค่าและชั้นการเชื่อมต่อบาง ๆ วิธีนี้ทำให้การตั้งค่าปลอดภัยต่อการอัปเกรด เมื่อบริษัทย้ายจาก Odoo 16 ไป 19 ทีมงาน บริการเชื่อมต่อระบบผ่าน API ของ Odoo ของเราดูแลงานเชื่อมต่อลักษณะนี้โดยตรง
เลขที่เอกสาร Odoo e-Tax invoice จุดที่มักตั้งค่าผิดมากที่สุด
กฎของไทยกำหนดให้เลขที่ใบกำกับภาษีต้องเรียงต่อเนื่อง ไม่มีเลขขาดหาย ไม่มีเลขซ้ำ แม้จะมีหลายสาขาก็ตาม เรื่องนี้ขัดกับวิธีที่หลายบริษัทเคยทำในสเปรดชีตหรือระบบเก่า ที่เลขขาดหายจากใบที่ยกเลิกมักถูกข้ามไปแบบไม่เป็นทางการ
ใน Odoo เราจะตั้งค่าให้เป็นดังนี้
- เอกสารตามกฎหมายแต่ละประเภทมี sequence object ของตัวเอง กำหนดขอบเขตตามบริษัทและสาขาอย่างถูกต้อง
- เอกสารที่ยกเลิกจัดการด้วยใบลดหนี้ ไม่ใช่การลบหรือเปลี่ยนเลขที่ใหม่ เพื่อรักษาความต่อเนื่องของเลขที่
- ใบแจ้งหนี้ในสถานะร่างจะยังไม่ใช้เลขที่จนกว่าจะยืนยันแล้ว การทดสอบหรือแก้ไขในสถานะร่างจึงไม่ทำให้ลำดับเลขที่ขาดหาย
ปัญหาที่เราพบบ่อยที่สุดในบริษัทที่ย้ายมาจากระบบอื่นคือรูปแบบเลขที่ถูกฝังไว้ในเทมเพลตใบแจ้งหนี้ แทนที่จะเป็น sequence ที่ถูกต้อง วิธีนี้จะพังทันทีที่มีผู้ใช้สองคนสร้างใบแจ้งหนี้พร้อมกัน ระบบ sequence ของ Odoo จัดการเรื่องการทำงานพร้อมกันได้ดีอยู่แล้ว แต่ต้องตั้งค่าไว้ก่อนขึ้นระบบใช้งานจริง ไม่ใช่มาแก้ทีหลัง
เลือกผู้ให้บริการสำหรับส่งเอกสาร e-Tax
Odoo ไม่มีการเชื่อมต่อสำเร็จรูปกับผู้ให้บริการ e-Tax ของไทยทุกราย บริษัทต้องเลือกและทำสัญญากับผู้ให้บริการที่ได้รับใบอนุญาต หรือใช้บริการประทับเวลาของ ETDA โดยตรงสำหรับผู้ยื่นแบบรายเล็ก จากนั้นจึงเชื่อมผู้ให้บริการนั้นเข้ากับ Odoo ผ่าน API หรือโมดูลเฉพาะทาง
สิ่งที่ควรรู้ก่อนตัดสินใจมีดังนี้
| ประเด็นที่ต้องพิจารณา | เหตุผลที่สำคัญ |
|---|---|
| ส่งผ่าน API หรือส่งไฟล์ | การเชื่อมต่อผ่าน API ทำให้ขั้นตอนอนุมัติทำงานอยู่ใน Odoo ได้เลย ส่วนแบบส่งไฟล์ต้อง export/import ด้วยมือทุกรอบ |
| ผู้ถือใบรับรองดิจิทัล | ผู้ให้บริการบางรายถือใบรับรองแทนบริษัท บางรายให้บริษัทดูแลเอง ซึ่งมีผลต่อความรับผิดชอบเรื่องต่ออายุ |
| ราคาตามปริมาณเอกสาร | ผู้ให้บริการมักคิดราคาต่อเอกสาร ธุรกิจค้าปลีกที่มีปริมาณสูงควรคำนวณต้นทุนนี้ก่อนเลือก |
| การจัดการเมื่อถูกปฏิเสธหรือส่งซ้ำ | เอกสารที่ถูกปฏิเสธต้องมีเส้นทางส่งกลับเข้า Odoo ที่ชัดเจน ไม่ใช่กระบวนการแยกที่ทำด้วยมือ |
เราไม่ยึดติดกับผู้ให้บริการรายใดรายหนึ่ง หน้าที่ของเราคือทำให้ผู้ให้บริการที่บริษัทเลือกเชื่อมต่อกับระบบใบแจ้งหนี้และบัญชีใน Odoo ได้อย่างเรียบร้อย ทีมบัญชีต้องมองเห็นเส้นทางเมื่อเอกสารถูกปฏิเสธหรือต้องส่งซ้ำ ไม่ใช่ซ่อนอยู่ใน log ของผู้ให้บริการที่ไม่มีใครเปิดดู ทีม ที่ปรึกษา Odoo ของเราช่วยชี้แจงข้อดีข้อเสียของแต่ละทางเลือกก่อนที่บริษัทจะเซ็นสัญญากับผู้ให้บริการ
ขั้นตอนอนุมัติภายใน Odoo
ส่วนที่เปลี่ยนพฤติกรรมการทำงานประจำวันของทีมการเงินจริง ๆ คือขั้นตอนอนุมัติ ในการตั้งค่าทั่วไปมีลำดับดังนี้
- ยืนยันคำสั่งขายและจัดส่งสินค้าเรียบร้อยแล้ว
- สร้างใบแจ้งหนี้ในสถานะร่างตามปกติ
- เมื่อยืนยันใบแจ้งหนี้ Odoo จะเริ่มขั้นตอนส่ง e-Tax อัตโนมัติหรือผ่านปุ่มที่ต้องกดเอง ขึ้นอยู่กับว่าลูกค้าต้องการควบคุมมากแค่ไหน
- ผู้ให้บริการลงนามและส่งต่อให้กรมสรรพากร แล้วส่งสถานะกลับมา
- Odoo บันทึกสถานะนั้นไว้ในใบแจ้งหนี้ ทีมการเงินเห็นสถานะอนุมัติแล้ว รอดำเนินการ หรือถูกปฏิเสธได้จากหน้ารายการใบแจ้งหนี้เลย
- เอกสารที่ถูกปฏิเสธจะถูกส่งกลับมาแก้ไข ส่วนใหญ่เป็นปัญหาข้อมูล เช่น เลขประจำตัวผู้เสียภาษีไม่ตรงหรือเลือกประเภทเอกสารผิด แล้วจึงส่งใหม่
โดยทั่วไปเราตั้งค่าไม่ให้เอกสารที่ถูกปฏิเสธไปกีดกันการบันทึกบัญชีขั้นถัดไป บริษัทยังต้องเดินหน้าบันทึกบัญชีต่อไปได้ระหว่างที่กำลังตรวจสอบแก้ไข นี่เป็นทางเลือกในการออกแบบ ไม่ใช่ค่าเริ่มต้นของ Odoo ควรคุยกับผู้ทำบัญชีของบริษัทก่อนขึ้นระบบใช้งานจริง
ภาษีหัก ณ ที่จ่ายและ PromptPay ควบคู่กับการตั้งค่า Odoo e-Tax invoice
ลูกค้าไทยส่วนใหญ่ของเราต้องการให้ e-Tax invoicing ทำงานควบคู่กับใบหัก ณ ที่จ่าย (PND 3 / PND 53) และการกระทบยอด PromptPay ในฝั่งลูกหนี้ เรื่องเหล่านี้เป็นการตั้งค่าแยกกันใน Odoo แต่แตะสมุดรายวันและกระบวนการปิดงบสิ้นเดือนเดียวกัน เราจึงมักตั้งค่าพร้อมกันแทนที่จะแยกทำทีละส่วน การจัดผังบัญชีและการแมปภาษีให้ถูกต้องตั้งแต่แรกช่วยลดงานที่ต้องแก้ไขซ้ำ เมื่อระบบ e-Tax เริ่มใช้งานจริงในอีกไม่กี่สัปดาห์ถัดมา หากระบบ Odoo ของบริษัทเชื่อมกับ Shopee, Lazada หรือ TikTok Shop ด้วย งาน เชื่อมต่อระบบผ่าน API ของ Odoo ของเรามักเริ่มต้นตรงจุดนี้ ก่อนจะเข้าสู่เรื่องการเลือกผู้ให้บริการ
ข้อจำกัดหนึ่งอย่างที่ควรรู้ไว้ก่อน
การเชื่อมต่อ e-Tax ของ Odoo ขึ้นอยู่กับความเสถียรและ uptime ของผู้ให้บริการที่บริษัทเลือกทั้งหมด หากผู้ให้บริการมีปัญหาระบบล่มหรือทำงานช้าในช่วงที่มีการส่งเอกสารจำนวนมาก ใบแจ้งหนี้อาจค้างอยู่ในสถานะรอดำเนินการภายใน Odoo จนกว่าผู้ให้บริการจะกลับมาใช้งานได้ปกติ เราเตรียมเส้นทางสำรองแบบแมนวลไว้รองรับ โดยพักใบแจ้งหนี้ไว้ในคิวแทนที่จะหยุดการขาย แต่ไม่มีทางทำให้การส่งเอกสารเร็วทันทีหรือไม่ขึ้นกับผู้ให้บริการได้เลย บริษัทที่มีปริมาณใบแจ้งหนี้ต่อวันสูงมากควรนำเรื่องนี้ไปพิจารณาตอนเลือกผู้ให้บริการและแพ็กเกจ
ทำ Odoo e-Tax invoice ให้ถูกต้องตั้งแต่ครั้งแรก
เราเข้าหางานตั้งค่า e-Tax และ e-Receipt ด้วยวิธีเดียวกับงานปรับระบบให้เข้ากับกฎไทยเรื่องอื่น ๆ ตั้งค่าก่อน ตรวจสอบกับชุดใบแจ้งหนี้จริงก่อนขึ้นระบบใช้งานจริง และอยู่ดูแลจนผ่านการปิดงบสิ้นเดือนครั้งแรก เพื่อจับกรณีปลีกย่อยที่จะปรากฏก็ต่อเมื่อมีธุรกรรมจริงวิ่งผ่านระบบเท่านั้น หากบริษัทกำลังวางแผนขึ้นระบบนี้ หน้า บริการวางระบบ Odoo ของเราอธิบายว่าเรากำหนดขอบเขตงานและลำดับขั้นตอนอย่างไร ทีม บริการดูแลระบบ Odoo ERP ของเราพร้อมดูแลเรื่องการเปลี่ยนแปลงของผู้ให้บริการและกฎระเบียบต่อเนื่องหลังขึ้นระบบใช้งานจริง
หากบริษัทกำลังจะลงทะเบียน e-Tax invoicing เป็นครั้งแรก ควรเริ่มการลงทะเบียนกับกรมสรรพากรและการเลือกผู้ให้บริการไปพร้อมกับการตั้งค่า Odoo ไม่ใช่ทำทีหลัง สองไทม์ไลน์นี้มักไม่ลงตัวกันเองโดยธรรมชาติ การปล่อยเรื่องคุยกับผู้ให้บริการไว้ท้ายสุดเป็นสาเหตุที่พบบ่อยที่สุด ที่ทำให้การขึ้นระบบใช้งานจริงล่าช้าจากประสบการณ์ที่เราเคยเห็นมา
