ข้อกำหนดการผสานรวม API ติดตามพัสดุของ USPS สำหรับทีมรับคืนสินค้าและจัดการคำสั่งซื้อ
การผสานรวม USPS tracking API ต้องการมากกว่าการส่งหมายเลขติดตามไปยัง endpoint ทีมจัดการการคืนสินค้าและทีมจัดการการจัดส่งต้องมีวิธีการเข้าถึงที่ได้รับอนุมัติ โมเดลข้อมูลการจัดส่งที่เชื่อถือได้ การทำให้เหตุการณ์เป็นมาตรฐาน ตรรกะการเรียกตรวจสอบเป็นระยะหรือ webhook การจัดการข้อยกเว้น และการควบคุมด้านความเป็นส่วนตัวและการกู้คืนการดำเนินงาน การออกแบบที่เหมาะสมควรรองรับทั้งกระบวนการทำงานของคลังสินค้าที่สร้างการจัดส่ง และกระบวนการคืนสินค้าที่ติดตามพัสดุซึ่งกำลังส่งกลับไปยังผู้ค้า
เอกสารและข้อตกลงการเข้าถึงของ USPS อาจเปลี่ยนแปลงได้ ดังนั้นทีมงานควรยืนยันโปรแกรมสำหรับนักพัฒนา วิธีการยืนยันตัวตน เงื่อนไขการให้บริการ และข้อจำกัดทางเทคนิคที่เป็นปัจจุบันก่อนเริ่มการติดตั้ง ข้อกำหนดด้านล่างเป็นกรอบการวางแผนที่ใช้งานได้ในระยะยาว โดยไม่สมมติว่าบัญชี USPS ทุกบัญชีมีสิทธิ์เข้าถึง API เหมือนกัน
สิ่งที่การผสานรวมต้องบรรลุ
การผสานรวมสำหรับการจัดส่งตอบคำถามด้านการดำเนินงานง่าย ๆ ว่า พัสดุขาออกอยู่ที่ไหน และธุรกิจควรดำเนินการใดต่อไป การผสานรวมสำหรับการคืนสินค้าถามคำถามที่เกี่ยวข้องแต่แตกต่างกันว่า สินค้าที่ส่งคืนได้เข้าสู่เครือข่ายของผู้ขนส่งแล้วหรือไม่ ถึงผู้ค้าแล้วหรือยัง หรือเกิดความล่าช้าก่อนการตรวจสอบและคืนเงิน
สำหรับกระบวนการทั้งสอง การผสานรวมควรเชื่อมโยงเหตุการณ์ติดตามของ USPS กับข้อมูลการจัดส่ง คำสั่งซื้อ การอนุมัติการคืนสินค้า และลูกค้าภายในระบบ เหมาะสมแล้วที่จะบอกว่ามีเพียงหมายเลขติดตามนั้นไม่เพียงพอ ระบบยังต้องมีบริบท เช่น ตัวระบุคำสั่งซื้อ ทิศทางของพัสดุ ประเภทบริการเมื่อมีข้อมูล ที่อยู่ปลายทางหรือที่อยู่สำหรับคืนสินค้า เวลาที่สร้าง และผู้รับผิดชอบทางธุรกิจสำหรับการดำเนินการถัดไป
- การจัดส่ง: สร้างหรือเชื่อมโยงการจัดส่ง ติดตามการรับพัสดุและการเคลื่อนย้าย และแจ้งทีมงานเมื่อการจัดส่งหรือข้อยกเว้นจำเป็นต้องได้รับการดูแล
- การคืนสินค้า: ระบุพัสดุขาเข้าที่คาดว่าจะได้รับ ยืนยันการรับโดยผู้ขนส่ง ตรวจจับการจัดส่งไปยังสถานที่คืนสินค้า และป้องกันไม่ให้การตัดสินใจคืนเงินอาศัยเพียงคำกล่าวของลูกค้าที่ไม่ได้รับการยืนยันหรือสถานะที่ล้าสมัย
- ฝ่ายสนับสนุนลูกค้า: แสดงข้อมูลการติดตามที่เข้าใจง่าย พร้อมรักษารายละเอียดเหตุการณ์ต้นฉบับของผู้ขนส่งไว้เพื่อการตรวจสอบและจัดการข้อพิพาท
ข้อกำหนดหลักของการผสานรวม USPS
1. ยืนยันรูปแบบการเข้าถึงและการยืนยันตัวตนที่เป็นปัจจุบัน
เริ่มต้นด้วยเอกสารสำหรับนักพัฒนาอย่างเป็นทางการของ USPS แทนการสมมติว่าตัวอย่างคำขอแบบเก่าหรือไลบรารีที่ไม่เป็นทางการสะท้อนโปรแกรมปัจจุบัน ยืนยันว่ากรณีการใช้งานที่ต้องการจำเป็นต้องมีบัญชี การลงทะเบียนแอปพลิเคชัน ข้อมูลรับรอง ผลิตภัณฑ์หรือบริการที่ได้รับอนุมัติ หรือการยอมรับเงื่อนไขเพิ่มเติมหรือไม่ จัดเก็บข้อมูลรับรองใน secrets manager จำกัดสิทธิ์เท่าที่ทำได้ และแยกข้อมูลรับรองสำหรับ sandbox หรือการทดสอบออกจากข้อมูลรับรองสำหรับการใช้งานจริง
ควรจัดการการยืนยันตัวตนนอกตรรกะทางธุรกิจ แอปพลิเคชันควรสามารถเปลี่ยนข้อมูลรับรองได้โดยไม่ต้องแก้ไขโค้ดประมวลผลคำสั่งซื้อ บันทึกความล้มเหลวในการยืนยันตัวตนแยกจากความล้มเหลวของสถานะผู้ขนส่ง และป้องกันไม่ให้ข้อมูลรับรองปรากฏในบันทึก โค้ดเบราว์เซอร์ ภาพหน้าจอของฝ่ายสนับสนุน หรือ URL ที่แสดงต่อลูกค้า
2. กำหนดสัญญาข้อมูลการจัดส่งขั้นต่ำ
โมเดลข้อมูลภายในไม่ควรขึ้นอยู่กับรูปแบบการตอบกลับของ USPS ที่ตายตัวเพียงแบบเดียว อย่างน้อยควรเก็บข้อมูลต่อไปนี้:
- รหัสการจัดส่งหรือการคืนสินค้าภายใน
- รหัสคำสั่งซื้อและรหัสการอนุมัติการคืนสินค้าเมื่อเกี่ยวข้อง
- ชื่อผู้ขนส่งและหมายเลขติดตามเฉพาะของผู้ขนส่ง
- ทิศทางการจัดส่ง: ขาออกหรือขาเข้า
- ระดับบริการ หากมีการระบุและเกี่ยวข้องกับการดำเนินงาน
- รหัสเหตุการณ์ คำอธิบายเหตุการณ์ เวลาของเหตุการณ์ และสถานที่เกิดเหตุการณ์เมื่อมีข้อมูล
- เวลาที่พบครั้งแรกและเวลาที่ตรวจสอบครั้งล่าสุด
- การตอบกลับดิบจากผู้ขนส่งหรือข้อมูลอ้างอิงที่ตรวจสอบได้
- สถานะปัจจุบันที่ทำให้เป็นมาตรฐานแล้วและกฎที่สร้างสถานะนั้น
เก็บถ้อยคำต้นฉบับของผู้ขนส่งไว้ควบคู่กับสถานะที่ทำให้เป็นมาตรฐาน สถานะกว้าง ๆ เช่น “อยู่ระหว่างการขนส่ง” มีประโยชน์สำหรับแดชบอร์ด แต่เหตุการณ์ต้นฉบับอาจจำเป็นต่อการอธิบายความพยายามจัดส่ง คำสั่งส่งต่อ ปัญหาที่อยู่ หรือข้อยกเว้น
3. ตรวจสอบหมายเลขติดตามก่อนส่งคำขอ
การตรวจสอบควรลบช่องว่างที่เกิดขึ้นโดยไม่ตั้งใจ รักษาอักขระนำหน้าที่เกี่ยวข้อง และปฏิเสธค่าที่ว่างเปล่าหรือมีรูปแบบผิดอย่างเห็นได้ชัดก่อนส่งไปยัง API การตรวจสอบไม่ควรพยายามพิสูจน์ว่าพัสดุมีอยู่จริงเพียงด้วยการตรวจความยาวหรือรูปแบบที่คาดเดาไว้ หมายเลขติดตามที่มีรูปแบบถูกต้องอาจยังไม่ได้ออก ไม่ได้ใช้งาน พิมพ์ผิด หรือเชื่อมโยงกับผู้ขนส่งรายอื่น
สำหรับการคืนสินค้า ให้เชื่อมโยงหมายเลขติดตามกับการอนุมัติการคืนสินค้าที่คาดไว้ก่อนเริ่มติดตาม หากลูกค้าเปลี่ยนวิธีคืนสินค้าหรือแจ้งหมายเลขอื่น ให้เก็บทั้งค่าที่คาดไว้เดิมและค่าที่เปลี่ยนใหม่พร้อมบันทึกการตรวจสอบ วิธีนี้จะป้องกันไม่ให้การสแกนในภายหลังถูกเชื่อมโยงกับการคืนสินค้าที่ไม่ถูกต้อง
4. เลือกกลยุทธ์การเรียกตรวจสอบเป็นระยะอย่างรอบคอบ
การผสานรวมกับผู้ขนส่งจำนวนมากสร้างขึ้นบนการตรวจสอบสถานะซ้ำ ๆ ขณะที่แพลตฟอร์มอื่นอาจรองรับการส่งเหตุการณ์หรือชั้นการติดตามที่มีการจัดการ การติดตั้งควรยืนยันว่าช่องทางการเข้าถึง USPS ที่เลือกนั้นมีความสามารถใดจริง อย่าเรียก API ที่ใช้การ polling ว่าเป็นการผสานรวมแบบ webhook เว้นแต่เอกสารอย่างเป็นทางการจะรองรับความสามารถดังกล่าว
การออกแบบ polling ที่ใช้งานได้จริงควรใช้ช่วงเวลาที่แตกต่างกันตามสถานะ การจัดส่งที่เพิ่งสร้างอาจต้องมีช่วงตรวจสอบเบื้องต้นสั้น ๆ พัสดุที่กำลังเคลื่อนย้ายสามารถตรวจสอบตามกำหนดเวลาปกติ และการคืนสินค้าที่จัดส่งแล้วหรือปิดรายการแล้วอาจเปลี่ยนไปใช้กระบวนการกระทบยอดที่มีความถี่ต่ำ ช่วงเวลาที่แน่นอนควรอิงตามเงื่อนไขของบริการที่ได้รับอนุญาต ข้อจำกัดที่บันทึกไว้ ความเร่งด่วนในการดำเนินงาน และต้นทุนของคำขอที่ไม่จำเป็น
ใช้ exponential backoff สำหรับข้อผิดพลาดชั่วคราว เพิ่ม jitter เพื่อป้องกันการลองใหม่จำนวนมากที่เกิดขึ้นพร้อมกัน และหยุดลองใหม่สำหรับคำขอที่ไม่ถูกต้องอย่างถาวร โดยทั่วไป queue หรือตัวจัดตารางงานปลอดภัยกว่าการส่งคำขอติดตามภายในธุรกรรม checkout การพิมพ์ฉลาก หรือการคืนเงิน
5. ทำให้เหตุการณ์เป็นมาตรฐานโดยไม่สูญเสียความไม่แน่นอน
ควรแมปเหตุการณ์ของ USPS เข้ากับคำศัพท์ภายในที่ควบคุมไว้ แต่การแมปต้องรักษาความกำกวม ตัวอย่างเช่น การสแกนที่ระบุว่ารับพัสดุแล้วไม่เหมือนกับวันที่จัดส่งโดยประมาณ และการพยายามจัดส่งไม่เหมือนกับการยืนยันว่าพัสดุสูญหาย โมเดลที่มีประโยชน์อาจมีสถานะ เช่น สร้างฉลากแล้ว รับพัสดุแล้ว กำลังเคลื่อนผ่านเครือข่าย พยายามจัดส่งแล้ว จัดส่งแล้ว พักไว้หรือพร้อมให้รับ มีข้อยกเว้น และไม่มีการอัปเดตล่าสุด
เก็บฟิลด์ “เหตุการณ์ล่าสุดของผู้ขนส่ง” และ “การดำเนินการทางธุรกิจ” แยกจากกัน พัสดุอาจมีการสแกนล่าสุดจากผู้ขนส่ง แต่ยังต้องรอการตัดสินใจจากฝ่ายปฏิบัติการ ในทางกลับกัน พัสดุที่ไม่มีการสแกนใหม่อาจไม่ได้สูญหาย การดำเนินการทางธุรกิจที่ถูกต้องอาจเป็นการรอ ติดต่อผู้ขนส่ง ติดต่อพนักงานหรือลูกค้า หรือเริ่มกระบวนการตรวจสอบที่กำหนดไว้
6. ทำให้การอัปเดตเป็นแบบ idempotent และเรียงลำดับ
เหตุการณ์เดียวกันอาจถูกส่งกลับมามากกว่าหนึ่งครั้ง และการตอบกลับที่มาถึงล่าช้าอาจไม่ใช่สถานะล่าสุด เก็บตัวระบุเหตุการณ์ที่คงที่เมื่อมี หากไม่มี ให้ใช้คีย์ผสมที่รอบคอบซึ่งอ้างอิงหมายเลขติดตาม เวลาของเหตุการณ์ รหัสเหตุการณ์ สถานที่ และคำอธิบาย พร้อมรองรับการสแกนที่ดูเหมือนซ้ำกันแต่เกิดขึ้นโดยชอบธรรม
อย่าเขียนทับสถานะจัดส่งแล้วด้วยสถานะทั่วไปก่อนหน้าเพียงเพราะคำขอเสร็จสิ้นไม่เรียงตามลำดับ เปรียบเทียบเวลาของเหตุการณ์และรักษาร่องรอยการตรวจสอบ หากเวลาไม่ครบถ้วนหรือไม่สอดคล้องกัน ให้ส่งข้อมูลเข้าสู่กฎการกระทบยอดแทนการบังคับสรุปผลโดยไม่แจ้งให้ทราบ
ข้อกำหนดเฉพาะสำหรับการดำเนินงานด้านการคืนสินค้า
ทีมคืนสินค้าต้องการมากกว่าการมองเห็นการจัดส่ง พวกเขาต้องการห่วงโซ่การครอบครองที่เชื่อมโยงคำขอคืนสินค้าของลูกค้าเข้ากับสินค้าจริงและการตัดสินใจทางการเงิน
- การอนุมัติการคืนสินค้า: สร้างรายการคืนสินค้าก่อนเริ่มติดตาม และบันทึกผู้ขนส่งกับหมายเลขติดตามที่คาดไว้
- การรับครั้งแรก: ถือว่าการสแกนรับพัสดุของผู้ขนส่งเป็นหลักฐานว่าพัสดุเข้าสู่เครือข่ายแล้ว ไม่ใช่หลักฐานว่าสินค้าที่ถูกต้องอยู่ภายใน
- การจัดส่งขาเข้า: เชื่อมโยงการจัดส่งกับที่อยู่หรือสถานที่รับคืนสินค้าที่กำหนด รวมถึงกรณีที่ผู้ค้ามีสถานที่รับสินค้ามากกว่าหนึ่งแห่ง
- คิวตรวจสอบ: ย้ายการคืนสินค้าไปยังการตรวจสอบต่อเมื่อเป็นไปตามกฎทางธุรกิจ การจัดส่งเพียงอย่างเดียวไม่ได้ยืนยันสภาพ จำนวน หรือสิทธิ์ของสินค้า
- การจัดการข้อยกเว้น: ตั้งค่าสถานะการเคลื่อนย้ายที่หยุดชะงัก ความพยายามจัดส่ง ปัญหาที่อยู่ และหมายเลขติดตามที่ขัดแย้งกัน เพื่อส่งต่อให้กระบวนการทำงานของมนุษย์หรือระบบอัตโนมัติ
- การควบคุมการคืนเงิน: กำหนดว่าสามารถคืนเงินเมื่อรับพัสดุ จัดส่งถึง ตรวจสอบแล้ว หรือเมื่อเกิดเหตุการณ์ตามนโยบายอื่น API ควรจัดเตรียมหลักฐานสำหรับนโยบาย ไม่ใช่ตัดสินนโยบายโดยอัตโนมัติ
การแยกส่วนนี้มีความสำคัญเป็นพิเศษเมื่อลูกค้าใช้ฉลากที่ผู้ค้าสร้างขึ้นแต่ส่งคืนสินค้าอื่น เมื่อมีพัสดุหลายชิ้นอยู่ในการคืนสินค้าเดียว หรือเมื่อการคืนสินค้าถูกส่งไปยังคลังสินค้าของบุคคลที่สาม
ข้อกำหนดสำหรับทีมจัดส่งและคลังสินค้า
การจัดส่งขาออกขึ้นอยู่กับการส่งต่องานที่สะอาด ระบบจัดการคลังสินค้า ระบบจัดการคำสั่งซื้อ แพลตฟอร์มการจัดส่ง และอินเทอร์เฟซบริการลูกค้าควรเห็นพ้องกันว่าระบบใดเป็นเจ้าของหมายเลขติดตาม และระบบใดเป็นเจ้าของสถานะการจัดส่ง บันทึกการจัดส่งซ้ำเป็นสาเหตุทั่วไปของการแจ้งเตือนซ้ำและจำนวนข้อยกเว้นที่ไม่ถูกต้อง
เมื่อสร้างฉลาก ให้บันทึกหมายเลขติดตามและข้อมูลผู้ขนส่งไว้ในข้อมูลถาวร เมื่อส่งมอบพัสดุ ให้บันทึกเหตุการณ์สำคัญที่เกี่ยวข้องของการจัดส่งแยกจากการสแกน USPS ครั้งแรก ความแตกต่างนี้ช่วยให้ทีมระบุได้ว่าความล่าช้าเกิดขึ้นก่อนผู้ขนส่งรับพัสดุ ระหว่างการขนส่ง หรือหลังจากพยายามจัดส่ง
แดชบอร์ดการดำเนินงานควรจัดลำดับความสำคัญให้ข้อยกเว้นที่ต้องดำเนินการ แทนที่จะแสดงทุกการสแกนอย่างเท่าเทียมกัน คิวที่มีประโยชน์อาจรวมถึงพัสดุที่ไม่มีเหตุการณ์รับพัสดุหลังช่วงเวลาที่กำหนด พัสดุที่พยายามจัดส่งซ้ำหลายครั้ง พัสดุที่จัดส่งแล้วแต่รอการรับเข้าคลัง และการคืนสินค้าที่หมายเลขติดตามไม่ตรงกับการอนุมัติ
รายการตรวจสอบก่อนใช้งานจริง
การทดสอบที่ประสบความสำเร็จควรครอบคลุมมากกว่าพัสดุที่จัดส่งสำเร็จเพียงรายการเดียว ใช้ข้อมูลทดสอบและการตอบกลับจากผู้ขนส่งที่โปรแกรม USPS ที่เลือกอนุญาต และหลีกเลี่ยงการใส่ข้อมูลลูกค้าจริงในบันทึกการพัฒนา
- หมายเลขติดตามที่ถูกต้องพร้อมสถานะเริ่มต้น
- หมายเลขติดตามที่ยังไม่มีเหตุการณ์เกิดขึ้น
- การจัดส่งที่จัดส่งสำเร็จแล้ว
- การพยายามจัดส่งหรือสถานะข้อยกเว้นอื่น
- การตอบกลับซ้ำและการ polling ซ้ำ
- คำขอมีรูปแบบผิด ข้อมูลรับรองไม่ถูกต้อง หมดเวลา และการตอบกลับเมื่อเกินอัตราจำกัด หากมีให้ทดสอบ
- เหตุการณ์ที่มาถึงไม่เรียงตามลำดับ
- การคืนสินค้าที่มีหมายเลขติดตามใหม่แทนที่หมายเลขเดิม
- พัสดุหลายชิ้นที่ผูกกับคำสั่งซื้อหรือการคืนสินค้าเดียว
- การตอบกลับจากผู้ขนส่งที่ไม่มีสถานที่ ไม่มีเวลา หรือใช้ถ้อยคำเหตุการณ์ที่ไม่คุ้นเคย
วัดความสำเร็จของคำขอ เวลาแฝงของการตอบกลับ ปริมาณการลองใหม่ ระเบียนที่ล้าสมัย หมายเลขติดตามที่ไม่ตรงกัน และเวลาตั้งแต่เกิดเหตุการณ์สำคัญจนถึงการอัปเดตภายใน ตัวชี้วัดเหล่านี้ช่วยเปิดเผยว่าปัญหาเกี่ยวข้องกับการยืนยันตัวตน ความพร้อมใช้งานของผู้ขนส่ง การแมปข้อมูล หรือกระบวนการของคลังสินค้า
เมื่อชั้นการติดตามหลายผู้ขนส่งอาจเหมาะสมกว่า
หากการดำเนินงานใช้ USPS ควบคู่กับผู้ขนส่งรายอื่น บริการติดตามหลายผู้ขนส่งสามารถลดจำนวนการผสานรวมเฉพาะผู้ขนส่งที่ทีมจัดส่งและทีมคืนสินค้าต้องดูแล 17TRACK’s Tracking API และ developer documentation อธิบายตัวเลือกการผสานรวมแยกต่างหากสำหรับการติดตามหลายผู้ขนส่ง ทีมงานควรตรวจสอบผู้ขนส่งที่รองรับ ฟิลด์เหตุการณ์ การยืนยันตัวตน เงื่อนไขการใช้งาน และข้อจำกัดด้านการดำเนินงานโดยตรงจากเอกสารปัจจุบันก่อนเลือกใช้
แนวทางนี้เหมาะอย่างยิ่งเมื่อธุรกิจต้องการกระบวนการติดตามที่ทำให้เป็นมาตรฐานเดียวกันระหว่างผู้ขนส่ง แทนการเชื่อมต่อเฉพาะ USPS แนวทางนี้ไม่ได้ขจัดความจำเป็นในการจับคู่การจัดส่งภายใน ตรรกะการอนุมัติการคืนสินค้า การควบคุมความเป็นส่วนตัว หรือผู้รับผิดชอบข้อยกเว้น ชั้นการทำให้เป็นมาตรฐานสามารถลดความแตกต่างระหว่างผู้ขนส่งได้ แต่ไม่สามารถแก้ไขการเชื่อมโยงคำสั่งซื้อกับหมายเลขติดตามที่ไม่ถูกต้อง
ความปลอดภัย ความเป็นส่วนตัว และการกำกับดูแล
จำกัดการเข้าถึงข้อมูลการจัดส่งตามหน้าที่งาน หน้าที่แสดงต่อลูกค้าควรแสดงเฉพาะข้อมูลที่จำเป็นต่อการสนับสนุนการจัดส่ง ขณะที่ระบบภายในอาจเก็บประวัติเหตุการณ์ที่ละเอียดกว่า กำหนดระยะเวลาเก็บรักษาสำหรับการตอบกลับดิบและบันทึก ปกปิดข้อมูลรับรองและข้อมูลส่วนบุคคลที่ไม่จำเป็น และบันทึกว่าใครมีสิทธิ์เปลี่ยนสถานะการจัดส่งด้วยตนเอง
แยกข้อมูลจากผู้ขนส่งออกจากการประมาณการที่สร้างโดยธุรกิจอย่างชัดเจน วันที่จัดส่งที่คาดการณ์ การตัดสินใจเกี่ยวกับสิทธิ์คืนเงิน หรือป้าย “พัสดุสูญหาย” ควรระบุได้ว่าเป็นการคำนวณภายในหรือผลลัพธ์จากนโยบาย ความแตกต่างนี้ทำให้การสื่อสารกับลูกค้าแม่นยำขึ้น และทำให้การตรวจสอบง่ายขึ้นเมื่อเหตุการณ์จากผู้ขนส่งเปลี่ยนแปลง
คู่มือการตัดสินใจด้านการติดตั้ง
เลือกการผสานรวม USPS โดยตรงเมื่อกระบวนการจำกัดอยู่ที่ USPS ทีมสามารถดูแลตรรกะเฉพาะผู้ขนส่งได้ และช่องทางการเข้าถึง USPS ปัจจุบันรองรับข้อมูลกับความต้องการด้านการดำเนินงานที่จำเป็น พิจารณาชั้นการติดตามหลายผู้ขนส่งเมื่อระบบคำสั่งซื้อ การคืนสินค้า และการสนับสนุนเดียวกันต้องรองรับผู้ขนส่งหลายราย และโมเดลเหตุการณ์ร่วมกันมีคุณค่ามากกว่าการควบคุมโดยตรง
ไม่ว่าในกรณีใด ควรอนุมัติการออกแบบก็ต่อเมื่อทีมสามารถตอบคำถามห้าข้อได้: ใครเป็นเจ้าของข้อมูลรับรอง ระบบใดเป็นเจ้าของข้อมูลการติดตาม อะไรถือเป็นการรับพัสดุ การจัดส่ง และการปิดรายการ จะเกิดอะไรขึ้นเมื่อเหตุการณ์หยุดลงหรือขัดแย้งกัน และการดำเนินการใดจะถูกเรียกใช้สำหรับข้อยกเว้นแต่ละประเภท คำตอบเหล่านี้คือข้อกำหนดการผสานรวมที่แท้จริง ส่วนคำขอ API เป็นเพียงส่วนหนึ่งของโซลูชัน
คำถามที่พบบ่อย
ทีมคืนสินค้าจำเป็นต้องมีการผสานรวม USPS tracking ที่แตกต่างหรือไม่
ไม่จำเป็น ข้อมูลจากผู้ขนส่งอาจคล้ายกัน แต่กระบวนการทางธุรกิจแตกต่างกัน การคืนสินค้าต้องมีระเบียนการอนุมัติ ที่อยู่ปลายทางขาเข้า กฎการตรวจสอบหรือคืนเงิน และการควบคุมหมายเลขติดตามที่ไม่ตรงกันหรือมีหลายหมายเลข
หมายเลขติดตามที่ถูกต้องพิสูจน์หรือไม่ว่า USPS มีพัสดุอยู่
ไม่ หมายเลขติดตามอาจมีรูปแบบถูกต้องโดยไม่มีเหตุการณ์รับพัสดุ ให้ถือว่าการรับโดยผู้ขนส่งเป็นเหตุการณ์สำคัญด้านการดำเนินงานแยกต่างหาก และเก็บรายละเอียดเหตุการณ์ต้นฉบับไว้
ทุกเหตุการณ์ของ USPS ควรกลายเป็นการแจ้งเตือนลูกค้าหรือไม่
ไม่ ควรทำให้เหตุการณ์เป็นมาตรฐานภายในก่อน จากนั้นกำหนดกฎการแจ้งเตือนสำหรับเหตุการณ์สำคัญและข้อยกเว้นที่มีความหมาย การแจ้งเตือนที่มากเกินไปอาจสร้างความสับสนเมื่อมีการสแกนซ้ำหรือเมื่อเหตุการณ์ไม่มีนัยสำคัญต่อการดำเนินงาน
API หลายผู้ขนส่งสามารถแทนที่เอกสาร USPS ได้หรือไม่
ไม่ แพลตฟอร์มหลายผู้ขนส่งอาจช่วยให้การผสานรวมและการทำให้เป็นมาตรฐานง่ายขึ้น แต่การติดตั้งยังคงต้องใช้เอกสารปัจจุบันของผู้ให้บริการ เงื่อนไขบัญชี การแมปฟิลด์ และกระบวนการจัดการข้อยกเว้นเฉพาะของผู้ขนส่ง
ควรทดสอบอะไรบ้างก่อนเปิดใช้งาน
ทดสอบการสแกนเบื้องต้น สถานะจัดส่งสำเร็จและสถานะข้อยกเว้น การตอบกลับซ้ำและไม่เรียงตามลำดับ ความล้มเหลวในการยืนยันตัวตน การหมดเวลา หมายเลขติดตามที่ไม่ตรงกัน พัสดุหลายชิ้น และกระบวนการทำงานเฉพาะสำหรับการคืนสินค้า นอกจากนี้ควรทดสอบว่าระบบคลังสินค้า ฝ่ายสนับสนุน และระบบคืนเงินตอบสนองต่อแต่ละสถานะที่ทำให้เป็นมาตรฐานอย่างไร
แหล่งข้อมูล
- USPS Developer Portal — ข้อมูลปัจจุบันเกี่ยวกับการเข้าถึงสำหรับนักพัฒนาและ API
- USPS Web Tools and APIs — เอกสาร API สำหรับธุรกิจและข้อมูลโปรแกรมของ USPS
- USPS Tracking — อินเทอร์เฟซติดตามอย่างเป็นทางการและบริบทของสถานะจากผู้ขนส่ง
- 17TRACK Tracking API — ข้อมูลผลิตภัณฑ์อย่างเป็นทางการสำหรับการติดตามผ่าน API
- 17TRACK API Documentation — เอกสารสำหรับนักพัฒนาอย่างเป็นทางการ
