←ย้อนกลับไปหน้าบทความ
P
Pattawee NakkarinAUTHOR
34 views
Parcel Tracking ด้วย Barcode: ออกแบบจุดสแกนให้รู้สถานะพัสดุจริง
Handheld•13 นาทีในการอ่าน

Parcel Tracking ด้วย Barcode: ออกแบบจุดสแกนให้รู้สถานะพัสดุจริง

แนวทางออกแบบ Parcel Tracking ด้วย Barcode ตั้งแต่รหัสพัสดุ จุดสแกนรับเข้า คัดแยก โหลดขึ้นรถ ส่งมอบ ไปจนถึง Offline และข้อมูลซ้ำ

ลูกค้าถามว่าพัสดุอยู่ไหน แต่ระบบแสดงเพียง “รับเข้าระบบ” ทั้งที่ของผ่านคัดแยกและขึ้นรถไปแล้ว ปัญหาไม่ได้เกิดจาก Barcode ไม่พอเสมอไป แต่เกิดจากจุดสแกนไม่ครบ เหตุการณ์ไม่มีความหมาย หรือข้อมูลจากหลายฝ่ายไม่เชื่อมกัน Parcel Tracking ที่ดีต้องบันทึกว่า พัสดุชิ้นใด ผ่าน ขั้นตอนใด ที่ จุดใด และ เมื่อไร

คำตอบสั้น: ใช้รหัสพัสดุที่ไม่ซ้ำบนฉลาก แล้วออกแบบ Scan Event ที่จุดรับเข้า คัดแยก โหลดขึ้นรถ ส่งออก ปลายทาง และส่งมอบ Barcode ช่วยระบุตัวพัสดุ ส่วนระบบติดตามต้องตีความและตรวจความสมบูรณ์ของเหตุการณ์เอง

ประเด็นสำคัญที่ควรรู้

  • Tracking Number ของผู้ให้บริการกับ SSCC ตาม GS1 อาจเป็นคนละรหัส ต้องกำหนดความสัมพันธ์ให้ชัด
  • การสแกนหนึ่งครั้งไม่ได้พิสูจน์ว่าขั้นตอนธุรกิจสำเร็จ หากไม่มีการยืนยัน Location, เที่ยวรถ หรือผู้รับ
  • เหตุการณ์ควรมีรหัสพัสดุ เวลา จุดอ่าน ผู้ปฏิบัติงาน/เครื่อง และผลลัพธ์ พร้อมจัดการ Offline และส่งซ้ำ
  • GS1 EPCIS เสนอกรอบ What, When, Where, Why สำหรับข้อมูลการเคลื่อนย้าย แต่โครงการเล็กเริ่มจาก Event Model ที่เรียบง่ายได้
  • การพิมพ์ฉลากและการอ่านในสภาพขนส่งจริงสำคัญพอ ๆ กับ API ติดตาม

สารบัญ

  1. Parcel Tracking ต่างจากการมีเลขพัสดุอย่างไร
  2. กำหนดรหัสพัสดุและโครงสร้างข้อมูล
  3. วางจุดสแกนตั้งแต่รับเข้าถึงส่งมอบ
  4. เลือกอุปกรณ์สำหรับคลังและภาคสนาม
  5. จัดการ Offline ข้อมูลซ้ำ และข้อยกเว้น
  6. Pilot และ Checklist ก่อนขยายเส้นทาง

Parcel Tracking ต่างจากการมีเลขพัสดุอย่างไร

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

ข้อมูลตัวอย่างใช้ตอบคำถาม
IdentifierParcel ID หรือ SSCCพัสดุชิ้นไหน
Event timeเวลาที่เกิดจริงและเวลาที่ระบบรับเกิดเมื่อไร; มีการซิงก์ช้าหรือไม่
Locationจุดรับ, Hub, รถ, จุดส่งล่าสุดผ่านที่ใด
Business stepReceived, Sorted, Loaded, Deliveredขั้นตอนไหนสำเร็จ
Evidenceผู้สแกน, ภาพ/ลายเซ็นตามนโยบายใครยืนยันและตรวจย้อนหลังอย่างไร

GS1 SSCC ใช้ระบุ Logistic Unit เช่น กล่องหรือพัสดุได้ แต่ไม่ได้หมายความว่าผู้ให้บริการทุกแห่งใช้ SSCC แทนเลขภายใน หากทำงานร่วมหลายขนส่ง ให้เก็บ Mapping ระหว่างรหัสของผู้ส่ง SSCC และเลขของผู้ให้บริการ โดยกำหนดว่าเลขใดเป็น Primary Key ในแต่ละระบบ

กำหนดรหัสพัสดุและโครงสร้างข้อมูล

รหัสต้องไม่ซ้ำในช่วงอายุข้อมูลที่ธุรกิจกำหนด และต้องไม่ถูกนำกลับมาใช้จนเกิดการปะปนกับประวัติเก่า ฉลากอาจมี Barcode หรือ 2D Code ที่เครื่องและระบบปลายทางรองรับ GS1 Logistic Label Guideline แสดงตัวอย่างฉลากพัสดุที่ใช้ SSCC และข้อมูลผู้ส่ง–ผู้รับ พร้อมข้อแนะนำด้านตำแหน่ง Barcode แต่รูปแบบจริงต้องตกลงกับขนส่งปลายทาง

Did You Know? รหัสสินค้า (GTIN) กับรหัสพัสดุเป็นคนละระดับ พัสดุหนึ่งกล่องอาจบรรจุหลาย SKU และหลายชิ้น หากใช้ GTIN ของสินค้าเป็น Parcel ID ทุกกล่องที่บรรจุสินค้าชนิดเดียวกันอาจแยกกันไม่ได้

ก่อนพิมพ์ฉลากจำนวนมาก ให้ตรวจว่ารหัสมนุษย์อ่านได้ตรงกับข้อมูลใน Barcode, จำนวนหลักไม่ถูกตัด, Quiet Zone เหลือพอ และไม่ติดบนรอยต่อกล่อง อ่าน วิธีเลือกขนาดฉลาก Barcode และ ปัญหาคุณภาพการพิมพ์ Barcode

วางจุดสแกนตั้งแต่รับเข้าถึงส่งมอบ

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

จุดงานEvent ที่ต้องการตรวจอะไรนอกเหนือจากรหัส
รับเข้าต้นทางReceivedจำนวน ชิ้นสภาพเสียหาย และใบรับ
คัดแยกSortedเส้นทาง/Hub ปลายทาง
โหลดขึ้นรถLoadedเที่ยวรถ รายการที่ควรขึ้น และของตกค้าง
รับเข้าปลายทางArrivedเทียบกับ Manifest และพัสดุขาด/เกิน
นำจ่ายOut for deliveryผู้ขับ เส้นทางและข้อจำกัดการส่ง
ส่งมอบ/ส่งไม่สำเร็จDelivered หรือ Exceptionผู้รับ หลักฐาน และเหตุผลตามนโยบาย

Case Study (สถานการณ์จำลอง): ศูนย์กระจายสินค้าสแกนพัสดุขึ้นรถ แต่ระบบส่งสถานะ “Loaded” ทุกครั้งที่เครื่องอ่านผ่านกองกล่อง ทีมแก้โดยให้สแกน Parcel ID ภายใต้ Trip ID ที่เปิดอยู่ ตรวจ Manifest และปิดรอบโหลดก่อนบันทึก Event หนึ่งชิ้นต่อหนึ่งเที่ยวรถ ผลที่ต้องวัดคือของที่ขึ้นรถจริงเทียบกับรายการ ไม่ใช่จำนวน Beep กรณีนี้เป็นตัวอย่างวิธีออกแบบ ไม่ใช่ผลโครงการลูกค้า Arc Tech

อ่าน Handheld สำหรับ Logistics สำหรับงานคนขับและคลัง และ Packing Station Equipment สำหรับจุดแพ็กต้นทาง

หากจุดโหลดมีพัสดุขาดหรือเกินบ่อย ส่ง Manifest กับขั้นตอนสแกนให้ทีม Arc Tech ช่วยออกแบบ Pilot พร้อมทดลอง Handheld ที่ใช้ในภาคสนาม กับแอปจริงได้

เลือกอุปกรณ์สำหรับคลังและภาคสนาม

ที่โต๊ะแพ็กอาจใช้ Scanner มีสายกับคอมพิวเตอร์และ Barcode Printer; บนสายคัดแยกหรือท่าโหลดต้องดูระยะอ่านและความทนของเครื่อง ส่วนภาคสนามมักต้องใช้ Handheld Computer ที่มีแอป กล้อง และเครือข่ายตามพื้นที่จริง ไม่ใช่ Scanner ไร้สายที่ไม่มีระบบจัดการ Event ในตัว

สถานีอุปกรณ์เริ่มทดลองเกณฑ์ผ่าน
แพ็กและพิมพ์ฉลากหมวด Barcode Printer + Scannerรหัสถูกและพิมพ์อ่านได้หลังแปะกล่อง
โหลดและคัดแยกหมวด Scanner หรือ Handheldอ่านในมุม/ระยะจริงพร้อมยืนยัน Trip
ส่งมอบนอกสถานที่iData T3 Pro หรือรุ่นที่ทดสอบผ่านแอปทำงานออฟไลน์และซิงก์ Event ไม่ซ้ำ

Common Mistakes: เลือกจากระยะอ่านสูงสุดในห้องทดลอง, พิมพ์ฉลากบนรอยพับกล่อง, และใช้ Tracking Number เป็นหลักฐานว่าได้ส่งมอบแล้วทั้งที่ไม่มี Event ยืนยัน

จัดการ Offline ข้อมูลซ้ำ และข้อยกเว้น

ภาคสนามอาจไม่มีสัญญาณชั่วคราว แอปควรเก็บ Event time จริง, Device ID, ผู้ใช้ และรหัสอ้างอิงเหตุการณ์ไว้ใน Queue แล้วส่งเมื่อกลับมาออนไลน์ API ควรป้องกันการส่งซ้ำด้วย Event ID หรือ Idempotency Key และแจ้งเมื่อมี Event ลำดับผิด เช่น Delivered ก่อน Loaded โดยไม่ซ่อนข้อมูลต้นฉบับ

Best Practice: แยก event_time ออกจาก received_at เพื่อเห็นความล่าช้าจากการซิงก์ และกำหนดสถานะข้อยกเว้น เช่น ฉลากเสีย พัสดุไม่มีใน Manifest ลูกค้าไม่รับ หรืออ่านรหัสไม่พบ จากนั้นให้ผู้รับผิดชอบแก้ในระบบพร้อม Audit trail

Troubleshooting: ถ้าเห็นสถานะวนซ้ำ ตรวจการ Retry ของแอป; ถ้าพัสดุถึง Hub แต่ไม่มี Event ตรวจจุดสแกน/Network/Manifest; ถ้าฉลากอ่านไม่ติดเฉพาะกล่องบางวัสดุ ตรวจตำแหน่งติดและคุณภาพพิมพ์ก่อนเพิ่มเครื่องอ่าน

Pilot และ Checklist ก่อนขยายเส้นทาง

เลือกเส้นทางหนึ่งที่มี Hub ต้นทางและปลายทางชัด ให้ทีมงานสแกนตามขั้นตอนจริง แล้วเทียบพัสดุบนรถกับ Manifest และ Event ในระบบ วัดความครบของ Event, ระยะเวลาที่ข้อมูลปรากฏ, พัสดุที่ต้องแก้มือ และความถูกต้องของหลักฐานส่งมอบ

  • กำหนด Parcel ID ไม่ซ้ำและ Mapping กับเลขขนส่ง
  • นิยาม Event, ผู้รับผิดชอบและเงื่อนไขเปลี่ยนสถานะ
  • ทดสอบฉลากบนกล่องจริงหลังขนย้าย
  • ตรวจ Scan ที่รับเข้า คัดแยก โหลด ปลายทางและส่งมอบ
  • ทดสอบออฟไลน์ การส่งซ้ำ และข้อมูลลำดับผิด
  • กำหนดนโยบายหลักฐานและสิทธิ์เข้าถึงข้อมูลผู้รับ
  • มี Dashboard แสดงรายการไม่มี Event หรือค้างผิดปกติ

Arc Tech Recommendation: เริ่มจากจุดโหลดขึ้นรถซึ่งมักเป็นคอขวด แล้วทดลอง iData T3 Pro ที่ Arc Tech จำหน่าย กับแอปและฉลากของคุณจริง ทีม Arc Tech ช่วยประเมินการสแกนและการเชื่อมระบบก่อนขยายทั้งเส้นทาง

ข้อสรุปสำหรับระบบติดตามพัสดุ

เลขพัสดุทำให้ระบุชิ้นได้ แต่ Tracking ที่เชื่อถือได้ต้องมี Event ที่ยืนยันจากจุดงานจริง พร้อมจัดการ Offline และข้อมูลซ้ำ เริ่มจากเส้นทาง Pilot หนึ่งสาย วัดความครบของ Event เทียบพัสดุจริง แล้วค่อยขยายระบบและอุปกรณ์

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

เริ่มต้น

1. Parcel Tracking ด้วย Barcode คืออะไร? การผูกพัสดุรายชิ้นกับเหตุการณ์สแกนตามเส้นทาง

2. มีเลขพัสดุแล้วถือว่าติดตามได้ไหม? ยังต้องมี Event ที่จุดงานจริง

3. GTIN ใช้แทน Parcel ID ได้ไหม? โดยทั่วไปไม่ควร เพราะ GTIN ระบุชนิดสินค้า ไม่ใช่กล่องรายชิ้น

4. SSCC คืออะไร? รหัสมาตรฐาน GS1 สำหรับ Logistic Unit รายหน่วย

คลังและขนส่ง

5. ควรสแกนจุดใดก่อน? เริ่มจุดรับเข้าและโหลดขึ้นรถที่ระบุเจ้าของ Event ได้

6. ทำไมต้องสแกนตอนโหลด? เพื่อเทียบของจริงกับเที่ยวรถและ Manifest

7. สแกนทุกเมตรดีไหม? ไม่จำเป็น เลือกจุดที่สถานะธุรกิจเปลี่ยนจริง

8. พัสดุหลายชิ้นในกล่องเดียวทำอย่างไร? ออกแบบความสัมพันธ์ระหว่างกล่องและชิ้นย่อย

9. ของตกค้างบนท่าโหลดรู้ได้อย่างไร? เทียบรายการคาดหมายกับผลสแกนปิดเที่ยวรถ

10. Cross Dock ต้องมี Event พิเศษไหม? ควรระบุรับ–คัด–ส่งออกตามทางผ่านจริง

ระบบและข้อมูล

11. ทำไม Event ต้องมีเวลาเกิดจริง? เพื่อแยกเวลาหน้างานจากเวลาซิงก์ระบบ

12. Offline แล้วข้อมูลหายไหม? ไม่ควร หากแอปเก็บ Queue และทดสอบการกู้คืน

13. ส่ง Event ซ้ำแก้อย่างไร? ใช้ Event ID และกฎ Idempotency

14. Delivered ก่อน Arrived ทำอย่างไร? เก็บข้อมูลต้นฉบับและแจ้งตรวจลำดับผิด

15. ลูกค้าเห็นสถานะทุก Scan ไหม? ควรเผยแพร่เฉพาะ Event ที่มีความหมายและผ่านกฎธุรกิจ

16. ต้องใช้ EPCIS เสมอไหม? ไม่จำเป็นใน Pilot แต่แนวคิด Event ช่วยออกแบบข้อมูล

17. Tracking Number กับ SSCC ต่างกันไหม? อาจต่างกันตามผู้ให้บริการ ควรเก็บ Mapping

18. ต้องเก็บข้อมูลผู้รับบน Barcode ไหม? ไม่ควรเก็บข้อมูลเกินจำเป็น ให้ระบบจัดการตามสิทธิ์

อุปกรณ์และฉลาก

19. ใช้ Scanner 1D ได้ไหม? ได้เมื่อรหัสที่ใช้เป็น 1D และหน้างานรองรับ

20. ต้องใช้ 2D Scanner ไหม? เมื่อฉลากใช้ 2D หรือระบบต้องอ่านหลายชนิดรหัส

21. Handheld ต่างจาก Scanner ไร้สายอย่างไร? Handheld มี OS และแอปจัดการ Workflow

22. พิมพ์ฉลากด้วย Direct Thermal ได้ไหม? ได้ในงานระยะสั้นที่ทดสอบสภาพขนส่งผ่าน

23. ฉลากเปียกแล้วอ่านไม่ติดแก้ตรงไหน? ตรวจวัสดุ การเคลือบ ตำแหน่งติดและวิธีพิมพ์

24. Barcode ควรอยู่บนรอยพับไหม? ควรหลีกเลี่ยงตำแหน่งที่บิดหรือเสียหายง่าย

Pilot และแก้ปัญหา

25. วัดผล Pilot จากอะไร? ความครบของ Event ความล่าช้า และรายการผิดเทียบของจริง

26. ถ้า Scanner มีเสียงแต่ไม่ขึ้นสถานะ? ตรวจแอป Trip ID และการส่ง Event

27. ถ้าสถานะซ้ำหลายรอบ? ตรวจ Retry และกฎกรอง Event

28. ถ้าพัสดุหายระหว่างทาง? ตรวจ Last confirmed event แล้วสอบสวนขั้นตอนถัดไป

29. ต้องเชื่อมผู้ให้บริการหลายรายอย่างไร? ทำ Mapping รหัสและสถานะของแต่ละราย

30. Arc Tech ช่วยส่วนใด? ช่วยประเมินอุปกรณ์สแกน ฉลากและการเชื่อม Workflow

บทความและหน้าที่เกี่ยวข้อง

แหล่งอ้างอิงภายนอก

ปรึกษาการออกแบบจุดสแกนพัสดุ

หากพัสดุมีเลขแต่สถานะยังไม่ช่วยตอบลูกค้า ส่งตัวอย่างฉลาก Manifest และขั้นตอนโหลด–ส่งมอบให้ Arc Tech ช่วยวาง Pilot พร้อมทดลอง Handheld สำหรับงานขนส่งที่มีบนเว็บ กับแอปจริงครับ

ถูกใจบทความนี้? ช่วยกดสนับสนุนให้ผู้เขียนด้วยครับ
แชร์บทความนี้

ความคิดเห็น (0)

กำลังโหลดความคิดเห็น...

ร่วมแสดงความคิดเห็น

แนะนำบทความอื่นๆ

Chat with usCall us