localization ในที่นี้หมายถึงฟังก์ชันของระบบ ไม่ใช่ภาษาที่แสดงบนหน้าจอ ทั้งสองเรื่องเป็นคนละงานกันและมีเงื่อนไขคนละชุด บทความนี้พูดเฉพาะเรื่องแรก
สถานะของประเทศไทยตามเอกสาร Microsoft
Microsoft เผยแพร่ตารางที่ระบุว่าแต่ละประเทศใช้ base app ตัวไหน และใครเป็นผู้จัดทำ localization แถวของประเทศไทยระบุค่าไว้ดังนี้
| Country/region | Localized by | Base app | Availability | Azure geography |
|---|---|---|---|---|
| Thailand | Partner | W1 | Available | Asia Pacific |
อ่านค่าทีละช่อง Localized by = Partner หมายความว่า Microsoft ไม่ได้เป็นผู้จัดทำ localization ให้ประเทศไทย ต่างจากประเทศอย่างสหรัฐอเมริกา เยอรมนี อิตาลี หรือออสเตรเลีย ที่ช่องนี้ระบุว่า Microsoft
Base app = W1 หมายความว่าไทยไม่มี base app เฉพาะประเทศ ระบบที่ใช้งานในไทยคือตัว international ส่วน Availability = Available คือใช้งานได้จริงแล้ว ไม่ใช่สถานะที่อยู่ระหว่างวางแผน
เอกสารอธิบายกลไกนี้ไว้ว่า ในประเทศที่ Microsoft ไม่ได้จัดทำ localization ให้ partner สามารถสร้าง localization app เผยแพร่บน Marketplace ได้ โดยสร้างอยู่บนเวอร์ชัน international (W1) และระบุเพิ่มว่าบางประเทศมี partner มากกว่าหนึ่งราย และ localization ของรายหนึ่งอาจประกอบด้วย app มากกว่าหนึ่งตัว
เมื่อฟังก์ชันที่ตอบข้อกำหนดของไทยไม่ได้มากับตัวผลิตภัณฑ์ คำถามที่ตามมาจึงไม่ใช่แค่เรื่องเทคนิค แต่คือเมื่อกฎหมายไทยเปลี่ยน ใครคือผู้ที่ต้องแก้ระบบ ในกรณีของไทยคำตอบคือ partner ไม่ใช่ Microsoft ข้อนี้ควรถูกถามตั้งแต่ตอนเลือกผู้ใช้งานร่วม ไม่ใช่ตอนที่ประกาศฉบับใหม่ออกมาแล้ว
Microsoft แบ่ง localization เป็นสามหมวด
ในเอกสารสำหรับผู้พัฒนา localization solution Microsoft ระบุว่า localization app ประกอบด้วยฟังก์ชันที่ตอบข้อกำหนดท้องถิ่นซึ่งจัดอยู่ในหมวดใดหมวดหนึ่งต่อไปนี้ และแนะนำให้แยก app ตามหมวดเหล่านี้เป็นอย่างน้อย
| หมวด | นิยามตามเอกสาร |
|---|---|
| Regulatory requirements | ฟังก์ชันที่ช่วยให้ธุรกิจทำตามข้อกำหนดทางกฎหมาย เช่น การรายงานภาษี local GAAP และข้อกำหนดตามกฎระเบียบอื่น |
| National standards requirements | ฟังก์ชันที่ตอบมาตรฐานท้องถิ่น เช่น รูปแบบธนาคารและการชำระเงิน รูปแบบที่อยู่ หรือการตีความมาตรฐานสากลในแบบท้องถิ่น |
| Market requirements | ฟังก์ชันที่เป็น nice-to-have และเป็นความสามารถเชิงแข่งขัน ช่วยให้กระบวนการทำงานมีประสิทธิภาพขึ้น แต่ไม่ได้ถูกบังคับจากมุมของกฎระเบียบ |
จุดที่ควรสังเกตคือเส้นแบ่งระหว่างหมวดเหล่านี้คือแหล่งที่มาของข้อบังคับ ไม่ใช่ความสำคัญ ความยากในการพัฒนา หรือจำนวนคนที่ต้องใช้ ผลก็คือฟังก์ชันที่ธุรกิจแทบทุกรายในประเทศต้องใช้ ก็ยังอาจไม่ได้อยู่ในหมวด regulatory
จำแนกงานของไทยลงในสามหมวด
ตารางนี้เป็นการจำแนกของผู้เขียน โดยใช้นิยามของ Microsoft ข้างต้นเป็นเกณฑ์
| งาน | หมวด | เหตุผลที่จัดลงหมวดนี้ |
|---|---|---|
| VAT และโครงสร้างสาขาภาษี | Regulatory | มาจากประมวลรัษฎากร เป็นข้อกำหนดทางกฎหมายโดยตรง |
| รายงานภาษีซื้อและภาษีขาย | Regulatory | เป็นรายงานตามข้อบังคับ ทั้งรายการที่ต้องแสดงและการแยกตามสาขาอ้างอิงข้อกำหนด |
| ใบกำกับภาษี | Regulatory | ทั้งหน้าที่ออก รายการที่ต้องมี และจังหวะที่ต้องออก กำหนดไว้ตามกฎหมาย |
| WHT หนังสือรับรอง 50 ทวิ และ ภ.ง.ด. | Regulatory | หน้าที่หักภาษีและออกหนังสือรับรองกำหนดไว้ตามกฎหมาย |
| ใบวางบิล | National standards | ไม่ใช่ข้อกำหนดทางกฎหมาย แต่เป็นวิธีปฏิบัติทางการค้าที่ใช้กันทั้งประเทศ |
บทความนี้ยังไม่ครอบคลุมงานในหมวด market requirements ซึ่งเป็นกลุ่มที่ช่วยให้ทำงานสะดวกขึ้นแต่ไม่ได้ถูกบังคับ รวมถึงรายงานที่ธุรกิจไทยใช้กันแต่ไม่ได้เป็นแบบยื่นตามกฎหมาย
VAT และสาขาภาษี
ประเด็นที่ทำให้ VAT ของไทยไม่ตรงกับ framework กลางโดยตรง คือธุรกิจที่จดทะเบียนหลายสาขาต้องแยกข้อมูลภาษีตามสาขา ในบริบทนี้สาขาไม่ได้เป็นเพียงที่อยู่สำหรับจัดส่งสินค้า แต่เป็นหน่วยที่ผูกกับการจดทะเบียนและการยื่นแบบ
ในระดับภาพรวม ระบบจึงต้องระบุสาขาบนเอกสารที่เกี่ยวกับภาษีได้ แยกลำดับเลขที่เอกสารตามสาขา และรวบรวมข้อมูลเพื่อยื่นแบบโดยแยกตามสาขา
อีกส่วนที่อยู่ในหมวดเดียวกันคือรายงานภาษีซื้อและรายงานภาษีขาย ซึ่งเป็นรายงานที่ต้องจัดทำตามข้อบังคับ ไม่ใช่รายงานเพื่อการบริหารที่ออกแบบได้ตามใจ ทั้งรายการที่ต้องแสดง ลำดับการเรียง และการแยกตามสาขา ล้วนอ้างอิงข้อกำหนด
ข้อสังเกตในทางปฏิบัติคือ รายงานสองตัวนี้เป็นจุดที่ความผิดพลาดจากการตั้งค่าจะแสดงตัวออกมา หากใบกำกับภาษีถูกออกโดยผูกสาขาผิด หรือกลุ่มภาษีถูกกำหนดไม่ตรงกับลักษณะรายการ ตัวเลขจะไปโผล่ผิดช่องในรายงานนี้ก่อนที่จะกลายเป็นปัญหาตอนยื่นแบบ
ใบกำกับภาษี
ใบกำกับภาษีเป็นงานที่อยู่ในหมวด regulatory เต็มตัว เพราะทั้งหน้าที่ในการออก รายการที่เอกสารต้องมี และจังหวะที่ต้องออก ถูกกำหนดไว้ตามกฎหมาย ไม่ใช่เรื่องที่ตกลงกับคู่ค้าได้เอง
สิ่งที่ทำให้เรื่องนี้เป็นงาน localization ไม่ใช่แค่การจัดหน้าเอกสาร คือเอกสารต้องผูกกลับไปยังรายการบัญชีที่เป็นต้นทาง ต้องสอดคล้องกับสาขาที่ออก และต้องอยู่ในลำดับเลขที่ที่ตรวจสอบย้อนหลังได้ เมื่อมีการยกเลิกหรือแก้ไขรายการ ระบบต้องแสดงความสัมพันธ์ระหว่างเอกสารเดิมกับเอกสารที่ออกใหม่ได้ด้วย
เนื่องจากรายละเอียดของรายการที่ต้องมี รูปแบบ และเงื่อนไขของแต่ละประเภทเอกสารอ้างอิงกับประมวลรัษฎากรและประกาศที่เกี่ยวข้อง จึงควรให้ผู้รับผิดชอบด้านภาษีตรวจและอนุมัติรูปแบบเอกสารกับตารางตั้งค่าก่อนใช้งานจริง เช่นเดียวกับการตั้งค่า VAT และสาขา
ภาษีหัก ณ ที่จ่าย
Business Central มาตรฐานไม่ครอบคลุมกระบวนการภาษีหัก ณ ที่จ่ายของไทยทั้งสาย ฟังก์ชันที่ต้องเพิ่มคือการออกหนังสือรับรอง 50 ทวิ จากรายการจ่ายจริง การรวบรวมรายการตามงวดเพื่อจัดทำ ภ.ง.ด. และการเตรียมไฟล์สำหรับโอนย้ายเข้า RD Prep
งานกลุ่มนี้อยู่ในหมวด regulatory เต็มตัว เพราะทั้งหน้าที่หักภาษี กำหนดเวลาออกหนังสือรับรอง และรูปแบบข้อมูลที่ยื่น ล้วนกำหนดไว้ตามกฎหมายและประกาศของกรมสรรพากร
รายละเอียดของกระบวนการนี้อยู่ในบทความ ออก 50 ทวิ และเตรียมไฟล์ RD Prep จาก Business Central โดยไม่คีย์ซ้ำ
ใบวางบิล และความหมายของหมวด national standards
ใบวางบิลเป็นตัวอย่างที่ชัดที่สุดของหมวด national standards ในบริบทไทย ไม่มีกฎหมายกำหนดให้ต้องมีเอกสารนี้ แต่ธุรกิจไทยจำนวนมากใช้รอบวางบิลเป็นส่วนหนึ่งของเงื่อนไขการชำระเงิน และคู่ค้าจำนวนไม่น้อยรับชำระเฉพาะเอกสารที่ผ่านรอบวางบิลที่ตกลงกันไว้
เมื่อนำนิยามของ Microsoft มาใช้ จะอธิบายได้ทันทีว่าทำไมระบบมาตรฐานถึงไม่มีฟังก์ชันนี้ เพราะมันไม่ใช่ข้อกำหนดสากล และไม่ใช่ข้อกำหนดทางกฎหมายของประเทศใดประเทศหนึ่ง มันคือมาตรฐานทางการค้าที่เกิดจากวิธีทำงานร่วมกันในตลาด
ข้อสังเกตที่ตามมาคือ การที่ฟังก์ชันหนึ่งไม่ได้อยู่ในหมวด regulatory ไม่ได้แปลว่าไม่จำเป็น ในทางปฏิบัติงานที่กระทบการรับเงินมักถูกจัดลำดับความสำคัญสูงกว่างานที่กระทบการยื่นแบบด้วยซ้ำ
รายละเอียดอยู่ในบทความ ใบวางบิลและวันวางบิล: ช่องว่างของ Business Central มาตรฐาน
คำแนะนำเรื่องการแบ่ง app
เอกสารไม่ได้หยุดอยู่ที่การแบ่งหมวด แต่ให้คำแนะนำต่อว่าควรจัดโครงสร้าง app อย่างไร สามข้อที่ตรงกับบริบทไทยมากที่สุดคือ
- แยกตามความถี่ของการเปลี่ยนแปลง ถ้าฟีเจอร์หนึ่งมีทั้งส่วนที่นิ่งและส่วนที่ต้องแก้ตามกฎระเบียบอยู่เรื่อย ๆ เอกสารแนะนำให้แยกสองส่วนนั้นออกจากกัน เหตุผลที่ให้ไว้คือทดสอบได้ทั่วถึงกว่า แก้ตามกฎใหม่ได้เร็วกว่า และเจอปัญหาตอน upgrade น้อยกว่า
- ต่อยอดจาก framework ที่มีอยู่แล้ว เช่น VAT reports รูปแบบธนาคาร และ data exchange แทนที่จะเขียนขึ้นใหม่ทั้งชุด เพราะโครงส่วนใหญ่เป็นของกลางอยู่แล้ว สิ่งที่ต่างกันจริง ๆ คือกฎท้องถิ่นที่มาต่อบนกรอบเหล่านั้น
- ตั้งค่า DataClassification ให้ครบ app ที่ยังมี field ค้างไว้เป็น
ToBeClassifiedจะไม่ผ่านการตรวจสอบตอนส่งขึ้น Marketplace
ข้อแรกใช้กับไทยได้ตรงที่สุด เอกสารไม่ได้พูดถึงประเทศไทย ส่วนต่อไปนี้จึงเป็นการนำเกณฑ์ที่เอกสารให้ไว้มาใช้กับความถี่ของการเปลี่ยนแปลงที่สังเกตได้จริง โครงสร้างสาขาภาษีและหลักการคำนวณ VAT แทบไม่ขยับ ในขณะที่รูปแบบไฟล์สำหรับยื่นและรายละเอียดของแบบ ปรับตามประกาศอยู่เป็นระยะ เมื่อสองอย่างนี้เปลี่ยนคนละจังหวะกัน การมัดรวมไว้ใน app เดียวจึงแปลว่าทุกครั้งที่แบบยื่นเปลี่ยน ต้องปล่อยเวอร์ชันใหม่ที่กระทบส่วนที่ไม่ได้เปลี่ยนไปด้วย
สรุป
Localization ไม่ใช่คำกว้าง ๆ ที่ตีความได้ตามใจ Microsoft ให้เกณฑ์แบ่งไว้สามหมวดตามแหล่งที่มาของข้อบังคับ และให้คำแนะนำเรื่องการแยก app ตามหมวดและตามความถี่ของการเปลี่ยนแปลง
สำหรับประเทศไทย เอกสารระบุสถานะไว้ชัดเจนว่าเป็น Partner บน base app W1 ซึ่งหมายความว่าฟังก์ชันที่ตอบข้อกำหนดของไทยทั้งหมดอยู่ในรูปของ app ที่ต้องมีผู้ดูแลต่อเนื่อง
ประโยชน์ในทางปฏิบัติของการรู้เกณฑ์นี้ คือมันเปลี่ยนคำถามตอนคุยขอบเขตโปรเจกต์ จากคำถามว่าฟังก์ชันนี้จำเป็นหรือไม่ ซึ่งตอบยากและขึ้นกับความเห็น ไปเป็นคำถามว่าฟังก์ชันนี้อยู่หมวดไหน ซึ่งตอบได้จากการดูว่าข้อบังคับมาจากที่ใด และคำตอบนั้นบอกต่อได้ด้วยว่าใครควรเป็นผู้ตัดสินใจ
อ้างอิง: Microsoft Learn: Development of a Localization Solution (14 เมษายน 2025) และ Microsoft Learn: Country/Regional Availability (12 กุมภาพันธ์ 2026)
กำลังประเมินว่าต้องทำ localization แค่ไหน?
นัดคุยเพื่อไล่ดูงานที่ธุรกิจของคุณต้องใช้ และแยกว่าอันไหนเป็นข้อกำหนดตามกฎหมาย อันไหนเป็นมาตรฐานทางการค้า
ปรึกษาเรื่องขอบเขตงาน →