การตรวจสอบเลขภาษีเป็นงานที่ดูเรียบง่ายในตอนแรก แต่พอลงมือทำจริงกลับมีคำถามตามมาทันทีว่าตรวจแค่ไหนจึงจะพอ บทความนี้จะพาคุณไล่ดูระดับการตรวจสอบที่มีให้ใช้จริง อธิบายว่าอะไรที่การตรวจแต่ละระดับทำได้และทำไม่ได้ พร้อมข้อผิดพลาดที่พบบ่อยในระบบจริง
การตรวจสอบเลขภาษีทำได้ถึงระดับไหน?
เลขประจำตัวผู้เสียภาษีเป็นหมายเลขที่หน่วยงานจัดเก็บภาษีออกให้กับผู้มีหน้าที่เสียภาษี ซึ่งรวมถึงบุคคลและนิติบุคคล การเรียกชื่อและโครงสร้างของหมายเลขนี้แตกต่างกันไปในแต่ละประเทศ บางแห่งเรียกรวมกับเลขทะเบียน บางแห่งแยกเป็นหมายเลขเฉพาะทาง
ระดับการตรวจสอบที่หนึ่งคือตรวจว่าข้อความที่กรอกมีรูปแบบตรงกับที่คาดไว้หรือไม่ ระดับนี้ทำงานในเครื่อง เร็ว และบอกผู้ใช้ได้ทันทีว่าน่าจะพิมพ์ผิด ระดับที่สองคือตรวจอักขระท้ายหมายเลขในกรณีที่ประเทศนั้นออกแบบมาให้มีการคำนวณได้ ระดับนี้จับข้อผิดพลาดได้ลึกขึ้นแต่ใช้ได้เฉพาะบางประเทศ
ระดับที่สามคือถามหน่วยงานต้นทางหรือบริการที่เชื่อถือได้ว่าเลขนี้มีอยู่จริงในทะเบียนหรือไม่ ระดับนี้ให้คำตอบที่หนักแน่นที่สุด แต่ช้ากว่า ต้องพึ่งเครือข่าย และมีค่าใช้จ่ายในบางกรณี การออกแบบระบบที่ดีคือใช้ทั้งสามระดับร่วมกัน โดยให้แต่ละระดับทำงานในจังหวะที่ต่างกัน
เลขภาษีที่มีหลักตรวจสอบกับที่ไม่มี ต่างกันอย่างไร?
ความต่างอยู่ที่ว่าเราสามารถจับข้อผิดพลาดได้เองโดยไม่ต้องถามใครหรือไม่ ถ้าหมายเลขถูกออกแบบให้อักขระตัวท้ายคำนวณจากตัวอื่นได้ ระบบก็ตรวจได้ทันทีว่าชุดที่กรอกนั้นเป็นไปได้หรือไม่ ซึ่งช่วยกันความผิดพลาดจากการคัดลอกหรือพิมพ์ตกหล่นได้ดี
แต่มีหมายเลขจำนวนมากที่ไม่ได้ออกแบบเช่นนั้น มันเป็นเพียงหมายเลขที่หน่วยงานเดินเรื่องเรียงตามลำดับที่รับมา ไม่มีความสัมพันธ์ทางคณิตศาสตร์ระหว่างตัวอักษรแต่ละตัวให้ตรวจ ระบบจึงไม่สามารถแยกได้เลยว่าเลขที่ดูปกติหนึ่งชุดนั้นมีอยู่จริงหรือเป็นเลขที่แต่งขึ้น
ข้อสรุปที่ควรจำคือ ไม่มีวิธีใดที่ใช้ได้กับทุกประเทศ ระบบที่ไม่รู้ว่าประเทศไหนมีหลักตรวจสอบจึงควรมีค่าตั้งต้นที่ยอมรับแบบกว้างไว้ก่อน แล้วค่อยเพิ่มกติกาเฉพาะประเทศเมื่อมีข้อมูลที่ตรวจสอบได้ ไม่ใช่ปฏิเสธทุกอย่างที่ตัวเองยังไม่รู้จัก
ทำไมรูปแบบถูกต้องจึงยังไม่ยืนยันว่ามีอยู่จริง?
เพราะรูปแบบบอกได้แค่ว่าหมายเลขนั้นถูกออกแบบให้มีหน้าตาอย่างไร ไม่ได้บอกว่าใครถือครองอยู่ หรือยังใช้งานได้หรือไม่ บริษัทที่ปิดกิจการไปแล้วยังมีหมายเลขที่หน้าตาถูกต้องเสมอ และหมายเลขของบริษัทที่ยังดำเนินกิจการก็อาจถูกพิมพ์ผิดแล้วบังเอิญไปตรงกับของบริษัทที่ปิดไปแล้ว
ความเข้าใจผิดข้อนี้สร้างปัญหาในสองทิศทาง ทางหนึ่งคือผู้ใช้ที่กรอกถูกต้องถูกปฏิเสธเพราะระบบตรวจรูปแบบเข้มเกินไป อีกทางหนึ่งคือผู้ใช้ที่กรอกเลขมั่วผ่านด่านรูปแบบได้ แล้วถูกบันทึกเข้าระบบในฐานะข้อมูลที่ตรวจแล้ว ทั้งสองทางล้วนทำให้ข้อมูลในระบบเสื่อมคุณภาพ
คำถามที่ระบบควรตอบให้ได้จึงไม่ใช่ แค่ รูปแบบถูกหรือไม่ แต่ควรตอบให้ได้ว่า หมายเลขนี้ตรวจแล้วพบในทะเบียน หรือ ยังไม่ได้ตรวจสอบกับต้นทาง การแยกสองสถานะนี้ให้ชัดตั้งแต่ในโครงสร้างข้อมูลจะช่วยลดความเข้าใจผิดของผู้ใช้ปลายทางได้มาก
ลำดับการตรวจสอบที่แนะนำ
ลำดับที่ทำงานได้ดีในทางปฏิบัติมีสามขั้น และแต่ละขั้นมีหน้าที่ของตัวเองชัดเจน
- ขั้นแรก ตรวจว่ากรอกครบและไม่มีอักขระต้องห้าม พร้อมตัดช่องว่างและเครื่องหมายคั่นส่วนเกินออกก่อนเทียบ
- ขั้นที่สอง ตรวจความสอดคล้องกับประเทศที่เลือก เช่น ตรวจรหัสประเทศนำหน้าหรืออักขระตรวจสอบเมื่อมีข้อมูลเพียงพอ
- ขั้นที่สาม ถามหน่วยงานต้นทางหรือบริการที่เชื่อถือได้ แล้วบันทึกผลพร้อมวันที่ตรวจไว้กับรายการนั้น
การเรียงลำดับแบบนี้ทำให้การเรียกเครือข่ายเกิดขึ้นเฉพาะกรณีที่ผ่านสองด่านแรกแล้ว ลดจำนวนการเรียกที่ไม่จำเป็นลงมาก และทำให้เมื่อผลลัพธ์ผิดพลาด เรายังรู้ได้ว่ามันติดที่ด่านใด
ความผิดพลาดที่พบบ่อยในระบบจริง
ความผิดพลาดข้อแรกคือบังคับให้กรอกเลขภาษีทุกกรณี แม้ลูกค้าเป็นบุคคลธรรมดาที่ไม่มีและไม่ต้องมีหมายเลขนี้ ผลคือผู้ใช้กรอกเลขอะไรก็ได้เพื่อให้ผ่านฟอร์ม แล้วข้อมูลปลอมก็ไหลเข้าระบบพร้อมสถานะว่าตรวจสอบแล้ว
ความผิดพลาดข้อที่สองคือตัดช่องว่างและเครื่องหมายคั่นออกแล้วเทียบกับค่าที่เก็บไว้ โดยไม่ได้เก็บค่าเดิมที่ผู้ใช้กรอก ทำให้เมื่อต้องออกเอกสารตามรูปแบบที่หน่วยงานต้นทางกำหนด ระบบไม่เหลือข้อมูลต้นฉบับให้ใช้
ความผิดพลาดข้อที่สามคือตีความผลลัพธ์จากบริการภายนอกแบบรวม ๆ เมื่อบริการตอบว่าไม่พบ ระบบก็แจ้งว่าบริษัทไม่มีอยู่จริง ทั้งที่สาเหตุอาจเป็นความหน่วงของเครือข่ายหรือประเทศนั้นไม่ได้อยู่ในขอบเขตของบริการนั้นเลย
ความผิดพลาดข้อที่สี่คือไม่เก็บประวัติการตรวจ เมื่อมีข้อโต้แย้งภายหลังจึงไม่มีหลักฐานว่าตรวจเมื่อไร ด้วยกติกาของประเทศใด และได้ผลว่าอะไร เรื่องนี้สำคัญพอที่จะออกแบบไว้ตั้งแต่แรกเพราะตามเก็บทีหลังแทบเป็นไปไม่ได้
สำหรับนักพัฒนา: ข้อความแจ้งข้อผิดพลาดต้องอธิบายได้
เมื่อการตรวจสอบล้มเหลว สิ่งที่ผู้ใช้ต้องการรู้ไม่ใช่แค่คำว่าข้อมูลไม่ถูกต้อง แต่ต้องการรู้ว่าผิดตรงไหนและควรทำอย่างไรต่อ ข้อความที่บอกเพียงว่าเลขไม่ถูกต้องจะทำให้ผู้ใช้ที่กรอกถูกต้องวนอยู่กับที่ เพราะเขาไม่รู้ด้วยซ้ำว่าระบบกำลังตรวจเรื่องอะไร
ข้อความที่ดีควรแยกอย่างน้อยสามความหมายให้ชัด คือ รูปแบบไม่ตรงกับประเทศที่เลือก ตรวจสอบกับต้นทางไม่สำเร็จเพราะระบบขัดข้อง และตรวจสอบแล้วไม่พบข้อมูลในทะเบียน สามความหมายนี้ต้องการการแก้ไขที่ต่างกันโดยสิ้นเชิง
อีกเรื่องที่ควรทำคือเก็บรหัสข้อผิดพลาดไว้ในบันทึก ไม่ใช่เก็บแค่ข้อความที่แสดงบนหน้าจอ ข้อความบนหน้าจอเปลี่ยนได้ตามการปรับถ้อยคำ แต่รหัสข้อผิดพลาดช่วยให้ค้นหาสาเหตุย้อนหลังได้ และช่วยให้ทีมสนับสนุนอธิบายให้ลูกค้าฟังได้ตรงประเด็น
สุดท้ายคือเรื่องการตรวจซ้ำเมื่อเกิดข้อขัดข้อง ควรมีนโยบายที่ชัดว่ากรณีใดลองใหม่ได้ กรณีใดต้องส่งต่อให้คนตรวจ และต้องบันทึกว่าครั้งสุดท้ายที่ลองคือเมื่อไร การปล่อยให้ระบบลองใหม่ไม่จำกัดจะทำให้บริการปลายทางมองว่าเราส่งคำขอที่ผิดปกติ
ลองตรวจเลขภาษีของบริษัทตัวอย่าง
ถ้าคุณต้องการทดสอบว่าด่านตรวจสอบของคุณแยกแยะสถานะได้จริง ให้สร้างบริษัทสมมติขึ้นมาสองสามราย แล้วลองกรอกกรณีที่แตกต่างกัน ทั้งกรณีที่ถูกต้องตามรูปแบบ กรณีที่ผิดรูปแบบ และกรณีที่ไม่ตรงกับประเทศที่เลือก สังเกตว่าข้อความที่ระบบตอบกลับสื่อความหมายต่างกันจริงหรือไม่
คุณสามารถเปิดเครื่องมือสร้างข้อมูลบริษัทสำหรับทดสอบเพื่อสร้างบริษัทสมมติพร้อมเลขภาษีและเลข VAT ของประเทศที่เลือกได้ทันที หากต้องการเข้าใจฝั่งภาษีมูลค่าเพิ่มเพิ่มเติม อ่านต่อที่เลข VAT และรูปแบบที่ไม่เหมือนกัน หรือดูรายการตรวจสอบที่ครอบคลุมขั้นตอนรับลูกค้าองค์กรได้ที่เช็กลิสต์การทดสอบ KYB
บทความนี้พูดถึงการตรวจสอบในมุมของงานทดสอบระบบเท่านั้น เลขภาษีและบริษัทที่ยกมาเป็นตัวอย่างสมมติ ไม่ควรนำไปใช้ยื่นแบบ เปิดบัญชี หรือทำธุรกรรมที่มีผลทางกฎหมายใด ๆ