ลูกค้าถามว่าพัสดุอยู่ไหน แต่ระบบแสดงเพียง “รับเข้าระบบ” ทั้งที่ของผ่านคัดแยกและขึ้นรถไปแล้ว ปัญหาไม่ได้เกิดจาก Barcode ไม่พอเสมอไป แต่เกิดจากจุดสแกนไม่ครบ เหตุการณ์ไม่มีความหมาย หรือข้อมูลจากหลายฝ่ายไม่เชื่อมกัน Parcel Tracking ที่ดีต้องบันทึกว่า พัสดุชิ้นใด ผ่าน ขั้นตอนใด ที่ จุดใด และ เมื่อไร
คำตอบสั้น: ใช้รหัสพัสดุที่ไม่ซ้ำบนฉลาก แล้วออกแบบ Scan Event ที่จุดรับเข้า คัดแยก โหลดขึ้นรถ ส่งออก ปลายทาง และส่งมอบ Barcode ช่วยระบุตัวพัสดุ ส่วนระบบติดตามต้องตีความและตรวจความสมบูรณ์ของเหตุการณ์เอง
ประเด็นสำคัญที่ควรรู้
- Tracking Number ของผู้ให้บริการกับ SSCC ตาม GS1 อาจเป็นคนละรหัส ต้องกำหนดความสัมพันธ์ให้ชัด
- การสแกนหนึ่งครั้งไม่ได้พิสูจน์ว่าขั้นตอนธุรกิจสำเร็จ หากไม่มีการยืนยัน Location, เที่ยวรถ หรือผู้รับ
- เหตุการณ์ควรมีรหัสพัสดุ เวลา จุดอ่าน ผู้ปฏิบัติงาน/เครื่อง และผลลัพธ์ พร้อมจัดการ Offline และส่งซ้ำ
- GS1 EPCIS เสนอกรอบ What, When, Where, Why สำหรับข้อมูลการเคลื่อนย้าย แต่โครงการเล็กเริ่มจาก Event Model ที่เรียบง่ายได้
- การพิมพ์ฉลากและการอ่านในสภาพขนส่งจริงสำคัญพอ ๆ กับ API ติดตาม
สารบัญ
- Parcel Tracking ต่างจากการมีเลขพัสดุอย่างไร
- กำหนดรหัสพัสดุและโครงสร้างข้อมูล
- วางจุดสแกนตั้งแต่รับเข้าถึงส่งมอบ
- เลือกอุปกรณ์สำหรับคลังและภาคสนาม
- จัดการ Offline ข้อมูลซ้ำ และข้อยกเว้น
- Pilot และ Checklist ก่อนขยายเส้นทาง
Parcel Tracking ต่างจากการมีเลขพัสดุอย่างไร
เลขพัสดุเป็นกุญแจระบุชิ้น ส่วน Tracking เป็นประวัติการเปลี่ยนสถานะที่ตรวจสอบได้ หากมีแต่เลขติดกล่องโดยไม่บันทึกการรับเข้าและส่งต่อ ระบบไม่อาจรู้ว่าของติดอยู่ขั้นใด ในทางกลับกัน หากบันทึก Scan ทุกครั้งโดยไม่กรองซ้ำ ผู้ใช้จะเห็นสถานะจำนวนมากแต่ยังตอบไม่ได้ว่าใครรับผิดชอบ
| ข้อมูล | ตัวอย่าง | ใช้ตอบคำถาม |
|---|---|---|
| Identifier | Parcel ID หรือ SSCC | พัสดุชิ้นไหน |
| Event time | เวลาที่เกิดจริงและเวลาที่ระบบรับ | เกิดเมื่อไร; มีการซิงก์ช้าหรือไม่ |
| Location | จุดรับ, Hub, รถ, จุดส่ง | ล่าสุดผ่านที่ใด |
| Business step | Received, 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
บทความและหน้าที่เกี่ยวข้อง
- Handheld สำหรับ Logistics
- RFID สำหรับ Logistics
- วิธีเลือก Printer สำหรับ Shipping Label
- คุณภาพการพิมพ์ Barcode
- iData T3 Pro
- หมวด Printer
- หมวด Scanner
แหล่งอ้างอิงภายนอก
ปรึกษาการออกแบบจุดสแกนพัสดุ
หากพัสดุมีเลขแต่สถานะยังไม่ช่วยตอบลูกค้า ส่งตัวอย่างฉลาก Manifest และขั้นตอนโหลด–ส่งมอบให้ Arc Tech ช่วยวาง Pilot พร้อมทดลอง Handheld สำหรับงานขนส่งที่มีบนเว็บ กับแอปจริงครับ



