หน้าสต็อกอาจแสดงยอดถูกต้อง แต่ไม่บอกว่ายอดนั้นมาจากอะไร ก่อนสร้างควรกำหนดให้การเปลี่ยนสต็อกแต่ละครั้งเป็นรายการปรับแยกกัน พร้อมเขียนเคสที่ต้องผ่าน คู่มือนี้ใช้สินค้าสมมติสามรายการ และไม่ได้อ้างว่า PickByTask ทดสอบแอป Lovable จริง
Lovable ระบุว่าสร้างแอปจากคำอธิบายภาษาธรรมชาติได้ พร้อมทางเชื่อม backend และ integration ส่วนเอกสาร Supabase อธิบาย workflow การเชื่อมฐานข้อมูล จึงใช้ทำต้นแบบได้ แต่ไม่ได้พิสูจน์ว่า logic สต็อก สิทธิ์ หรือประวัติที่สร้างขึ้นถูกต้อง ข้อมูลผลิตภัณฑ์ Lovable
สารบัญ — เลือกหัวข้อที่อยากอ่าน
แยกข้อมูลสินค้าออกจากรายการปรับ
สินค้าแต่ละชิ้นควรมี ID คงที่ ชื่อ และหน่วย บันทึกยอดตั้งต้นเป็นรายการปรับแถวแรก แทนการเก็บเป็นตัวเลขที่แก้ทับได้ รายการถัดไปต้องมี request ID ไม่ซ้ำ จำนวนที่เพิ่มหรือลด เหตุผล ผู้ทำรายการ และเวลา คำนวณยอดปัจจุบันจากรายการที่ยอมรับ หรืออัปเดตยอดสำรองภายใน operation เดียวกันที่ป้องกันไว้
ใช้ Lovable ทำต้นแบบสต็อกแบบทิ้งได้ แล้วเทียบการเปลี่ยนยอดทุกครั้งกับประวัติการปรับที่แก้ทับไม่ได้ก่อนนำเข้าสินค้าจริง
ใช้ prompt ที่กำหนดขอบเขต
สร้างต้นแบบสต็อกสมมติที่มีสินค้า 3 รายการ
บันทึกยอดตั้งต้นเป็น adjustment หนึ่งแถว
การเปลี่ยนครั้งต่อไปต้องมี request ID ไม่ซ้ำ จำนวนแบบบวกหรือลบ เหตุผล และผู้ทำรายการ
ปฏิเสธการเปลี่ยนที่ทำให้ยอดติดลบ
ส่ง request ID เดิมซ้ำต้องคืนผลเดิมและไม่เปลี่ยนยอดอีก
ผู้ใช้เพิ่มรายการแก้ไขได้ แต่ห้ามเขียนทับประวัติ
ถ้าบันทึกล้มเหลวให้แสดงว่ายังไม่ทราบผล ห้ามใช้สินค้าและข้อมูลลูกค้าจริงPrompt บอกพฤติกรรมที่ต้องการ แต่ไม่ใช่คำรับรองระดับฐานข้อมูล ก่อนใช้จริงต้องให้ผู้พัฒนาตรวจ schema สิทธิ์ระดับแถว และ operation ฝั่งเซิร์ฟเวอร์ เอกสาร Supabase ของ Lovable อธิบายทางเชื่อมปัจจุบัน ส่วนการตั้งค่าที่ถูกต้องยังเป็นหน้าที่ของผู้สร้าง
ไปที่เว็บไซต์ Lovable ↗ทดสอบการปรับยอดหกกรณี
- สร้างยอดตั้งต้น 10 หน่วย แล้วตรวจว่าประวัติมีรายการ +10 หนึ่งแถว
- บันทึกขาย 3 และคืน 1 ยอดที่แสดงควรเป็น 8 และประวัติต้องเก็บครบสามแถว
- ลองปรับ -9 จากยอด 8 ระบบต้องปฏิเสธโดยไม่เพิ่มรายการที่ดูเหมือนยอมรับแล้วและไม่เปลี่ยนยอด
- ส่ง request ID ของรายการ -2 ซ้ำสองครั้ง ยอดต้องลดครั้งเดียว และคำตอบทั้งสองชี้ไปยังรายการเดียวกัน
- แก้รายการ -3 ที่ผิดด้วยแถวใหม่ +3 พร้อมเหตุผล โดยแถวเดิมยังต้องมองเห็น
- ใช้บทบาททดสอบอีกแบบอ่านและเปลี่ยนยอด ตรวจว่าทั้งสองการกระทำเป็นไปตามสิทธิ์และบันทึกผู้ทำรายการ
หลังแต่ละเคส ให้เทียบยอดบนหน้าจอกับผลรวมของรายการที่ยอมรับ ลองจำลองกรณีไม่ได้รับคำตอบด้วย การส่งซ้ำต้องไม่สร้างการเปลี่ยนรอบสอง
ตัดสินใจก่อนใช้งานต่อ
ตัวอย่างนี้ผ่านเมื่อยอดรวมตรงกัน ป้องกันยอดติดลบได้ คำขอซ้ำไม่ทำรายการซ้ำ และการแก้ไขยังเก็บประวัติเดิม ล้างข้อมูลและรันใหม่หลังเปลี่ยน schema ระบบยืนยันตัวตน หรือ logic การปรับยอด
ถ้ายอดเทียบกันไม่ได้ ให้หยุดแก้ข้อมูลและนับสต็อกจากรายการล่าสุดที่เชื่อถือได้ด้วยมือ เก็บใบแก้ไขที่มีวันที่ไว้จนผู้พัฒนาซ่อม operation และตรวจแถวเดิม การสแกนบาร์โค้ด จัดซื้อ มูลค่าสินค้า ภาษี การโอนหลายสาขา การใช้ออฟไลน์ และการเก็บข้อมูลตามกฎหมายต้องมีข้อกำหนดและการทดสอบแยก
ตรวจหน้าผลิตภัณฑ์และเอกสาร Supabase วันที่ 27 กันยายน 2026 นี่คือแผนทดสอบ ไม่ใช่การรับรองความพร้อมใช้งานจริง บัญชี หรือความปลอดภัย