Case study · ระบบสต็อก + AI · ร้านอะไหล่มอเตอร์ไซค์และอู่ซ่อม

Paolo Auto Car: ระบบดูแลสต็อกอะไหล่ 22,940 รายการ สรุปเข้า LINE ทุกเช้า

Paolo Auto Car เป็นร้านอะไหล่มอเตอร์ไซค์ที่มีอู่ซ่อมในร้าน ใช้ Smile Account บันทึกการขายมานาน แต่ช่องจุดสั่งซื้อในระบบตั้งไว้แค่ 4 จาก 27,262 รายการ เราติดตั้งตัวอ่านข้อมูลแบบอ่านอย่างเดียวบนเครื่องของร้าน ซิงก์ทุก 15 นาที คำนวณอัตราขายและจุดสั่งซื้อให้ 22,940 รายการที่ยังเคลื่อนไหว แล้วส่งสรุปเข้ากลุ่ม LINE ของร้านทุกเช้า 09:00 พร้อมให้พิมพ์ถามสต็อกในกลุ่มได้ Phase 1 นี้ใช้งานจริงทุกวันตั้งแต่ 22 ก.ย. 2026 ส่วน Phase 2 (บิลเข้า ตอบลูกค้า กระทบยอดเงิน นับสต็อก เจ้าหนี้) กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง

ข้อมูลโปรเจกต์

ลูกค้าPaolo Auto Car — ร้านอะไหล่มอเตอร์ไซค์ + อู่ซ่อมในร้าน (1 สาขา · คลังเดียว 3 ตำแหน่งเก็บ)
ระบบเดิมของร้านSmile Account — ร้านใช้ต่อตามเดิม เราไม่เปลี่ยนและไม่เขียนข้อมูลกลับ
ขนาดข้อมูลสินค้า 27,262 รายการ · ยังเคลื่อนไหว 22,940 · บรรทัดขาย 370,174 · ความเคลื่อนไหวสต็อก 401,820
ช่วงเวลาสำรวจหน้างาน 9 ก.ย. 2026 · ติดตั้ง 17 ก.ย. · สรุปเข้า LINE ทุกวันตั้งแต่ 22 ก.ย. · Phase 2 เริ่ม 24 ก.ย. (ยังดำเนินอยู่)
งานของ Hashboxสำรวจฐานข้อมูล · ออกแบบระบบ · ตัวอ่านข้อมูลบนเครื่องร้าน · ระบบคำนวณบน cloud · ข้อความ LINE · ติดตั้งหน้างาน
สถานะPhase 1 ใช้งานจริง · Phase 2 กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
บริการที่เกี่ยวข้องที่ปรึกษา AI สำหรับธุรกิจ

โจทย์: ข้อมูลขายมีครบ แต่ระบบไม่ได้บอกว่าต้องสั่งอะไร

ร้านบันทึกการขายและการรับสินค้าใน Smile Account มาหลายปี ข้อมูลย้อนหลังจึงมีครบ แต่ช่องที่บอกว่าควรสั่งของเมื่อไหร่ (จุดสั่งซื้อ จำนวนขั้นต่ำ ระยะเวลารอของ) ถูกตั้งไว้แค่ 4 รายการจาก 27,262 รายการ การตัดสินใจสั่งของจึงขึ้นกับความจำของคนในร้าน

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

ขอบเขตงานคาดไว้ไม่เกิน 5,000 รายการ ตัวเลขจริงคือ 22,940 รายการที่ยังขายหรือมีของ — เราเจอตัวเลขนี้เพราะเข้าไปดูฐานข้อมูลจริงก่อนเขียนโค้ด

Phase 1 ทำอะไรบ้าง

เงื่อนไขที่ตั้งไว้ตั้งแต่วันแรก: อ่านข้อมูลบัญชีของร้านอย่างเดียว ไม่เปิดพอร์ตรับการเชื่อมต่อบนเครื่องร้าน และไม่ติดตั้งโปรแกรมระบบเพิ่ม

  1. สำรวจหน้างานก่อนเขียนโค้ด (9 ก.ย.)

    เปิดดูฐานข้อมูลจริงของร้าน นับตาราง และเทียบยอดคงเหลือกับความเคลื่อนไหวของสต็อก ยอดคงเหลือในตารางสินค้าตรงกับผลรวมรับเข้า−จ่ายออกทุกรายการ ยกเว้นไม่ถึง 20 รายการ จึงใช้เป็นตัวเลขหลักได้

  2. ตัวอ่านข้อมูลบนเครื่องร้าน (ติดตั้ง 17 ก.ย.)

    โปรแกรมเล็กที่ใช้ Python แบบพกพาในโฟลเดอร์เดียว อ่านด้วยคำสั่ง SELECT อย่างเดียวทุก 15 นาที และส่งเฉพาะรายการที่เปลี่ยนออกไปทาง HTTPS ฐานข้อมูลของร้านเป็นรุ่นเก่าที่รองรับการเข้ารหัสรุ่นเก่าเท่านั้น เราจึงใช้ไดรเวอร์ที่มีอยู่แล้วบนเครื่องแทนการติดตั้งตัวใหม่ การส่งครั้งแรกทั้งก้อนใช้เวลาราว 20 วินาที

  3. คำนวณจุดสั่งซื้อจากยอดขายจริง

    อัตราขายต่อวัน = ยอดขาย 90 วัน ÷ 90 (ถ้าข้อมูลน้อยใช้ 180 หรือ 365 วัน) · จุดสั่งซื้อ = อัตราขาย × ระยะรอของ 14 วัน ปัดขึ้น · เตือนล่วงหน้าเมื่อของพอขายอีกไม่เกินระยะรอของ + 7 วัน · เรียงความสำคัญ ติดลบ → ต่ำกว่าจุดสั่งซื้อ → ใกล้ถึง → ปกติ สูตรเต็มอยู่ในบทความ จุดสั่งซื้อและ Safety Stock

  4. สรุปเข้ากลุ่ม LINE ทุกเช้า และถามสต็อกในกลุ่ม

    สรุปส่งเวลา 09:00 หลังร้านเปิด 08:30 และส่งเฉพาะเมื่อข้อมูลซิงก์มาไม่เกิน 45 นาที ถ้าข้อมูลเก่ากว่านั้นระบบงดส่งแทนการส่งตัวเลขผิด พนักงานพิมพ์ชื่อหรือรหัสสินค้าอย่างน้อย 3 ตัวอักษรในกลุ่ม แล้วได้ยอดคงเหลือสูงสุด 5 รายการ ข้อความทุกฉบับถูกบันทึกก่อนส่ง จึงไม่มีข้อความซ้ำเมื่อระบบส่งใหม่

อะไรใช้งานจริงแล้ว อะไรยังไม่เปิด

ตามสถานะส่งมอบ ณ 11 ต.ค. 2026 — เราแก้ตารางนี้เมื่อแต่ละส่วนเปิดใช้กับข้อมูลจริง

ส่วนของงานทำอะไรสถานะ
Phase 1 · ซิงก์และคำนวณอ่านสต็อกทุก 15 นาที คำนวณจุดสั่งซื้อ 22,940 รายการใช้งานจริง
Phase 1 · สรุป LINE + ถามสต็อกสรุปเข้ากลุ่มร้าน 09:00 และตอบคำถามสต็อกในกลุ่มใช้งานจริงตั้งแต่ 22 ก.ย. 2026
Phase 1 · แจ้งเตือนทันทีส่งเตือนเมื่อสินค้าต่ำกว่าจุดสั่งซื้อระหว่างวันพัฒนาเสร็จ ปิดไว้รอร้านอนุมัติเกณฑ์
Phase 2A · บิลเข้าถ่ายรูปบิลผู้ขายใน LINE → AI ร่างรายการ → พนักงานตรวจก่อนนำเข้ากำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
Phase 2A · เบิกของและของทดแทนเบิกอะไหล่ ยอดพร้อมขาย และสินค้าที่ใช้แทนกันได้กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
Phase 2B · ตอบลูกค้าใน LINEAI ร่างคำตอบเรื่องสินค้าและสต็อกให้ลูกค้าใน LINE OAกำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
Phase 2C · กระทบยอดเงินจับคู่เงินสดและเงินโอนกับรายการขายกำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
Phase 2D · นับสต็อกนับสต็อกและยอดยกมากำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
Phase 2E · เจ้าหนี้รายการค้างจ่าย เตรียมจ่าย และเงินทดรอง (ไม่มีการโอนเงินจากระบบ)กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง

ทำไม Phase 1 ไม่ใช้ AI

ทุกตัวเลขใน Phase 1 มาจากสูตรที่ตรวจย้อนได้ เจ้าของร้านถามได้ว่า "ทำไมรายการนี้ต้องสั่ง" แล้วเราชี้ได้ว่ามาจากยอดขาย 90 วันกับระยะรอของ งานที่คำตอบต้องถูกทุกครั้งแบบนี้ สูตรธรรมดาดีกว่าโมเดลภาษา

AI อยู่ใน Phase 2 ตรงที่สูตรทำไม่ได้: อ่านรูปบิลจากผู้ขายให้เป็นรายการ และร่างคำตอบลูกค้าใน LINE ทั้งสองงานมีคนตรวจก่อนข้อมูลเข้าระบบเสมอ ดูตัวอย่างการออกแบบแบบนี้ใน AI Agent คืออะไร

5 เรื่องในฐานข้อมูลจริงที่ไม่ตรงกับที่คาดไว้

ทั้งหมดนี้เจอระหว่างสำรวจและติดตั้ง และเป็นเหตุผลที่เราไม่เริ่มงานจากข้อมูลจำลองอีก

  • คอลัมน์ยอดคงเหลือในบัตรสต็อกเป็น 0 ทุกแถว — ใช้ยอดในตารางสินค้าแทน หลังเทียบกับผลรวมรับ−จ่ายแล้ว
  • งานซ่อมในอู่ถูกบันทึกเป็นการขาย — สำหรับร้านนี้ยอดขายคือยอดใช้ของ จึงไม่ต้องแยกการเบิกของอู่
  • ฐานข้อมูลแยกเป็นปีละชุด และปีเก่ายังมีการลงรายการหลังขึ้นปีใหม่ — ประวัติขาย 12 เดือนต้องรวมข้ามปีและตัดรายการซ้ำด้วยเลขเอกสาร
  • คอลัมน์จำนวนที่แปลงหน่วยแล้วเป็น 0 ทั้งหมด — ต้องคูณหน่วยขายกับอัตราแปลงเอง (1.8% ของบรรทัดขายใช้หน่วยที่ไม่ใช่หน่วยสต็อก)
  • ค่าแรงซ่อม 252 รหัสอยู่ในตารางสินค้า และเป็นที่มาของยอดติดลบ 171 จาก 549 รายการ ณ วันที่ตรวจ — ต้องแยกออกก่อนคำนวณ และยอดติดลบที่เหลือขึ้นบนสุดของสรุป ไม่ถูกซ่อน

ตัวเลขที่ตรวจได้

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

ตัวเลขหมายถึงที่มา
22,940สินค้าที่ระบบดูแล (ยังขายหรือมีของ จากทั้งหมด 27,262 รายการ)ฐานข้อมูลของร้าน · สำรวจ 9 ก.ย. 2026
4 จาก 27,262สินค้าที่ตั้งจุดสั่งซื้อไว้ก่อนเริ่มโปรเจกต์ฐานข้อมูลของร้าน · สำรวจ 9 ก.ย. 2026
3,686สินค้าต่ำกว่าจุดสั่งซื้อในชั่วโมงแรกที่ระบบคำนวณ (ติดลบ 547 · ใกล้ถึง 47 · ปกติ 12,246)ผลคำนวณรอบแรก วันติดตั้ง 17 ก.ย. 2026
15 นาทีรอบซิงก์สต็อกจากเครื่องร้าน (ส่งครั้งแรกทั้งก้อนราว 20 วินาที จากนั้นส่งเฉพาะที่เปลี่ยน)บันทึกการทำงานของตัวอ่านข้อมูล วันติดตั้ง
09:00 ทุกวันสรุปสต็อกเข้ากลุ่ม LINE ของร้าน ตั้งแต่ 22 ก.ย. 2026ร้านยืนยันข้อความจากข้อมูลจริง 21 ก.ย. 2026

สิ่งที่เราเรียนรู้จากงานนี้

  1. ตัวคุมจำนวนแจ้งเตือนคือยอดขายล่าสุด ไม่ใช่ระยะรอของ ลดระยะรอของจาก 14 เหลือ 3 วัน รายการที่ถูกเตือนลดจาก 4,229 เหลือแค่ 3,769 แต่ถ้านับเฉพาะของที่ขายอย่างน้อย 10 ชิ้นใน 90 วัน จะเหลือ 513 รายการ แจ้งเตือนที่เยอะเกินไปคือแจ้งเตือนที่ไม่มีใครอ่าน แจ้งเตือนทันทีจึงยังปิดไว้จนกว่าร้านเลือกเกณฑ์เอง
  2. ข้อมูลจำลองไม่เหมือนของจริง โค้ดที่เขียนกับข้อมูลจำลองต้องแก้หน้างานในวันติดตั้ง และสคริปต์ติดตั้งรันไม่ได้บน PowerShell รุ่นเก่าของเครื่องร้านเพราะข้อความภาษาไทย ตั้งแต่นั้นเราสำรวจฐานข้อมูลจริงก่อนเขียนทุกครั้ง
  3. ระบบต้องรู้ตัวว่าข้อมูลเก่า 23 ก.ย. อินเทอร์เน็ตของร้านมีปัญหา การซิงก์หยุด ระบบงดส่งสรุปเช้าและติดป้าย "ข้อมูลเก่า" ในคำตอบถามสต็อก แทนที่จะส่งตัวเลขเมื่อวานเหมือนเป็นของวันนี้
  4. LINE ตัดข้อความยาวทิ้งโดยไม่แจ้ง ข้อความที่ยาวเกิน 5,000 ตัวอักษรถูกตัดเงียบๆ สรุปจึงต้องแบ่งเป็นหลายข้อความ และเราเจอบั๊กแสดงตัวเลขติดลบผิดรูปแบบจากการอ่านข้อความจริงในกลุ่ม
  5. ไม่ทดสอบกับข้อมูลจริงของร้าน Smile ของร้านไม่มีบริษัทสำหรับทดสอบ เราจึงหยุดทดสอบการนำเข้าไฟล์ แทนที่จะลองกับบัญชีจริง นี่เป็นเหตุผลหนึ่งที่ Phase 2 ยังไม่เปิด

คำถามที่พบบ่อย

ระบบนี้ต้องเปลี่ยนโปรแกรมบัญชีไหม

ไม่ต้อง ร้านใช้ Smile Account ต่อตามเดิม ระบบอ่านข้อมูลอย่างเดียวและไม่เขียนอะไรกลับเข้าโปรแกรมบัญชี

ข้อมูลของร้านถูกส่งออกไปที่ไหน

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

Phase 1 ใช้ AI ไหม

ไม่ใช้ ทุกตัวเลขมาจากสูตรคำนวณจากยอดขายจริงที่ตรวจย้อนได้ AI อยู่ใน Phase 2 คืออ่านรูปบิลและร่างคำตอบลูกค้า ซึ่งมีคนตรวจก่อนเสมอ และยังไม่เปิดใช้กับข้อมูลจริง

จากวันสำรวจถึงวันที่ร้านใช้งานใช้เวลาเท่าไหร่

สำรวจหน้างาน 9 ก.ย. 2026 ติดตั้ง 17 ก.ย. และร้านได้สรุปเข้า LINE ทุกวันตั้งแต่ 22 ก.ย. รวมประมาณ 2 สัปดาห์

ทำแบบนี้กับโปรแกรมบัญชีอื่นได้ไหม

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

ข้อมูลอยู่ในระบบเดิมแล้ว แต่ยังไม่มีใครเอามาใช้?

เล่าโจทย์ให้เราฟัง เราสำรวจระบบเดิมก่อน แล้วบอกตรงๆ ว่าทำอะไรได้และทำอะไรไม่ได้ ก่อนเสนอขอบเขต

ขอประเมินงาน AI ของธุรกิจคุณ