Odoo เป็นระบบที่ออกแบบมาให้ใช้ได้ทั่วโลก ซึ่งเป็นข้อดี แต่ก็แปลว่ามันไม่ได้รู้จักกฎหมายภาษีไทยมาตั้งแต่แรก บทความนี้สรุปสิ่งที่ต้องทำจริงเพื่อให้ Odoo ใช้กับงานบัญชีและภาษีในประเทศไทยได้อย่างถูกต้อง พร้อมชื่อโมดูลและจุดที่โครงการมักพลาด
หมายเหตุสำคัญ บทความนี้เขียนเพื่ออธิบายแนวทางการตั้งค่าระบบ ไม่ใช่คำแนะนำทางกฎหมายหรือทางบัญชี อัตราภาษี เกณฑ์ และกำหนดเวลาเปลี่ยนแปลงได้ตามประกาศของกรมสรรพากรและกระทรวงการคลัง กรุณาตรวจสอบตัวเลขที่เป็นปัจจุบันกับผู้สอบบัญชีหรือที่ปรึกษาภาษีของคุณเสมอก่อนนำไปตั้งค่าจริง
สรุปสั้นสำหรับคนไม่มีเวลาอ่านยาว
งานที่ต้องทำเพิ่มบน Odoo เพื่อให้ใช้กับภาษีไทยได้ มีห้าก้อนใหญ่
| ก้อนงาน | Odoo มาตรฐานให้มาไหม | ความยากโดยประมาณ |
|---|---|---|
| VAT 7% ขาย-ซื้อ | ให้โครงมา ตั้งค่าเพิ่มได้ | ต่ำ |
| รายงานภาษีซื้อ-ภาษีขายตามแบบสรรพากร | ไม่ให้ | กลาง |
| ภาษีหัก ณ ที่จ่าย + 50 ทวิ + ภ.ง.ด.3/53 | ไม่ให้ | สูงที่สุด |
| เอกสารภาษีภาษาไทยตามประกาศสรรพากร | ไม่ให้ | กลาง |
| e-Tax Invoice | ไม่ให้ | กลาง-สูง ขึ้นกับช่องทาง |
ถ้าเริ่มจากศูนย์ งานชุดนี้กินเวลาหลายสัปดาห์ถึงหลักเดือน ทางลัดมีสองทาง คือใช้ชุดโมดูล OCA l10n-thailand เป็นฐาน หรือเริ่มจากระบบที่ทำส่วนนี้ไว้แล้ว
1. ภาษีมูลค่าเพิ่ม (VAT)
โครงสร้างที่ต้องตั้งใน Odoo
Odoo ใช้สองแนวคิดหลักในการจัดการภาษี คือ Tax (account.tax) และ Fiscal Position (account.fiscal.position) สำหรับประเทศไทยคุณต้องมีอย่างน้อยชุดนี้
| รายการภาษี | อัตรา | ใช้กับ |
|---|---|---|
| ภาษีขาย | 7% | ขายสินค้าและบริการในประเทศ |
| ภาษีซื้อ | 7% | ซื้อสินค้าและบริการที่มีใบกำกับภาษี |
| ภาษีขายอัตราศูนย์ | 0% | ส่งออก และบริการที่ใช้ในต่างประเทศ |
| ยกเว้นภาษี | – | สินค้าและบริการที่ได้รับยกเว้นตามกฎหมาย |
| ภาษีซื้อที่ยังไม่ถึงกำหนด | 7% | ตั้งพักไว้ระหว่างรอใบกำกับภาษีตัวจริง |
Fiscal Position คือกลไกที่ทำให้ระบบสลับชุดภาษีอัตโนมัติตามประเภทคู่ค้า เช่น ลูกค้าต่างประเทศให้ใช้อัตราศูนย์โดยไม่ต้องให้พนักงานเลือกเอง จุดนี้สำคัญมากในทางปฏิบัติ เพราะข้อผิดพลาดด้านภาษีเกือบทั้งหมดที่เราเจอมาจากคนเลือกภาษีผิดตอนออกเอกสาร ไม่ได้มาจากระบบคำนวณผิด
กับดักที่พบบ่อยที่สุด: ใบกำกับภาษีซื้อมาช้า
ธุรกิจไทยจำนวนมากบันทึกซื้อในเดือนหนึ่งแต่ได้รับใบกำกับภาษีตัวจริงในเดือนถัดไป ถ้าระบบผูกภาษีซื้อไว้กับวันที่ใบแจ้งหนี้อย่างเดียว รายงานภาษีซื้อจะไม่ตรงกับที่ยื่นจริง
วิธีออกแบบที่ใช้ได้จริงคือแยกบัญชี ภาษีซื้อรอเรียกคืน (undue input VAT) ออกจาก ภาษีซื้อ แล้วย้ายยอดเมื่อได้รับใบกำกับภาษีตัวจริง ซึ่งต้องเตรียมทั้งผังบัญชีและ tax ที่มีสองขา (cash basis ใน Odoo รองรับแนวคิดนี้อยู่แล้ว แต่ต้องตั้งค่าให้ตรงกับวิธีที่ผู้สอบบัญชีของคุณยอมรับ)
รายงานภาษีซื้อ-ภาษีขาย
รายงานภาษีมาตรฐานของ Odoo ไม่ตรงกับรูปแบบที่กรมสรรพากรกำหนด สิ่งที่รายงานไทยต้องมีคือ
- ลำดับที่ ต่อเนื่องภายในเดือน
- วัน เดือน ปี ของใบกำกับภาษี
- เลขที่ใบกำกับภาษี
- ชื่อผู้ขายหรือผู้ซื้อ
- เลขประจำตัวผู้เสียภาษี 13 หลัก
- การระบุสำนักงานใหญ่หรือสาขา
- มูลค่าสินค้าหรือบริการ และจำนวนภาษีมูลค่าเพิ่ม
- ยอดรวมท้ายรายงานที่ตรงกับตัวเลขในแบบ ภ.พ.30
โมดูล OCA ที่ทำส่วนนี้ไว้แล้วคือ l10n_th_account_tax_report ซึ่งออกรายงานภาษีซื้อและภาษีขายในรูปแบบไทย ประหยัดเวลาได้มากเทียบกับการเขียน QWeb report เองตั้งแต่ต้น
2. ภาษีหัก ณ ที่จ่าย (Withholding Tax)
นี่คือส่วนที่ Odoo มาตรฐานขาดมากที่สุดสำหรับประเทศไทย และเป็นก้อนที่ทำให้โครงการล่าช้าบ่อยที่สุดถ้าประเมินต่ำไป
อัตราที่ระบบต้องรองรับ
อัตราด้านล่างเป็นอัตราที่ใช้กันทั่วไปสำหรับผู้จ่ายที่เป็นนิติบุคคล ใช้เป็นโครงในการตั้งค่าระบบได้ แต่ต้องยืนยันกับที่ปรึกษาภาษีของคุณเพราะมีข้อยกเว้นและกรณีเฉพาะจำนวนมาก
| ประเภทเงินได้ | อัตราที่ใช้ทั่วไป | ผู้รับเป็นบุคคลธรรมดา | ผู้รับเป็นนิติบุคคล |
|---|---|---|---|
| ค่าบริการ ค่าจ้างทำของ | 3% | ภ.ง.ด.3 | ภ.ง.ด.53 |
| ค่าวิชาชีพอิสระ | 3% | ภ.ง.ด.3 | ภ.ง.ด.53 |
| ค่าเช่าทรัพย์สิน | 5% | ภ.ง.ด.3 | ภ.ง.ด.53 |
| ค่าโฆษณา | 2% | ภ.ง.ด.3 | ภ.ง.ด.53 |
| ค่าขนส่ง | 1% | ภ.ง.ด.3 | ภ.ง.ด.53 |
| เงินเดือนและค่าจ้าง | ตามอัตราก้าวหน้า | ภ.ง.ด.1 | – |
เกณฑ์การหัก โดยทั่วไปหักเมื่อยอดจ่ายต่อครั้งตั้งแต่ 1,000 บาทขึ้นไป แต่ถ้าเป็นสัญญาต่อเนื่องที่มูลค่ารวมถึงเกณฑ์ ต้องหักแม้แต่ละงวดจะไม่ถึง เช่น ค่าอินเทอร์เน็ตรายเดือนเดือนละ 800 บาทตามสัญญาปีหนึ่ง ก็ต้องหักทุกงวด
ระบบที่ออกแบบดีจึงต้องผูกเกณฑ์การหักไว้ที่ระดับ สัญญาหรือคู่ค้า ไม่ใช่ที่ใบแจ้งหนี้ใบเดียว ซึ่งเป็นจุดที่การพัฒนาแบบเร่งรีบมักทำผิด
ฐานที่ใช้คำนวณ: ก่อน VAT เสมอ
ข้อผิดพลาดอันดับหนึ่งของระบบที่ตั้งค่าใหม่ ๆ คือคำนวณภาษีหัก ณ ที่จ่ายจากยอดรวม VAT
| รายการ | จำนวน |
|---|---|
| ค่าบริการ | 10,000.00 |
| VAT 7% | 700.00 |
| รวมตามใบกำกับภาษี | 10,700.00 |
| หัก ณ ที่จ่าย 3% (คิดจาก 10,000) | −300.00 |
| ยอดจ่ายจริง | 10,400.00 |
ถ้าระบบคำนวณ 3% จาก 10,700 จะได้ 321 บาท ผิดทั้งยอดจ่าย ยอดในหนังสือรับรอง และยอดที่นำส่งสรรพากร แล้วต้องตามแก้ย้อนหลังทั้งเดือน
e-Withholding Tax และเรื่องอัตราที่เปลี่ยนตามช่วงเวลา
มาตรการลดอัตราภาษีหัก ณ ที่จ่ายสำหรับการจ่ายผ่านระบบ e-Withholding Tax เป็นมาตรการชั่วคราวที่ต่ออายุเป็นช่วง ๆ ตามมติคณะรัฐมนตรี อัตราที่ใช้จึงเปลี่ยนได้ตามวันที่จ่ายเงิน และเคยมีทั้งช่วงที่ลดเหลือ 1% และช่วงที่กลับสู่อัตราปกติ
บทเรียนเชิงออกแบบระบบ: อย่า hard-code อัตราภาษีลงไปในโค้ดหรือในฟิลด์เดียวเด็ดขาด ให้ผูกอัตราไว้กับ ช่วงวันที่มีผลบังคับ (effective date) เพื่อให้ระบบเลือกอัตราถูกต้องตามวันที่จ่ายเงินจริง และย้อนดูเอกสารเก่าได้โดยไม่เพี้ยน ระบบที่ไม่ได้ออกแบบเผื่อจุดนี้จะเจ็บทุกครั้งที่มีประกาศใหม่
ก่อนตั้งค่าอัตราจริง ให้ตรวจสอบอัตราและช่วงเวลาที่มีผลบังคับปัจจุบันกับกรมสรรพากรหรือผู้สอบบัญชีของคุณ
สิ่งที่ระบบต้องทำได้ทั้งหมด
- แยก ประเภทเงินได้ ตามที่กฎหมายกำหนด และผูกอัตราให้อัตโนมัติ
- แยกกรณีผู้รับเป็น บุคคลธรรมดา (ภ.ง.ด.3) และ นิติบุคคล (ภ.ง.ด.53)
- ออก หนังสือรับรองการหักภาษี ณ ที่จ่าย (50 ทวิ) พร้อมเลขที่เอกสารเรียงต่อเนื่อง ไม่ซ้ำ ไม่ข้าม
- รองรับการยกเลิกและออกใบแทน โดยเก็บร่องรอยไว้ตรวจสอบได้
- สรุปรายเดือนเป็นรายงานที่ยอดตรงกับแบบยื่น
- บันทึก ภาษีที่เราถูกหัก เป็นสินทรัพย์ พร้อมแนบหลักฐาน 50 ทวิ ที่ได้รับ เพื่อใช้เครดิตตอนสิ้นปี
เคสที่ทำให้การพัฒนายากกว่าที่คิด
ภาษีหัก ณ ที่จ่ายเกิดตอน จ่ายเงิน ไม่ใช่ตอนตั้งหนี้ ระบบจึงต้องผูกการหักเข้ากับรายการชำระเงิน (account.payment) ไม่ใช่ใบแจ้งหนี้ ซึ่งเปิดประตูให้เคสยุ่งยากเหล่านี้
- จ่ายบางส่วน จ่าย 40% ก่อน ที่เหลือจ่ายทีหลัง ต้องหักตามสัดส่วนและออก 50 ทวิ สองใบ หรือใบเดียวตอนจ่ายครบ ขึ้นกับนโยบายที่ตกลงกับผู้สอบบัญชี
- จ่ายรวมหลายใบแจ้งหนี้ในครั้งเดียว ที่มีประเภทเงินได้ต่างกัน เช่น จ่ายค่าเช่ากับค่าบริการให้คู่ค้ารายเดียวกันในเช็คใบเดียว ต้องแตกฐานภาษีตามประเภทและออกหนังสือรับรองที่แสดงแยกบรรทัด โมดูล OCA ที่รองรับเคสนี้คือ
l10n_th_account_tax_multi - หักเงินประกันผลงาน (retention) ที่หักจากยอดก่อนคำนวณภาษี หรือหลัง ขึ้นกับสัญญา
- ตั้งหนี้ข้ามปีแล้วจ่ายปีถัดไป อัตราที่ใช้ต้องอิงวันจ่าย ไม่ใช่วันตั้งหนี้
- จ่ายเป็นเงินตราต่างประเทศ ต้องแปลงเป็นบาทตามอัตราที่กฎหมายกำหนดเพื่อคำนวณภาษี
กำหนดเวลายื่นแบบ
| แบบ | ใช้กับ | กำหนดยื่น |
|---|---|---|
| ภ.ง.ด.1 | เงินเดือน ค่าจ้าง | ภายในวันที่ 7 ของเดือนถัดไป |
| ภ.ง.ด.3 | หัก ณ ที่จ่าย ผู้รับเป็นบุคคลธรรมดา | ภายในวันที่ 7 ของเดือนถัดไป |
| ภ.ง.ด.53 | หัก ณ ที่จ่าย ผู้รับเป็นนิติบุคคล | ภายในวันที่ 7 ของเดือนถัดไป |
| ภ.พ.30 | ภาษีมูลค่าเพิ่ม | ภายในวันที่ 15 ของเดือนถัดไป |
การยื่นผ่านอินเทอร์เน็ตมักได้รับการขยายกำหนดเวลาเพิ่มจากกำหนดปกติ ตามประกาศกระทรวงการคลังที่ออกเป็นช่วง ๆ ให้ตรวจสอบกำหนดของปีปัจจุบันก่อนตั้งค่าการแจ้งเตือนในระบบ และถ้าวันสุดท้ายตรงกับวันหยุดราชการ ยื่นได้ในวันทำการถัดไป
ในทางปฏิบัติ สิ่งที่ช่วยทีมบัญชีได้มากคือตั้ง activity หรือ reminder อัตโนมัติใน Odoo ให้เตือนก่อนกำหนดยื่นสองสามวัน พร้อมลิงก์ตรงไปยังรายงานสรุปของเดือนนั้น เป็นงานเล็กที่ผู้ใช้ชอบมาก
3. เอกสารภาษีภาษาไทย
ชุดเอกสารที่ต้องมี
- ใบกำกับภาษี / ใบส่งของ / ใบแจ้งหนี้ แบบเต็มรูป
- ใบกำกับภาษีอย่างย่อ สำหรับธุรกิจค้าปลีก
- ใบเพิ่มหนี้ และ ใบลดหนี้
- ใบเสร็จรับเงิน
- ใบสำคัญจ่าย และ ใบสำคัญรับ
- หนังสือรับรองการหักภาษี ณ ที่จ่าย (50 ทวิ)
- ใบเสนอราคา / ใบสั่งซื้อ / ใบขอซื้อ ภาษาไทย
ข้อมูลที่ใบกำกับภาษีเต็มรูปต้องมีครบ
ทุกฉบับต้องมีข้อความและข้อมูลครบตามที่ประกาศกรมสรรพากรกำหนด ได้แก่ คำว่า “ใบกำกับภาษี” ที่เห็นชัด ชื่อ ที่อยู่ และเลขประจำตัวผู้เสียภาษีของผู้ขาย ชื่อและที่อยู่ของผู้ซื้อ การระบุ สำนักงานใหญ่ หรือ สาขาที่ เลขที่และวันที่ของเอกสาร รายการสินค้าหรือบริการพร้อมมูลค่า และจำนวนภาษีมูลค่าเพิ่มที่แยกออกจากมูลค่าสินค้าอย่างชัดเจน
สิ่งที่ต้องทำใน Odoo
ต้องออกแบบ QWeb report ใหม่ทั้งชุด ไม่ใช่แค่เปลี่ยนโลโก้ เพราะเทมเพลตมาตรฐานไม่มีช่องสำหรับข้อมูลข้างต้นหลายรายการ พร้อมกับสองเรื่องที่มักถูกลืม
ฟอนต์ไทย เทมเพลต PDF มาตรฐานของ Odoo ไม่ได้ฝังฟอนต์ไทย ทำให้สระและวรรณยุกต์ลอยผิดตำแหน่งหรือกลายเป็นกล่องสี่เหลี่ยม โมดูล l10n_th_fonts ของ OCA แก้ปัญหานี้ให้
จำนวนเงินเป็นตัวอักษรภาษาไทย เอกสารไทยหลายฉบับต้องมีบรรทัด “หนึ่งหมื่นสี่ร้อยบาทถ้วน” ซึ่ง Odoo มาตรฐานเขียนเป็นภาษาอังกฤษ โมดูล l10n_th_amount_to_text จัดการส่วนนี้
ลำดับเลขที่เอกสาร เรื่องเล็กที่กลายเป็นเรื่องใหญ่ตอนถูกตรวจ
เลขที่ใบกำกับภาษีต้องเรียงต่อเนื่อง ไม่ซ้ำ และอธิบายได้ว่าเลขที่หายไปเพราะอะไร สิ่งที่ต้องตั้งใน Odoo คือ
- แยก sequence ตามประเภทเอกสารและตามสาขา
- ล็อกรูปแบบเลขที่ให้มีปีหรือเดือนกำกับตามที่บริษัทใช้ เช่น
INV-2569-08-0001 - ปิดสิทธิ์ผู้ใช้ทั่วไปไม่ให้แก้เลขที่เอกสารด้วยมือ
- ตั้งนโยบายชัดเจนว่าเอกสารที่ยกเลิกจะใช้วิธี “ยกเลิกแล้วออกใหม่” หรือ “ออกใบลดหนี้”
โมดูล l10n_th_base_sequence ช่วยจัดการรูปแบบลำดับเอกสารแบบไทยได้
4. ผังบัญชีและงบการเงิน
ผังบัญชีมาตรฐานที่ Odoo ให้มาเป็นโครงสร้างสากลซึ่งผู้สอบบัญชีไทยอ่านแล้วไม่คุ้น ควรตั้งผังบัญชีใหม่โดยอิงโครงสร้างที่ใช้กันทั่วไปในประเทศไทย และจัดกลุ่มให้ออก งบแสดงฐานะการเงิน และ งบกำไรขาดทุน ตามรูปแบบที่ยื่นกรมพัฒนาธุรกิจการค้าได้
สิ่งที่ควรตั้งตั้งแต่วันแรก ไม่ใช่ไปแก้ทีหลัง
- รอบระยะเวลาบัญชี และวันสิ้นรอบ
- การล็อกงวดที่ปิดแล้ว (Lock Date) เพื่อกันการแก้ย้อนหลังหลังปิดงบ ซึ่งเป็นสาเหตุอันดับต้น ๆ ที่ทำให้ตัวเลขในระบบไม่ตรงกับงบที่ยื่นไปแล้ว
- สิทธิ์ผู้ใช้ ว่าใครแก้เอกสารที่ผ่านการอนุมัติแล้วได้บ้าง
- บัญชีพักสำหรับรายการที่ยังจัดประเภทไม่ได้ พร้อมรอบตรวจสอบประจำเดือน
สำหรับรายงานผู้บริหารที่ต้องดึงข้ามงวดและเทียบงบ โมดูล mis_builder ของ OCA คู่กับ l10n_th_mis_report เป็นทางเลือกที่ทีมบัญชีปรับเองได้โดยไม่ต้องเรียกนักพัฒนาทุกครั้ง
5. ใบกำกับภาษีอิเล็กทรอนิกส์
เทียบสองช่องทาง
| หัวข้อ | e-Tax Invoice by Email | e-Tax Invoice และ e-Receipt |
|---|---|---|
| เหมาะกับ | ผู้ประกอบการรายเล็ก | องค์กรที่มีเอกสารจำนวนมาก |
| เกณฑ์รายได้ | ไม่เกิน 30 ล้านบาทต่อปี | ไม่จำกัด |
| การยื่นคำขอ | แบบ ก.อ.01 | ขออนุมัติกับกรมสรรพากร |
| รูปแบบไฟล์ | PDF/A-3 | XML ตามมาตรฐาน พร้อมลายมือชื่อดิจิทัล |
| วิธีรับรอง | ประทับรับรองเวลาโดย สพธอ. | ใบรับรองอิเล็กทรอนิกส์ |
| นำส่งกรมสรรพากร | ผ่านระบบอีเมลของ สพธอ. | นำส่งข้อมูลตามรอบที่กำหนด |
| ความซับซ้อนในการเชื่อม Odoo | ต่ำ-กลาง | กลาง-สูง มักผ่านผู้ให้บริการ |
สิ่งที่ต้องออกแบบตอนเชื่อมกับ Odoo
ไม่ว่าจะเลือกช่องทางไหน ระบบต้องทำสี่อย่างนี้ให้ครบ ไม่อย่างนั้นทีมบัญชีจะต้องมานั่งไล่เช็กเองทุกสิ้นเดือน
- ส่งอัตโนมัติเมื่อยืนยันใบกำกับภาษี ไม่ใช่ให้คนกดส่งทีละใบ
- เก็บสถานะการนำส่งกลับมาแสดงบนเอกสาร เช่น รอส่ง ส่งสำเร็จ ปฏิเสธ พร้อมข้อความแสดงเหตุผล
- มีคิวและระบบส่งซ้ำอัตโนมัติ เมื่อ API ปลายทางล่มชั่วคราว
- รายงานกระทบยอด ระหว่างจำนวนใบกำกับภาษีในระบบกับจำนวนที่นำส่งสำเร็จในเดือนนั้น
ข้อสี่คือสิ่งที่มักไม่ได้ทำในโครงการที่รีบ แล้วไปรู้ตัวตอนสรรพากรถามว่าทำไมตัวเลขไม่ตรง
รายละเอียดขั้นตอนสมัคร แบบ ก.อ.01 และ บ.อ.01 ใบรับรองอิเล็กทรอนิกส์ และแผนงานทั้งหมด อ่านต่อได้ที่ e-Tax Invoice & e-Receipt ทำยังไง
6. เรื่องเล็กที่ทำให้ผู้ใช้ชอบระบบขึ้นมาก
- ตั้ง วันหยุดราชการไทย ในปฏิทินระบบ เพื่อให้การวางแผนส่งของและงานผลิตแม่นขึ้น
- แสดง ปีพุทธศักราช ในเอกสารที่ต้องใช้ พ.ศ. โดยยังเก็บ ค.ศ. ในฐานข้อมูล
- ตั้งค่า สกุลเงินบาท รูปแบบตัวเลข และการปัดเศษให้ตรงกับที่บัญชีใช้
- ดึง อัตราแลกเปลี่ยนจากธนาคารแห่งประเทศไทย อัตโนมัติด้วย
currency_rate_update_TH_BOTแทนการคีย์มือ - เพิ่ม QR PromptPay บนใบแจ้งหนี้ ช่วยให้ลูกค้าจ่ายเร็วขึ้นอย่างเห็นได้ชัด
- ตั้ง ที่อยู่แบบไทย ให้มีตำบล อำเภอ จังหวัด รหัสไปรษณีย์ ครบตามรูปแบบที่เอกสารราชการใช้ (
l10n_th_partner) - แปลหน้าจอและชื่อฟิลด์เป็นภาษาไทยให้สม่ำเสมอทั้งระบบ ไม่ใช่แปลครึ่งเดียว
7. ชุดโมดูล OCA ที่ใช้เป็นฐานได้
OCA (Odoo Community Association) ดูแล repository ชื่อ l10n-thailand ซึ่งรวมโมดูลไทยที่ทีมงานในไทยช่วยกันพัฒนาและเปิดให้ใช้ฟรีภายใต้ AGPL-3.0
| โมดูล | หน้าที่ |
|---|---|
l10n_th_account_tax |
VAT และภาษีหัก ณ ที่จ่าย |
l10n_th_account_tax_report |
รายงานภาษีซื้อ-ภาษีขายแบบไทย |
l10n_th_account_wht_cert_form |
ฟอร์มหนังสือรับรองหัก ณ ที่จ่าย 50 ทวิ |
l10n_th_account_tax_multi |
หักภาษีเมื่อจ่ายรวมหลายรายการ |
l10n_th_account_tax_expense |
ภาษีในใบเบิกค่าใช้จ่ายพนักงาน |
l10n_th_amount_to_text |
จำนวนเงินเป็นตัวอักษรภาษาไทย |
l10n_th_base_sequence |
รูปแบบลำดับเลขที่เอกสารไทย |
l10n_th_partner |
ที่อยู่และข้อมูลคู่ค้าแบบไทย |
l10n_th_mis_report |
รายงานการเงินแบบไทยบน mis_builder |
currency_rate_update_TH_BOT |
ดึงอัตราแลกเปลี่ยนจาก ธปท. |
ข้อควรรู้ก่อนใช้ โมดูล OCA เป็นฐานที่ดีมาก แต่ไม่ใช่ของสำเร็จรูปที่ติดตั้งแล้วจบ สิ่งที่ต้องเผื่อไว้คือ
- แต่ละ repo ตามเวอร์ชัน Odoo ไม่พร้อมกัน ต้องเช็กว่าเวอร์ชันที่คุณใช้มี branch รองรับหรือยัง
- เอกสารและฟอร์มยังต้องปรับให้ตรงกับรูปแบบที่บริษัทคุณใช้อยู่
- สัญญาอนุญาต AGPL-3.0 มีเงื่อนไขต่างจาก LGPL ควรให้ฝ่ายกฎหมายดูก่อนถ้าคุณจะพัฒนาต่อยอดแล้วนำไปให้บริการภายนอก
- ต้องมีคนดูแลการอัปเดตตามเมื่อ Odoo ออกเวอร์ชันใหม่
8. เช็กลิสต์ก่อน Go-Live ด้านภาษี
พิมพ์ไปใช้ได้เลย ทุกข้อควรมีคนเซ็นรับผิดชอบ ไม่ใช่แค่ติ๊ก
ตั้งค่าพื้นฐาน
- ผังบัญชีไทยตั้งครบ และผู้สอบบัญชีเห็นชอบแล้ว
- รายการภาษีขาย ภาษีซื้อ อัตราศูนย์ และยกเว้น ครบทุกกรณีที่ธุรกิจใช้จริง
- Fiscal Position ผูกกับประเภทคู่ค้าเรียบร้อย ทดสอบสลับอัตโนมัติแล้ว
- เลขประจำตัวผู้เสียภาษีของบริษัทและสาขาถูกต้องทุกจุด
- รอบระยะเวลาบัญชีและ Lock Date ตั้งแล้ว
ภาษีหัก ณ ที่จ่าย
- ประเภทเงินได้และอัตราครบ พร้อมผูกช่วงวันที่มีผลบังคับ
- แยก ภ.ง.ด.3 และ ภ.ง.ด.53 ได้อัตโนมัติจากประเภทคู่ค้า
- ทดสอบเคสจ่ายบางส่วน และจ่ายรวมหลายใบแจ้งหนี้แล้ว
- ฟอร์ม 50 ทวิ พิมพ์ออกมาแล้วให้ฝ่ายบัญชีตรวจจริง ไม่ใช่ดูบนจอ
- ระบบบันทึกภาษีที่เราถูกหักได้ พร้อมที่เก็บหลักฐาน
เอกสาร
- ใบกำกับภาษีเต็มรูปมีข้อมูลครบตามประกาศ ผ่านการตรวจของผู้สอบบัญชี
- ฟอนต์ไทยแสดงถูกต้องบน PDF ทุกเทมเพลต ทดสอบกับสระซ้อนแล้ว
- จำนวนเงินตัวอักษรภาษาไทยถูกต้อง รวมกรณีมีสตางค์
- ลำดับเลขที่เอกสารต่อเนื่อง แยกตามสาขา และผู้ใช้ทั่วไปแก้ไม่ได้
รายงานและการยื่น
- รายงานภาษีซื้อและภาษีขายออกได้ ยอดตรงกับ ภ.พ.30
- รายงานสรุปหัก ณ ที่จ่ายรายเดือนยอดตรงกับแบบยื่น
- ทดลองปิดงบเดือนตัวอย่างเต็มรอบด้วยข้อมูลจริงอย่างน้อยหนึ่งเดือน
- ตั้งการแจ้งเตือนกำหนดยื่นแบบในระบบแล้ว
e-Tax Invoice (ถ้าใช้)
- เลือกช่องทางและได้รับอนุมัติแล้ว
- ทดสอบส่งจริงในระบบทดสอบของผู้ให้บริการ
- มีคิวส่งซ้ำและรายงานกระทบยอดการนำส่ง
ห้าข้อผิดพลาดที่เราเจอบ่อยที่สุด
- คำนวณหัก ณ ที่จ่ายจากยอดรวม VAT แก้ทีหลังแปลว่าต้องออกหนังสือรับรองใหม่ทั้งเดือน
- ผูกการหักภาษีไว้กับใบแจ้งหนี้แทนที่จะเป็นการจ่ายเงิน พอเจอเคสจ่ายบางส่วนก็พังทันที
- ไม่แยกภาษีซื้อรอเรียกคืน ทำให้รายงานภาษีซื้อไม่เคยตรงกับที่ยื่นจริงสักเดือน
- ไม่ตั้ง Lock Date แล้วมีคนแก้เอกสารย้อนหลังหลังปิดงบ ตัวเลขในระบบกับงบที่ยื่นไปแล้วไม่ตรงกัน
- ทดสอบเอกสารบนจอแต่ไม่เคยสั่งพิมพ์จริง ไปเจอฟอนต์เพี้ยนหรือข้อมูลตกหล่นเอาวันแรกที่ใช้งาน
สรุป
Odoo ใช้กับบัญชีไทยได้ดีมาก แต่ไม่ใช่ทันทีที่ติดตั้งเสร็จ งานที่ต้องทำเพิ่มคือระบบภาษีหัก ณ ที่จ่ายที่รองรับเคสจริง รายงานภาษีตามแบบสรรพากร เอกสารภาษาไทยที่ข้อมูลครบตามประกาศ ผังบัญชีที่ผู้สอบบัญชีอ่านได้ และการเชื่อม e-Tax Invoice ซึ่งรวมแล้วเป็นงานหลายสัปดาห์ถึงหลักเดือนถ้าเริ่มจากศูนย์
ทางลัดมีสองทาง ทางแรกคือใช้ชุดโมดูล OCA l10n-thailand เป็นฐานแล้วปรับต่อ ซึ่งประหยัดเวลาได้จริงถ้าทีมของคุณมีนักพัฒนาที่อ่านโค้ด Odoo ได้ ทางที่สองคือเริ่มจากระบบที่ทำส่วนเหล่านี้ไว้และผ่านการใช้งานจริงมาแล้ว
เราจึงพัฒนา OneBiz ERP ขึ้นบนฐาน Odoo โดยเติมความพร้อมด้านภาษีไทยไว้ให้ คุยกับเรา ถ้าอยากดูว่าเอกสารและรายงานหน้าตาเป็นอย่างไรก่อนตัดสินใจ หรืออ่านต่อเรื่อง ค่าใช้จ่ายวางระบบ Odoo ในไทย และ Community กับ Enterprise เลือกแบบไหน
คำถามที่พบบ่อย
Odoo มาตรฐานทำภาษีหัก ณ ที่จ่ายได้เลยไหม?
ไม่ได้ทันทีครับ Odoo มาตรฐานมีระบบภาษีที่ยืดหยุ่นพอจะตั้งค่าให้หักเงินได้ แต่ส่วนที่ขาดคือการจัดประเภทเงินได้ตามกฎหมายไทย การออกหนังสือรับรองการหักภาษี ณ ที่จ่าย (50 ทวิ) และรายงานสรุปสำหรับยื่น ภ.ง.ด.3 / ภ.ง.ด.53 ซึ่งต้องพัฒนาโมดูลเพิ่ม ใช้ชุดโมดูล OCA l10n-thailand หรือใช้ระบบที่ปรับมาให้แล้ว
ต้องใช้ Odoo Enterprise ไหมถึงจะทำบัญชีไทยได้?
ไม่จำเป็นเสมอไป Community ทำได้ถ้าเสริมโมดูลที่เหมาะสม แต่ Enterprise จะช่วยเรื่องการกระทบยอดธนาคารและรายงานงบการเงินได้สะดวกกว่า การเลือกจึงขึ้นกับว่าคุณจะปิดงบเองในระบบหรือส่งให้สำนักงานบัญชี
e-Tax Invoice by Email กับ e-Tax Invoice & e-Receipt ต่างกันอย่างไร?
e-Tax Invoice by Email เป็นช่องทางสำหรับผู้ประกอบการจดทะเบียน VAT ที่มีรายได้ไม่เกิน 30 ล้านบาทต่อปี ยื่นคำขอด้วยแบบ ก.อ.01 ส่งไฟล์ PDF/A-3 ผ่านระบบประทับรับรองเวลาของ สพธอ. ส่วน e-Tax Invoice และ e-Receipt ใช้ใบรับรองอิเล็กทรอนิกส์ลงลายมือชื่อดิจิทัลและนำส่งข้อมูลให้กรมสรรพากร ไม่จำกัดขนาดรายได้ เหมาะกับองค์กรที่มีปริมาณเอกสารมาก
ภาษีหัก ณ ที่จ่าย คำนวณจากยอดรวม VAT หรือยอดก่อน VAT?
คำนวณจากยอดก่อน VAT ครับ นี่เป็นข้อผิดพลาดที่พบบ่อยที่สุดข้อหนึ่งเวลาตั้งค่าระบบใหม่ ถ้าค่าบริการ 10,000 บาท VAT 7% เท่ากับ 700 บาท ภาษีหัก ณ ที่จ่าย 3% จะคำนวณจาก 10,000 ได้ 300 บาท ไม่ใช่จาก 10,700 ยอดที่จ่ายจริงคือ 10,400 บาท
ต้องหักภาษี ณ ที่จ่ายทุกครั้งที่จ่ายเงินไหม?
ไม่ครับ โดยทั่วไปหักเมื่อยอดจ่ายต่อครั้งตั้งแต่ 1,000 บาทขึ้นไป แต่ถ้าเป็นสัญญาต่อเนื่องที่มูลค่ารวมถึงเกณฑ์ ก็ต้องหักแม้แต่ละงวดจะไม่ถึง 1,000 บาท ระบบจึงควรผูกเกณฑ์การหักไว้กับสัญญาหรือคู่ค้า ไม่ใช่กับใบแจ้งหนี้ใบเดียว