วิธีตรวจสอบความครอบคลุมของ API ติดตามการจัดส่งก่อนเข้าสู่ตลาดใหม่
เพื่อยืนยันความครอบคลุมของ Shipment Tracking API ก่อนเข้าสู่ตลาดใหม่ ให้ทดสอบชุดค่าผสมที่ตรงกับผู้ให้บริการขนส่ง บริการ เส้นทางการจัดส่ง และการจัดส่งช่วงสุดท้ายที่คุณวางแผนจะใช้ ตรวจสอบพัสดุที่กำลังจัดส่งกับข้อมูลของผู้ให้บริการขนส่ง ยืนยันว่าเหตุการณ์ต่าง ๆ ถูกส่งไปยังระบบของคุณอย่างถูกต้อง และบันทึกช่องว่างก่อนเปิดตัว การที่ผู้ให้บริการขนส่งปรากฏอยู่ในรายชื่อที่ผู้ให้บริการ API รองรับ เป็นเพียงจุดเริ่มต้น ไม่ใช่หลักฐานว่าเส้นทางการจัดส่งที่คุณวางแผนไว้จะแสดงข้อมูลได้ครบถ้วน
คู่มือนี้จัดทำขึ้นสำหรับผู้จัดการด้านโลจิสติกส์ ทีมปฏิบัติการอีคอมเมิร์ซ และผู้รับผิดชอบการเชื่อมต่อระบบที่กำลังเตรียมเปิดตัวในตลาดใหม่ เป้าหมายคือการตัดสินใจเปิดใช้งานจริงที่นำไปใช้ได้: เส้นทางการจัดส่งใดได้รับการตรวจสอบแล้ว เส้นทางใดต้องมีทางเลือกสำรอง และเส้นทางใดยังต้องการหลักฐานเพิ่มเติม
กำหนดความครอบคลุมตามเส้นทางการจัดส่ง ไม่ใช่จำนวนประเทศ
สำหรับการวางแผนเข้าสู่ตลาด ให้มองความครอบคลุมของการติดตามว่าเป็นความสามารถในการเรียกดูและส่งมอบเหตุการณ์ของพัสดุที่ใช้งานได้ สำหรับรูปแบบการจัดส่งที่เฉพาะเจาะจง ประเทศปลายทางเพียงอย่างเดียวเป็นหน่วยวิเคราะห์ที่กว้างเกินไป พัสดุสองชิ้นที่เข้าสู่ประเทศเดียวกันอาจใช้ผู้ให้บริการต้นทาง รูปแบบพิธีการศุลกากร พาร์ทเนอร์จัดส่ง และระดับบริการที่แตกต่างกัน
แยกคำถามสามข้อที่มักถูกรวมเข้าด้วยกันในการพูดคุยด้านการจัดซื้อ:
- ความเข้ากันได้กับผู้ให้บริการขนส่ง: API สามารถรับและระบุพัสดุจากผู้ให้บริการขนส่งและบริการที่คุณใช้ได้หรือไม่
- การมองเห็นตลอดเส้นทาง: API ส่งคืนเหตุการณ์ที่ทีมของคุณต้องการในขั้นตอนการจัดส่งที่เกี่ยวข้องหรือไม่
- การส่งมอบด้านปฏิบัติการ: เหตุการณ์เหล่านั้นสามารถส่งไปยังระบบจัดการคำสั่งซื้อ เครื่องมือสนับสนุน และการแจ้งเตือนลูกค้าได้อย่างน่าเชื่อถือหรือไม่
คำขอ API ที่สำเร็จตอบได้เพียงบางส่วนของคำถามแรกเท่านั้น ไม่ได้ยืนยันว่าพัสดุมีเหตุการณ์ที่ใช้งานได้ ไม่ได้ยืนยันว่าผลลัพธ์การจัดส่งขั้นสุดท้ายจะแสดงให้เห็น และไม่ได้ยืนยันว่าแอปพลิเคชันของคุณประมวลผลการอัปเดตแล้ว
1. สร้างตารางความครอบคลุมเฉพาะตลาด
เริ่มจากแผนการจัดส่งที่ทีมโลจิสติกส์ของคุณตั้งใจจะดำเนินการจริง ขอให้คลังสินค้า ผู้ให้บริการฟูลฟิลเมนต์ และพาร์ทเนอร์ด้านการขนส่งยืนยันผู้ให้บริการขนส่งและบริการที่เกี่ยวข้อง หากผู้รวบรวมพัสดุเป็นผู้เลือกพาร์ทเนอร์จัดส่งช่วงสุดท้ายแบบไดนามิก ให้บันทึกความไม่แน่นอนดังกล่าว แทนที่จะถือว่าชื่อของผู้รวบรวมพัสดุเป็นคำอธิบายเส้นทางที่สมบูรณ์
สร้างหนึ่งแถวสำหรับชุดค่าผสมที่มีความหมายแต่ละชุด ฟิลด์ต่อไปนี้เป็นตารางการทำงานที่มีประโยชน์:
| ฟิลด์ | สิ่งที่ต้องบันทึก | เหตุผลที่สำคัญ |
|---|---|---|
| เส้นทางการจัดส่ง | ตลาดต้นทางและปลายทาง | ผลลัพธ์ภายในประเทศไม่ได้ยืนยันการมองเห็นข้อมูลข้ามพรมแดน |
| ผู้ให้บริการขนส่งและบริการ | ผู้ให้บริการตามสัญญา ชื่อบริการ และตัวระบุที่เกี่ยวข้อง | รายชื่อระดับผู้ให้บริการอาจไม่ตอบคำถามเฉพาะของแต่ละบริการ |
| รูปแบบการส่งต่อ | พาร์ทเนอร์จัดส่งที่ทราบและหมายเลขติดตามใหม่ หากมี | คุณต้องทดสอบความต่อเนื่องระหว่างการส่งต่อ |
| เหตุการณ์สำคัญที่ต้องการ | การรับพัสดุ การเคลื่อนย้าย ความพยายามจัดส่ง การจัดส่ง และข้อยกเว้นที่เกี่ยวข้อง | ข้อกำหนดควรสะท้อนความต้องการของฝ่ายสนับสนุนและลูกค้า |
| ผลกระทบทางธุรกิจ | สัดส่วนพัสดุที่คาดการณ์และผลกระทบจากการขาดการอัปเดต | เส้นทางที่มีปริมาณมากและความเสี่ยงสูงควรได้รับความสำคัญก่อน |
| สถานะการตรวจสอบ | ตรวจสอบแล้ว มีเงื่อนไข ยังไม่ได้ตรวจสอบ หรือยืนยันว่าไม่รองรับ | ต้องไม่สับสนระหว่างการขาดหลักฐานกับการไม่รองรับ |
กำหนดผู้รับผิดชอบตั้งแต่เนิ่น ๆ ฝ่ายโลจิสติกส์ควรตรวจสอบเส้นทางทางกายภาพ ฝ่ายวิศวกรรมควรตรวจสอบการส่งข้อมูล และฝ่ายปฏิบัติการควรตัดสินใจว่าการมองเห็นข้อมูลที่ได้สนับสนุนคำมั่นสัญญาต่อลูกค้าหรือไม่ ฝ่ายจัดซื้อสามารถประสานงานกระบวนการได้ แต่ไม่ควรใช้รายการฟีเจอร์เพียงอย่างเดียวเป็นตัวตัดสินการยอมรับ
2. ตรวจสอบเอกสารอย่างเป็นทางการ แล้วตั้งคำถามเฉพาะเส้นทาง
ใช้เอกสาร API อย่างเป็นทางการของผู้ให้บริการเพื่อกำหนดขอบเขตการเชื่อมต่อที่มีการระบุไว้ ตรวจสอบตัวระบุผู้ให้บริการขนส่ง ข้อกำหนดการลงทะเบียน ฟิลด์ในผลลัพธ์ คำจำกัดความของเหตุการณ์ การยืนยันตัวตน ขีดจำกัดการใช้งาน และพฤติกรรมการส่งอัปเดต เก็บบันทึกเอกสารที่เกี่ยวข้องกับการนำไปใช้งานของคุณพร้อมวันที่
สำหรับการประเมิน 17TRACK ให้ใช้ หน้าติดตาม API อย่างเป็นทางการ และ เอกสาร API เป็นจุดเริ่มต้นในการตรวจสอบ ใช้การทดสอบการยอมรับระดับเส้นทางเดียวกับที่อธิบายด้านล่าง อย่าถือว่าคำอธิบายผลิตภัณฑ์ทั่วไปเป็นการยืนยันบริการหรือรูปแบบการส่งต่อที่เฉพาะเจาะจง
ส่งคำขอตรวจสอบที่เป็นรูปธรรมให้ผู้ให้บริการ แทนการถามว่าผู้ให้บริการนั้น “ครอบคลุม” ประเทศหนึ่งหรือไม่ ระบุผู้ให้บริการขนส่งและบริการที่วางแผนไว้ ต้นทางและปลายทาง หมายเลขติดตามตัวอย่างที่ได้รับอนุญาต เหตุการณ์สำคัญที่ต้องการ และปริมาณพัสดุที่คาดการณ์
- บริการที่เฉพาะเจาะจงนี้ต้องใช้ตัวระบุผู้ให้บริการขนส่งโดยชัดแจ้งหรือข้อมูลพัสดุเพิ่มเติมหรือไม่
- การเชื่อมต่อควรจัดการกับหมายเลขที่อาจตรงกับผู้ให้บริการขนส่งมากกว่าหนึ่งรายอย่างไร
- ตัวระบุเดิมสามารถแสดงกิจกรรมการจัดส่งช่วงสุดท้ายได้หรือไม่ หรือต้องลงทะเบียนตัวระบุที่สอง
- คาดว่าจะได้รับเหตุการณ์ที่จำเป็นใดบ้างจากเส้นทางนี้ และเหตุการณ์ใดขึ้นอยู่กับการส่งข้อมูลของผู้ให้บริการขนส่ง
- จะเกิดอะไรขึ้นเมื่อไม่สามารถติดตามได้ชั่วคราว หรือเมื่อพัสดุยังไม่มีเหตุการณ์
- ขีดจำกัดการใช้งาน กฎการเก็บรักษาข้อมูล และเงื่อนไขการเรียกเก็บเงินใดบ้างที่ใช้กับเวิร์กโฟลว์ที่เสนอ
แยกพฤติกรรมที่ระบุไว้ในเอกสารออกจากข้อผูกพันตามสัญญา คำอธิบายทางเทคนิคเกี่ยวกับการอัปเดตไม่จำเป็นต้องหมายถึงช่วงเวลาการรีเฟรชหรือข้อผูกพันด้านระดับการให้บริการที่รับประกัน ขอการยืนยันเป็นลายลักษณ์อักษรเมื่อความแตกต่างนี้ส่งผลต่อความเสี่ยงในการเปิดตัว
3. ทดสอบพัสดุตัวแทน ไม่ใช่เฉพาะการจัดส่งที่สำเร็จ
สร้างชุดทดสอบจากพัสดุที่คุณได้รับอนุญาตให้เข้าถึง รวมทั้งพัสดุที่จัดส่งเสร็จแล้วและพัสดุที่กำลังจัดส่ง ข้อมูลย้อนหลังช่วยให้ตรวจสอบลำดับเหตุการณ์ได้ ส่วนพัสดุที่กำลังจัดส่งจำเป็นสำหรับการสังเกตการลงทะเบียน การมาถึงของการอัปเดต และการส่งข้อมูลเข้าสู่ระบบของคุณเอง
เลือกตัวอย่างจากเส้นทางและบริการต่าง ๆ ในตารางของคุณ รวมการจัดส่งตามปกติ และเมื่อมีตัวอย่างจริง ให้รวมพัสดุที่ล่าช้า ความพยายามจัดส่งที่ไม่สำเร็จ การจัดส่งไปยังจุดรับพัสดุ และการส่งคืนผู้ส่ง อย่าสร้างผลการทดสอบข้อยกเว้นขึ้นเองเมื่อไม่มีพัสดุที่เหมาะสม ให้ระบุสถานการณ์ดังกล่าวว่าอยู่ระหว่างรอการตรวจสอบ
ไม่มีจำนวนตัวอย่างสากลที่สามารถพิสูจน์ความครอบคลุมได้ ชุดตัวอย่างขนาดเล็กอาจเปิดเผยข้อผิดพลาดในการเชื่อมต่อ แต่ไม่สามารถยืนยันประสิทธิภาพที่น่าเชื่อถือในทุกบริการและข้อยกเว้นได้ เพิ่มการทดสอบเมื่อความหลากหลายของเส้นทาง ความกำกวมของผู้ให้บริการขนส่ง หรือผลกระทบจากการขาดเหตุการณ์มีมากขึ้น
เปรียบเทียบพัสดุเดียวกันผ่านหลักฐานสามชั้น
- ข้อมูลจากผู้ให้บริการขนส่ง: บันทึกข้อมูลการติดตามที่มีอยู่โดยตรงจากผู้ให้บริการขนส่งที่เกี่ยวข้อง รวมถึงเวลาที่ตรวจสอบ
- ผลลัพธ์จาก API: บันทึกผลลัพธ์ดิบ ตัวตนของผู้ให้บริการขนส่งที่ส่งกลับมา เวลาของเหตุการณ์ และเวลาที่เรียกดู
- แอปพลิเคชันของคุณ: ยืนยันว่าระบบของคุณบันทึก แสดงผล และใช้ข้อมูลใดเพื่อเรียกใช้การดำเนินการ
หลักฐานทั้งสามชั้นช่วยระบุตำแหน่งที่เกิดความล้มเหลว เหตุการณ์ที่หายไปทั้งจากการติดตามของผู้ให้บริการขนส่งและ API แตกต่างจากเหตุการณ์ที่แสดงในระบบของผู้ให้บริการขนส่งแต่ไม่มีใน API เหตุการณ์ที่มีอยู่ใน API แต่หายไปจากระบบคำสั่งซื้อของคุณชี้ไปยังส่วนอื่นของการเชื่อมต่อ
ให้ถือข้อมูลจากผู้ให้บริการขนส่งเป็นข้อมูลอ้างอิง ไม่ใช่บันทึกการเคลื่อนย้ายทางกายภาพที่ถูกต้องอย่างไม่มีข้อผิดพลาด บันทึกการติดตามอธิบายเหตุการณ์ที่มีการรายงาน ไม่ได้ให้การสังเกตพัสดุอย่างต่อเนื่อง ตรวจสอบความแตกต่างที่มีนัยสำคัญกับผู้ให้บริการขนส่งและผู้ให้บริการ API
4. ตรวจสอบการส่งต่อ ความหมายของสถานะ และเวลาอัปเดต
ตรวจสอบความต่อเนื่องจนถึงการจัดส่งช่วงสุดท้าย
สำหรับเส้นทางข้ามพรมแดนแต่ละเส้นทาง ให้ตรวจสอบว่าจะเกิดอะไรขึ้นเมื่อพัสดุถูกส่งต่อ บันทึกว่าหมายเลขเดิมยังคงส่งคืนเหตุการณ์ที่ใช้งานได้หรือไม่ มีหมายเลขอื่นปรากฏขึ้นหรือไม่ และระบบของคุณสามารถเชื่อมโยงตัวระบุทั้งสองกับคำสั่งซื้อเดียวกันได้หรือไม่
ข้อความการส่งต่อไม่ใช่หลักฐานว่ามองเห็นการจัดส่งได้ ติดตามพัสดุจนถึงผลลัพธ์สุดท้าย หากไม่มีข้อมูลการจัดส่งช่วงสุดท้าย ให้ระบุว่าสาเหตุคือข้อมูลต้นทางขาดหาย ปัญหาตัวระบุ ปัญหาการกำหนดค่า หรือข้อจำกัดด้านการสนับสนุน และคงสถานะของเส้นทางไว้เป็นแบบมีเงื่อนไขจนกว่าจะทราบความแตกต่างดังกล่าวอย่างชัดเจน
ตรวจสอบความหมายเบื้องหลังสถานะที่ทำให้เป็นมาตรฐาน
หากการเชื่อมต่อของคุณใช้สถานะมาตรฐาน ให้เปรียบเทียบกับข้อความเหตุการณ์พื้นฐาน ยืนยันว่าการสร้างฉลากไม่ได้เรียกข้อความว่าออกจัดส่ง การมาถึงศูนย์จัดส่งไม่ได้กลายเป็น “จัดส่งแล้ว” และความพยายามจัดส่งที่ล้มเหลวไม่ได้ปิดคำสั่งซื้อว่าเสร็จสมบูรณ์
ทดสอบความพร้อมในการรับพัสดุและผลลัพธ์การส่งคืนผู้ส่งเมื่อเกี่ยวข้องด้วย สถานะที่เรียบง่ายช่วยให้ลูกค้าเข้าใจความคืบหน้าได้ แต่ทีมสนับสนุนอาจต้องใช้คำอธิบายเดิมเพื่ออธิบายข้อยกเว้น ยืนยันว่าระบบส่งคืนรายละเอียดใดจริงก่อนออกแบบอินเทอร์เฟซตามรายละเอียดเหล่านั้น
วัดความล่าช้าที่สังเกตได้โดยไม่กล่าวอ้างความแม่นยำเกินจริง
แยกเวลาของเหตุการณ์ เวลาที่สังเกต และเวลาประมวลผลโดยแอปพลิเคชันออกจากกัน การประทับเวลาที่แนบกับเหตุการณ์ของผู้ให้บริการขนส่งไม่จำเป็นต้องเป็นเวลาที่เหตุการณ์นั้นพร้อมใช้งานออนไลน์ ดังนั้นการเปรียบเทียบเวลาของเหตุการณ์กับเวลาที่ API ได้รับข้อมูลอาจรวมแหล่งที่มาของความล่าช้าหลายประการเข้าด้วยกัน
หากคุณตรวจสอบข้อมูลจากผู้ให้บริการขนส่งเป็นระยะ คุณจะทราบเวลาที่สังเกตเห็นเหตุการณ์ครั้งแรก ไม่ใช่เวลาที่เผยแพร่เหตุการณ์อย่างแน่นอน บันทึกช่วงเวลาการตรวจสอบและระบุผลลัพธ์ว่าเป็นความล่าช้าที่สังเกตได้ ปรับเขตเวลาให้เป็นมาตรฐานและเก็บการประทับเวลาเดิมไว้เพื่อให้สามารถตรวจสอบปัญหาลำดับเหตุการณ์ที่ดูผิดปกติได้
5. ตรวจสอบการเชื่อมต่อภายใต้เงื่อนไขการเปิดตัวจริง
การมองเห็นเส้นทางไม่เพียงพอหากการอัปเดตล้มเหลวภายในแอปพลิเคชันของคุณ ทดสอบกลไกการอัปเดตที่คุณจะใช้จริงในระบบการผลิต สำหรับเวิร์กโฟลว์ที่ใช้ webhook ให้ตรวจสอบการยืนยันตัวตน การตอบรับ การลองใหม่ และพฤติกรรมการกู้คืนตามเอกสาร สำหรับการเรียกตรวจสอบเป็นระยะ ให้ยืนยันความถี่ของคำขอที่อนุญาตและวิธีที่แอปพลิเคชันกู้คืนหลังเกิดการหยุดชะงัก
- การลงทะเบียน: แยกพัสดุที่ได้รับการยอมรับออกจากคำขอที่ถูกปฏิเสธ และพัสดุที่ได้รับการยอมรับแต่ยังไม่มีเหตุการณ์
- การอัปเดตซ้ำ: ตรวจสอบว่าข้อมูลซ้ำไม่ทำให้ส่งการแจ้งเตือนลูกค้าซ้ำ
- ลำดับเหตุการณ์: ตรวจสอบว่าเหตุการณ์เก่าที่มาถึงล่าช้าไม่ทำให้พัสดุที่จัดส่งแล้วเปลี่ยนกลับเป็นอยู่ระหว่างการขนส่ง
- ปลายทางล้มเหลว: ทดสอบระบบรับข้อมูลหยุดทำงานชั่วคราวและกระบวนการกู้คืนตามเอกสาร
- ขีดความสามารถ: เปรียบเทียบการคาดการณ์เมื่อเปิดตัวและช่วงที่มีคำขอพุ่งสูงกับขีดจำกัดการลงทะเบียนและคำขอที่ใช้บังคับ
- การจัดการข้อมูล: ยืนยันว่าฟิลด์ใดจำเป็น จำกัดการเข้าถึงข้อมูลรับรอง และให้ทีมที่เหมาะสมตรวจสอบข้อกำหนดด้านความเป็นส่วนตัวและสัญญา
ตรวจสอบสมมติฐานทางการค้าควบคู่กับสมมติฐานทางเทคนิค ถามว่าสิ่งใดนับเป็นการใช้งานที่ต้องเรียกเก็บเงิน การลงทะเบียนซ้ำได้รับการจัดการอย่างไร และจะเกิดอะไรขึ้นเมื่อถึงขีดจำกัด อย่าสันนิษฐานว่าการทดสอบการเชื่อมต่อหรือช่วงทดลองใช้มีเงื่อนไขเดียวกับรูปแบบการใช้งานจริงที่วางแผนไว้
6. กำหนดเกณฑ์การเปิดตัวที่วัดผลได้
กำหนดเกณฑ์การยอมรับก่อนประเมินผล มิฉะนั้น เมื่อใกล้ถึงกำหนดเปิดตัว การทดสอบที่อ่อนแออาจถูกตีความใหม่ว่าเพียงพอได้ง่าย ใช้เกณฑ์ที่เหมาะกับคำมั่นสัญญาต่อลูกค้าและผลกระทบด้านปฏิบัติการของคุณ แทนการยืมเกณฑ์มาตรฐานอุตสาหกรรมที่ไม่มีคำอธิบาย
ตัวชี้วัดที่มีประโยชน์ ได้แก่:
- ความสำเร็จของการลงทะเบียน: พัสดุทดสอบที่ถูกต้องซึ่งได้รับการยอมรับสำเร็จ หารด้วยจำนวนครั้งที่พยายามลงทะเบียนที่ถูกต้อง
- ความพร้อมใช้งานของการติดตาม: พัสดุที่ทดสอบและมีเหตุการณ์การติดตามที่ใช้งานได้ หารด้วยพัสดุที่ทดสอบและมีสิทธิ์ทั้งหมด
- การเก็บเหตุการณ์สำคัญที่ต้องการ: เหตุการณ์สำคัญที่จำเป็นซึ่ง API ส่งคืน หารด้วยเหตุการณ์สำคัญที่สอดคล้องกันซึ่งพบในข้อมูลอ้างอิง
- ความสอดคล้องของผลลัพธ์สุดท้าย: พัสดุที่จัดส่งเสร็จและมีสิทธิ์ซึ่งผลลัพธ์จาก API ตรงกับผลลัพธ์อ้างอิง หารด้วยพัสดุที่จัดส่งเสร็จและมีสิทธิ์ที่ตรวจสอบแล้ว
- ความล่าช้าของการอัปเดตที่สังเกตได้: การกระจายของความล่าช้าที่วัดด้วยวิธีการสังเกตที่ระบุไว้
รายงานจำนวนดิบพร้อมเปอร์เซ็นต์และระบุรายการที่ไม่นับรวม อย่านับพัสดุที่กำลังจัดส่งเป็นผลลัพธ์การจัดส่งที่หายไป อย่าตัดความล้มเหลวในการติดตามที่ยังไม่ได้รับการแก้ไขออกโดยไม่ระบุ หากถ่วงน้ำหนักผลลัพธ์ตามปริมาณพัสดุที่คาดการณ์ไว้ ให้แสดงผลลัพธ์รายเส้นทางด้วย เพื่อให้เส้นทางที่อ่อนแอแต่สำคัญยังคงมองเห็นได้
ใช้สถานะการตัดสินใจสี่แบบ: ตรวจสอบแล้ว เมื่อเส้นทางผ่านการทดสอบที่ตกลงกันไว้; มีเงื่อนไข เมื่อช่องว่างที่ทราบมีวิธีแก้ไขที่ยอมรับได้; ยังไม่ได้ตรวจสอบ เมื่อหลักฐานไม่ครบถ้วน; และ ยืนยันว่าไม่รองรับ เมื่อการยืนยันโดยตรงหรือข้อจำกัดที่วินิจฉัยแล้วทำให้ได้ข้อสรุปดังกล่าว คำขอที่ล้มเหลวโดยไม่มีคำอธิบายเพียงอย่างเดียวไม่เพียงพอสำหรับสถานะสุดท้าย
7. เปิดตัวพร้อมทางเลือกสำรองและเงื่อนไขที่ต้องตรวจสอบซ้ำอย่างชัดเจน
สำหรับทุกเส้นทางที่มีเงื่อนไข ให้ระบุผู้รับผิดชอบและทางเลือกสำรอง ทางเลือกอาจรวมถึงการตรวจสอบกับผู้ให้บริการขนส่งด้วยตนเอง กระบวนการส่งต่อให้ฝ่ายสนับสนุน บริการจัดส่งอื่น หรือข้อความถึงลูกค้าที่ระบุได้อย่างจำกัดมากขึ้น หลีกเลี่ยงการส่งคำกล่าวอ้างเรื่องการจัดส่งที่มั่นใจเกินจริงเมื่อข้อมูลการติดตามไม่สนับสนุน
ตรวจสอบซ้ำเมื่อบริการของผู้ให้บริการขนส่งเปลี่ยน พาร์ทเนอร์ฟูลฟิลเมนต์เปลี่ยนเส้นทาง มีพาร์ทเนอร์จัดส่งช่วงสุดท้ายรายใหม่ หรือระบบติดตามพบผลลัพธ์ที่หายไป เก็บตารางที่อนุมัติแล้ว หลักฐานการทดสอบ ปัญหาที่ยังไม่ได้แก้ไข และการยืนยันจากผู้ให้บริการไว้ด้วยกัน ความครอบคลุมสำหรับการเข้าสู่ตลาดควรเป็นบันทึกด้านปฏิบัติการ ไม่ใช่คำกล่าวอ้างด้านการจัดซื้อเพียงครั้งเดียว
คำถามที่พบบ่อย
รายชื่อผู้ให้บริการขนส่งที่รองรับพิสูจน์ความครอบคลุมของทุกบริการหรือไม่
ไม่ ใช้รายชื่อดังกล่าวเพื่อระบุการเชื่อมต่อที่เป็นไปได้ จากนั้นตรวจสอบบริการ เส้นทาง ข้อกำหนดของตัวระบุ และผลลัพธ์การจัดส่งช่วงสุดท้ายที่เฉพาะเจาะจง ขอการยืนยันโดยตรงเมื่อเอกสารสาธารณะไม่สามารถตอบรายละเอียดเหล่านั้นได้
เราสามารถตรวจสอบความครอบคลุมโดยใช้เฉพาะพัสดุที่จัดส่งแล้วได้หรือไม่
พัสดุที่จัดส่งแล้วช่วยตรวจสอบความครบถ้วนของเหตุการณ์ย้อนหลังและผลลัพธ์สุดท้าย แต่ไม่สามารถยืนยันว่าเหตุการณ์ใหม่จะมาถึงเร็วเพียงใด หรือระบบของคุณจัดการกับการอัปเดตแบบเรียลไทม์อย่างไร ให้รวมพัสดุที่กำลังจัดส่งก่อนอนุมัติเวิร์กโฟลว์การแจ้งเตือนที่มีความอ่อนไหวด้านเวลา
หาก API ไม่ส่งคืนเหตุการณ์การติดตามควรทำอย่างไร
ตรวจสอบผลลัพธ์ของคำขอ การเลือกผู้ให้บริการขนส่ง ข้อมูลที่จำเป็น และดูว่าผู้ให้บริการขนส่งเองแสดงเหตุการณ์หรือไม่ แยกข้อมูลที่อยู่ระหว่างรอออกจากการลงทะเบียนที่ไม่ถูกต้องและการยืนยันว่าไม่รองรับ ส่งต่อกรณีที่ยังไม่ได้รับการแก้ไขพร้อมหมายเลขติดตาม รายละเอียดคำขอ การประทับเวลา และหลักฐานอ้างอิง
พัสดุทุกชิ้นควรแสดงเหตุการณ์ศุลกากรหรือไม่
อย่าสันนิษฐานว่าทุกเส้นทางจะแสดงเหตุการณ์สำคัญด้านศุลกากรผ่านการติดตามพัสดุ หากเหตุการณ์เหล่านั้นจำเป็นต่อเวิร์กโฟลว์ของคุณ ให้ตรวจสอบโดยเฉพาะและกำหนดว่าฝ่ายปฏิบัติการจะตอบสนองอย่างไรเมื่อไม่มีข้อมูล การขาดรายละเอียดการติดตามไม่ได้ยืนยันปัญหาด้านศุลกากรด้วยตัวมันเอง
เราสามารถเปิดตัวขณะที่บางเส้นทางยังไม่ได้รับการตรวจสอบได้หรือไม่
การเปิดตัวแบบจำกัดอาจเหมาะสม หากเข้าใจผลกระทบแล้ว เส้นทางที่ได้รับผลกระทบมีทางเลือกสำรองที่อนุมัติแล้ว และมีผู้รับผิดชอบการตรวจสอบที่เหลืออยู่ อย่านำเสนอเส้นทางเหล่านั้นภายในองค์กรว่าได้รับการตรวจสอบแล้ว หรือใช้ความสามารถที่ยังไม่ได้รับการพิสูจน์เป็นพื้นฐานของคำมั่นสัญญาต่อลูกค้า
แหล่งข้อมูล
ใช้แหล่งข้อมูลอย่างเป็นทางการเหล่านี้เพื่อตรวจสอบขอบเขตผลิตภัณฑ์และข้อกำหนดการนำไปใช้งานสำหรับการประเมิน 17TRACK ขั้นตอนการทดสอบและเกณฑ์การเปิดตัวในคู่มือนี้เป็นคำแนะนำด้านปฏิบัติการ ไม่ใช่คำกล่าวอ้างว่าครอบคลุมเส้นทางใด ๆ อย่างแน่นอน
