เดินทางมาถึง ตอนที่ 14 กันแล้ว! ในตอนที่แล้ว (Ep.13) เราเปรียบ Odoo เป็นเหมือน “ตัวต่อเลโก้” ที่แยกส่วนประกอบได้ แต่พี่น้องครับ… เลโก้ที่ผลิตจากเมืองนอก บางทีรูปทรงมันอาจจะเหลี่ยมจัดเกินไป ไม่เข้ากับ “ช่องว่าง” ของระเบียบราชการไทยที่มีความโค้งมนซับซ้อน
วันนี้เราจะมาคุยกันเรื่อง “Customization” หรือการ “เฉือน ปรับ ดัด” เจ้าซอฟต์แวร์ฝรั่งตัวนี้ ให้เข้าใจคำว่า “ปีงบประมาณ”, “ฎีกาเบิกเงิน” และ “ขออนุมัติหลักการ” แบบไทยๆ กันครับ มันทำได้จริงหรือ? แล้วต้องระวังอะไรบ้าง? มาหาคำตอบกันครับ
ส่วนที่ 2: รู้จัก Odoo และ Digital Governance (The Tools & Rules)
จุดประสงค์: ทำความเข้าใจเครื่องมือและหลักธรรมาภิบาลข้อมูล
ตอนที่ 14/80: ความสามารถในการปรับแต่ง (Customization) เพื่อรองรับระเบียบราชการไทย
Odoo เวอร์ชันต้นฉบับ (Standard) ถูกสร้างมาด้วยตรรกะธุรกิจสากล (ซื้อมา-ขายไป-กำไร) แต่ระบบราชการไทยขับเคลื่อนด้วย “ระเบียบและงบประมาณ” ความท้าทายคือการจูนสองสิ่งนี้ให้ตรงกันครับ
1. ภารกิจ “แปลงสัญชาติ” ซอฟต์แวร์ (Localization)
- ปีงบประมาณ (Fiscal Year): ชาวโลกเริ่มปีใหม่เดือนมกราคม แต่ราชการไทยเริ่มเดือน “ตุลาคม” เราสามารถตั้งค่าใน Odoo ให้ตัดรอบบัญชีตามแบบไทยเป๊ะๆ ได้ เพื่อให้รายงานงบประมาณตรงกับความเป็นจริง
- ตัวเลขและตัวอักษร (Thai Baht Text): เอกสารการเงินไทยขาดไม่ได้คือคำว่า (หนึ่งพันบาทถ้วน) ในวงเล็บ Odoo เดิมทำไม่ได้ แต่เราสามารถเขียนโค้ดเพิ่ม (Python Script) ให้ระบบแปลงตัวเลขเป็นตัวหนังสือภาษาไทยอัตโนมัติในทุกบิล
- แบบฟอร์มราชการ (Official Forms): หน้าจอทำงานอาจดูอินเตอร์ แต่เวลาสั่งพิมพ์ (Print) เราสามารถ Custom ให้ระบบจัดหน้ากระดาษลงล็อกแบบฟอร์ม “ใบเบิกพัสดุ (พ.ด.)” หรือ “หนังสือราชการ (ตราครุฑ)” ได้พอดิบพอดี โดยไม่ต้องมานั่งจัดหน้าใหม่ใน Word
2. ตัวอย่างเหตุการณ์จริง: การจัดซื้อแบบ “ไทยสไตล์”
- Standard Odoo: กดสั่งซื้อ -> ของส่งมา -> จ่ายเงิน (จบ)
- Thai Government: ขออนุมัติหลักการ -> สืบราคา -> คณะกรรมการตรวจรับ -> วางฎีกา -> หักภาษี ณ ที่จ่าย -> ออกหนังสือรับรอง -> จ่ายเงิน
- Customization: ทีมพัฒนา สามารถสร้าง “Workflow” แทรกขั้นตอนเหล่านี้เข้าไปใน Odoo ได้ ทำให้สถานะเอกสารเปลี่ยนจาก “Draft” เป็น “รอตรวจรับ” และ “รออนุมัติฎีกา” ตามลำดับขั้นของ ทร.
3. ข้อจำกัดที่ต้องระวัง (The Red Zone)
- อย่าแก้ Core System: เปรียบเหมือนรถยนต์ เราแต่งสเกิร์ต (Add-on) ได้ แต่อย่าไปผ่าเครื่องยนต์ (Core Code) เพราะถ้าวันหนึ่ง Odoo ออกรุ่นใหม่ เครื่องยนต์ที่เราผ่าไว้อาจจะพัง หรืออัปเกรดไม่ได้
- ตรรกะวิบัติ (Logic Conflict): บางระเบียบของไทยมีความซับซ้อนจนคอมพิวเตอร์งง เช่น การกันเงินเหลื่อมปีที่มีเงื่อนไขซ้อนเงื่อนไข การเขียนโค้ดส่วนนี้ต้องใช้ความระมัดระวังสูงมาก
4. ข้อแนะนำ (Recommendations)
- เน้นแก้ที่ “รายงาน” (Output) มากกว่า “กระบวนการ” (Process): พยายามปรับกระบวนการทำงานของคนให้เข้ากับมาตรฐานสากลของ Odoo ให้มากที่สุด แล้วค่อยไป Custom หน้าตารายงานให้เป็นแบบไทย วิธีนี้จะทำให้ระบบเสถียรกว่า
- Thai Localization Module: ควรสร้าง Module กลางที่เป็น “มาตรฐาน ทร.” ชุดเดียว (เช่น ชุดคำนวณภาษีหัก ณ ที่จ่าย) แล้วแจกจ่ายให้ทุกหน่วยใช้เหมือนกัน อย่าให้แต่ละหน่วยไปเขียนสูตรคำนวณภาษีกันเอง
บทสรุป
ความสามารถในการ Customization คือไม้ตายก้นหีบที่ทำให้ Odoo เหนือกว่าซอฟต์แวร์สำเร็จรูปทั่วไป เพราะมันอนุญาตให้เรานำ “ระเบียบราชการ” ที่เป็นตัวหนังสือ มาแปลงเป็น “โค้ดคอมพิวเตอร์” ได้
แม้การปรับแต่งจะมีความยากและท้าทาย แต่ผลลัพธ์คือเราจะได้ระบบที่ “คิดแบบสากล แต่ปฏิบัติแบบไทย” ช่วยลดภาระงานเอกสารที่ซ้ำซ้อน และทำให้ระเบียบที่ดูยุ่งยากกลายเป็นเรื่องอัตโนมัติครับ
(อ้างอิง: คู่มือการพัฒนา Odoo สำหรับนักพัฒนา และ ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างฯ)
คำถามชวนคิด
- เอกสารใบไหนในหน่วยงานของท่าน ที่ท่านคิดว่า “จัดหน้ายากที่สุด” และอยากให้ระบบพิมพ์ให้อัตโนมัติ?
- ท่านเคยเจอปัญหาใช้โปรแกรมฝรั่ง แล้วมันไม่รู้จัก “ปี พ.ศ.” จนคำนวณวันเกษียณอายุผิดพลาดหรือไม่?
- ท่านเห็นด้วยหรือไม่? ถ้าระบบจะบังคับให้ทำตามขั้นตอน 1-2-3-4 ห้ามข้ามขั้น เพื่อให้ถูกต้องตามระเบียบ 100% (แม้จะช้าลงนิดหน่อย)
ติดตามตอนต่อไป
เมื่อระบบพร้อม กฎพร้อม แต่ยังมีอีกเรื่องที่หลายคนกังวล คือ “ความปลอดภัย” ในโลก Open Source ที่ใครๆ ก็เห็นโค้ด มันจะปลอดภัยจริงหรือ? ในตอนหน้า Ep.15/80 “Security in Open Source: ลบภาพจำผิดๆ เรื่องความปลอดภัยของข้อมูล” เราจะมาทลายความเชื่อเดิมๆ และพิสูจน์ให้เห็นว่า ทำไมทำเนียบขาวและ NASA ถึงกล้าใช้ Open Source! ห้ามพลาดครับ
Talk is cheap. Show me the code.