รายการตรวจสอบเอกสาร API ของ USPS สำหรับการผสานรวมบริการจัดการคำสั่งซื้อและการคืนสินค้าของ 17TRACK

การผสานรวม USPS กับ 17TRACK ที่เชื่อถือได้ควรวางแผนเป็นงานสองส่วนที่เชื่อมโยงกันแต่แยกจากกัน: เอกสารของ USPS ควบคุมข้อมูลและบริการที่เกี่ยวข้องกับผู้ให้บริการขนส่ง ขณะที่ 17TRACK สามารถให้ชั้นการติดตามที่ครอบคลุมกว่าเพื่อมองเห็นการจัดส่งจากผู้ให้บริการหลายราย สำหรับการดำเนินการจัดส่งและการคืนสินค้า ทีมพัฒนาควรตรวจสอบการยืนยันตัวตน ตัวระบุการจัดส่ง การจับคู่เหตุการณ์ ความรับผิดชอบด้านอัตราค่าบริการและฉลาก พฤติกรรมการสำรวจข้อมูลหรือการแจ้งเตือน การจัดการข้อผิดพลาด และขอบเขตระหว่างการจัดส่งขาออกกับโลจิสติกส์ย้อนกลับ ก่อนเขียนโค้ดสำหรับใช้งานจริง

รายการตรวจสอบนี้จัดทำขึ้นสำหรับนักพัฒนา ทีมปฏิบัติการอีคอมเมิร์ซ และผู้รับผิดชอบโซลูชันที่เชื่อมต่อข้อมูลการจัดส่งที่เกี่ยวข้องกับ USPS เข้ากับระบบจัดการคำสั่งซื้อ กระบวนการทำงานของคลังสินค้า ประสบการณ์การติดตามที่ลูกค้าใช้งาน หรือกระบวนการคืนสินค้า รายการนี้ไม่ได้ตั้งสมมติฐานว่าความสามารถทุกอย่างของ USPS API สามารถใช้งานผ่าน 17TRACK ได้ หรือ API ติดตามจะสร้างฉลาก ซื้อไปรษณียากร หรือจัดการการคืนสินค้าจริงได้ด้วยตัวเอง

1. กำหนดขอบเขตการผสานรวมก่อน

เริ่มต้นด้วยการบันทึกว่าระบบแต่ละระบบควรทำหน้าที่อะไร เอกสาร USPS อธิบายบริการของ USPS และอินเทอร์เฟซที่ผู้ผสานรวมที่ได้รับอนุมัติสามารถใช้งานได้ เอกสาร Tracking API ของ 17TRACK มีความเกี่ยวข้องเมื่อแอปพลิเคชันต้องการกระบวนการติดตามที่ไม่ผูกกับผู้ให้บริการขนส่ง หรืออินเทอร์เฟซเดียวสำหรับเหตุการณ์การจัดส่ง หน้าผลิตภัณฑ์ 17RETURNS มีความเกี่ยวข้องเมื่อโครงการรวมการจัดการการคืนสินค้าสำหรับอีคอมเมิร์ซด้วย กรณีการใช้งานเหล่านี้เกี่ยวข้องกัน แต่ไม่สามารถใช้แทนกันได้

• USPS: ยืนยันว่าต้องใช้ฟังก์ชันใดที่เกี่ยวข้องกับผู้ให้บริการขนส่ง เช่น การติดตาม บริการที่อยู่ การกำหนดราคา ข้อมูลบริการ หรือ API อื่นที่มีการจัดทำเอกสารไว้
• 17TRACK Tracking API: ตรวจสอบว่าหมายเลขติดตามของ USPS ถูกส่ง สอบถาม อัปเดต และแสดงผลอย่างไรในโมเดลเหตุการณ์มาตรฐานของแอปพลิเคชัน
• แพลตฟอร์มการดำเนินการจัดส่ง: ระบุระบบที่รับผิดชอบการจัดสรรสินค้าคงคลัง การปล่อยคำสั่งซื้อ การสร้างฉลาก การซื้อไปรษณียากร การยืนยันจากคลังสินค้า และการสร้างการจัดส่ง
• กระบวนการคืนสินค้า: กำหนดว่าใครอนุมัติการคืนสินค้า สร้างคำแนะนำหรือฉลากคืนสินค้า บันทึกพัสดุที่ส่งคืน และตัดสินผลลัพธ์ว่าจะคืนเงินหรือเปลี่ยนสินค้า

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

2. ตรวจสอบเอกสารสำหรับนักพัฒนา USPS ฉบับปัจจุบัน

ใช้ ข้อมูล USPS Web Tools และ APIs เป็นจุดเริ่มต้น จากนั้นติดตามเอกสารสำหรับนักพัฒนาและเอกสารอ้างอิงเฉพาะผลิตภัณฑ์ฉบับปัจจุบันที่ USPS เชื่อมโยงไว้ หลีกเลี่ยงการคัดลอก endpoint วิธีการยืนยันตัวตน ชื่อฟิลด์ หรือประกาศยุติการใช้งานจากตัวอย่างโค้ดเก่าโดยไม่ตรวจสอบสถานะปัจจุบัน

ก่อนเริ่มใช้งาน ให้บันทึกข้อเท็จจริงต่อไปนี้จากเอกสารไว้ในบันทึกโครงการ:

• ผลิตภัณฑ์ USPS API ที่ต้องใช้โดยระบุชื่ออย่างชัดเจน
• URL พื้นฐานและรายละเอียดสภาพแวดล้อมปัจจุบันสำหรับการทดสอบและการใช้งานจริง
• ขั้นตอนการลงทะเบียน ข้อมูลประจำตัวของแอปพลิเคชัน และการใช้งานข้อมูลประจำตัวดังกล่าวที่ได้รับอนุญาต
• ขั้นตอนการยืนยันตัวตน อายุการใช้งานโทเค็น ขอบเขตสิทธิ์ และข้อกำหนดในการหมุนเวียนข้อมูลประจำตัว หากมีการระบุไว้สำหรับ API ที่เลือก
• ส่วนหัวที่จำเป็น ประเภทเนื้อหา รูปแบบคำขอ รูปแบบการตอบกลับ และตัวระบุเวอร์ชัน
• การดำเนินการที่รองรับและข้อจำกัดใด ๆ ตามบัญชี บริการ ภูมิศาสตร์ หรือประเภทข้อมูล
• ขีดจำกัดอัตราการเรียกใช้ แนวทางเรื่องหมดเวลา ประกาศการบำรุงรักษา และการตอบกลับข้อผิดพลาดที่มีการจัดทำเอกสารไว้
• ข้อกำหนดเกี่ยวกับการจัดเก็บ การแสดง การนำกลับมาใช้ และการเผยแพร่ข้อมูลการตอบกลับของ USPS

หากข้อกำหนดใดไม่ได้ระบุไว้ในเอกสารทางการ ให้ทำเครื่องหมายเพื่อยืนยันโดยตรงกับ USPS หรือตัวแทนบัญชีที่เกี่ยวข้อง อย่าสรุปว่าตัวอย่าง USPS Web Tools รุ่นเก่าแสดงถึง API ปัจจุบัน และอย่าสรุปว่าฟังก์ชันที่อธิบายไว้ในผลิตภัณฑ์ USPS หนึ่งมีให้ใช้งานในอีกผลิตภัณฑ์หนึ่ง

3. จัดทำรายการตรวจสอบการยืนยันตัวตนและความปลอดภัย

ควรทดสอบการยืนยันตัวตนแยกจากตรรกะทางธุรกิจ ทีมควรสามารถเพิกถอนและเปลี่ยนข้อมูลประจำตัวได้โดยไม่ต้องแก้ไขโค้ดแอปพลิเคชันหรือรบกวนฟังก์ชันการติดตามที่ไม่เกี่ยวข้อง

1. จัดเก็บข้อมูลลับของไคลเอ็นต์ API keys โทเค็น และใบรับรองไว้ในที่เก็บข้อมูลลับที่มีการจัดการ แทนการเก็บไว้ในซอร์สโค้ดหรือแอปพลิเคชันฝั่งไคลเอ็นต์
2. ยืนยันว่า USPS API ที่เลือกใช้วิธีการยืนยันตัวตนตามที่อธิบายไว้ในเอกสารปัจจุบันหรือไม่ ใช้ขั้นตอนที่มีการจัดทำเอกสารไว้อย่างถูกต้อง รวมถึงคำขอโทเค็น ขอบเขตสิทธิ์ การหมดอายุ และการรีเฟรชหรือการยืนยันตัวตนใหม่
3. ใช้ข้อมูลประจำตัวหรือสภาพแวดล้อมแยกกันเมื่อ USPS อนุญาต เพื่อไม่ให้ทราฟฟิกทดสอบปะปนกับทราฟฟิกจริง
4. จำกัดการเข้าถึงข้อมูลที่อยู่ลูกค้า ข้อมูลการจัดส่ง และข้อมูลการคืนสินค้าตามบทบาทที่จำเป็นต้องใช้
5. ปกปิดข้อมูลประจำตัวและข้อมูลส่วนบุคคลที่ไม่จำเป็นจากบันทึกของแอปพลิเคชัน
6. บันทึกความล้มเหลวในการยืนยันตัวตนด้วยตัวระบุการเชื่อมโยง แต่หลีกเลี่ยงการบันทึกข้อมูลลับหรือเพย์โหลดที่ละเอียดอ่อนทั้งหมด
7. ทดสอบพฤติกรรมเมื่อโทเค็นหมดอายุ ข้อมูลประจำตัวถูกเพิกถอน คำขอถูกส่งซ้ำ หรือบริการยืนยันตัวตนไม่พร้อมใช้งานชั่วคราว

สำหรับการผสานรวม 17TRACK ให้แยกข้อมูลประจำตัวของผู้ให้บริการขนส่งออกจากข้อมูลประจำตัวของ 17TRACK ในเชิงแนวคิด เว้นแต่เอกสารที่เกี่ยวข้องจะกำหนดรูปแบบอื่นอย่างชัดเจน ไม่ควรสรุปว่าคำขอติดตามที่ส่งผ่าน 17TRACK จะให้สิทธิ์เข้าถึงบริการไปรษณียากร บัญชี หรือฉลากของ USPS

4. ยืนยันตัวระบุและเจ้าของข้อมูล

ตัวตนของการจัดส่งเป็นสาเหตุที่พบบ่อยของคำสั่งซื้อซ้ำและลิงก์การคืนสินค้าที่ใช้งานไม่ได้ ควรจัดทำแผนผังฟิลด์ก่อนเชื่อมต่อระบบ อย่างน้อยต้องแยกค่าต่อไปนี้:

ค่าทางธุรกิจ	คำถามด้านการใช้งาน	จุดตรวจสอบ
รหัสคำสั่งซื้อ	ระเบียนการค้าหรือ OMS ใดเป็นเจ้าของคำสั่งซื้อ	คำสั่งซื้อหนึ่งรายการอาจมีหลายพัสดุ
รหัสการจัดส่ง	การดำเนินการของคลังสินค้าหรือ 3PL ใดเป็นผู้ปล่อยการจัดส่ง	อย่าแทนที่ด้วยหมายเลขติดตาม
หมายเลขติดตาม	ตัวระบุใดถูกส่งไปยัง USPS หรือ 17TRACK	ตรวจสอบรูปแบบ การกำหนดผู้ให้บริการ และการจัดการรายการซ้ำ
รหัสการคืนสินค้า	การอนุมัติหรือกรณีคืนสินค้าใดเป็นเจ้าของพัสดุ	การจัดส่งคืนไม่ควรเขียนทับการจัดส่งขาออก
รหัสเหตุการณ์และเวลาประทับ	จัดการเหตุการณ์ซ้ำหรือล่าช้าอย่างไร	กำหนดกฎลำดับ เขตเวลา และ idempotency

เก็บรักษาเหตุการณ์ดั้งเดิมของผู้ให้บริการขนส่งและสถานะภายในที่ผ่านการทำให้เป็นมาตรฐานไว้เมื่อทำได้ สถานะมาตรฐาน เช่น "อยู่ระหว่างการขนส่ง" มีประโยชน์สำหรับหน้าร้าน แต่ทีมปฏิบัติการอาจยังต้องใช้ข้อความเหตุการณ์ USPS ดั้งเดิม สถานที่ และเวลาของเหตุการณ์เพื่อการตรวจสอบ

5. ออกแบบการรับข้อมูลการติดตามและการจับคู่สถานะ

ก่อนเชื่อมต่อทราฟฟิกจริง ให้จัดทำรายการสถานะตลอดวงจรที่ธุรกิจต้องการจริง สถานะทั่วไปอาจรวมถึงสร้างฉลากแล้ว รับพัสดุแล้ว อยู่ระหว่างการขนส่ง กำลังนำจ่าย จัดส่งสำเร็จ ข้อยกเว้นในการจัดส่ง และส่งคืนผู้ส่ง ต้องตรวจสอบคำศัพท์เหตุการณ์ USPS ที่แน่นอนและเหตุการณ์ที่ 17TRACK เปิดเผยในเอกสารและการตอบกลับการทดสอบที่เกี่ยวข้อง อย่าสร้างการจับคู่จากชื่อสถานะเพียงอย่างเดียว

สำหรับแต่ละเหตุการณ์ ให้กำหนด:

• ระบบต้นทางและรหัสหรือคำอธิบายเหตุการณ์ดั้งเดิม
• สถานะภายในที่ผ่านการทำให้เป็นมาตรฐาน
• เหตุการณ์นั้นแสดงต่อลูกค้า สำหรับฝ่ายปฏิบัติการเท่านั้น หรือทั้งสองกลุ่ม
• เหตุการณ์นั้นสามารถเลื่อนคำสั่งซื้อไปข้างหน้า หยุด SLA ชั่วคราว กระตุ้นการแจ้งเตือน หรือเปิดกรณีข้อยกเว้นได้หรือไม่
• เหตุการณ์ภายหลังสามารถแก้ไขหรือแทนที่เหตุการณ์นั้นได้หรือไม่
• วิธีจัดการเหตุการณ์ซ้ำและเหตุการณ์ที่ไม่เรียงตามลำดับ

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

6. ตัดสินใจระหว่างการสำรวจข้อมูลและการแจ้งเตือน

การใช้งานต้องระบุวิธีรับข้อมูลการติดตามใหม่ หากผลิตภัณฑ์ USPS หรือ 17TRACK ที่เลือกสนับสนุนกลไกการแจ้งเตือน ให้ตรวจสอบโมเดลการสมัคร รูปแบบการส่ง พฤติกรรมการลองใหม่ วิธีลงนามหรือการตรวจสอบ และข้อจำกัดในเอกสารทางการ หากจำเป็นต้องใช้การสำรวจข้อมูล ให้กำหนดช่วงเวลา เงื่อนไขหยุด กลยุทธ์ backoff และการจัดการการจัดส่งที่ไม่มีเหตุการณ์ใหม่

อย่าสำรวจข้อมูลอย่างถี่เกินไปเพียงเพราะลูกค้ารีเฟรชหน้าติดตาม ใช้ที่เก็บเหตุการณ์หรือแคชฝั่งเซิร์ฟเวอร์ตามความเหมาะสม ใช้ exponential backoff สำหรับความล้มเหลวชั่วคราว และทำให้การรับข้อมูลมี idempotency คำขอที่ล้มเหลวไม่ควรสร้างการจัดส่งครั้งที่สอง การคืนสินค้าครั้งที่สอง หรือการแจ้งเตือนลูกค้าซ้ำ

การแจ้งเตือนด้านปฏิบัติการควรครอบคลุมความล้มเหลวในการยืนยันตัวตน การตอบกลับเกินขีดจำกัดอัตราการเรียกใช้อย่างต่อเนื่อง การตอบกลับของผู้ให้บริการที่มีรูปแบบไม่ถูกต้อง ความล้มเหลวในการประมวลผลเหตุการณ์ และจำนวนการจัดส่งที่ยังไม่สามารถระบุผลลัพธ์ได้ที่เพิ่มขึ้น การตรวจสอบควรแสดงทั้งสถานะของ API และสถานะทางธุรกิจ: การตอบกลับ HTTP สำเร็จไม่ได้หมายความว่าการจัดส่งถูกจับคู่กับคำสั่งซื้อที่ถูกต้องเสมอไป

7. แยกการจัดส่งออกจากการคืนสินค้า

การจัดส่งขาออกและการคืนสินค้าใช้ข้อมูลการจัดส่งร่วมกัน แต่มีหลักเกณฑ์ทางธุรกิจต่างกัน การจัดส่งขาออกมักเริ่มจากคำสั่งซื้อและสิ้นสุดเมื่อจัดส่งสำเร็จหรือเกิดข้อยกเว้น การคืนสินค้าเริ่มจากการตัดสินใจของลูกค้าหรือผู้ขาย อาจต้องได้รับอนุมัติ และสิ้นสุดด้วยการตรวจรับ การคืนเงิน การเปลี่ยนสินค้า หรือการดำเนินการอื่น

สำหรับการผสานรวมการคืนสินค้า ให้บันทึกการตัดสินใจต่อไปนี้ก่อนเพิ่มการติดตามของผู้ให้บริการขนส่ง:

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

17RETURNS อาจมีความเกี่ยวข้องเมื่อโครงการต้องการกระบวนการจัดการการคืนสินค้าโดยเฉพาะ ขณะที่ API ของ 17TRACK มีความเกี่ยวข้องกับการมองเห็นการจัดส่ง ควรยืนยันเอกสารผลิตภัณฑ์ปัจจุบันก่อนกำหนดให้ผลิตภัณฑ์ใดทำหน้าที่ เช่น การสร้างฉลาก การอนุมัติคืนเงิน การรับเข้าคลังสินค้า หรือการจัดการบัญชีผู้ให้บริการขนส่ง

8. ทดสอบการผสานรวมด้วยสถานการณ์จริง

การทดสอบเส้นทางปกติสำหรับพัสดุที่จัดส่งสำเร็จเพียงรายการเดียวไม่เพียงพอ จัดทำเมทริกซ์การทดสอบที่รวมถึง:

1. หมายเลขติดตาม USPS ที่ถูกต้องแต่ไม่มีเหตุการณ์ล่าสุด
2. การจัดส่งที่ได้รับเหตุการณ์ไม่เรียงตามลำดับ
3. เหตุการณ์จัดส่งสำเร็จหรือเหตุการณ์ข้อยกเว้นที่เกิดซ้ำ
4. ตัวระบุที่ไม่ถูกต้อง พิมพ์ผิด หรือไม่รองรับ
5. พัสดุที่ถูกส่งคืนผู้ส่ง
6. การจัดส่งขาออกและการจัดส่งคืนที่เชื่อมโยงกับคำสั่งซื้อเดียวกัน
7. API หมดเวลา การตอบกลับเกินขีดจำกัดอัตราการเรียกใช้ ความล้มเหลวในการยืนยันตัวตน และการตอบกลับที่มีรูปแบบไม่ถูกต้อง
8. การจัดส่งที่ยังไม่ทราบผู้ให้บริการในเบื้องต้นหรือต้องยืนยัน
9. หน้าสำหรับลูกค้าที่ได้รับเหตุการณ์ใหม่ขณะที่ผู้ใช้ฝ่ายปฏิบัติการกำลังแก้ไขคำสั่งซื้อ

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

9. การตรวจสอบความพร้อมสำหรับการใช้งานจริง

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

ดำเนินการตรวจสอบให้เสร็จสิ้นหลังจากตรวจสอบเอกสาร USPS ปัจจุบัน เอกสาร 17TRACK API ที่เลือก และข้อกำหนดหรือแนวทางปฏิบัติการเฉพาะผลิตภัณฑ์แล้วเท่านั้น เก็บบันทึกแบบมีเวอร์ชันของเอกสารอ้างอิง endpoint การจับคู่ฟิลด์ หลักฐานการทดสอบ เจ้าของข้อมูลประจำตัว ผู้ติดต่อสำหรับการยกระดับปัญหา และสมมติฐานที่ต้องยืนยันโดยตรง ทบทวนบันทึกเมื่อเวอร์ชัน API กระบวนการของผู้ให้บริการขนส่ง กระบวนการคลังสินค้า หรือนโยบายการคืนสินค้าเปลี่ยนแปลง

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

17TRACK สามารถแทนที่ USPS API สำหรับฟังก์ชันการจัดส่งทั้งหมดได้หรือไม่

ไม่ควรตั้งสมมติฐานเช่นนั้น สามารถประเมิน 17TRACK ในฐานะชั้นการติดตามได้ แต่ฟังก์ชันที่เกี่ยวข้องกับ USPS เช่น การกำหนดราคา บริการที่อยู่ ไปรษณียากร หรือการดำเนินการอื่นของผู้ให้บริการขนส่ง ต้องยืนยันกับเอกสารผลิตภัณฑ์และข้อกำหนดของบัญชีที่เกี่ยวข้อง การมองเห็นการติดตามไม่ใช่สิ่งเดียวกับการซื้อฉลากหรือการดำเนินการจัดส่ง

จำเป็นต้องมีทั้งการผสานรวม USPS และ 17TRACK หรือไม่

ไม่เสมอไป หากแอปพลิเคชันต้องการเพียงฟังก์ชัน USPS ที่กำหนดขอบเขตแคบ การผสานรวมกับ USPS โดยตรงอาจเหมาะสม หากต้องการการติดตามมาตรฐานจากผู้ให้บริการหลายรายหรือกระบวนการติดตามที่ไม่ผูกกับผู้ให้บริการขนส่ง 17TRACK อาจมีความเกี่ยวข้อง การตัดสินใจควรเป็นไปตามความสามารถที่ต้องการ โมเดลความเป็นเจ้าของ และการไหลของข้อมูล ไม่ใช่หมายเลขติดตามเพียงอย่างเดียว

ควรแทนที่หมายเลขติดตามขาออกด้วยหมายเลขติดตามการคืนสินค้าหรือไม่

ไม่ควร เก็บการคืนสินค้าเป็นการจัดส่งหรือการเคลื่อนย้ายการคืนสินค้าแยกต่างหากที่เชื่อมโยงกับคำสั่งซื้อเดิมและระเบียนการจัดส่ง วิธีนี้ช่วยรักษาประวัติการจัดส่งขาออก และทำให้การคืนสินค้ามีเหตุการณ์ ข้อยกเว้น และผลลัพธ์ด้านปฏิบัติการของตนเอง

ควรจัดการเหตุการณ์การติดตามที่หายไปอย่างไร

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

ควรเก็บข้อมูลประจำตัวของ USPS ไว้ที่ใด

ใช้ที่เก็บข้อมูลลับฝั่งเซิร์ฟเวอร์ที่มีการจัดการ และจำกัดการเข้าถึงตามบทบาท ห้ามใส่ข้อมูลประจำตัวไว้ใน JavaScript ของหน้าร้าน โค้ดไคลเอ็นต์มือถือ พื้นที่เก็บข้อมูลสาธารณะ หรือบันทึก ตรวจสอบข้อกำหนดปัจจุบันของ USPS เกี่ยวกับการยืนยันตัวตนและการจัดการข้อมูลประจำตัวก่อนใช้งานจริง

แหล่งข้อมูล

• USPS Web Tools and APIs — จุดเริ่มต้นอย่างเป็นทางการของ USPS สำหรับข้อมูล API ธุรกิจ
• เอกสาร 17TRACK Tracking API — เอกสารอย่างเป็นทางการสำหรับการผสานรวม 17TRACK API
• 17RETURNS — ข้อมูลผลิตภัณฑ์อย่างเป็นทางการสำหรับกรณีการใช้งานด้านการจัดการการคืนสินค้า
• 17TRACK API — ภาพรวมผลิตภัณฑ์อย่างเป็นทางการสำหรับกรณีการใช้งาน Tracking API