นำ AI มาลงทะเบียนอีเมลคำสั่งซื้อของลูกค้าใน ERP โรงงาน: แนวทางเริ่มโครงการ

เมื่อโรงงานต้องการใช้ AI ลงทะเบียนอีเมลคำสั่งซื้อ งานจริงไม่ได้จบที่การคัดลอกข้อความจากไฟล์ ลูกค้าส่งอีเมลพร้อม PDF, Excel หรือภาพเอกสารมาให้ ผู้รับต้องตัดสินใจว่าเป็นคำสั่งซื้อที่ยืนยันแล้วหรือเพียงคำถาม ต้องตรวจลูกค้า รหัสสินค้า จำนวน ราคา และวันส่งมอบ ก่อนสร้าง ใบสั่งขายใน ERP ของโรงงาน ข้อความอย่าง “เหมือนครั้งก่อน” ไฟล์ฉบับแก้ไข หรือวันส่งของที่ขัดแย้งกันไม่สามารถปล่อยให้ OCR ตัดสินใจเองได้ บทความนี้อธิบายขอบเขตข้อมูล การจัดการข้อยกเว้น RFP และการทดสอบ FAT/SAT สำหรับฐานการผลิตในไทย

กำหนดขอบเขตก่อน: รับคำสั่งซื้อจากลูกค้า ไม่ใช่งานจัดซื้อ

จุดเริ่มต้นคือ ลูกค้าส่งคำสั่งซื้อมาที่บริษัทเรา ข้อมูลเข้าคือกล่องอีเมลของฝ่ายขายและไฟล์แนบ ผลลัพธ์คือใบสั่งขายใน ERP เอกสารอาจมีชื่อ Purchase Order หรือ PO เพราะเป็นใบสั่งซื้อจากมุมของลูกค้า แต่จากมุมโรงงานผู้รับคือยอดสั่งขาย การอ่าน PO ที่บริษัทออกให้ซัพพลายเออร์ การเปรียบเทียบใบเสนอราคาจัดซื้อ การตรวจรับ และการประมวลผลใบแจ้งหนี้เป็นคนละกระบวนการ หากรวมกันจะสับสนเรื่องเจ้าของงาน มาสเตอร์ข้อมูล เอกสาร ERP และตัวชี้วัด

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

ขั้นตอนอัตโนมัติของอีเมลคำสั่งซื้อ 7 ขั้น

1. รับและเก็บหลักฐาน บันทึก ID อีเมล ID ไฟล์แนบ เวลา ผู้ส่ง และสายสนทนา Microsoft Graph มี delta query เพื่อติดตามการเปลี่ยนแปลงอีเมล แต่การใช้งานจริงต้องตรวจสิทธิ์กล่องจดหมาย กฎส่งต่อ นโยบายเก็บข้อมูล และระบบอีเมลที่ใช้
2. จำแนกเจตนา แยกคำสั่งซื้อใหม่ การแก้ไข การยกเลิก ขอใบเสนอราคา คำถามทั่วไป และสแปม อย่าดูเพียงคำว่า PO
3. ดึงข้อมูลผู้สมัคร อ่านชื่อลูกค้า เลข PO ลูกค้า วันที่ จุดส่งสินค้า สกุลเงิน รายการสินค้า รุ่น จำนวน หน่วย ราคา และวันส่งที่ต้องการ พร้อมตำแหน่งต้นทางว่าอยู่ในย่อหน้า หน้า PDF หรือเซลล์ใด
4. ปรับเป็นรหัสมาตรฐาน จับคู่รหัสสินค้าลูกค้ากับรหัสภายใน หน่วยกับหน่วย ERP และชื่อลูกค้ากับรหัสที่ตรวจแล้ว AI เสนอคำตอบได้ แต่การยืนยันต้องอาศัยมาสเตอร์ที่อนุมัติหรือผู้มีสิทธิ์
5. ตรวจเงื่อนไข เทียบราคาในสัญญา ขนาดล็อต สินค้าที่ขายได้ สถานที่ส่ง วงเงินเครดิต และคำสั่งซื้อเดิม คะแนนความมั่นใจสูงไม่ลบล้างกฎธุรกิจที่ไม่ผ่าน
6. ให้คนตรวจและอนุมัติ แสดงค่าที่ยังไม่แน่ใจคู่กับต้นฉบับ กำหนดเจ้าของงาน สิทธิ์อนุมัติ และช่องทางถามลูกค้า AI ไม่ใช่ผู้มีอำนาจยืนยันการค้า
7. บันทึกครั้งเดียวและตอบกลับ สร้างใบสั่งขาย ERP หนึ่งฉบับ เชื่อมเลข ERP กับอีเมล ไฟล์ และประวัติการตรวจ การตอบรับอีเมลกับการยืนยันวันส่งเป็นการตัดสินใจคนละขั้น ใช้เฉพาะข้อมูลที่อนุมัติแล้ว

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

แยกข้อมูลส่วนหัว รายการ และหลักฐาน

เลข PO ของลูกค้าเพียงอย่างเดียวอาจไม่เป็นรหัสเอกลักษณ์ ลูกค้าอาจแก้ฉบับโดยใช้เลขเดิม เพิ่มรายการทีหลัง หรือใช้เลขเดียวกันในหลายโรงงาน ออกแบบกุญแจตรวจซ้ำจากรหัสลูกค้า เลข PO จุดส่ง และรุ่น พร้อมข้อยกเว้นเฉพาะลูกค้า ตรวจการส่งอีเมลซ้ำจาก ID และ hash ไฟล์ หาก ERP รับคำสั่งสำเร็จแต่การตอบกลับทางเครือข่ายหายไป ให้ค้นด้วยกุญแจธุรกิจก่อนลองส่งอีกครั้ง การ POST ซ้ำทันทีเสี่ยงสร้างยอดสั่งซ้ำ

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

ประเมินการอ่านอีเมลและ AI-OCR เอกสารแยกกัน

PDF สแกนและภาพต้องใช้ OCR กับการอ่านตาราง ข้อความอีเมลไม่ต้องใช้ OCR แต่ “สัปดาห์หน้า” “เงื่อนไขเดิม” หรือ “แก้เฉพาะบรรทัดที่สาม” ต้องเข้าใจบริบท Excel มีแถวซ่อน หลายชีต สูตร และหน่วยที่อยู่นอกบรรทัดสินค้า คะแนน “ความแม่นยำในการอ่าน” ตัวเดียวปกปิดจุดเสียที่ต่างกัน

วัดการจำแนกเอกสาร การดึงส่วนหัว การดึงรายการ การจับคู่รหัสสินค้า การจำแนกเจตนา และการลง ERP แยกขั้น เอกสาร Google Cloud Document AI อธิบาย precision, recall และผลของ threshold ต่อการตรวจพบผิดหรือพลาด คำโฆษณา “แม่นยำ 99%” จึงไม่พอหากไม่มีชุดข้อมูลเฉลยที่แยกตามลูกค้า รูปแบบ ภาษา คุณภาพภาพ และสถานะการแก้ไข

หาก 99 ใน 100 บรรทัดถูกต้อง แต่บรรทัดสุดท้ายเป็น 100 ชิ้นแทน 10 ชิ้น ความเสียหายอาจสูงกว่าคะแนนรวมบอกมาก ตรงกันข้าม ชื่อสินค้าที่สะกดต่างแต่จับคู่มาสเตอร์ได้อย่างแน่นอนอาจมีผลน้อย จัดอันดับความผิดตามผลกระทบและความสามารถตรวจ โดยเน้นสินค้า ราคา สกุลเงิน จำนวน และวันส่ง เก็บการแก้ของคนไว้ปรับกฎและโมเดล อย่าประกาศผ่านจากค่าเฉลี่ยเมื่อกลุ่มเสี่ยงยังผิด

เชื่อมวัตถุใบสั่งขายของ ERP ก่อนคิดทำบอตกดหน้าจอ

เปรียบเทียบ API ของ ERP ช่องนำเข้ามาตรฐาน ส่วนขยาย แล้วจึงระบบกดหน้าจอ ตัวอย่างเช่น Business Central มี API สำหรับสร้าง salesOrders อย่างเป็นทางการ แต่การมี API ไม่ได้ยืนยันว่า ERP ของบริษัทจะบันทึกฟิลด์เฉพาะ ภาษี คลัง เงื่อนไขลูกค้า และรายการครบ ตรวจเวอร์ชัน ใบอนุญาต สิทธิ์ API และระบบทดสอบ แล้วลองสร้างทั้งส่วนหัวและบรรทัดจริง

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

ต้องมีเจ้าของตารางจับคู่รหัสสินค้า รหัส ABC-100 ของลูกค้าอาจแมปเป็น P-001 ปกติ แต่รุ่นหรือขนาดที่เปลี่ยนอาจเป็นสินค้าอีกตัว เมื่อมีตัวเลือกหลายตัวให้พักงานและบันทึกการเปลี่ยนตาราง หากแผนผลิตขึ้นกับคำสั่งซื้อ ให้เริ่มจากเหตุการณ์ที่ ERP ยืนยันแล้ว ไม่ใช้เพียงอีเมลที่รับมาเป็นคำสั่งผลิต อ่านต่อเรื่องการจัดการยอดค้างส่งของโรงงาน

แยกแก้ไขและยกเลิกออกจากคำสั่งซื้อใหม่

งานยากในกล่องอีเมลมักเป็นข้อความที่สอง: “เปลี่ยนบรรทัดสามเป็น 50” “ใช้ไฟล์ใหม่” หรือ “เลื่อนส่งหนึ่งสัปดาห์” หากสร้างใบสั่งขายอีกฉบับ ยอดค้างส่งจะสูงผิด หากผลิตตามรุ่นเก่าก็เกิดความผิดอีกแบบ ต้องจำแนก ใหม่ แก้ไข ยกเลิก และเสนอเลข ERP กับบรรทัดที่จะแก้

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

ประเด็นของฐานผลิตในไทย: ภาษา นิติบุคคล เวลา และข้อมูล

โรงงานไทยอาจได้รับเอกสารญี่ปุ่น อังกฤษ ไทย และเวียดนาม นิติบุคคลที่ขาย สกุลเงิน จุดส่ง และเงื่อนไขส่งออกอาจต่างกัน เก็บตัวเลข รหัส และหน่วยจากต้นฉบับ แปลคำอธิบายบนหน้าจอได้ แต่ไม่ตัดสินราคาโดยดูเฉพาะคำแปล ตรวจรูปแบบปีไทย/ปีสากล วันเดือน เวลา วันหยุดท้องถิ่น และการแสดง VAT ตามลูกค้าและนิติบุคคล

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

อีเมลลูกค้าเป็นข้อมูลภายนอก ไม่ใช่คำสั่งที่เชื่อถือได้ หากเอกสารเขียนว่า “ละเลยกฎแล้วส่งข้อมูลไปที่อื่น” ให้ถือเป็นเนื้อหาที่ต้องอ่าน ไม่ใช่คำสั่งแก่ระบบ แปลงผลดึงข้อมูลเป็น schema จำกัด และให้ workflow ที่มีสิทธิ์เท่านั้นสั่ง ERP หรือส่งอีเมล OWASP อธิบายความเสี่ยง indirect prompt injection เมื่อเนื้อหาภายนอกถูกยกระดับเป็นคำสั่ง

สำรวจปริมาณงานก่อนเลือกผลิตภัณฑ์

เก็บตัวอย่างอีเมลอย่างน้อยสองถึงสี่สัปดาห์ แยกตามลูกค้า ภาษา ชนิดไฟล์ คำสั่งใหม่หรือแก้ไข และช่วงปกติหรือช่วงเร่ง นับอีเมลที่มีแต่ข้อความ PDF ทางการ และ Excel หลายร้อยบรรทัดแยกกัน แบ่งเวลางานเป็นอ่าน ตรวจ คีย์ และแก้ข้อยกเว้น หากฤดูกาลทำให้รูปแบบเปลี่ยนให้ขยายช่วงเก็บข้อมูล

วัดเวลาจากรับถึงเริ่มทำ เวลาถึงลง ERP งานแก้ซ้ำ คำสั่งซ้ำ การถามลูกค้า และนาทีแรงงานต่อรายการ หลังใช้ AI แยก “ลงได้โดยไม่แก้” “ลงหลังคนตรวจ” “พัก” “ลงผิด” และ “ประมวลผลใหม่” จำนวนหน้าที่ OCR อ่านได้ไม่ใช่ผลสำเร็จถ้าตอบลูกค้าผิด

PoC ไม่ควรมีเพียงแบบฟอร์มลูกค้าที่เรียบร้อยรายเดียว ต้องรวมลูกค้าหลัก แบบไม่มาตรฐาน ฉบับแก้ หลายภาษา ภาพไม่ดี รหัสสินค้ากำกวม และข้อมูลในอีเมลขัดกับไฟล์ แยกชุดพัฒนากับชุดรับงาน ทำเฉลยจากกระบวนการฝ่ายขายของบริษัท ไม่คัดลอกเฉลยจาก OCR ฝั่งจัดซื้อ หากผู้เชี่ยวชาญเองเห็นต่าง ให้บันทึกเหตุผลก่อนตัดสินว่า AI ผิด

คิดผลตอบแทนจากข้อยกเว้นและต้นทุนความผิด

สูตรตั้งต้นคือจำนวนคำสั่งซื้อที่เข้าเกณฑ์ต่อเดือนคูณนาทีทำงานเดิมและต้นทุนแรงงาน แล้วหักเวลาตรวจรายการอัตโนมัติ เวลาตรวจโดยคน เวลาจัดการข้อยกเว้น และค่าบริการต่อเนื่อง ใช้ปริมาณจริงแยกตามลูกค้าและช่วงเร่ง สมมุติ 600 ใน 1,000 รายการดูเป็นมาตรฐาน แต่ทุกคำสั่งต้องอนุมัติราคา การอ้างว่าอัตโนมัติ 60% จะเกินจริง ในทางกลับกันการประมวลผลช่วงสิ้นเดือนได้เร็วอาจช่วยตอบกำหนดส่งมากกว่าแค่ชั่วโมงแรงงาน อย่านำ ROI ทั่วไปมาแทนค่าที่วัดในโรงงานตนเอง

เปรียบเทียบต้นทุนทั้งหมด ไม่ใช่ราคา OCR ต่อหน้า รวมการต่อกล่องเมล การอ่านตาราง หน้าจอตรวจ ระบบ ERP การเฝ้าระวัง และการเปลี่ยนเทมเพลตลูกค้า ผู้ขายคิดราคาต่อหน้า ต่อเอกสาร หรือต่อแถวต่างกัน ระบุปริมาณ จำนวนบรรทัด ไฟล์ ช่วงพีก อายุเก็บ และภาษาใน RFP

ข้อกำหนดที่ควรใส่ใน RFP

ขอบเขตงานและสิทธิ์ตัดสินใจ

ระบุกล่องเมล ลูกค้า ภาษา ชนิดเอกสาร การจัดการ ใหม่/แก้/ยกเลิก ผู้ตรวจ ผู้อนุมัติ และการแจ้งหลัง ERP ขอผังการตัดสินว่าเงื่อนไขใดลงอัตโนมัติ เงื่อนไขใดพัก จำกัด AI ไม่ให้เปลี่ยนมาสเตอร์สินค้าและราคา

ข้อมูล ความปลอดภัย และการสนับสนุน

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

การเชื่อมต่อและหลักฐานรับงาน

ให้ระบุ API/CSV/RPA ที่เลือก ลำดับสร้างส่วนหัวและรายการ วิธีจัดการ error/rollback กุญแจป้องกันซ้ำ และช่องทางส่งเลข ERP กลับ ทดสอบการส่งซ้ำ ฉบับแก้ จำนวนศูนย์ หน่วยผิด สินค้ายกเลิก สกุลเงินผิด เครือข่ายหลุด และ ERP ปิดซ่อม การสาธิต API ที่ทำงานกับตัวอย่างเดียวไม่พอ

FAT และ SAT ต้องพิสูจน์ว่า ERP มีคำสั่งซื้อที่ถูกต้อง

FAT ใช้ตัวอย่างที่ปกปิดข้อมูลตามตกลง ทดสอบตั้งแต่จำแนก ดึงข้อมูล ปรับมาตรฐาน ลง ERP ทดสอบ และ audit log SAT ทดสอบทางอีเมลจริง สิทธิ์จริง มาสเตอร์ลูกค้า เวลาไทย หน้าจอที่พนักงานใช้ และการฟื้นระบบ ตกลงเกณฑ์ผ่านก่อนเริ่มทดสอบ

ตั้งเกณฑ์ตัวเลขตามโครงการ พร้อมจำนวนตัวอย่างและระยะดูผล “ความผิดสำคัญเป็นศูนย์” ไม่มีความหมายถ้าไม่บอกจำนวนทดสอบ ติดตามการลงผิดรุนแรง เวลาปิดข้อยกเว้น การป้องกันซ้ำ และการแจ้งขั้นถัดไปพร้อมอัตราลงอัตโนมัติ NIST AI RMF แบ่งงานความเสี่ยงเป็น Govern, Map, Measure, Manage เป็นกรอบสมัครใจที่ช่วยติดตามหลังเริ่มใช้ ไม่ใช่หลักประกันทางกฎหมาย

เริ่มทีละกลุ่มลูกค้า รูปแบบ และความเสี่ยง

เริ่มกับลูกค้าที่มีปริมาณพอ รูปแบบนิ่ง และจับคู่สินค้าได้ชัด แต่เก็บเอกสารยากไว้ในชุดประเมิน ระยะแรกให้ AI เสนอและคนตรวจทุกงาน เทียบกับการคีย์เดิมและบันทึกความต่าง ระยะต่อมาลดจุดตรวจหรือยอมให้ลงอัตโนมัติเฉพาะลูกค้า รูปแบบ ชนิดคำสั่ง มาสเตอร์ที่ตรวจแล้ว การไม่ซ้ำ และผลตอบ ERP ที่ผ่านเกณฑ์ มีสวิตช์กลับไปให้คนตรวจเมื่ออัตราผิดหรือข้อยกเว้นสูงขึ้น แล้วจึงขยายลูกค้าและการแก้ไข พร้อม regression test ทุกครั้งที่กฎหรือโมเดลเปลี่ยน

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

กำหนดตารางตัดสินใจและแผนกู้คืนก่อนใช้จริง

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

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

เก็บผลรับงานตามลูกค้าและความรุนแรง

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

คำถามพบบ่อย

AI ลงทะเบียนอีเมลคำสั่งซื้อทั้งหมดเข้า ERP โดยอัตโนมัติได้ไหม?

การเขียน ERP อาจทำได้ทางเทคนิค แต่คำสั่งที่เจตนาไม่ชัด ไฟล์ขัดกับข้อความ รหัสสินค้าไม่แน่ใจ ราคาเปลี่ยน หรือรุ่นกำกวมควรพัก ประเมินผลของการรับผิด แล้วทำอัตโนมัติเฉพาะรายการที่ผ่านเงื่อนไขชัดเจน

AI-OCR เอกสารคำสั่งซื้อทำให้งานคีย์หายไปทั้งหมดหรือไม่?

OCR เสนอค่าจากเอกสาร ยังต้องจับคู่ลูกค้า/สินค้า ตรวจราคาและวันส่ง จัดการรุ่น อนุมัติ เชื่อม ERP และป้องกันซ้ำ ประเมินเดโมอ่านเอกสารแยกจากเดโมลงใบสั่งขายครบวงจร

ต่างจาก OCR ใบสั่งซื้อฝั่งจัดซื้ออย่างไร?

PO ที่ลูกค้าสร้างคือข้อมูลเข้าของใบสั่งขายเรา PO ที่บริษัทสร้างให้ซัพพลายเออร์เป็นงานจัดซื้อ เจ้าของ มาสเตอร์ เอกสาร ERP และ KPI ต่างกัน

RFP และ FAT/SAT ต้องตรวจขั้นต่ำอะไร?

ระบุลูกค้า รูปแบบ ภาษา ฟิลด์สำคัญ การแก้และยกเลิก เจ้าของข้อยกเว้น การเชื่อม ERP log ความปลอดภัย และผู้ดูแล FAT ตรวจตัวอย่างและกรณีเสีย SAT ตรวจเส้นทางเมลจริงกับผู้ใช้จริง ติดตามทุกกรณีจนถึงเลขใบ ERP

สรุป

การใช้ AI ลงทะเบียนอีเมลคำสั่งซื้อของโรงงานคือการออกแบบทางที่ควบคุมได้จากข้อความลูกค้าสู่ใบสั่งขาย ERP จุดสำคัญคือเจตนาคำสั่ง หลักฐานย้อนกลับ การตรวจสินค้า/ราคา/วันส่ง การแก้และส่งซ้ำ การอนุมัติโดยคน การลงครั้งเดียว และการเฝ้าดูหลังเริ่มใช้ เริ่มจากแยกอีเมลตามลูกค้าและข้อยกเว้น แล้วทดลองทั้งสายด้วยตัวอย่างจริง

หากกำลังสำรวจอีเมลคำสั่งซื้อ AI-OCR หรือการเชื่อม ERP สำหรับฐานในไทย สามารถปรึกษา TOMAS TECH ตั้งแต่ขั้นจัดประเภทอีเมลและงานคีย์เดิม ระดับอัตโนมัติที่เหมาะต้องตัดสินจากคำสั่งซื้อและกฎ ERP ของท่าน

แหล่งอ้างอิง

• Microsoft Graph: message delta query — ติดตามอีเมลแบบเพิ่มเฉพาะส่วน
• Microsoft Azure Document Intelligence: confidence and accuracy — ความมั่นใจของฟิลด์และการตรวจโดยคน
• Google Cloud Document AI: Evaluate performance — precision recall และ threshold
• Microsoft Business Central: Create salesOrders — ตัวอย่าง API ใบสั่งขาย
• NIST AI RMF Core — การจัดการความเสี่ยง AI ต่อเนื่อง
• OWASP Top 10 for LLM Applications — ประเด็น prompt injection
• Thailand PDPC GPPC privacy notice — ตัวอย่างคำอธิบายข้อมูลส่วนบุคคล