ยอดคงเหลือ ยอดจอง และของระงับใช้ต้องแยกกัน ตัวอย่างสมมติ มี 50 จองแล้ว 8 ระงับขาย 2 จะพร้อมขาย 40 ก่อนส่วนกันเผื่ออื่น หากทุกช่องทางใช้คงเหลือ 50 ก็มีโอกาสรับงานเกิน
กำหนดสูตรพร้อมขายให้ทุกช่องทางใช้ตรงกัน
ยอดคงเหลือ ยอดจอง และของระงับใช้ต้องแยกกัน ตัวอย่างสมมติ มี 50 จองแล้ว 8 ระงับขาย 2 จะพร้อมขาย 40 ก่อนส่วนกันเผื่ออื่น หากทุกช่องทางใช้คงเหลือ 50 ก็มีโอกาสรับงานเกิน
กำหนดต้นทางสต๊อกหนึ่งแห่งตามแบบที่เลือก และบอกความถี่/เวลาซิงก์ของแต่ละช่องทาง ไม่ให้พนักงานแก้ยอดแยกหลายแห่งจนตามเหตุไม่ได้
จองสินค้าต้องทนสองออเดอร์พร้อมกัน
การตรวจว่ามีของแล้วค่อยตัดในคนละขั้นโดยไม่มีการควบคุม อาจทำให้สองคำสั่งซื้อเห็นชิ้นสุดท้ายพร้อมกัน ต้องออกแบบการจัดสรรแบบที่ป้องกันการแข่งขันของงาน
ระบุจุดหมดอายุของการจองและเงื่อนไขคืนยอด เช่น ยกเลิกหรือชำระไม่ทัน แต่ไม่ปล่อยยอดที่ถูกส่งไปหยิบแล้วโดยไม่ตรวจสถานะหน้างาน
สินค้าชุดและหลายคลังทำให้ซับซ้อนขึ้น
| สถานการณ์ | สิ่งที่ระบบควรทำ | วิธีตรวจ |
|---|---|---|
| ชุด A ใช้ X 2 ชิ้น | คำนวณตามส่วนประกอบ | ไม่ขายชุดเกิน X ที่พร้อม |
| คลังมีของแต่ไม่ส่งพื้นที่นั้น | กรองคลังที่ให้บริการ | ไม่โชว์พร้อมขายเกินจริง |
| ของคืนรอตรวจ | ยังไม่เพิ่มพร้อมขาย | ปล่อยขายเมื่ออนุมัติ |
| ช่องทางส่งยอดไม่ผ่าน | แสดงงานค้างและลองตามกติกา | ไม่ปล่อยให้ผิดโดยไม่รู้ |
กันชนช่วยลดความเสี่ยง แต่ไม่แทนการตรวจ
ส่วนกันเผื่ออาจช่วยเมื่อช่องทางอัปเดตไม่ทัน แต่ต้องเลือกตามความเร็วขายและความหน่วงจริง ไม่หักเท่ากันทุกสินค้าโดยไม่ประเมิน
ให้รายงานระบุความต่างแต่ละ SKU ระหว่างคลังกับช่องทาง และแนวโน้มออเดอร์ที่ขาดของ เพื่อปรับทั้งกติกาและกระบวนการรับงาน
เช็กลิสต์ก่อนเริ่มทำระบบ
- SKU กลาง ตัวเลือก ชุดสินค้า และหน่วยขาย
- สถานะจอง ตัด ปล่อย และหมดอายุ
- คลังที่ให้บริการแต่ละช่องทาง
- สิทธิ์ API ข้อจำกัด และผู้รับงานซิงก์ไม่ผ่าน
คำถามที่พบบ่อย
ต้องอัปเดตทันทีทุกช่องทางหรือไม่?
ขึ้นกับสิทธิ์ ความถี่ที่รองรับ และยอดขาย ต้องออกแบบให้รับความหน่วงได้ และเปิดเผยความสดของข้อมูล
มี POS อยู่แล้วเพิ่มขายออนไลน์ได้ไหม?
ตรวจช่องทางอ่านและปรับสต๊อกของ POS เดิมก่อน จากนั้นเลือกจุดกลางข้อมูลและวิธีจองที่ทุกระบบทำงานร่วมกันได้
อ่านต่อจากแหล่งข้อมูลโดยตรง
ลิงก์ต่อไปนี้ประกอบประเด็นมาตรฐานและการเชื่อมต่อ ส่วนตัวอย่างขั้นตอนและตัวเลขในบทความใช้เพื่ออธิบายการออกแบบระบบ
ตรวจแหล่งข้อมูล: 11 ตุลาคม 2569 · สิทธิ์ API และข้อกำหนดอาจเปลี่ยนได้ ควรยืนยันก่อนเริ่มโครงการ