📌 Context: ปัญหาที่ดูเหมือนง่าย แต่จริง ๆ ซับซ้อนมาก
ในงานหนึ่งของระบบบัญชี เราได้รับข้อมูล Invoice ที่มาจาก OCR
ปัญหาคือ:
- ข้อมูลอยู่ใน Excel แต่ “ไม่มีโครงสร้างที่แน่นอน”
- กระจายหลายคอลัมน์ หลายบรรทัด
- มีบรรทัดว่าง / คอลัมน์ว่างจำนวนมาก
- ข้อมูลสำคัญ (เช่น invoice number, customer, totals) ไม่ได้อยู่ตำแหน่งคงที่
- รายละเอียดสินค้าแทรกอยู่ใน layout ที่เปลี่ยนไปตามเอกสาร
พูดง่าย ๆ คือ
เราไม่ได้กำลัง “อ่านข้อมูล” แต่กำลัง “ตีความเอกสารที่ OCR ทำให้เสียโครงสร้าง”
⚠️ Problem: Excel ไม่ได้ผิด แต่ “ข้อมูลไม่มีความหมายเชิงโครงสร้าง”
ปัญหาหลักไม่ใช่การอ่าน Excel
แต่คือ
- OCR ทำให้ “layout กลายเป็น noise”
- business logic กระจายอยู่ทั่ว sheet
- ไม่มี schema ที่แน่นอน
- จุดสำคัญของ invoice ต้อง “ค้นหา” ไม่ใช่ “อ้างตำแหน่ง”
ถ้าใช้วิธีปกติ
- copy/paste
- manual clean
- หรือ fixed cell mapping
จะพังทันทีเมื่อ format เปลี่ยน
🧠 Core Idea ของ Solution
แทนที่จะพยายาม “ทำความสะอาดข้อมูล”
เราเปลี่ยนวิธีคิดเป็น
“ไม่ใช่การ clean data แต่คือการ reconstruct meaning จาก chaos”
ดังนั้นระบบถูกออกแบบให้
- scan หา key markers เช่น “TOTALE”, “Importo”
- ใช้ pattern-based segmentation แทน fixed cell
- rebuild structure ทีละ invoice
- แล้วค่อย transform เป็น database schema
⚙️ Technical Approach (จากโค้ดจริง)
ระบบ VBA ถูกแบ่งเป็น pipeline หลายชั้น เช่น
1. Data Ingestion
- เปิดไฟล์ OCR Excel
- copy raw data เข้าระบบกลาง
2. Structure Detection
- ใช้ dictionary เก็บตำแหน่ง key fields
- หา boundary ของเอกสาร (เช่น “Importo”, “TOTALE MERCE”)
3. Document Reconstruction
- แยก invoice ออกจากกัน
- rebuild layout ลง Sheet1 ชั่วคราว
4. Data Normalization
- merge column ที่แตกจาก OCR
- delete empty structural noise
- fix row misalignment
5. Field Extraction Engine
- ดึง field สำคัญ เช่น:
- Invoice number
- Date
- Customer
- VAT / totals
- Item lines
🧩 Key Design Decision ที่สำคัญมาก
แทนที่จะใช้ “cell address based logic”
ระบบนี้ใช้
“content-driven parsing”
เช่น:
- หา “TOTALE DOCUMENTO” แทนการอ้าง B23
- หา pattern ของตัวเลขแทน fixed column
- ใช้ dictionary mapping เพื่อ reuse context
นี่คือการเปลี่ยนจาก
spreadsheet automation → document intelligence (ในเชิงแนวคิด)
📊 Outcome ของระบบ
ผลลัพธ์ที่ได้คือ:
- OCR data ที่ chaos → structured database
- รองรับหลาย format ของ invoice
- ลด manual cleaning almost entirely
- สามารถ batch process ได้
- ข้อมูลพร้อมใช้ใน reporting / accounting system
💡 Insight Layer (หัวใจของบทความนี้)
🧠 System Insight
ปัญหาที่แท้จริงของ OCR invoice ไม่ใช่ “ข้อมูลผิด”
แต่คือ
ไม่มี schema ตั้งแต่ต้น → ทุกอย่างกลายเป็น spatial guessing problem
ดังนั้น solution ที่ถูกต้องคือ
rebuild schema จาก semantic markers ไม่ใช่ layout
👥 Behavioral Insight
ในระบบองค์กร คนมักแก้ OCR ด้วยวิธี:
- clean Excel manually
- fix template เฉพาะเคส
- hardcode position
เพราะมันเร็วในระยะสั้น
แต่สิ่งที่เกิดขึ้นคือ
technical debt ถูกฝังใน process แทนที่จะอยู่ใน code
🔁 Reusable Principle
ถ้าข้อมูลมาจาก OCR หรือ unstructured source
อย่าพยายาม “อ่านจากตำแหน่ง”
ให้ “ตีความจากความหมายของข้อมูล”
เพราะ
- layout เปลี่ยนได้เสมอ
- แต่ business meaning ไม่เปลี่ยน
🚀 สรุป
ระบบนี้ไม่ใช่แค่ VBA automation
แต่มันคือ
“document reconstruction engine สำหรับข้อมูลที่ไม่มี structure”
และสิ่งที่สำคัญที่สุดไม่ใช่โค้ด
แต่คือแนวคิดว่า
เราไม่ได้จัด Excel เรากำลัง “สร้างความหมายใหม่ให้ข้อมูล”