วิธีทำไฟล์ PDF/A-3 ให้ e-Tax by Time Stamp ประทับเวลาได้

ไฟล์ที่ส่งให้ e-Tax by Time Stamp ต้องมีครบสี่ส่วน คือหน้าใบกำกับภาษี XML ที่แนบเป็นข้อมูลต้นทาง ข้อมูลกำกับไฟล์ของ ETDA และตัวอักษรไทยที่อ่านออกมาได้ถูก หน้าตรวจของ ETDA ดูแค่ XML จึงต้องมีวิธีตรวจตัว PDF ก่อนส่งด้วย

ในโพสต์นี้ 8 หัวข้อ
  1. ไฟล์หนึ่งไฟล์มีสี่ส่วน
  2. หน้าใบกำกับภาษีบอกว่าออกแบบอิเล็กทรอนิกส์
  3. XML ต้องแนบเป็นข้อมูลต้นทางของหน้านั้น
  4. ข้อมูลกำกับไฟล์บอก ETDA ว่าไฟล์นี้คืออะไร
  5. ภาษาไทยต้องใช้ PDF/A-3 ระดับ U
  6. ตรวจตัว PDF ก่อนส่ง เพราะหน้าตรวจของ ETDA ดูแค่ XML
  7. กรณีที่อาจเจอในงานจริง
  8. เรื่องที่ควรถามทีมพัฒนา

ระบบ e-Tax Invoice by Time Stamp ไม่มี API ให้ต่อ เราส่งอีเมลที่แนบใบกำกับภาษีถึงผู้ซื้อ แล้ว CC ไปที่ ETDA ระบบของ ETDA จะประทับเวลาลงไฟล์แล้วส่งกลับให้ทั้งสองฝ่าย งานทั้งหมดจึงอยู่ที่ไฟล์แนบไฟล์เดียว คู่มือ Time Stamp ของสรรพากร กำหนดไว้สั้น ๆ ว่าไฟล์ต้องเป็น PDF/A-3 ใบกำกับภาษี 1 ใบต่อ 1 ไฟล์ ไม่เกิน 3 MB และห้ามใส่รหัสผ่าน ที่เหลือเป็นรายละเอียดที่ต้องทำให้ถูกเอง ถ้าไฟล์ไม่ตรงข้อกำหนด ETDA ตอบกลับว่าไม่ประทับเวลาให้ และใบกำกับภาษีใบนั้นก็ยังไม่ได้ออกแบบอิเล็กทรอนิกส์

โพสต์นี้เล่าว่าไฟล์นั้นต้องมีอะไรบ้าง และแต่ละส่วนมีไว้ทำไม จากตอนที่เราเชื่อม Time Stamp เข้ากับระบบบัญชีที่ภัทรชัย อาร์ทิซาน ทำขึ้นใช้เอง ถ้ากำลังจะจ้างทำหรือให้ทีมทำเอง ใช้เป็นรายการคุยกับทีมพัฒนาได้

ไฟล์หนึ่งไฟล์มีสี่ส่วน

PDF/A คือ PDF แบบที่เก็บทุกอย่างที่ต้องใช้ไว้ในไฟล์ ทั้งฟอนต์และสี เปิดที่ไหนในอีกสิบปีก็หน้าตาเหมือนเดิม ส่วนเลข 3 คือรุ่นที่แนบไฟล์อื่นไว้ข้างในได้ Time Stamp ใช้ความสามารถนี้แนบข้อมูลใบกำกับภาษีเป็น XML ไว้ในไฟล์เดียวกับหน้าที่คนอ่าน

ไฟล์ PDF/A-3 หนึ่งไฟล์ที่ส่งให้ Time Stamp มีสี่ส่วน

หน้าที่คนอ่าน XML ที่แนบไว้ ข้อมูลกำกับไฟล์ และตัวอักษรที่อ่านออกมาได้ ต้องถูกครบทั้งสี่ส่วน

ส่วน มีไว้ทำไม ถ้าผิด
หน้าใบกำกับภาษี ผู้ซื้อเปิดอ่านและเก็บเป็นหลักฐาน ETDA ไม่ได้ตรวจหน้าตา แต่ผู้ซื้ออาจขอใบใหม่
XML ที่แนบไว้ ข้อมูลที่โปรแกรมอ่านต่อได้ ตรงกับหน้าที่เห็น ไม่ผ่านหน้าตรวจของ ETDA
ข้อมูลกำกับไฟล์ บอกว่า XML ชื่ออะไร เป็นเอกสารประเภทไหน ระบบประทับเวลาไม่รับ
ตัวอักษรอ่านออก ดึงข้อความออกจากไฟล์ได้ตรงกับที่พิมพ์ ระบบประทับเวลาไม่รับ

หน้าใบกำกับภาษีบอกว่าออกแบบอิเล็กทรอนิกส์

หน้าที่ผู้ซื้อเห็นคือใบกำกับภาษีหน้าเดิมที่ระบบพิมพ์อยู่แล้ว เราเพิ่มข้อความหนึ่งบรรทัดใต้เลขหน้าว่าใบนี้จัดทำและส่งข้อมูลให้กรมสรรพากรด้วยวิธีการทางอิเล็กทรอนิกส์ ถ้อยคำนี้เราใช้ตามไฟล์ตัวอย่างที่ผ่านการประทับเวลาจริง เพราะคู่มือไม่ได้ให้ถ้อยคำไว้ชัด

เมื่อใบไหนออกเป็น e-Tax แล้ว ทุกครั้งที่พิมพ์ซ้ำต้องมีบรรทัดนี้ด้วย ผู้ซื้อถือฉบับที่ประทับเวลาซึ่งมีบรรทัดนี้อยู่ ถ้าฉบับที่ฝั่งเราพิมพ์ใหม่ไม่มี ก็จะกลายเป็นเอกสารเดียวกันสองหน้าตา

อีกเรื่องคือขนาด ไฟล์ต้องไม่เกิน 3 MB และใบกำกับภาษี 1 ใบต่อ 1 ไฟล์ รูปตราประทับและลายเซ็นที่อัปโหลดมาความละเอียดสูงเป็นตัวที่ทำให้ไฟล์ใหญ่ ครั้งหนึ่งหน้าเดียวของเราหนักถึง 3.77 MB ก่อนจะย่อรูปตอนอัปโหลด หลังย่อแล้วใบกำกับภาษีหนึ่งหน้าเหลือราว 95 KB ระบบควรหยุดตั้งแต่ตอนสร้างไฟล์ถ้าเกิน 3 MB ดีกว่ารอให้ ETDA ตีกลับในอีกหลายชั่วโมง

XML ต้องแนบเป็นข้อมูลต้นทางของหน้านั้น

PDF ทั่วไปแนบไฟล์ได้อยู่แล้ว แต่ไฟล์ที่แนบธรรมดาไม่ได้บอกว่าเกี่ยวกับหน้าไหน PDF/A-3 มีวิธีแนบอีกแบบที่เรียกว่า associated file ซึ่งบอกได้ว่าไฟล์ที่แนบเป็นอะไรของเอกสาร ใบกำกับภาษีแนบ XML ในฐานะ "ข้อมูลต้นทาง" (Source) ของหน้าที่เห็น โปรแกรมบัญชีของผู้ซื้อที่อ่าน XML ต่อก็รู้ว่าข้อมูลชุดนี้คือใบเดียวกับที่คนอ่าน

ตัว XML เป็นงานอีกก้อน ต้องตรงตามมาตรฐานข้อมูลใบกำกับภาษีของ ETDA และ ETDA มีหน้าตรวจให้อัปโหลดไปลองได้ที่ validation.teda.th ส่วนนี้ผ่านง่ายกว่าที่คิด เพราะมีหน้าตรวจบอกว่าผิดตรงไหน

ข้อมูลกำกับไฟล์บอก ETDA ว่าไฟล์นี้คืออะไร

PDF ทุกไฟล์มีข้อมูลกำกับไฟล์ (XMP) เช่นชื่อเรื่องและโปรแกรมที่สร้าง แนวทางการทำ PDF/A-3 ของ ETDA ขอเพิ่มสามช่องในชุดข้อมูลของ ETDA เอง คือชื่อไฟล์ XML ที่แนบ ประเภทเอกสาร (เช่น Tax Invoice) และเวอร์ชันของ XML ไฟล์ที่ ETDA ประทับเวลาให้เราก็มีสามช่องนี้ คู่มือของสรรพากรไม่ได้ลงรายละเอียดส่วนนี้ ทีมพัฒนาต้องไปอ่านจากแนวทางของ ETDA

ช่องที่เพิ่มเองแบบนี้ PDF/A บังคับให้ประกาศไว้ในไฟล์ด้วยว่ามีช่องอะไรบ้าง และข้อมูลกำกับไฟล์ต้องบอกระดับของ PDF/A ที่ไฟล์อ้างด้วย ถ้าอ้างระดับหนึ่งแต่ไฟล์จริงเป็นอีกระดับ ก็ไม่ผ่าน

แนวทางการทำ PDF/A-3 ของ ETDA เป็นฉบับร่างปี 2018 บางจุดในแนวทางไม่ตรงกับไฟล์ที่ ETDA ประทับเวลาให้จริง เช่นชนิดความสัมพันธ์ของไฟล์แนบ ทางที่ปลอดภัยคือยึดไฟล์ที่ผ่านการประทับเวลาแล้วเป็นตัวอย่าง และเก็บไฟล์นั้นไว้เทียบทุกครั้งที่แก้ระบบ

ภาษาไทยต้องใช้ PDF/A-3 ระดับ U

PDF/A-3 มีหลายระดับ ระดับ B รับประกันแค่ว่าหน้าตาเหมือนเดิม ส่วนระดับ U รับประกันเพิ่มว่าดึงตัวอักษรออกจากไฟล์ได้ถูกทุกตัว คู่มือของสรรพากรบอกแค่ว่าต้องเป็น PDF/A-3 ส่วนแนวทางของ ETDA ขอระดับ U เพื่อให้รองรับอักษรไทย และระบบประทับเวลาตรวจเรื่องนี้จริง ไฟล์ระดับ B ของเราเคยโดนปฏิเสธมาแล้วทั้งที่หน้าตาถูกทุกอย่าง พอเปลี่ยนเป็นระดับ U ใบเดียวกันก็ผ่าน

ภาษาไทยมีจุดที่พลาดง่าย ฟอนต์ไทยหลายตัววาดวรรณยุกต์ไว้สองแบบ แบบปกติกับแบบเล็กที่ใช้วางบนพยัญชนะตัวสูง โปรแกรมที่แปลงหน้าเว็บเป็น PDF อย่าง Chrome มักไม่บอกว่าวรรณยุกต์แบบเล็กคือตัวไหน พอดึงข้อความออกมา คำว่า "เลขที่" จะเหลือ "เลขที" และ "สิทธิ์" เหลือ "สิทธิ" หน้ากระดาษดูถูกต้อง แต่ข้อความข้างในไม่ครบ ระบบต้องซ่อมจุดนี้ก่อนแปลงเป็น PDF/A ถ้าซ่อมไม่ได้ ควรหยุดสร้างไฟล์ไปเลย เพราะเอกสารภาษีที่ข้อความข้างในผิดแย่กว่าไฟล์ที่สร้างไม่สำเร็จ

เรื่องฟอนต์ไทยใน PDF ที่สระลอยหรือวรรณยุกต์ซ้อน เป็นอีกเรื่องที่เขียนไว้ในสร้าง PDF ภาษาไทยใน Laravel ให้ฟอนต์ไม่เพี้ยน

ตรวจตัว PDF ก่อนส่ง เพราะหน้าตรวจของ ETDA ดูแค่ XML

หน้าตรวจที่ validation.teda.th อ่านเฉพาะ XML ที่แนบอยู่ในไฟล์ ไฟล์ที่ผ่านหน้านี้จึงยังโดนระบบประทับเวลาปฏิเสธได้ เพราะระบบประทับเวลาตรวจตัว PDF ด้วย การตรวจก่อนส่งจึงมีสองด่านที่แทนกันไม่ได้

  • ตรวจมาตรฐาน PDF/A ด้วยโปรแกรมตรวจที่เป็นกลางอย่าง veraPDF ซึ่งฟรีและเปิดซอร์ส บอกได้ว่าไฟล์เป็น PDF/A-3U จริงหรือเปล่า แต่ไม่รู้จักข้อกำหนดเฉพาะของ ETDA
  • ตรวจตามข้อกำหนดของ ETDA ว่าไฟล์แนบ ชนิดความสัมพันธ์ และข้อมูลกำกับไฟล์สามช่องอยู่ครบและสะกดตรง ส่วนนี้ไม่มีโปรแกรมสำเร็จรูป ทีมพัฒนาต้องเขียนตรวจเอง

ตอนที่ใบแรกของเราโดนปฏิเสธ มีสี่จุดที่ผิด สองจุดโปรแกรมตรวจ PDF/A เห็น อีกสองจุดเห็นได้จากการตรวจตามข้อกำหนดของ ETDA เท่านั้น ถ้ามีด่านเดียว ก็ยังต้องส่งไปให้โดนปฏิเสธก่อนถึงจะรู้

กรณีที่อาจเจอในงานจริง

  • ไฟล์ที่ทำบนเครื่องพัฒนาผ่าน แต่บนเซิร์ฟเวอร์ไม่ผ่าน โปรแกรมที่แปลง PDF เป็น PDF/A ที่ใช้กันมากคือ Ghostscript และคนละเวอร์ชันให้ไฟล์ไม่เหมือนกัน เราเจอว่าโค้ดเดียวกันบน Ghostscript 10.02 กับ 10.07 ได้ไฟล์ที่โครงสร้างต่างกัน และรุ่นใหม่ตัดข้อมูลบางช่องที่ PDF/A ต้องมีทิ้งไปเงียบ ๆ จึงควรตรวจไฟล์ที่สร้างบนเครื่องที่ใช้งานจริง และตรวจซ้ำทุกครั้งที่อัปเดตเซิร์ฟเวอร์
  • ทีมพัฒนาปิดระบบป้องกันของ Ghostscript ให้ทำงานผ่าน Ghostscript รุ่นใหม่เปิดโหมดป้องกัน (-dSAFER) ไว้ตลอด และจะไม่ยอมอ่านไฟล์สีกับ XML ที่จะแนบ ทางที่ถูกคืออนุญาตให้อ่านเฉพาะสองไฟล์นั้น ไม่ใช่ปิดโหมดป้องกันทั้งหมด เพราะ Ghostscript กำลังเปิดไฟล์ที่มีข้อมูลจากผู้ใช้อยู่
  • ส่งจริงครั้งแรกแล้วโดนปฏิเสธ ใบกำกับภาษีที่ส่งออกไปแล้วดึงคืนไม่ได้ ระบบควรมีโหมดซ้อมส่งเข้ากล่องอีเมลของเราเองก่อน ทั้งไฟล์ หัวข้อ และขนาดจริง
  • ผู้ซื้อขอไฟล์ XML แยก ไม่ต้องทำอะไรเพิ่ม XML อยู่ในไฟล์ PDF/A-3 แล้ว โปรแกรมอ่าน PDF ส่วนใหญ่เปิดดูไฟล์แนบได้

เรื่องที่ควรถามทีมพัฒนา

  1. ไฟล์ที่ได้เป็น PDF/A-3 ระดับ U หรือเปล่า และตรวจด้วยอะไร
  2. ข้อมูลกำกับไฟล์สามช่องของ ETDA มาจากไหน และตรวจว่าครบก่อนส่งหรือไม่
  3. ตรวจตัว PDF นอกจากหน้าตรวจของ ETDA อย่างไร ทั้งมาตรฐาน PDF/A และข้อกำหนดของ ETDA
  4. ถ้าไฟล์เกิน 3 MB หรือภาษาไทยในไฟล์อ่านออกมาไม่ครบ ระบบหยุดหรือส่งต่อ
  5. ตรวจไฟล์บนเครื่องที่ใช้งานจริงแล้วหรือยัง และจะตรวจซ้ำเมื่อไหร่
  6. มีโหมดซ้อมส่งก่อนส่งให้ลูกค้าจริงไหม

ตอนถัดไปของซีรีส์ เอกสารภาษี ไฟล์ธนาคาร และ e-GP

อ่านต่อ

ถูกอ้างถึงใน

ล่าสุด

ดูทั้งหมด →