บัญชีตั้งแต่ต้นทาง
เอกสารใน LINE จะเปลี่ยนเป็นคิวงานที่ตามต่อได้อย่างไร
แปลง message/file ให้มี event identity, task ID, company/period, owner, status, duplicate control และ retention ที่ชัดเจน
หลายทีมใช้ LINE เป็นจุดรับเอกสารเพราะสะดวก แต่ปัญหาเกิดเมื่อรูปใบเสร็จหนึ่งรูปถูกส่งในกลุ่มแล้วไม่มีใครรู้ว่าใครต้องทำต่อ เคยส่งซ้ำหรือยัง และตอนสิ้นเดือนต้องย้อนหาในประวัติแชต การแก้ปัญหาไม่จำเป็นต้องห้ามใช้ LINE แต่ต้องแปลง message ให้เป็นงานที่มีสถานะและผู้รับผิดชอบ
บทความนี้อธิบายแนวคิด intake workflow โดยใช้ LINE Messaging API เป็นตัวอย่างสาธารณะ ไม่ได้หมายความว่า lindaaccounting.com หรือทุกแอปของ Linda เปิด bot integration แบบเดียวกันทั้งหมดใน Production
เก็บ message event และต้นฉบับก่อนตีความ
LINE ส่ง webhook event เมื่อผู้ใช้ส่งข้อความหรือไฟล์ไปยัง Official Account และ message event มี message ID ที่ใช้ดึง content เช่น image, video, audio หรือ file ได้ในช่วงเวลาที่ LINE ยังเก็บ content ไว้ ระบบรับเอกสารจึงควรเก็บ event ID/message ID, ผู้ส่ง, เวลา และไฟล์ต้นฉบับตามนโยบายที่ได้รับอนุญาตก่อนเริ่ม OCR หรือ classification
เอกสาร LINE แนะนำให้ตรวจ signature ของ webhook ก่อนประมวลผล เพราะ endpoint อาจได้รับ HTTP request จากแหล่งอื่นด้วย นี่เป็นชั้นความปลอดภัยของ intake ไม่ใช่หลักฐานว่าตัวเอกสารถูกต้องทางบัญชี
สร้าง Task จากเอกสาร ไม่ปล่อยให้ message เป็นสถานะสุดท้าย
เมื่อรับไฟล์แล้ว ให้สร้าง task ID ที่อ้าง message ID และเก็บประเภทเบื้องต้น เช่น ใบกำกับ/ใบเสร็จ/สลิป/เอกสารไม่ชัด พร้อม company, period, ผู้รับผิดชอบ และ due date ตามกติกา ถ้าระบุบริษัทไม่ได้ให้เข้าคิวสอบถาม ไม่เดาจากชื่อกลุ่มหรือผู้ส่ง
Reply ใน LINE สามารถแจ้งเลขงานและข้อมูลที่ยังขาดได้ เช่น “รับเอกสารแล้ว #DOC-1042 กรุณาระบุบริษัท” ทำให้ผู้ส่งรู้ว่าเอกสารถูกเข้าสู่ระบบและลดการส่งซ้ำจากความไม่แน่ใจ
แยกการส่งซ้ำออกจากเอกสารคนละฉบับ
Webhook อาจถูกส่งซ้ำเมื่อเกิดปัญหาการรับ และผู้ใช้เองก็อาจส่งรูปเดิมหลายครั้ง จึงควรใช้ webhook event ID/message ID ป้องกันการประมวลผล event เดิมซ้ำ และใช้ document fingerprint/metadata เป็นเพียงสัญญาณช่วยตรวจว่าไฟล์อาจซ้ำ ไม่ควร auto-merge จากภาพคล้ายกันอย่างเดียว
LINE ระบุว่า webhook redelivery สามารถเกิดขึ้นได้และจำนวน/ช่วงเวลาไม่ได้รับประกันคงที่ ระบบ downstream จึงต้องออกแบบ idempotency ตั้งแต่ intake เพื่อไม่ให้เอกสารเดียวสร้างงานหลายรายการ
แหล่งอ้างอิง: [1]
สถานะงานต้องบอกสิ่งที่ขาด ไม่ใช่แค่ “อ่านแล้ว”
ตัวอย่างสถานะ: Received → Needs Context → Ready for Review → Approved/Rejected → Exported/Posted → Reconciled โดยแต่ละ transition มี actor และ timestamp ถ้า OCR อ่านยอดไม่ได้ให้เข้าสถานะ Needs Review ไม่ควรส่งค่าที่เดาไปต่ออัตโนมัติ
สำหรับสำนักงานบัญชี task queue ควรค้นตามลูกค้า รอบเดือน ประเภทเอกสาร ผู้รับผิดชอบ และอายุงานได้ เพื่อให้สิ้นเดือนทีมเห็นว่าขาดอะไรโดยไม่ต้องเปิดแชตทีละห้อง
กำหนด retention และสิทธิ์เข้าถึงต้นฉบับตั้งแต่ต้น
ไฟล์ในแชตอาจมีข้อมูลส่วนบุคคลหรือข้อมูลธุรกิจ จึงต้องกำหนดว่าระบบใดเก็บสำเนา ใครเข้าถึงได้ เก็บนานเท่าไร และการลบทำอย่างไร อย่าถือว่า content ในแพลตฟอร์มแชตจะเก็บให้ดาวน์โหลดได้ตลอดไป
LINE ระบุว่า user-sent content ถูกลบอัตโนมัติหลังช่วงเวลาหนึ่ง และข้อความ text ไม่มี API ให้ดึงย้อนหลังใหม่หลังรับ webhook แล้ว ดังนั้นระบบที่ต้องใช้ข้อมูลต่อควรจัดเก็บตามนโยบายของตนอย่างมีการควบคุมแทนการพึ่ง history ของ API
แหล่งอ้างอิง: [1]
เช็กลิสต์เริ่มต้น
- ตรวจ webhook signature และเก็บ message/event identity
- สร้าง task ID พร้อม company/period/owner/status
- ทำ idempotency สำหรับ event และคิวตรวจ document duplicate
- ให้สถานะบอกข้อมูลที่ขาดและผู้รับผิดชอบต่อ
- กำหนดสิทธิ์และ retention ของไฟล์ต้นฉบับ
นำไปใช้กับธุรกิจของคุณ
LINE เป็นช่องทางรับเอกสารที่สะดวกได้ แต่คุณค่าทางปฏิบัติการเกิดเมื่อข้อความถูกแปลงเป็น task ที่ติดตามได้ พร้อม identity, owner, evidence และ state ที่ชัดเจน
แหล่งอ้างอิง
- LINE. (n.d.). Receive messages (webhook). สืบค้น 1 ตุลาคม 2026.
- LINE. (n.d.). Messaging API reference. สืบค้น 1 ตุลาคม 2026.
แหล่งอ้างอิงรองรับข้อความที่ระบุหมายเลข ส่วนตัวอย่างและแนวทางปฏิบัติเป็นข้อเสนอของ Linda ไม่ใช่ผลลัพธ์ที่รับรองจากลูกค้าจริง
บทความนี้เป็นแนวทางออกแบบงานและตัวอย่างเพื่อการเรียนรู้ ไม่ใช่คำวินิจฉัยบัญชี ภาษี กฎหมาย หรือการรับรองความพร้อมของทุกโมดูล การนำไปใช้ต้องพิจารณาธุรกิจ สิทธิ์ผู้ใช้ และขอบเขตระบบจริง