เชื่อม SAP Business One กับผู้ให้บริการ e-Tax Invoice ส่งใบกำกับภาษีอัตโนมัติ

บริษัทเจออะไรอยู่#

ลูกค้าของเราเป็นบริษัทจัดจำหน่ายที่ออกใบกำกับภาษี ใบลดหนี้ ใบเพิ่มหนี้ และใบเสร็จจาก SAP Business One ทางบริษัทอยากเปลี่ยนเป็น e-Tax Invoice ส่งให้ลูกค้าทางอีเมลและยื่นกรมสรรพากรแบบอิเล็กทรอนิกส์ ผ่านผู้ให้บริการ e-Tax (Service Provider) ที่ลงลายมือชื่ออิเล็กทรอนิกส์และนำส่งสรรพากรให้ ลูกค้ารายนี้ใช้บริการของธนาคารที่ติดต่อกันอยู่แล้ว ซึ่งเป็นผู้ให้บริการรายหนึ่ง

ผู้ให้บริการเปิดช่องทางให้ส่งข้อมูลเอกสารเข้าไป แต่ SAP ไม่ได้ส่งเองในรูปแบบที่ผู้ให้บริการต้องการ ถ้าไม่มีตัวกลาง ก็ต้องมีคน export และอัปโหลดเองทุกวัน แล้วคอยตามว่าใบไหนผ่าน ใบไหนโดนตีกลับ

เราทำระบบกลางที่ทำทั้งหมดนี้ให้อัตโนมัติ ทีมบัญชีทำแค่ออกเอกสารใน SAP ให้ถูกต้อง

ภาพรวมการทำงาน#

flowchart TD
  U[ทีมบัญชีออกเอกสารใน SAP] --> F[ระบบดึงเอกสารจาก SAP<br/>ทุก 1 นาที]
  F --> C{เป็นเอกสารแบบไหน}
  C -->|ใหม่| S[ส่งให้ผู้ให้บริการ]
  C -->|แก้ช่องสำคัญหลังส่งไปแล้ว| R[ส่งฉบับใหม่แทนของเดิม]
  C -->|ไม่มีอะไรเปลี่ยน| K[ข้าม]
  S --> B[ผู้ให้บริการลงลายมือชื่อ<br/>อีเมลถึงลูกค้า<br/>ยื่นกรมสรรพากร]
  R --> B
  B --> P[ระบบดึง PDF ที่เซ็นแล้วกลับมาเก็บ]

ไม่มีใครต้องกดส่ง ระบบดึงและส่งเองทุกนาที

ระบบดูแลเอกสาร 5 ประเภท คือ ใบกำกับภาษี ใบมัดจำ ใบลดหนี้ ใบเพิ่มหนี้ และใบเสร็จรับเงินที่ออกต่อจากใบกำกับ แต่ละประเภทมีรูปแบบข้อมูลของตัวเองที่ต้องแปลงจาก SAP ให้ตรงกับที่ผู้ให้บริการรับ ทีมบัญชีเปิดดูได้ว่าเอกสารแต่ละใบจะออกมาหน้าตาแบบไหน คู่กับข้อมูลที่ระบบส่งให้ผู้ให้บริการจริง

ตัวอย่างเอกสารที่สร้างจากข้อมูลชุดเดียวกับที่ส่งให้ผู้ให้บริการ ถ้าตรงไหนผิด จะเห็นก่อนที่ลูกค้าได้รับ (ข้อมูลตัวอย่าง)

เอกสารแต่ละใบมีสถานะให้ทีมบัญชีเห็นว่าอยู่ตรงไหน

flowchart LR
  A[รอส่ง] --> B[ส่งแล้ว]
  B --> C[ผู้ให้บริการกำลังทำ]
  C --> D[เสร็จ ได้ PDF แล้ว]
  B -.แก้ข้อมูลใน SAP.-> E[รอส่งซ้ำ]
  D -.แก้ข้อมูลใน SAP.-> E
  E --> B
  B -.ผู้ให้บริการปฏิเสธ.-> X[ถูกปฏิเสธ]
  X -.แก้ใน SAP แล้ว.-> A

ถ้าผู้ให้บริการปฏิเสธ ทีมบัญชีแก้ที่เอกสารใน SAP แล้วระบบส่งใหม่ให้เอง

หน้ารวมเอกสาร: นับจำนวนแต่ละสถานะไว้ด้านบน ใบที่ถูกปฏิเสธบอกเหตุผลในแถวเลย (ข้อมูลตัวอย่าง)

เอกสารหนึ่งใบ: แถบด้านบนบอกว่าผ่านขั้นไหนแล้ว ด้านขวาคือประวัติตั้งแต่ดึงจาก SAP จนผู้ให้บริการส่งอีเมลถึงลูกค้า (ข้อมูลตัวอย่าง)

ส่งได้สองช่องทาง ตามที่ลูกค้าแต่ละรายต้องการ#

ลูกค้าบางรายต้องการ PDF ธรรมดาที่เซ็นแล้ว บางรายต้องการไฟล์ PDF/A-3 ที่ฝังข้อมูล XML ของสรรพากรไว้ในไฟล์ เพื่อเอาเข้าระบบของตัวเองต่อ ผู้ให้บริการรับสองแบบนี้ผ่านคนละช่องทาง

ทีมบัญชีติ๊กไว้ที่ข้อมูลลูกค้าใน SAP ครั้งเดียว ระบบก็เลือกช่องทางและรหัสงานที่ตรงกันให้ ไม่อย่างนั้นอาจเจอกรณีที่เอกสารเซ็นผ่าน แต่ไม่ได้นำส่งสรรพากร ทั้งสองช่องทางยื่นสรรพากรเหมือนกัน ต่างกันแค่ไฟล์ที่ลูกค้าได้

แก้เอกสารใน SAP แล้ว ระบบส่งฉบับใหม่ให้เอง#

เรื่องที่ทีมบัญชีถามบ่อยที่สุดคือ แก้อะไรแล้วระบบจะส่งใหม่ ระบบเฝ้าดูเฉพาะช่องที่มีผลกับตัวเอกสาร และส่งใหม่เมื่อตรงทั้งสองข้อ

1. มีการกดบันทึกที่ตัวเอกสารใน SAP จริง
2. ช่องที่เฝ้าดูมีค่าเปลี่ยนไป

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

อีเมลถึงคนที่ถูกต้อง#

ผู้ให้บริการเป็นคนส่งอีเมลแนบเอกสารให้ลูกค้า ระบบจึงต้องบอกผู้ให้บริการว่าส่งถึงใคร โดยเลือกตามลำดับ อีเมลแรกที่มีค่าเป็นผู้รับหลัก ที่เหลือเป็นสำเนา และไม่เกิน 5 คนต่อใบ

flowchart LR
  A[อีเมลของที่อยู่ออกบิล] --> B[พนักงานเจ้าของเอกสาร]
  B --> C[ผู้ติดต่อฝ่ายจัดซื้อ]
  C --> D[อีเมลคงที่ที่ตั้งไว้]

ตั้งลำดับแยกได้ตามประเภทเอกสาร

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

เมื่อผู้ให้บริการปฏิเสธเอกสาร หรือระบบล่ม#

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

หน้าต้องตรวจสอบ: แยกปัญหาเป็นกลุ่ม แต่ละกลุ่มบอกว่าต้องทำอะไรต่อ เช่นแก้ใน SAP แล้วดึงใหม่ หรือเช็กกับลูกค้าแล้วกดเสร็จ (ข้อมูลตัวอย่าง)

เก็บเอกสารไว้ให้ทีมบัญชี#

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

ใช้กับระบบของคุณได้ยังไง#

แนวเดียวกันนี้ใช้ได้กับ ERP ตัวอื่นและผู้ให้บริการ e-Tax รายอื่น ขอแค่อ่านเอกสารจาก ERP ได้ และผู้ให้บริการเปิด API หรือรับไฟล์ ถ้ายังไม่แน่ใจเรื่องกติกาของสรรพากร ลองอ่านหลักเกณฑ์ e-Tax Invoice ที่ควรรู้ก่อนเชื่อมระบบประกอบได้ จากนั้นลองตอบคำถามเหล่านี้

• เอกสารประเภทไหนบ้างที่ต้องเข้า e-Tax และแต่ละแบบมาจากเอกสารไหนใน ERP
• แก้อะไรแล้วต้องส่งฉบับใหม่ และแก้อะไรที่ไม่ควรทำให้ลูกค้าได้เอกสารซ้ำ
• ใครควรได้อีเมล และลูกค้าที่รับเป็นกระดาษจะทำยังไง
• ใบที่ถูกปฏิเสธ ใครเป็นคนแก้ และจะรู้ได้ยังไง

ผลลัพธ์#

เราเริ่มพัฒนาเดือนมีนาคม 2569 และระบบเริ่มใช้งานจริงวันที่ 1 กรกฎาคม 2569 ทุกวันนี้ทีมบัญชีไม่ต้องอัปโหลดหรือกดส่งเอง เห็นสถานะของทุกใบในที่เดียว และแก้เอกสารที่ถูกปฏิเสธได้จาก SAP ตามปกติ

ระบบเขียนด้วย Laravel 12 ใช้ Livewire กับ Flux ทำหน้าจอ งานตามรอบเวลาและงานเบื้องหลังรันบน Horizon ฐานข้อมูลเป็น MySQL อ่าน SAP HANA ผ่าน SQL proxy ที่เราแยกเป็นแพ็กเกจ laravel-sap-proxy และวางรายงานลง SharePoint ผ่าน Microsoft Graph