เปิดร้านใน Shopee, Lazada และ TikTok Shop พร้อมเว็บไซต์ของตัวเอง ยอดขายอาจโตขึ้น แต่ทีมหลังบ้านกลับเจอปัญหาออร์เดอร์บางรายการหายไป สินค้าชิ้นเดียวกันมีหลาย SKU และระบบหนึ่งแจ้งว่ามีของ ขณะที่อีกระบบตัดสต็อกไปแล้ว หากแก้ด้วยการให้พนักงานกดนำเข้าข้อมูลทุกเช้า ธุรกิจจะยิ่งตามออร์เดอร์ไม่ทันในวันที่ยอดขายพุ่ง
การ เชื่อม Marketplace กับ ERPNext ไม่ใช่แค่ส่งข้อมูลคำสั่งซื้อให้สำเร็จหนึ่งครั้ง สิ่งที่ต้องออกแบบจริงคือเจ้าของข้อมูล การเปลี่ยนสถานะ อัตลักษณ์ของสินค้า การอัปเดตสต็อก และวิธีฟื้นตัวเมื่อ API ขัดข้อง บทความนี้สรุปหลักการที่นำไปใช้ได้กับหลายช่องทาง โดยรายละเอียด API และสิทธิ์การเข้าถึงจริงจะขึ้นอยู่กับผู้ให้บริการแต่ละแพลตฟอร์ม
ก่อนต่อ API ต้องตกลงว่าใครเป็นเจ้าของข้อมูลแต่ละส่วน
- Marketplace เป็นแหล่งข้อมูลออร์เดอร์จากลูกค้าและสถานะที่แพลตฟอร์มยืนยัน เช่น สถานะการชำระเงินหรือจัดส่ง
- OMS เป็นชั้นรวมคำสั่งซื้อจากหลายช่องทาง ใช้ติดตาม แพ็ก จัดส่ง และจัดการกรณีผิดปกติ
- ERPNext เป็นระบบหลักสำหรับข้อมูลสินค้า คลัง การซื้อขาย และบัญชีตามขอบเขตที่องค์กรเลือก
- WMS ใช้เมื่อต้องควบคุมตำแหน่งจัดเก็บ การหยิบ การตรวจ และการเคลื่อนไหวในคลังอย่างละเอียด
ไม่ใช่ทุกร้านต้องใช้ OMS และ WMS แยกต่างหาก ร้านเล็กอาจใช้กระบวนการใน ERPNext ได้เลย แต่เมื่อมีหลายช่องทางและหลายคลัง การวางชั้นกลางเพื่อตรวจสอบเหตุการณ์และควบคุมงานแพ็กช่วยลดผลกระทบต่อระบบบัญชี สำคัญที่สุดคืออย่าส่งสถานะ “ชำระเงินแล้ว” ไปแทนสถานะ “ส่งของแล้ว” เพราะเป็นคนละเหตุการณ์
SKU Mapping ต้องตรงระดับตัวเลือกสินค้า ไม่ใช่แค่ชื่อ
เสื้อชื่อเดียวกันอาจมี 4 สีและ 5 ไซซ์ หากแมปจากชื่อสินค้าเพียงอย่างเดียว ออร์เดอร์สีดำไซซ์ L อาจไปตัด SKU สีดำไซซ์ M ได้โดยไม่มีใครรู้จนกว่าจะหยิบของจริง การเชื่อมต่อที่ดีควรใช้ SKU ภายในเป็นรหัสหลัก และเก็บรหัสรายการขายของ Marketplace เช่น Item ID, Variant ID หรือ Model ID แยกไว้ตามช่องทาง
รายการจาก Marketplace ที่ยังไม่แมปควรถูกนำเข้ามาเป็นออร์เดอร์ที่ รอตรวจสอบ Mapping ได้ ไม่ควรทิ้งออร์เดอร์เพราะไม่พบสินค้า และไม่ควรสร้างสินค้าซ้ำทุกครั้งที่ดึงข้อมูลเข้า เมื่อเจ้าหน้าที่จับคู่ SKU ได้แล้วจึงส่งไปขั้นตอนจองหรือเตรียมสินค้า โดยเก็บชื่อ ราคา ส่วนลด และตัวเลือกสินค้าตามข้อมูล ณ เวลาที่ลูกค้าสั่งไว้ด้วย
ถ้ามีสินค้าหลายระบบหรือเคยนำเข้าผิดรหัส ให้ทำตารางจับคู่และการตรวจคู่ซ้ำก่อนเปิดงานจริง การมี Item Master ที่เป็นระเบียบสำคัญพอ ๆ กับ API อ่านรายละเอียดแนวทางคลังต่อได้ที่ ERPNext Inventory และ Warehouse Management
สต็อกจริงกับสต็อกพร้อมขายบนหน้าร้านไม่ใช่เลขเดียวกัน
สมมติสินค้ามีอยู่จริง 15 ชิ้น มีออร์เดอร์จองไว้แล้ว 5 ชิ้น และกันไว้สำหรับหน้าร้าน 2 ชิ้น จำนวนที่พร้อมเปิดขายออนไลน์อาจเหลือ 8 ชิ้น แต่ตัวเลขนี้ยังขึ้นกับว่ามีสินค้าอยู่คลังใด จัดสรรให้ช่องทางไหน และนโยบายกัน Oversell เป็นอย่างไร
ควรแสดงอย่างน้อย 3 มุมมองให้ทีมเข้าใจตรงกัน ได้แก่ Actual/Physical Stock, Reserved/Allocated Stock และ Sellable/Published Stock อย่านำยอดจากหลายคลังมาบวกส่งหน้าร้านโดยอัตโนมัติหากบางคลังส่งสินค้านั้นไม่ได้จริง โดยเฉพาะสินค้าชำรุด ของรอตรวจ หรือของคนละบริษัท
เมื่อระบบภายในไม่สามารถอ่านสต็อกได้เพราะ API ล่ม ควรมีกติกา fail-safe และแจ้งผู้รับผิดชอบ ไม่ควรเผยแพร่สต็อกเป็นศูนย์ทันทีจากความผิดพลาดชั่วคราว เพราะอาจทำให้สินค้าถูกปิดขายพร้อมกันหลายช่องทางโดยไม่จำเป็น
Webhook ช่วยลดความหน่วง แต่ต้องออกแบบกันเหตุการณ์ซ้ำ
การเชื่อมต่อที่ใช้ Webhook เป็นตัวรับเหตุการณ์ช่วยลดการสอบถามข้อมูลซ้ำ ๆ แต่ Webhook ไม่ได้หมายความว่าจะมาถึงเพียงครั้งเดียวเสมอ ระบบรับข้อมูลควรตรวจลายเซ็นหรือวิธีตรวจสอบผู้ส่งตามข้อกำหนดของแพลตฟอร์ม เก็บ Event ID หรือรหัสอ้างอิงที่ตรวจซ้ำได้ แล้วตอบรับอย่างรวดเร็วก่อนนำงานไปประมวลผลในคิว
- แยกขั้นตอนรับ Event ออกจากขั้นตอนเขียนลง ERPNext เพื่อไม่ให้การตอบกลับแพลตฟอร์มติดเวลาประมวลผลบัญชี
- ใช้ Idempotency Key จากแพลตฟอร์มและประเภทเหตุการณ์ ป้องกันสร้าง Sales Order หรือ Payment Entry ซ้ำ
- เก็บสถานะงาน Pending, Processing, Completed และ Failed รวมถึงเหตุผลที่ผิดพลาดอย่างอ่านเข้าใจได้
- มีระบบ Retry แบบจำกัด พร้อม Backoff และรายการให้เจ้าหน้าที่แก้เฉพาะเคสที่ล้มเหลว
- ทำ Recovery Scan ช่วงเวลาสั้น ๆ หรือดึงย้อนหลังตามคำสั่งผู้ใช้ เมื่อเหตุการณ์หลุดจากช่องทางหลัก
หากแพลตฟอร์มไม่รองรับ Webhook สำหรับเหตุการณ์นั้น อาจต้องใช้ API ดึงการเปลี่ยนแปลงตามช่วงเวลาอย่างมีขอบเขต และเก็บ Cursor หรือจุดล่าสุดที่ตรวจเสร็จไว้ ไม่ควรวนดึงออร์เดอร์ทั้งหมดตั้งแต่เปิดร้านทุกครั้ง
จ่ายเงินแล้วไม่ได้แปลว่าส่งสินค้าแล้ว
Marketplace อาจมีสถานะ Paid, Ready to Ship, Shipped, Delivered, Cancelled และ Refunded ซึ่งไม่ควรนำไปแมปเป็นสถานะทางบัญชีหรือสต็อกเพียงค่าเดียว ใน ERPNext ให้แยก Sales Order, Delivery Note, Sales Invoice และ Payment Entry ตามหน้าที่เอกสาร แล้วออกแบบการเชื่อมกลับไปแพลตฟอร์มเมื่อมีการจัดส่งจริง
เมื่อเกิดการคืนสินค้า ต้องแยกให้ชัดว่าลูกค้าได้เงินคืนหรือยัง สินค้ากลับเข้าคลังจริงหรือไม่ และควรออก Credit Note เมื่อไร อย่าให้ข้อความสถานะ Returned ไปเพิ่มสต็อกหรือคืนเงินเองโดยไม่มีเอกสารอ้างอิง หากอยากเห็นตัวอย่างความต่างของเอกสารขาย อ่าน เอกสารงานขายใน ERPNext ตั้งแต่ใบเสนอราคาถึงรับเงิน
รายงานที่ควรมีตั้งแต่วันแรก
- จำนวนออร์เดอร์เข้าใหม่ แยกช่องทาง และจำนวนที่รอ Mapping
- จำนวนและอายุของงานซิงก์ Failed/Retry แยกสาเหตุ เช่น SKU หาย หรือ Token หมดอายุ
- ยอด Actual/Reserved/Sellable Stock พร้อมคลังที่ใช้คำนวณ
- จำนวนออร์เดอร์จ่ายแล้วแต่ยังไม่แพ็ก และแพ็กแล้วแต่ยังไม่มีเลขติดตาม
- รายการรับเงินที่ยังไม่จัดสรร ใบคืนสินค้า และยอดเงินคืนที่ยังรอตรวจสอบ
ถ้าระบบไม่มีหน้าตรวจงานซิงก์ ทีมงานมักพบปัญหาหลังลูกค้าทักมาเท่านั้น จึงควรทำ Dashboard ที่กดเข้าไปดูรายการจริงได้ ไม่ใช่มีแค่ตัวเลขรวมว่า “เชื่อมต่อสำเร็จ”
เริ่มเชื่อมทีละช่องทางหรือเปิดพร้อมกันทั้งหมดดี
เริ่มจากหนึ่งช่องทางที่มี SKU และคำสั่งซื้อหลายรูปแบบ เช่น มีตัวเลือกสินค้า ส่วนลด จัดส่งบางส่วน และคืนสินค้า ทดสอบข้อมูลแบบใหม่ ย้อนหลัง และเหตุการณ์ซ้ำให้ครบ แล้วจึงเพิ่มอีกช่องทางโดยใช้ Mapping และหลักการซิงก์ชุดเดียวกัน การเริ่มเล็กไม่ได้ทำให้สถาปัตยกรรมด้อยลง แต่ช่วยให้เห็น Root Cause ก่อนข้อมูลสะสมผิดเป็นจำนวนมาก
ถ้าองค์กรกำลังออกแบบระบบหลายช่องทาง สามารถดูบริการ เชื่อมต่อ ERP, API และ Marketplace และแนวทาง วางระบบ ERPNext เพื่อกำหนดว่าข้อมูลใดควรอยู่ในระบบหลักและข้อมูลใดควรอยู่ในระบบขาย
คำถามที่พบบ่อย
มีชื่อสินค้าเหมือนกันแต่ SKU ไม่เหมือนกัน รวมเป็นสินค้าเดียวได้ไหม
ทำได้เมื่อพิสูจน์แล้วว่าเป็นสินค้าชนิดเดียวกันและคุณลักษณะตรงกัน ควรแมปจากรหัสสินค้าและตัวเลือก ไม่ใช่จากการสะกดชื่อโดยอัตโนมัติ
ถ้า API Marketplace ล่ม จะทำอย่างไรไม่ให้ออร์เดอร์หาย
ต้องเก็บเหตุการณ์และสถานะการประมวลผลไว้ในระบบคิว พร้อมวิธีตรวจย้อนหลังเฉพาะช่วงเวลาที่ขาด และมีเจ้าหน้าที่รับผิดชอบงานผิดพลาด
เชื่อมต่อแล้ว ERPNext ต้องเป็นตัวตัดสต็อกทั้งหมดไหม
ไม่จำเป็นต้องให้ ERPNext ทำทุกขั้น แต่ต้องกำหนดแหล่งข้อมูลจริงและจุดที่ยืนยันการหักหรือจองสต็อกไม่ให้เกิดซ้ำกันระหว่าง OMS/WMS/ERP
