การทำให้สถานะการติดตามของผู้ขนส่งเป็นมาตรฐาน: วิธีแมปเหตุการณ์ของผู้ขนส่งเข้าสู่โมเดลสถานะเดียว
การทำให้สถานะการติดตามของผู้ให้บริการขนส่งเป็นมาตรฐาน หมายถึงการแปลรหัสสแกนและข้อความเฉพาะของผู้ให้บริการขนส่งให้เป็นโมเดลการจัดส่งที่สอดคล้องกัน โดยยังคงรักษาหลักฐานต้นฉบับไว้ การนำไปใช้อย่างน่าเชื่อถือควรแมปแต่ละเหตุการณ์กับสถานะมาตรฐานและเหตุผล จากนั้นคำนวณสถานะปัจจุบันของการจัดส่งโดยใช้เวลาของเหตุการณ์ บริบทของการจัดส่ง และกฎการเปลี่ยนสถานะที่ชัดเจน อย่าถือว่าข้อความล่าสุดที่ได้รับเป็นสถานะปัจจุบันของการจัดส่งโดยอัตโนมัติ
คู่มือนี้จัดทำขึ้นสำหรับนักพัฒนา ทีมปฏิบัติการด้านโลจิสติกส์ และเจ้าของผลิตภัณฑ์ที่กำลังสร้างระบบติดตามในระบบจัดการคำสั่งซื้อ แดชบอร์ดสนับสนุน หรือเวิร์กโฟลว์การแจ้งเตือนลูกค้า โมเดลด้านล่างเป็นรูปแบบการนำไปใช้ที่เสนอ ไม่ใช่มาตรฐานอย่างเป็นทางการของผู้ให้บริการขนส่งหรือการจำลองอนุกรมวิธานสถานะของผู้ให้บริการติดตามรายใด
แยกเหตุการณ์ของผู้ให้บริการขนส่งออกจากสถานะการจัดส่ง
เหตุการณ์การติดตามอธิบายสิ่งที่มีการรายงานเกี่ยวกับการจัดส่ง เช่น มีการสร้างฉลาก พัสดุไปถึงศูนย์คัดแยก หรือความพยายามจัดส่งไม่สำเร็จ ส่วนสถานะการจัดส่งคือการตีความหลักฐานที่เกี่ยวข้องของแอปพลิเคชัน ณ ช่วงเวลาหนึ่ง แนวคิดทั้งสองควรจัดเก็บแยกกัน
ตัวอย่างเช่น พัสดุอาจมีเหตุการณ์พยายามจัดส่งตามด้วยเหตุการณ์มาถึงศูนย์คัดแยก การมาถึงเป็นประวัติการดำเนินงานที่มีประโยชน์ แต่ไม่ได้หมายความว่าสภาวะการพยายามจัดส่งที่ล้มเหลวได้รับการแก้ไขแล้วเสมอไป ในทางกลับกัน การสแกนล่าช้าที่มาถึงหลังการยืนยันการจัดส่งไม่ควรทำให้พัสดุกลับไปอยู่ในสถานะกำลังขนส่งโดยอัตโนมัติ
สถาปัตยกรรมเชิงปฏิบัติมี 3 ชั้น:
- หลักฐานดิบ: เพย์โหลดต้นฉบับจากผู้ให้บริการขนส่งหรือผู้ให้บริการระบบ รวมถึงรหัส ข้อความ เวลา และตัวระบุ
- เหตุการณ์ที่ทำให้เป็นมาตรฐาน: การตีความเหตุการณ์แต่ละรายการโดยใช้กฎการแมปที่มีเวอร์ชัน
- ภาพสถานะปัจจุบันของการจัดส่ง: สถานะที่เลือกจากประวัติเหตุการณ์ รวมถึงเงื่อนไขที่ยังใช้งานอยู่และการดำเนินการของลูกค้า
การแยกเช่นนี้ช่วยให้คุณแก้ไขการแมปและสร้างสถานะการจัดส่งใหม่ได้โดยไม่ต้องทิ้งบันทึกต้นฉบับ
กำหนดโมเดลสถานะขนาดกะทัดรัดพร้อมเงื่อนไขที่แยกจากกัน
ฟิลด์สถานะเดียวจะดูแลรักษาได้ยากเมื่อจำเป็นต้องแทนการเคลื่อนย้ายทางกายภาพ การดำเนินพิธีการศุลกากร ปัญหาการจัดส่ง และการคืนสินค้าพร้อมกัน ให้ใช้โมเดลวงจรชีวิตขนาดเล็ก แล้วแนบเงื่อนไขและเหตุผลที่เฉพาะเจาะจงเพิ่มเติม
| สถานะมาตรฐาน | ความหมายที่แนะนำ | ขอบเขตที่ต้องรักษาไว้ |
|---|---|---|
| UNKNOWN | ไม่สามารถแมปหลักฐานได้อย่างมั่นใจ | ไม่เทียบเท่ากับสูญหายหรือล่าช้า |
| PRE_TRANSIT | มีข้อมูลการจัดส่งทางอิเล็กทรอนิกส์ แต่ยังไม่มีการยืนยันการรับพัสดุทางกายภาพ | การสร้างฉลากไม่ใช่หลักฐานว่าผู้ให้บริการขนส่งครอบครองพัสดุ |
| IN_TRANSIT | การจัดส่งกำลังเคลื่อนผ่านหรืออยู่ระหว่างการดำเนินการภายในเครือข่ายจัดส่ง | ไม่ได้หมายความว่าจะจัดส่งถึงในวันนั้น |
| OUT_FOR_DELIVERY | แหล่งข้อมูลรายงานอย่างชัดเจนว่ามีการนำพัสดุออกไปเพื่อพยายามจัดส่ง | การมาถึงศูนย์คัดแยกในพื้นที่ยังไม่เพียงพอ |
| READY_FOR_PICKUP | การจัดส่งพร้อมให้ผู้รับมารับด้วยตนเองอย่างชัดเจน | การมาถึงจุดรับสินค้าเพียงอย่างเดียวอาจยังไม่ยืนยันความพร้อม |
| DELIVERED | มีการยืนยันการจัดส่งสำหรับช่วงการจัดส่งที่เกี่ยวข้องอย่างชัดเจน | การส่งต่อระหว่างผู้ให้บริการขนส่งไม่จำเป็นต้องหมายถึงการส่งถึงผู้รับ |
| CANCELED | แหล่งข้อมูลยืนยันอย่างชัดเจนว่าบันทึกการจัดส่งถูกยกเลิก | การยกเลิกคำสั่งซื้อไม่ได้พิสูจน์ว่าพัสดุหยุดเคลื่อนที่ |
เก็บเงื่อนไขต่าง ๆ เช่น CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE หรือ DELAY_REPORTED ไว้นอกฟิลด์วงจรชีวิตหลัก การจัดส่งอาจยังคงเป็น IN_TRANSIT ขณะที่ปัญหาที่อยู่ต้องได้รับการแก้ไข อย่าระบุว่าการดำเนินพิธีการศุลกากรตามปกติเป็นข้อยกเว้น เว้นแต่แหล่งข้อมูลจะรายงานว่ามีการกักไว้ ปัญหา หรือจำเป็นต้องดำเนินการ
ให้แสดงทิศทางแยกต่างหากด้วยฟิลด์ เช่น journey_type การคืนสินค้าสามารถมีสถานะกำลังขนส่งและจัดส่งสำเร็จของตนเองได้ วิธีนี้ช่วยป้องกันการตีความว่าการจัดส่งคืนไปยังผู้ส่งคือการจัดส่งสำเร็จถึงผู้ซื้อ
สร้างระเบียนเหตุการณ์ก่อนเขียนกฎการแมป
ระเบียนที่ทำให้เป็นมาตรฐานควรมีบริบทเพียงพอที่จะอธิบายการแมปและทำซ้ำผลลัพธ์ได้ สคีมาเริ่มต้นที่มีประโยชน์ประกอบด้วย:
- ข้อมูลระบุตัวตน: ID การจัดส่งภายใน ตัวระบุผู้ให้บริการขนส่ง หมายเลขติดตาม แหล่งที่มา และช่วงการจัดส่ง
- หลักฐานต้นฉบับ: รหัสเหตุการณ์ดิบ คำอธิบายดิบ ID เหตุการณ์จากแหล่งข้อมูลเมื่อมีการระบุ และข้อมูลอ้างอิงไปยังเพย์โหลดต้นฉบับ
- เวลา: เวลาที่เกิดเหตุการณ์ ข้อมูลเขตเวลา เวลาที่รับข้อมูล และความละเอียดของเวลา
- การตีความ: สถานะมาตรฐาน เงื่อนไข รหัสเหตุผล ประเภทเส้นทาง และข้อกำหนดการดำเนินการ
- การตรวจสอบย้อนกลับ: ID กฎการแมป เวอร์ชันการแมป และหมวดหมู่ความมั่นใจ
แยกเวลาที่เกิดเหตุการณ์ออกจากเวลาที่ระบบได้รับการอัปเดต เว็บฮุกที่ได้รับในช่วงบ่ายอาจอธิบายการสแกนที่เกิดขึ้นในตอนเช้า การตอบกลับจากการดึงข้อมูลเป็นระยะก็อาจมีเหตุการณ์ในอดีตหลายรายการ ไม่ใช่เพียงเหตุการณ์ใหม่หนึ่งรายการ
ใช้รูปแบบเวลาที่มีการบันทึกไว้ เช่น RFC 3339 เมื่อทราบเวลาและออฟเซ็ต หากแหล่งข้อมูลให้เวลาท้องถิ่นโดยไม่มีออฟเซ็ตที่เชื่อถือได้ ให้รักษาข้อจำกัดนั้นไว้แทนการเพิ่มการระบุ UTC ที่ไม่ถูกต้อง เก็บเหตุการณ์ที่มีเฉพาะวันที่เป็นหลักฐานเฉพาะวันที่ แทนการสร้างเวลาสแกนที่แม่นยำขึ้นเอง
จัดเก็บเพย์โหลดดิบภายใต้การควบคุมสิทธิ์การเข้าถึงและกฎการเก็บรักษาที่เหมาะสม เนื่องจากอาจมีรายละเอียดผู้รับหรือข้อมูลอื่นที่ไม่ควรอยู่ในตารางวิเคราะห์ที่เข้าถึงได้อย่างกว้างขวาง
แมปรหัสของผู้ให้บริการขนส่งก่อน แล้วจึงใช้ข้อความอย่างระมัดระวัง
เริ่มจากกฎที่กำหนดขอบเขตตามแหล่งข้อมูลและผู้ให้บริการขนส่งที่เฉพาะเจาะจง รหัสอย่าง 01 ไม่มีความหมายที่เชื่อถือได้นอกบริบทที่มีการบันทึกไว้ หากแหล่งข้อมูลแยกบริการ ภูมิภาค หรือช่วงการจัดส่ง ให้รวมมิติเหล่านั้นเมื่อมีผลต่อการตีความ
ใช้ลำดับการแมปต่อไปนี้เป็นค่าเริ่มต้นในการนำไปใช้:
- จับคู่รหัสเหตุการณ์แบบมีโครงสร้างที่มีการบันทึกไว้ รวมถึงตัวระบุเพิ่มเติมที่จำเป็น
- ใช้สถานะหรือสถานะย่อยจากแหล่งข้อมูลที่มีการบันทึกไว้ เมื่ออธิบายเหตุการณ์ที่กำลังประมวลผลได้อย่างชัดเจน
- ใช้กฎจากข้อความที่มีขอบเขตแคบสำหรับข้อความที่รู้จักและไม่มีฟิลด์แบบมีโครงสร้างเพียงพอ
- ปล่อยเหตุการณ์ที่ยังไม่สามารถระบุได้ให้ไม่มีการแมป และส่งกรณีที่เกิดซ้ำให้ตรวจสอบ
ก่อนอื่นให้ตรวจสอบว่าฟิลด์สถานะของผู้ให้บริการอธิบายเหตุการณ์แต่ละรายการหรือสรุปสถานะปัจจุบันของการจัดส่ง การคัดลอกสรุประดับการจัดส่งไปใส่ในทุกเหตุการณ์ย้อนหลังอาจทำให้การสแกนก่อนหน้านี้ดูเหมือนเป็นการยืนยันการจัดส่ง
หลีกเลี่ยงกฎคีย์เวิร์ดทั่วโลก เช่น “มีคำว่า delivered” เนื่องจากวลี “not delivered” ก็จะตรงกันได้ เช่นเดียวกับข้อความที่อธิบายการจัดส่งให้พันธมิตรด้านโลจิสติกส์ กฎจากข้อความต้องรองรับการปฏิเสธ บริบทภาษา และข้อยกเว้น การแปลด้วยเครื่องอาจช่วยให้ผู้ตรวจสอบเข้าใจข้อความ แต่ถ้อยคำที่แปลแล้วไม่ควรกลายเป็นคำนิยามเหตุการณ์ที่เป็นทางการโดยไม่แจ้งให้ทราบ
ตัวอย่างการแมปและข้อจำกัด
ตัวอย่างด้านล่างใช้ข้อความสมมติขึ้นเพื่อสาธิตการออกแบบกฎ ไม่ใช่รหัสหรือข้อความที่ตรวจสอบแล้วจากผู้ให้บริการขนส่งรายใดรายหนึ่ง
- “Shipment details submitted”: แมปเป็น
PRE_TRANSITเมื่อคำนิยามของแหล่งข้อมูลระบุว่ามีเพียงข้อมูลทางอิเล็กทรอนิกส์ - “Accepted at origin facility”: แมปเป็น
IN_TRANSITเมื่อเหตุการณ์ยืนยันการรับพัสดุทางกายภาพ - “Recipient unavailable; attempt unsuccessful”: บันทึก
DELIVERY_ATTEMPT_FAILEDและประเมินวงจรชีวิตจากหลักฐานโดยรอบ อย่าสรุปว่าพร้อมให้ไปรับ - “Available for collection”: แมปเป็น
READY_FOR_PICKUPเมื่อแหล่งข้อมูลยืนยันว่าพร้อมให้ผู้รับมารับ - “Transferred to delivery partner”: บันทึกการส่งต่อและคงสถานะกำลังขนส่งที่เหมาะสม แทนการระบุว่าจัดส่งถึงผู้รับแล้ว
แต่ละกฎควรมีเหตุผลสั้น ๆ และผู้รับผิดชอบ เมื่อผู้เชี่ยวชาญด้านปฏิบัติการโต้แย้งการแมป ทีมควรระบุกฎที่แน่นอนได้ แทนการย้อนวิเคราะห์ป้ายกำกับที่แสดงต่อลูกค้า
คำนวณสถานะปัจจุบันด้วยตัวลดที่กำหนดผลลัพธ์แน่นอน
ตัวลดคือฟังก์ชันที่ประเมินเหตุการณ์ที่ทำให้เป็นมาตรฐานและสร้างภาพสถานะปัจจุบันของการจัดส่ง ตัวลดควรคืนผลลัพธ์เดียวกันเมื่อได้รับหลักฐานและเวอร์ชันกฎเดียวกัน ไม่ว่าจะเล่นอินพุตซ้ำกี่ครั้ง
กำจัดรายการซ้ำโดยไม่ลบการสแกนที่มีความหมาย
ควรใช้ตัวระบุเหตุการณ์จากแหล่งข้อมูลที่คงที่เมื่อมี หากไม่มี ให้สร้างคีย์กำจัดรายการซ้ำจากแอตทริบิวต์ที่มี เช่น ข้อมูลระบุตัวตนการจัดส่ง ผู้ให้บริการขนส่ง รหัส เวลาที่เกิดเหตุการณ์ และสถานที่ คำนึงถึงความละเอียดของเวลาและพฤติกรรมของแหล่งข้อมูล การสแกนสองรายการที่มีคำอธิบายเหมือนกันไม่จำเป็นต้องเป็นรายการซ้ำ โดยเฉพาะเมื่อพัสดุกลับมายังศูนย์เดิม
จัดลำดับเหตุการณ์โดยไม่สมมติว่านาฬิกาแม่นยำสมบูรณ์
ใช้เวลาที่เกิดเหตุการณ์ที่เชื่อถือได้และข้อมูลลำดับที่มีการบันทึกไว้เมื่อมี เวลาที่รับข้อมูลช่วยแก้กรณีที่เวลาเท่ากันได้ แต่ไม่ควรใช้แทนเวลาที่เกิดขึ้นก่อนหน้าเป็นประจำ หากเวลาขัดแย้งกันหรือไม่สามารถเปรียบเทียบได้อย่างน่าเชื่อถือ ให้รักษาความกำกวมไว้แทนการสร้างความแน่นอนขึ้นมาเอง
ตรวจสอบการเปลี่ยนสถานะแทนการกำหนดลำดับสากล
การเรียงสถานะด้วยตัวเลขแบบง่ายไม่สามารถแทนเส้นทางการจัดส่งทุกแบบได้ พัสดุอาจเปลี่ยนจากกำลังนำจ่ายกลับไปเป็นกำลังขนส่งหลังความพยายามจัดส่งไม่สำเร็จ ความพร้อมให้รับสินค้าอาจหมดอายุ และการแก้ไขอย่างชัดเจนอาจทำให้การยืนยันการจัดส่งเป็นโมฆะ
กำหนดการเปลี่ยนสถานะที่อนุญาตและหลักฐานที่แต่ละรายการต้องใช้ ถือว่าสถานะจัดส่งแล้วได้รับการปกป้องจากการสแกนเก่าตามปกติ แต่อนุญาตให้มีการแก้ไขที่บันทึกไว้หรือการแทนที่โดยผู้ปฏิบัติงานที่ได้รับอนุญาต บันทึกเหตุผลและแหล่งที่มาของการแทนที่ทุกครั้ง
ติดตามเงื่อนไขที่ยังใช้งานอยู่อย่างอิสระ
การสแกนการเคลื่อนย้ายในภายหลังอาจแสดงความคืบหน้า แต่ไม่ได้พิสูจน์ว่าปัญหาการชำระเงินหรือที่อยู่ได้รับการแก้ไข กำหนดกฎการล้างเงื่อนไขเฉพาะ เช่น การแก้ไขอย่างชัดเจน เหตุการณ์ที่แก้ไขปัญหาได้ตามตรรกะ หรือการดำเนินการด้วยตนเองที่ได้รับอนุญาต อย่าล้างทุกเงื่อนไขเพียงเพราะมีเหตุการณ์อื่นเข้ามา
แยกความล่าช้าที่ผู้ให้บริการขนส่งรายงานออกจากการแจ้งเตือนการไม่มีความเคลื่อนไหวของคุณเองด้วย การไม่มีการสแกนใหม่เป็นข้อสังเกตเกี่ยวกับความสดใหม่ของข้อมูล ไม่ใช่หลักฐานว่าพัสดุสูญหาย
จัดการการส่งต่อระหว่างผู้ให้บริการขนส่งและการคืนสินค้าเป็นเส้นทางที่เชื่อมโยงกัน
การติดตามข้ามพรมแดนอาจเกี่ยวข้องกับผู้ให้บริการขนส่งและตัวระบุหลายรายการ เก็บข้อมูลระบุตัวตนการจัดส่งภายใน และแนบข้อมูลอ้างอิงการติดตามเฉพาะผู้ให้บริการไว้กับช่วงการจัดส่งที่เกี่ยวข้อง เชื่อมโยงข้อมูลอ้างอิงโดยใช้ความสัมพันธ์ที่แหล่งข้อมูลจัดให้หรือข้อมูลปฏิบัติการที่ผ่านการตรวจสอบ ไม่ใช่เพียงปลายทางที่คล้ายกันหรือเวลาที่ใกล้เคียงกัน
เหตุการณ์จัดส่งในระดับช่วงการจัดส่งต้องตีความตามบริบท การจัดส่งไปยังศูนย์รวมสินค้าหรือเครือข่ายพันธมิตรอาจทำให้ช่วงนั้นเสร็จสมบูรณ์ แต่ไม่ได้ทำให้การจัดส่งถึงผู้ซื้อเสร็จสมบูรณ์ ภาพสถานะการจัดส่งของคุณต้องทราบว่าปลายทางของเหตุการณ์คือที่ใด
ในทำนองเดียวกัน ให้แยก “ขอคืนสินค้าแล้ว” “เริ่มเคลื่อนย้ายสินค้าคืนแล้ว” และ “คืนให้ผู้ส่งแล้ว” เนื่องจากเป็นเหตุการณ์สำคัญคนละแบบ คำขอคืนสินค้าไม่ได้พิสูจน์ว่าพัสดุกำลังเคลื่อนกลับทางกายภาพ และการยืนยันการจัดส่งของเส้นทางย้อนกลับควรระบุปลายทางการคืนสินค้า
ใช้ API การติดตามโดยไม่ละทิ้งกฎทางธุรกิจของคุณ
การเชื่อมต่อกับผู้ให้บริการขนส่งหลายรายสามารถให้จุดรับข้อมูลร่วมกันได้ แต่รูปแบบการตอบกลับร่วมไม่ได้ขจัดความจำเป็นในการมีสัญญาภายในที่ชัดเจน เมื่อประเมิน 17TRACK Tracking API ให้ใช้เอกสารอย่างเป็นทางการเพื่อตรวจสอบความหมายของฟิลด์และอินเทอร์เฟซที่เกี่ยวข้องกับการนำไปใช้ของคุณ อย่าสมมติว่าสถานะที่เสนอในคู่มือนี้ตรงกับอนุกรมวิธานดั้งเดิมของระบบ
ก่อนเชื่อมต่อ API ใด ๆ กับการแจ้งเตือนลูกค้าหรือระบบอัตโนมัติด้านปฏิบัติการ ให้กำหนดสิ่งต่อไปนี้:
- ฟิลด์ใดอธิบายเหตุการณ์แต่ละรายการ และฟิลด์ใดอธิบายสรุปสถานะปัจจุบันของการจัดส่ง
- รายละเอียดต้นฉบับของผู้ให้บริการขนส่งใดที่เปิดเผยและสามารถเก็บรักษาได้
- การแสดงเวลา ค่าที่หายไป การแก้ไข และการอัปเดตซ้ำเป็นอย่างไร
- จะแยกเส้นทางการคืนสินค้าและการจัดส่งไปยังพันธมิตรระหว่างทางได้อย่างไร
- การเชื่อมต่อของคุณจะตอบสนองต่อรหัสที่ไม่รู้จักหรือการเปลี่ยนแปลงสคีมาในอนาคตอย่างไร
คงอะแดปเตอร์แบบบางไว้ระหว่างการตอบกลับจากภายนอกกับโมเดลมาตรฐานของคุณ วิธีนี้ช่วยให้ส่วนที่เหลือของแอปพลิเคชันใช้สัญญาสถานะการติดตามเดียวกันโดยไม่ต้องพึ่งพาชื่อฟิลด์จากต้นทางทุกแห่ง ให้ถือว่ากฎการแจ้งเตือนเป็นอีกชั้นหนึ่ง เหตุการณ์ใหม่ที่ทำให้เป็นมาตรฐานไม่ควรกระตุ้นข้อความถึงลูกค้าโดยอัตโนมัติ
ทดสอบประวัติเหตุการณ์ ไม่ใช่เพียงการแมปแต่ละรายการ
การแมปอาจถูกต้องเมื่อพิจารณาแยกกัน แต่ยังสร้างสถานะการจัดส่งที่ผิดได้ ให้ทดสอบประวัติทั้งหมด รวมถึงการอัปเดตที่ส่งมาในลำดับแตกต่างจากเวลาที่เกิดเหตุการณ์
- ประวัติล่าช้า: การยืนยันการจัดส่งมาถึงก่อนการสแกนการขนส่งที่เก่ากว่า การจัดส่งยังคงอยู่ในสถานะจัดส่งแล้ว
- การรับข้อมูลซ้ำ: ประมวลผลเหตุการณ์เดิมอีกครั้ง จะไม่มีการส่งการแจ้งเตือนลูกค้าซ้ำ
- ความพยายามจัดส่งล้มเหลว: ความพยายามที่ไม่สำเร็จเกิดขึ้นหลังสถานะกำลังนำจ่าย ภาพสถานะจะไม่สัญญาว่ากำลังจัดส่งอยู่โดยไม่มีหลักฐานสนับสนุน
- ความพร้อมให้รับสินค้า: พัสดุไปถึงศูนย์รับสินค้าก่อนมีการยืนยันว่าพร้อม จะไม่มีการออกคำแนะนำให้ไปรับก่อนเวลา
- เหตุการณ์ที่ไม่รู้จัก: มีรหัสใหม่ปรากฏ ระเบียนดิบจะถูกเก็บรักษาไว้ และสถานะการจัดส่งที่มีอยู่เดิมจะไม่ถูกแทนที่ด้วย unknown โดยอัตโนมัติ
- การเคลื่อนย้ายเพื่อคืนสินค้า: เส้นทางย้อนกลับสิ้นสุดที่ผู้ส่ง การจัดส่งเดิมถึงผู้ซื้อจะไม่ถูกระบุว่าสำเร็จ
- การแก้ไข: การแก้ไขอย่างชัดเจนจากแหล่งข้อมูลเปลี่ยนผลลัพธ์ผ่านการเปลี่ยนสถานะที่ตรวจสอบย้อนหลังได้
ติดตามเหตุการณ์ที่ไม่มีการแมป การใช้ทางเลือกจากข้อความ การเปลี่ยนสถานะที่ไม่ถูกต้อง และความพยายามแจ้งเตือนซ้ำ โดยแยกตามผู้ให้บริการขนส่งและแหล่งข้อมูล แยกความครบถ้วนของการแมปออกจากความถูกต้องของการแมป การจดจำรหัสได้ทุกตัวไม่มีประโยชน์หากตีความผิด
ก่อนนำการเปลี่ยนแปลงการแมปไปใช้งาน ให้เล่นประวัติตัวแทนซ้ำและเปรียบเทียบภาพสถานะเก่ากับใหม่ ตรวจสอบความแตกต่างที่มีผลต่อการยืนยันการจัดส่ง คำแนะนำการรับสินค้า การคืนสินค้าที่เสร็จสมบูรณ์ หรือการดำเนินการของลูกค้า กำหนดเวอร์ชันให้กฎเพื่อให้เจ้าหน้าที่สนับสนุนอธิบายได้ว่าเหตุใดระบบจึงให้ผลลัพธ์นั้น
คำถามที่พบบ่อย
เหตุการณ์การติดตามทุกเหตุการณ์ควรมีสถานะเพียงหนึ่งเดียวหรือไม่
แต่ละเหตุการณ์สามารถมีการตีความหลักที่ทำให้เป็นมาตรฐานได้หนึ่งรายการ แต่ก็อาจต้องมีเงื่อนไข เหตุผล และบริบทของเส้นทางด้วย การบังคับให้ความหมายทั้งหมดอยู่ในรายการสถานะแบนเพียงชุดเดียวทำให้โมเดลใช้งานและดูแลรักษาได้ยากขึ้น
เหตุการณ์ที่ไม่รู้จักควรแทนที่สถานะปัจจุบันของการจัดส่งหรือไม่
โดยทั่วไปไม่ควร ให้การแมปของเหตุการณ์ยังไม่ถูกแก้ไข พร้อมคงสถานะการจัดส่งล่าสุดที่รองรับไว้ แสดงความสดใหม่ของข้อมูลแยกต่างหาก เพื่อไม่ให้ผู้ใช้เข้าใจผิดว่าสถานะเก่าที่ได้รับการยืนยันเป็นการอัปเดตล่าสุด
การจัดส่งที่เสร็จสิ้นแล้วสามารถกลับไปเป็นกำลังขนส่งได้หรือไม่
การสแกนการขนส่งที่เก่าไม่ควรทำให้เกิดการเปลี่ยนแปลงดังกล่าว การแก้ไขที่ผ่านการตรวจสอบอาจทำให้เปลี่ยนได้ ขณะที่เส้นทางคืนสินค้าที่เริ่มต้นใหม่ควรแสดงแยกต่างหากตามปกติ การเปลี่ยนสถานะต้องมีเหตุผลชัดเจน ไม่ใช่เพียงเวลาที่รับข้อมูลภายหลัง
ควรแสดงการขาดการอัปเดตการติดตามอย่างไร
ใช้ตัวบ่งชี้ความสดใหม่ภายในหรือการแจ้งเตือนการไม่มีความเคลื่อนไหว แยกสิ่งนี้ออกจากความล่าช้า การสูญหาย หรือสถานะข้อยกเว้นที่ผู้ให้บริการขนส่งรายงาน เกณฑ์การยกระดับควรสะท้อนคำมั่นด้านบริการและนโยบายการดำเนินงานของคุณ ไม่ใช่สมมติฐานสากล
ใครควรอนุมัติการเปลี่ยนแปลงการแมป
ฝ่ายวิศวกรรมควรรับผิดชอบการนำไปใช้และการทดสอบเล่นประวัติซ้ำ ฝ่ายปฏิบัติการด้านโลจิสติกส์ควรตรวจสอบความหมายด้านการขนส่ง และเจ้าของประสบการณ์ลูกค้าควรอนุมัติผลกระทบต่อข้อความ กำหนดผู้มีอำนาจตัดสินใจที่ระบุชื่อ เพื่อไม่ให้เหตุการณ์กำกวมค้างอยู่โดยไม่ได้รับการแก้ไขอย่างไม่มีกำหนด
แหล่งข้อมูล
- RFC 3339: Date and Time on the Internet: Timestamps — แหล่งอ้างอิงสำหรับการแสดงเวลาและออฟเซ็ตตัวเลข
- 17TRACK Tracking API — จุดเริ่มต้นอย่างเป็นทางการสำหรับการเชื่อมต่อ API การติดตามที่กล่าวถึงข้างต้น
- 17TRACK API documentation — แหล่งอ้างอิงการนำไปใช้สำหรับตรวจสอบสัญญาของผู้ให้บริการ โมเดลมาตรฐานและตัวอย่างการแมปในบทความนี้เป็นรูปแบบการออกแบบที่เสนอ ไม่ใช่คำนิยามเฉพาะของผู้ให้บริการ
