กรณีการใช้งาน

การทำงานอัตโนมัติเอกสารในทางปฏิบัติ

ความแตกต่างระหว่างเครื่องมือประมวลผลเอกสารกับ Document Automation Transformer (DAT) จะชัดเจนที่สุดในสถานการณ์จริง เครื่องมือสกัดข้อความ Transformer กำจัด Workflow

กรณีการใช้งานด้านล่างแสดงให้เห็นว่าการทำงานอัตโนมัติแบบ Full-pipeline หน้าตาเป็นอย่างไร — ตั้งแต่รับเอกสารเข้ามาจนถึงการ Integration กับระบบ แต่ละสถานการณ์อธิบายปัญหาที่แก้ไข, ประเภทเอกสารที่เกี่ยวข้อง, ข้อมูลที่สกัดมา และ Flow การทำงานอัตโนมัติที่แทนที่กระบวนการด้วยมือ

กรณีที่ 1: ระบบอัตโนมัติสำหรับบัญชีเจ้าหนี้

สถานการณ์

บริษัทขนาดกลางรับใบแจ้งหนี้จากผู้จำหน่าย 200–300 ใบต่อเดือน ใบแจ้งหนี้แต่ละใบมาในรูปแบบ PDF ทาง Email ในรูปแบบที่แตกต่างกันจากผู้จำหน่ายต่างๆ ทีมบัญชีเจ้าหนี้ประมวลผลแต่ละใบด้วยมือ: สกัดรายละเอียดผู้จำหน่าย, ยอดเงิน และวันครบกำหนด, ป้อนข้อมูลลงในระบบบัญชี, ส่งต่อเพื่ออนุมัติ และกำหนดการชำระเงิน

ในช่วง Peak (ปิดบัญชีสิ้นเดือน, ปิดบัญชีปลายปี) งานค้างอาจเกินกำลังของทีมต่อวัน ทำให้เกิดค่าปรับชำระล่าช้าและความสัมพันธ์กับผู้จำหน่ายที่ตึงเครียด

ประเภทเอกสาร

• ใบแจ้งหนี้ PDF จากผู้จำหน่าย
• ไฟล์แนบ Email (ส่งต่อมายัง Ocriva ผ่าน API)
• ใบแจ้งหนี้กระดาษที่สแกน

ฟิลด์ที่สกัดมา

• ชื่อและเลขประจำตัวผู้เสียภาษีของผู้จำหน่าย
• เลขที่ใบแจ้งหนี้และวันที่
• วันครบกำหนดชำระและเงื่อนไขการชำระเงิน
• รายการสินค้า (คำอธิบาย, จำนวน, ราคาต่อหน่วย, ยอดรวม)
• ยอดรวมก่อนภาษี, ภาษีมูลค่าเพิ่ม, ยอดสุทธิ
• รายละเอียดบัญชีธนาคาร (สำหรับการกำหนดตารางการชำระเงิน)

Flow การทำงานอัตโนมัติ

รับใบแจ้งหนี้ (Email/Upload)
        ↓
Ocriva: สกัดผ่าน Template ใบแจ้งหนี้ (GPT-4o)
        ↓
Webhook → ระบบบัญชี API (สร้างรายการเจ้าหนี้อัตโนมัติ)
        ↓
Webhook → Workflow อนุมัติ (Auto-route ถ้ายอดต่ำกว่า Threshold)
        ↓
Webhook → ระบบกำหนดการชำระเงิน (ตั้ง Reminder วันครบกำหนด)
        ↓
Notification → ทีม AP (สรุปการเสร็จสมบูรณ์ของ Batch)

ผลกระทบ

หมายเหตุการตั้งค่า

• ใช้ Ocriva Template เดียวครอบคลุมทุกรูปแบบผู้จำหน่าย
• ตั้งค่า Webhook ให้ POST ไปยังระบบบัญชีเมื่อ document.processed
• ตั้งกฎ Auto-approve ในระบบบัญชีสำหรับใบแจ้งหนี้ที่ต่ำกว่ายอดกำหนด
• เปิดใช้ Batch Export สำหรับรายงานกระทบยอดประจำเดือน

กรณีที่ 2: การประมวลผลรายงานค่าใช้จ่าย

สถานการณ์

บริษัทที่มีพนักงาน 150 คนต้องให้พนักงานส่งใบเสร็จค่าใช้จ่ายเพื่อเบิกเงิน พนักงานถ่ายรูปใบเสร็จด้วยโทรศัพท์แล้วส่ง Email หรือส่งผ่าน App ค่าใช้จ่าย ฝ่ายการเงินประมวลผลเหล่านี้ด้วยมือ ตรวจสอบยอดเงิน, วันที่ และร้านค้า และป้อนลงในระบบจัดการค่าใช้จ่าย

ปริมาณจะสูงขึ้นช่วงปลายเดือนและก่อน Quarter Close

ประเภทเอกสาร

• ใบเสร็จถ่ายรูป (JPG/PNG) — ร้านอาหาร, แท็กซี่, โรงแรม, อุปกรณ์สำนักงาน
• ใบเสร็จ Thermal ของ POS (ถ่ายรูป)
• E-receipts (PDF)
• ใบเสร็จน้ำมันและบัตรจอดรถ

ฟิลด์ที่สกัดมา

• ชื่อและหมวดหมู่ร้านค้า
• วันและเวลาทำธุรกรรม
• รายการที่ซื้อ (ถ้ามี)
• ยอดรวมก่อนภาษี, ภาษี, ยอดสุทธิ
• วิธีการชำระเงิน (เงินสด, บัตร)
• หมายเลขใบเสร็จหรือ Reference

Flow การทำงานอัตโนมัติ

พนักงานถ่ายรูปใบเสร็จผ่าน LINE
        ↓
LINE → Ocriva: Template ใบเสร็จ (Gemini Flash เพื่อความเร็ว)
        ↓
ผลลัพธ์ JSON ที่มีโครงสร้าง (ร้านค้า, ยอดเงิน, วันที่, หมวดหมู่)
        ↓
Webhook → ระบบจัดการค่าใช้จ่าย (สร้าง Draft Claim อัตโนมัติ)
        ↓
Batch CSV Export → ทีมการเงิน (ตรวจสอบรายเดือน)
        ↓
Analytics → Dashboard หมวดหมู่ค่าใช้จ่าย

ผลกระทบ

• ลดเวลาตรวจสอบของทีมการเงินลง 70% — ตรวจสอบเฉพาะกรณีพิเศษ ไม่ใช่ทุกใบเสร็จ
• การ Submit ของพนักงานใช้เวลาไม่กี่วินาที (ถ่ายรูปผ่าน LINE) แทนที่จะกรอกฟอร์มด้วยมือ
• การจัดหมวดหมู่สม่ำเสมอในทุกพนักงาน (AI ใช้กฎที่สม่ำเสมอ)
• ปิดบัญชีรายเดือนเร็วขึ้น 2 วัน

หมายเหตุการตั้งค่า

• เปิดใช้ LINE Integration สำหรับการรับใบเสร็จบนมือถือ
• ใช้ Gemini Flash สำหรับการสกัดใบเสร็จปริมาณมากและง่าย
• ตั้งค่าการเข้าถึงโปรเจกต์ต่อพนักงานเพื่อความเป็นส่วนตัว
• ตั้งค่า Category Normalization ในคำสั่ง Template (เช่น "จัดประเภทค่าอาหารทั้งหมดเป็น 'ค่าอาหารและบันเทิง'")

กรณีที่ 3: ระบบอัจฉริยะสำหรับสัญญา

สถานการณ์

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

ทีมต้องการสร้างฐานข้อมูลสัญญาที่ค้นหาได้พร้อมการแจ้งเตือนต่ออายุอัตโนมัติ

ประเภทเอกสาร

• สัญญาบริการผู้จำหน่าย (PDF หลายหน้า)
• สัญญาไม่เปิดเผยข้อมูล
• สัญญาจ้างงาน
• สัญญาใบอนุญาตซอฟต์แวร์

ฟิลด์ที่สกัดมา

• คู่สัญญา (ชื่อ, ที่อยู่จดทะเบียน, เลขประจำตัวผู้เสียภาษี)
• ประเภทและเรื่องของสัญญา
• วันที่มีผลและวันหมดอายุ
• ข้อกำหนดต่ออายุอัตโนมัติ (ใช่/ไม่ใช่, ระยะเวลาแจ้งล่วงหน้า)
• มูลค่าสัญญาและเงื่อนไขการชำระ
• พันธกรณีสำคัญ (สรุป)
• เงื่อนไขการบอกเลิกสัญญา
• กฎหมายที่ใช้บังคับและเขตอำนาจศาล

Flow การทำงานอัตโนมัติ

อัปโหลด Contract PDF ไปยัง Ocriva (เมื่อลงนาม)
        ↓
Ocriva: สกัดผ่าน Template สัญญา (Claude Sonnet — เข้าใจ Long-form ละเอียดอ่อน)
        ↓
ผลลัพธ์ JSON ที่มีโครงสร้างพร้อมฟิลด์สัญญาสำคัญทั้งหมด
        ↓
Webhook → ฐานข้อมูลสัญญา (สร้าง Record ที่ค้นหาได้)
        ↓
Webhook → ระบบปฏิทิน (ตั้ง Reminder ต่ออายุตามระยะเวลาแจ้ง)
        ↓
Webhook → Workflow อนุมัติ (สัญญาเกินมูลค่ากำหนด)
        ↓
รายเดือน: รายงาน Batch Extraction → ทีมกฎหมาย

ผลกระทบ

• เวลาตรวจสอบสัญญาต่อฉบับ: จาก 45 นาที (ด้วยมือ) เป็น 2 นาที (ตรวจสอบ Output AI)
• ไม่พลาดการต่ออายุ (การแจ้งเตือนปฏิทินอัตโนมัติ)
• ฐานข้อมูลสัญญาครบวงจรค้นหาได้ตามคู่สัญญา, มูลค่า, วันหมดอายุ, ประเภท
• สัญญาใหม่ประมวลผลได้ภายในวันเดียวแทนที่จะรอคิวของทีมกฎหมาย

หมายเหตุการตั้งค่า

• ใช้ Claude Sonnet สำหรับการสกัดสัญญา — Context Window ที่ยาวกว่า, เข้าใจภาษากฎหมายได้ละเอียดอ่อน
• รวมคำสั่ง Template สำหรับสรุปข้อกำหนดพันธกรณีเป็นภาษาธรรมดา
• แนบเอกสารอ้างอิงพร้อมคำนิยามข้อกำหนดสัญญามาตรฐานขององค์กร
• ตั้งค่า Webhook เพื่อ Filter การแจ้งเตือนต่ออายุอัตโนมัติตามระยะเวลาแจ้ง (เช่น แจ้งเตือน 90 วันก่อนหมดอายุ)

กรณีที่ 4: การประมวลผลเอกสารทางการแพทย์

สถานการณ์

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

ประเภทเอกสารแต่ละอย่างต้องการฟิลด์ต่างกันสำหรับระบบปลายทางที่ต่างกัน: เวชระเบียน, การเงิน, การเคลมประกัน และระบบจัดการร้านยา

ประเภทเอกสาร

• ใบรับรองแพทย์ (ออกโดยแพทย์)
• ใบสั่งยาผู้ป่วยนอก
• รายงานผลตรวจทางห้องปฏิบัติการ
• แบบฟอร์มรับเข้าโรงพยาบาล
• แบบฟอร์มเคลมประกัน
• จดหมายส่งตัวจากโรงพยาบาลอื่น

ฟิลด์ที่สกัดมา (ต่อประเภทเอกสาร)

ใบรับรองแพทย์:

• ชื่อผู้ป่วย, วันเกิด, เลขประจำตัว
• วินิจฉัย (รหัส ICD และคำอธิบาย)
• ชื่อแพทย์และเลขใบประกอบวิชาชีพ
• วันที่ตรวจ, วันที่ออกใบรับรอง
• ระยะเวลาพักรักษา

ใบสั่งยา:

• ข้อมูลผู้ป่วย
• ยา (ชื่อ, ขนาด, ความถี่, ระยะเวลา)
• แพทย์ผู้สั่ง
• วันที่สั่งยาและวันหมดอายุ

รายงานผลตรวจ:

• ข้อมูลผู้ป่วยและตัวอย่าง
• ชื่อและรหัสการทดสอบ
• ผลลัพธ์พร้อมค่าอ้างอิง
• การตีความ (ปกติ/ผิดปกติ)
• ห้องปฏิบัติการและรายละเอียดนักเทคนิค

Flow การทำงานอัตโนมัติ

รับเอกสาร (สแกนหรือถ่ายรูปอัปโหลด)
        ↓
Ocriva: Route ไปยัง Template ที่เหมาะสมตามประเภทเอกสาร
        ↓
การสกัดด้วย AI (Claude Sonnet เพื่อความแม่นยำทางการแพทย์)
        ↓
Webhook → ระบบข้อมูลโรงพยาบาล (อัพเดทเวชระเบียน)
        ↓
Webhook → ระบบการเงิน (สำหรับรายการที่เรียกเก็บได้)
        ↓
Webhook → ระบบร้านยา (สำหรับใบสั่งยา)
        ↓
Audit Trail: บันทึกการสกัดทุกครั้งพร้อม Timestamp และโมเดล

ผลกระทบ

• ลดเวลาการรับผู้ป่วยจาก 25 นาทีเหลือไม่ถึง 5 นาที
• กำจัดข้อผิดพลาดการถอดความใบสั่งยา (การถอดความด้วยมือมีอัตราผิดพลาด ~1.5%)
• เตรียมการเคลมประกันเร็วขึ้น 60%
• Audit Trail ครบวงจรสำหรับการปฏิบัติตามกฎระเบียบ

หมายเหตุการตั้งค่า

• ใช้ Claude Sonnet หรือ GPT-4o สำหรับเอกสารทางการแพทย์ที่ความแม่นยำไม่อาจเจรจาได้
• ตั้งค่า Template แยกต่อประเภทเอกสารภายในโปรเจกต์เดียวกัน
• เปิดใช้ประวัติการสกัดสำหรับเอกสารทั้งหมดเพื่อรองรับการตรวจสอบด้านกฎระเบียบ
• เพิ่มเอกสารอ้างอิงศัพท์ทางการแพทย์ใน Template เพื่อปรับปรุงการรู้จำรหัส ICD

กรณีที่ 5: โลจิสติกส์และการจัดส่ง

สถานการณ์

บริษัทโลจิสติกส์ระดับภูมิภาคจัดการการจัดส่งขาเข้าและขาออกทุกวัน เอกสารรวมถึงป้ายพัสดุ, ใบตราส่ง, ใบขนสินค้าและใบยืนยันการส่งมอบ เอกสารเหล่านี้ถูกถ่ายรูปโดยพนักงานคลังสินค้าและต้องกระทบยอดกับระบบจัดการการจัดส่ง

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

ประเภทเอกสาร

• ป้ายพัสดุและป้ายบาร์โค้ด
• ใบตราส่งทางอากาศ (AWB)
• ใบตราส่งสินค้า (B/L)
• แบบฟอร์มใบขนสินค้า
• ใบรับของ (ลงนามโดยผู้รับ)
• ใบกำกับสินค้าเชิงพาณิชย์สำหรับการนำเข้า

ฟิลด์ที่สกัดมา

• หมายเลขติดตาม/ใบตราส่ง
• รายละเอียดผู้ส่งและผู้รับ (ชื่อ, ที่อยู่, โทรศัพท์)
• ต้นทางและปลายทาง
• ขนาดและน้ำหนักพัสดุ
• มูลค่าที่ประกาศและคำอธิบายเนื้อหา
• รหัส Tariff ศุลกากร
• คำแนะนำการจัดการ (แตกง่าย, ควบคุมอุณหภูมิ ฯลฯ)

Flow การทำงานอัตโนมัติ

พนักงานคลังสินค้าถ่ายรูปเอกสาร (LINE Mobile Capture)
        ↓
LINE → Ocriva: Template โลจิสติกส์ (Gemini Flash)
        ↓
ข้อมูลติดตามและที่อยู่ที่สกัดมา
        ↓
Webhook → ระบบติดตามการจัดส่ง (อัพเดทแบบเรียลไทม์)
        ↓
Webhook → ระบบแจ้งเตือนลูกค้า (SMS/Email)
        ↓
Batch CSV → รายการจัดส่งประจำวัน
        ↓
Analytics → Dashboard ปริมาณงานและ Throughput

ผลกระทบ

• อัพเดทการจัดส่งแบบเรียลไทม์แทนที่จะล่าช้า 30–60 นาที
• พนักงานคลังสินค้ารับและส่งในไม่ถึง 30 วินาทีต่อเอกสาร
• ลดเวลา Latency การแจ้งเตือนลูกค้าจากชั่วโมงเป็นนาที
• ลดข้อผิดพลาดด้านเอกสารศุลกากร (พบบ่อยกับการถอดความรหัสตัวเลข-ตัวอักษรด้วยมือ)

หมายเหตุการตั้งค่า

• LINE Integration เหมาะอย่างยิ่งสำหรับ Workflow คลังสินค้าที่ใช้มือถือเป็นหลัก
• Gemini Flash ให้ความเร็วที่จำเป็นสำหรับการดำเนินการปริมาณสูง
• ตั้งค่า Template เพื่อ Normalize รูปแบบที่อยู่ (สำคัญสำหรับความเข้ากันได้ในการนำเข้าระบบ)
• ใช้ Batch Export สำหรับการสร้างรายการจัดส่งปลายวัน

กรณีที่ 6: การศึกษาและการบริหาร HR

สถานการณ์

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

มหาวิทยาลัยประมวลผลใบสมัครมากกว่า 2,000 ฉบับต่อรอบรับสมัคร ฝ่าย HR ประมวลผลเอกสารการรับเข้าทำงานสำหรับพนักงานใหม่กว่า 500 คนต่อปี รวมถึงการรวบรวมเอกสารที่ต่อเนื่อง (รีวิวประสิทธิภาพประจำปี, ใบรับรองการฝึกอบรม, การเลื่อนตำแหน่ง)

ประเภทเอกสาร (การศึกษา)

• ผลการเรียน (จากมหาวิทยาลัยและโรงเรียนมัธยมต่างๆ)
• ใบรับรองการสำเร็จการศึกษาและปริญญาบัตร
• รายงานผลสอบมาตรฐาน
• จดหมายอ้างอิง
• Statement of Purpose (สำหรับการสกัดข้อมูลสำคัญ)

ประเภทเอกสาร (HR)

• แบบฟอร์มใบสมัครงาน
• บัตรประจำตัวและใบอนุญาตทำงาน
• ใบรับรองการศึกษา
• หนังสือรับรองการทำงานจากที่เก่า
• ใบรับรองวิชาชีพและใบอนุญาต
• รายงานผลตรวจสุขภาพ

ฟิลด์ที่สกัดมา (ผลการเรียน)

• ชื่อและรหัสนักศึกษา
• ชื่อและการรับรองสถาบัน
• ชื่อโปรแกรมและสาขา
• GPA และเกณฑ์การให้คะแนน
• รายวิชาที่เรียนพร้อมเกรดและหน่วยกิต
• สถานะและวันที่สำเร็จการศึกษา

ฟิลด์ที่สกัดมา (HR — การรับเข้าทำงานใหม่)

• ชื่อเต็ม (ไทยและอังกฤษ)
• เลขบัตรประชาชนและใบอนุญาตทำงาน
• วันเกิดและสัญชาติ
• การศึกษาสูงสุดและสถาบัน
• นายจ้างก่อนหน้าและตำแหน่งงาน
• ข้อมูลผู้ติดต่อในกรณีฉุกเฉิน

Flow การทำงานอัตโนมัติ

ผู้สมัครอัปโหลดเอกสาร (Batch ผ่าน Application Portal API)
        ↓
Ocriva: สกัดผ่าน Template เฉพาะประเภทเอกสาร
        ↓
ผลลัพธ์ JSON ต่อเอกสาร
        ↓
Webhook → ระบบข้อมูลนักศึกษา / HRIS (สร้าง Record ผู้สมัคร/พนักงาน)
        ↓
Batch CSV → Dashboard ตรวจสอบของคณะกรรมการรับสมัคร / HR
        ↓
Analytics → ปริมาณใบสมัครแยกตามโปรแกรม / แผนก
        ↓
Alert → การแจ้งเตือนเอกสารที่ขาดหาย (ถ้าฟิลด์ที่จำเป็นว่างเปล่า)

ผลกระทบ (มหาวิทยาลัย)

• สำนักงานรับสมัครประมวลผล 2,000 ใบสมัครใน 2 วันแทนที่จะเป็น 3 สัปดาห์
• คุณภาพข้อมูลสม่ำเสมอในทุกใบสมัครจากหลายร้อยสถาบันที่แตกต่างกัน
• ระบุใบสมัครที่ไม่สมบูรณ์ตั้งแต่เนิ่นๆ (เอกสารที่ขาดหายถูกตั้งค่าสถานะโดยอัตโนมัติ)

ผลกระทบ (HR)

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

หมายเหตุการตั้งค่า

• สร้าง Template แยกต่อประเภทเอกสารภายในโปรเจกต์ "Onboarding" เดียว
• ใช้คำสั่ง Template เพื่อทำให้ GPA มาตรฐานในสถาบันต่างๆ (เช่น "แปลง GPA ทั้งหมดเป็นระบบ 4.0")
• ตั้งค่าการแจ้งเตือน Webhook "missing field" สำหรับฟิลด์ที่จำเป็นที่คืนค่าว่าง
• Batch Upload รองรับการพุ่งสูงของปริมาณที่เป็นลักษณะเฉพาะของรอบรับสมัครและการจ้างงาน

กรณีที่ 7: การประมวลผลเอกสารอัตโนมัติผ่าน Google Drive

สถานการณ์

บริษัทที่มีทีมหลายแผนกใช้ Google Drive เป็นที่เก็บเอกสารกลาง — ฝ่ายบัญชีเก็บใบแจ้งหนี้ ฝ่ายจัดซื้อเก็บใบ PO ฝ่ายกฎหมายเก็บสัญญา ทั้งหมดอยู่ใน Shared Drive ที่จัดโครงสร้างตามแผนก

ปัจจุบัน พนักงานต้องดาวน์โหลดเอกสารจาก Drive มา key-in ข้อมูลเข้าระบบด้วยมือ ข้อมูลล่าช้า 1–2 วันหลังจากเอกสารถูกอัปโหลด เมื่อเอกสารสะสมมากขึ้นช่วงปิดบัญชี งานค้างทำให้กระบวนการยิ่งช้าลง

ทีมต้องการระบบที่ดึงเอกสารจาก Drive มาประมวลผลอัตโนมัติ และส่งผลลัพธ์กลับไปยัง folder ที่กำหนดใน Drive — โดยไม่ต้องเปลี่ยน workflow การทำงานของแต่ละแผนก

ประเภทเอกสาร

• ใบแจ้งหนี้จากผู้จำหน่าย (PDF ที่ถูกอัปโหลดเข้า Drive)
• ใบสั่งซื้อ (PO) และใบส่งของ
• สัญญาและข้อตกลง (PDF หลายหน้า)
• ใบกำกับภาษีและใบเสร็จ
• เอกสาร Scan จากทีมภาคสนาม (ถ่ายรูปแล้วอัปโหลดเข้า Drive ผ่านมือถือ)

ฟิลด์ที่สกัดมา

ขึ้นอยู่กับประเภทเอกสารและ Template ที่ตั้งค่า ตัวอย่างสำหรับใบแจ้งหนี้:

• ชื่อและเลขประจำตัวผู้เสียภาษีของผู้จำหน่าย
• เลขที่ใบแจ้งหนี้และวันที่
• รายการสินค้า (คำอธิบาย, จำนวน, ราคาต่อหน่วย)
• ยอดก่อน VAT, VAT 7%, ยอดสุทธิ
• วันครบกำหนดชำระ

Flow การทำงานอัตโนมัติ

ทีมอัปโหลดเอกสารเข้า Google Drive (Shared Folder)
        ↓
Ocriva: Pull ไฟล์จาก Drive Input Folder ตาม Template Config
        ↓
AI สกัดข้อมูลผ่าน Template (GPT-4o)
        ↓
ผลลัพธ์ JSON/CSV ที่มีโครงสร้าง
        ↓
Export → Google Drive Output Folder (ผลลัพธ์พร้อมใช้งาน)
        ↓
Webhook → ระบบปลายทาง (ERP / ระบบบัญชี / CRM)
        ↓
Analytics → Dashboard สรุปเอกสารที่ประมวลผล

ผลกระทบ

หมายเหตุการตั้งค่า

• เชื่อมต่อ Google Drive กับ Organization ผ่าน OAuth2 (ตั้งค่าครั้งเดียว)
• กำหนด Input Folder (เอกสารรอประมวลผล) และ Output Folder (ผลลัพธ์) ในแต่ละ Template
• รองรับ Shared Drive ขององค์กร — แต่ละแผนกมี folder แยก จัดการสิทธิ์ผ่าน Drive permissions ตามปกติ
• ใช้ร่วมกับ Webhook ได้ — เมื่อประมวลผลเสร็จ ทั้ง export กลับ Drive และส่ง webhook ไประบบปลายทางพร้อมกัน
• เหมาะสำหรับองค์กรที่ใช้ Google Workspace อยู่แล้ว — ไม่ต้อง training พนักงานใหม่

การเลือก Configuration ที่เหมาะสม

Configuration ที่เหมาะสมขึ้นอยู่กับความซับซ้อนของเอกสาร, ปริมาณ, ความต้องการความแม่นยำ และความสามารถของระบบปลายทาง กรณีการใช้งานเหล่านี้ทั้งหมดสามารถ Implement และรันใน Ocriva ได้ภายในวันทำงานเดียว