ระบบใบแจ้งหนี้และสลิป

หลักการ สถานการณ์ และความเหมาะสม

การอ่านใบแจ้งหนี้และสลิปแยก OCR ออกจากการสกัด field และการตรวจธุรกรรมจริง ภาพที่อ่านยอดและเลขบัญชีได้ไม่พิสูจน์ว่ามีการชำระเงินหรือเอกสารถูกต้อง ต้องใช้แหล่งยืนยันที่ได้รับอนุญาตและกระบวนการบัญชี

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

schema คือรายการฟิลด์และชนิดข้อมูลที่ตกลงใช้ การตรวจสมการยอดช่วยค้นข้อผิดพลาดบางชนิดแต่เอกสารแก้ภาพก็อาจมียอดสอดคล้อง การส่งเข้าคิวร่างเพิ่มขั้นตรวจแต่ลดความเสี่ยงลงบัญชีผิด ควรให้พนักงานเห็นข้อความดิบและ crop ที่เกี่ยวข้อง พร้อมร่องรอยการแก้ แยกสิทธิ์ถอดข้อมูลจากสิทธิ์อนุมัติ ไม่ใช้บัญชีบริการสร้างผลทางการเงินโดยข้ามกฎธุรกิจ

ตัวอย่างเชิงออกแบบ

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

ตัวเลขสมมติเพื่อแสดงสมการ ไม่ใช่อัตราภาษีที่รับรอง: ยอดก่อนภาษี 1,000 ภาษี 70 และยอดรวม 1,070 ต้องอ่านครบทุกช่อง หากผลอ่านยอดรวมเป็น 10,700 สมการช่วยให้พักตรวจ แต่ไม่ควรแก้เป็น 1,070 เอง ต้องให้ผู้ตรวจดูต้นฉบับและยืนยันความหมาย รวมหน่วยเงินที่อาจต่างกัน

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

ข้อมูลนำเข้าและเงื่อนไขเริ่มต้น

เตรียมชนิดเอกสาร schema field รูปแบบจำนวนและวันที่ รหัสคู่ค้า และนโยบายข้อมูลส่วนบุคคล ต้องแยกสิทธิ์ผู้ถอดข้อมูล ผู้ตรวจ และผู้อนุมัติธุรกรรม

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

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

ขั้นตอนทดลองและเชื่อมงาน

การประเมินและเกณฑ์ตรวจรับ

วัด exact match ราย field และอัตราเอกสารที่ต้องแก้ ตรวจยอดผิดหลัก ทศนิยม วันที่ และรายการซ้ำ รวม false positive ของกฎเอกสารซ้ำ เกณฑ์รับต้องแยกผล OCR จากผลตรวจบัญชีและการชำระ

exact match ต้องถูกทั้งค่าและช่องความหมาย ตรวจเอกสารต่าง layout และข้อมูลกำกวมที่กันไว้ ไม่ใช้ความถูกอักษรรวมแทนยอดถูกเพราะความผิดหนึ่งหลักอาจมีผลทางการเงินมาก

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

กรณีล้มเหลวและข้อจำกัด

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

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

การเสนอเชื่อมแหล่งยืนยันหรือ ERP ในอนาคตต้องตรวจสิทธิ์และ API จริง ไม่อ้างว่ามีบริการตรวจธนาคารทุกแห่งหรือรับรองตามกฎหมาย การเก็บภาพและการแก้ต้องคุ้มครองบุคคลและคู่ค้าตามวัตถุประสงค์จำกัด

รายการตรวจสอบก่อนใช้งาน

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

แหล่งอ้างอิงและอ่านต่อ

• Tesseract — Improving OCR quality
• OpenAPI Initiative — OpenAPI Specification