API ติดตามการขนส่งสินค้าทางทะเล: เหตุการณ์ของตู้คอนเทนเนอร์ ข้อมูล ETA และเกณฑ์การคัดเลือก
API ติดตามการขนส่งทางทะเลควรเชื่อมโยงการเคลื่อนย้ายตู้คอนเทนเนอร์ เหตุการณ์สำคัญของการขนส่ง และข้อมูล ETA เข้ากับการขนส่งสินค้าที่ทีมของคุณดูแล สำหรับผู้รับจัดการขนส่งสินค้า ผู้นำเข้า และทีมงานด้านการผสานระบบ เกณฑ์ในการคัดเลือกคือ API สามารถระบุเส้นทางการเดินทางของตู้คอนเทนเนอร์ที่ถูกต้องได้อย่างน่าเชื่อถือ แยกเหตุการณ์จริงออกจากการคาดการณ์ และแสดงบริบทที่เพียงพอเพื่อสนับสนุนการตัดสินใจด้านปฏิบัติการหรือไม่ สถานะการขนส่งทั่วไปหรือวันที่มาถึงที่ไม่มีคำอธิบายไม่เพียงพอสำหรับการจัดการขนส่งทางทะเล
คู่มือนี้อธิบายข้อมูลที่ควรร้องขอ วิธีตีความเหตุการณ์ของตู้คอนเทนเนอร์และค่าประมาณการมาถึง ตลอดจนวิธีประเมินการผสานระบบก่อนนำทราฟฟิกจริงหรือใช้งบประมาณจัดซื้อ
เริ่มจากโมเดลการขนส่ง ไม่ใช่หน้าจอติดตาม
การติดตามการขนส่งทางทะเลเกี่ยวข้องกับวัตถุหลายรายการที่เชื่อมโยงกัน ได้แก่ การขนส่งเชิงพาณิชย์ เอกสารการขนส่ง ตู้คอนเทนเนอร์หนึ่งตู้หรือมากกว่า และช่วงการขนส่งที่ใช้ลำเลียงสินค้า ความสัมพันธ์เหล่านี้มีความสำคัญ เนื่องจากการจองครั้งเดียวอาจเกี่ยวข้องกับตู้คอนเทนเนอร์หลายตู้ ขณะที่ตู้คอนเทนเนอร์หนึ่งตู้อาจเคลื่อนผ่านเรือ ท่าเทียบเรือ และช่วงขนส่งภายในประเทศหลายช่วง
การผสานระบบที่มีประโยชน์ต้องรักษาความสัมพันธ์เหล่านี้ไว้ แทนที่จะรวมทุกอย่างให้เหลือเพียงสถานะเดียว หากตู้คอนเทนเนอร์สองตู้ภายใต้การขนส่งเดียวกันเคลื่อนที่แตกต่างกัน ระบบควรเปิดให้ผู้ปฏิบัติงานเห็นความแตกต่างนั้น แทนที่จะแสดงเหตุการณ์สำคัญระดับการขนส่งที่ดูเหมือนสมบูรณ์
ก่อนประเมิน API ให้ระบุข้อมูลอ้างอิงที่ธุรกิจของคุณได้รับจริง:
- หมายเลขตู้คอนเทนเนอร์: ระบุอุปกรณ์ แต่ควรเชื่อมโยงกับการขนส่งหรือเส้นทางที่เกี่ยวข้อง เนื่องจากตู้คอนเทนเนอร์ถูกนำกลับมาใช้ซ้ำ
- หมายเลขอ้างอิงการจองของผู้ให้บริการขนส่ง: สามารถเชื่อมโยงคำขอติดตามกับการจองได้ ทั้งนี้ขึ้นอยู่กับข้อกำหนดการค้นหาของระบบต้นทาง
- หมายเลขอ้างอิงเอกสารการขนส่ง: อาจใช้ระบุการขนส่งในระดับผู้ให้บริการขนส่งทางทะเล ควรยืนยันว่า API รองรับหมายเลขอ้างอิงเอกสารที่ทีมของคุณมีหรือไม่
- ID การขนส่งภายใน: เชื่อมโยงข้อมูลการติดตามจากภายนอกกับระบบจัดการการขนส่ง ERP หรือซอฟต์แวร์การรับจัดการขนส่งของคุณ
อย่าสันนิษฐานว่าหมายเลขอ้างอิงใบตราส่งสินค้าภายในที่ออกโดยผู้รับจัดการขนส่งจะใช้ได้ทุกกรณีที่ต้องใช้หมายเลขอ้างอิงเอกสารของผู้ให้บริการขนส่งทางทะเล ให้ทดสอบตัวระบุที่มีอยู่จริงในขั้นตอนการจองและการจัดการเอกสารของคุณ
API ควรแสดงเหตุการณ์ใดของตู้คอนเทนเนอร์
มาตรฐาน Track & Trace ของ Digital Container Shipping Association เป็นข้อมูลอ้างอิงที่มีประโยชน์สำหรับการอภิปรายข้อมูลการขนส่งทางทะเล DCSA แยกเหตุการณ์เป็นเหตุการณ์ของการขนส่ง เหตุการณ์ของช่วงการขนส่ง และเหตุการณ์ของอุปกรณ์ หมวดหมู่เหล่านี้ช่วยแยกความคืบหน้าด้านเอกสาร การเคลื่อนที่ของการขนส่ง และการจัดการตู้คอนเทนเนอร์จริงออกจากกัน
ผู้ให้บริการไม่จำเป็นต้องใช้ชื่อฟิลด์ตามที่คุณต้องการจึงจะมีประโยชน์ แต่ควรอธิบายว่าโมเดลเหตุการณ์ของตนเชื่อมโยงกับเหตุการณ์สำคัญด้านปฏิบัติการที่คุณต้องการอย่างไร
เหตุการณ์ของอุปกรณ์: เกิดอะไรขึ้นกับตู้คอนเทนเนอร์
เหตุการณ์สำคัญของอุปกรณ์ที่เกี่ยวข้องอาจรวมถึงการนำตู้เข้า การบรรทุก การขนถ่าย การนำตู้ออก และการเคลื่อนย้ายตู้เปล่า ความพร้อมใช้งานขึ้นอยู่กับเส้นทาง แหล่งข้อมูล และผลิตภัณฑ์ ควรขอตัวอย่างข้อมูลจริง แทนที่จะสันนิษฐานว่าทุกเหตุการณ์มีอยู่ที่ทุกท่าเทียบเรือ
ความแตกต่างเหล่านี้มีผลในทางปฏิบัติ การมาถึงของเรือไม่ได้พิสูจน์ว่าตู้คอนเทนเนอร์บางตู้ถูกขนถ่ายแล้ว การขนถ่ายไม่ได้พิสูจน์ว่าตู้ได้รับการปล่อยหรือพร้อมให้ไปรับ บันทึกการนำตู้ออกก็ต้องมีสถานที่และบริบทด้วย การนำตู้ออกจากสถานีถ่ายลำไม่ใช่ผลลัพธ์ทางธุรกิจแบบเดียวกับการรับตู้จากท่าเทียบเรือนำเข้าปลายทาง
เหตุการณ์ของการขนส่ง: เรือหรือช่วงการขนส่งอยู่ที่ใด
เหตุการณ์การมาถึงและการออกเดินทางอธิบายกิจกรรมการขนส่ง ในการตีความ ระบบของคุณต้องมีสถานที่ที่เกี่ยวข้อง รูปแบบการขนส่ง และช่วงการขนส่ง หากมี ตัวระบุเรือและเที่ยวเรือจะช่วยแยกการเดินเรือที่ต้องการออกจากการเคลื่อนย้ายอื่นที่ให้บริการท่าเรือเดียวกัน
สำหรับสินค้าถ่ายลำ ให้เก็บจุดแวะพักระหว่างทางไว้ การลดเส้นทางให้เหลือเพียงต้นทางและปลายทางอาจซ่อนการพลาดเที่ยวเชื่อมต่อหรือการเปลี่ยนเส้นทาง ไทม์ไลน์ด้านปฏิบัติการควรทำให้เห็นได้ว่าช่วงใดเสร็จสิ้นแล้วและช่วงใดยังเป็นเพียงค่าประมาณ
เหตุการณ์ของการขนส่ง: ความคืบหน้าด้านเอกสารไม่ใช่การเคลื่อนที่จริง
เหตุการณ์ด้านเอกสารและการประมวลผลการขนส่งอาจเป็นประโยชน์ต่อขั้นตอนงานรับจัดการขนส่ง แต่ควรแยกออกจากการเคลื่อนที่ของตู้คอนเทนเนอร์ เหตุการณ์สำคัญด้านเอกสารไม่ได้ยืนยันว่าสินค้าเคลื่อนที่จริง และเหตุการณ์การเคลื่อนที่ก็ไม่ได้ยืนยันว่าข้อกำหนดทางการค้าหรือกฎระเบียบทั้งหมดได้รับการปฏิบัติตาม
สำหรับแต่ละเหตุการณ์ ให้ร้องขอประเภทเหตุการณ์ วัตถุที่เกี่ยวข้อง สถานที่ เวลาเหตุการณ์ ข้อมูลเขตเวลา แหล่งที่มา และตัวบ่งชี้ว่าเหตุการณ์นั้นเป็นแผนการ ค่าประมาณ หรือเหตุการณ์จริง นอกจากนี้ควรขอตัวระบุเหตุการณ์ที่คงที่และพฤติกรรมเมื่อมีการแก้ไข เพื่อไม่ให้การอัปเดตซ้ำสร้างเหตุการณ์สำคัญซ้ำ
ข้อมูล ETA ต้องมีปลายทาง ความหมาย และประวัติ
ETA คือเวลาประมาณการมาถึง ณ จุดที่ระบุ ไม่ได้หมายความโดยอัตโนมัติว่าสินค้าจะพร้อมให้รับ API ติดตามการขนส่งทางทะเลควรระบุเหตุการณ์สำคัญของปลายทางอย่างชัดเจน แทนการส่งฟิลด์กำกวมที่มีชื่อเพียง eta
ตัวอย่างเช่น ค่าประมาณการมาถึงอาจหมายถึงการเข้าเทียบท่า ท่าเทียบเรือ สถานที่ภายในประเทศ หรือปลายทางอื่นที่กำหนดไว้ ก่อนนำไปใช้จัดตารางรถบรรทุกหรือรับรองความพร้อมของสินค้า ควรระบุให้ชัดเจนว่าเวลานั้นหมายถึงอะไร
แยกแหล่งที่มาของค่าประมาณออกจากสถานะ
ค่าประมาณจากผู้ให้บริการขนส่งและการคาดการณ์ที่ผู้ให้บริการระบบสร้างขึ้นเป็นข้อมูลคนละประเภท ไม่ควรนำเสนออย่างใดอย่างหนึ่งว่าเป็นการมาถึงจริง ควรถามว่าการตอบกลับระบุแหล่งที่มาของค่าประมาณ เวลาที่คำนวณหรือเผยแพร่ และสถานที่หรือเหตุการณ์ที่คาดการณ์หรือไม่
หากผู้ให้บริการมี ETA แบบคาดการณ์ ให้ขอวิธีการและแนวทางการตรวจสอบความถูกต้อง คำถามที่มีประโยชน์ ได้แก่ คาดการณ์เหตุการณ์สำคัญใด วัดประสิทธิภาพล่วงหน้าก่อนการมาถึงนานเท่าใด และผลลัพธ์แตกต่างกันระหว่างเส้นทางที่คุณใช้หรือไม่ การกล่าวอ้างเรื่องความแม่นยำโดยรวมตีความได้ยาก หากไม่ระบุเหตุการณ์เป้าหมายและช่วงเวลาที่ใช้วัด
เก็บการแก้ไข ETA แทนการเขียนทับ
ETA ล่าสุดสนับสนุนการวางแผนในวันนี้ ส่วนประวัติการแก้ไขอธิบายว่าอะไรเปลี่ยนแปลง ให้จัดเก็บค่าประมาณเดิม ค่าประมาณใหม่ เหตุการณ์สำคัญที่เกี่ยวข้อง แหล่งที่มา และเวลาที่ระบบของคุณได้รับการเปลี่ยนแปลง
ประวัตินี้ช่วยให้ทีมปฏิบัติการแยกความล่าช้าที่มีนัยสำคัญออกจากการแก้ไขรูปแบบหรือการเปลี่ยนแปลงการเข้าเทียบท่าที่ไม่เกี่ยวข้อง อีกทั้งสนับสนุนการประเมินย้อนหลังโดยไม่แสร้งทำเป็นว่าทราบค่าประมาณสุดท้ายตั้งแต่ช่วงต้นของเส้นทาง
ควรทดสอบเขตเวลาอย่างชัดเจน เก็บเวลาจากแหล่งที่มาและส่วนต่างเขตเวลาเมื่อมีการระบุ ทำให้เวลาเป็นมาตรฐานสำหรับการคำนวณ และแสดงเวลาปฏิบัติการท้องถิ่นเมื่อเหมาะสม หากแหล่งข้อมูลให้เพียงวันที่ อย่าแปลงเป็นคำมั่นสัญญาว่าจะมาถึงในเวลาเที่ยงคืนอย่างแม่นยำโดยไม่แจ้งให้ทราบ
ประเมินความครอบคลุมในระดับเหตุการณ์
การที่ผู้ให้บริการขนส่งปรากฏอยู่ในรายการความครอบคลุมไม่ได้พิสูจน์ด้วยตัวเองว่าเหตุการณ์สำคัญของตู้คอนเทนเนอร์ทุกเหตุการณ์มีให้บริการ ควรทดสอบความครอบคลุมกับผู้ให้บริการ เส้นทาง หมายเลขอ้างอิงการขนส่ง และเหตุการณ์ด้านปฏิบัติการที่สำคัญต่อธุรกิจของคุณ
จัดทำตารางประเมินตามข้อกำหนดจริงของคุณ สำหรับการขนส่งตัวแทนแต่ละรายการ ให้ตรวจสอบว่า API แก้ไขหมายเลขอ้างอิงได้หรือไม่ ส่งคืนเส้นทางที่ถูกต้องหรือไม่ แสดงเหตุการณ์สำคัญที่ต้องการหรือไม่ และรักษาการอัปเดตจนถึงช่วงของเส้นทางที่คุณดูแลหรือไม่
- การขนส่งทางทะเลโดยตรง: คุณสามารถระบุการออกจากต้นทาง การมาถึงปลายทาง และเหตุการณ์การจัดการตู้คอนเทนเนอร์ที่เกี่ยวข้องได้หรือไม่
- การขนส่งแบบถ่ายลำ: มองเห็นช่วงระหว่างทางหรือไม่ และสามารถแยกตู้คอนเทนเนอร์ที่เคลื่อนที่แตกต่างกันได้หรือไม่
- ช่วงขนส่งภายในประเทศ: หากบริการของคุณรวมช่วงดังกล่าว API มีเหตุการณ์สำคัญที่เกี่ยวข้องกับรถไฟ เรือบาร์จ หรือรถบรรทุกหรือไม่ หรือการมองเห็นสิ้นสุดที่ท่าเรือ
- เหตุการณ์ผิดปกติ: เหตุการณ์ที่หายไป เส้นทางที่เปลี่ยน หมายเลขอ้างอิงที่จับคู่ไม่ได้ และการหยุดชะงักของแหล่งข้อมูลถูกนำเสนออย่างไร
- การขนส่งที่เสร็จสิ้นแล้ว: ทีมของคุณเรียกดูข้อมูลย้อนหลังได้เพียงพอเพื่อตรวจสอบข้อพิพาทของลูกค้าหรือกระทบยอดบันทึกด้านปฏิบัติการหรือไม่
แยกข้อมูลที่ไม่พร้อมใช้งานออกจากเหตุการณ์เชิงลบ การไม่มีบันทึกการขนถ่ายไม่ได้พิสูจน์ว่าการขนถ่ายยังไม่เกิดขึ้น การผสานระบบที่มีประโยชน์ต้องแยกสถานะด้านปฏิบัติการที่ระบุไว้อย่างชัดเจนออกจากช่องว่างในการมองเห็น
พฤติกรรมของ API สำคัญพอๆ กับรายการเหตุการณ์
แม้ฟีดเหตุการณ์จะมีข้อมูลมาก แต่ก็อาจใช้งานยากหากพฤติกรรมการส่งข้อมูลไม่ชัดเจน ควรประเมินว่าแอปพลิเคชันของคุณรับการอัปเดต จัดการการแก้ไข และกู้คืนหลังระบบขัดข้องอย่างไร
การเรียกดูข้อมูล เว็บฮุก และการกู้คืน
การเรียกดูข้อมูลเปิดให้แอปพลิเคชันร้องขอการอัปเดตตามกำหนดเวลาของตน เว็บฮุกเปิดให้ผู้ให้บริการส่งการอัปเดตไปยังปลายทางที่คุณดูแล กลไกทั้งสองแบบไม่ได้รับประกันความใหม่ของข้อมูลด้วยตัวเอง เว็บฮุกที่ส่งถึงทันทีอาจยังมีเหตุการณ์จากแหล่งข้อมูลที่ได้รับล่าช้า
ขอคำจำกัดความแยกกันของเวลาเหตุการณ์จากแหล่งข้อมูล เวลาที่ผู้ให้บริการได้รับ และเวลาการแจ้งเตือนเมื่อมีข้อมูล สำหรับเว็บฮุก ให้ยืนยันการยืนยันตัวตนหรือการตรวจสอบลายเซ็น การลองส่งซ้ำ พฤติกรรมเมื่อส่งซ้ำ และการนำการแจ้งเตือนที่ล้มเหลวกลับมาเล่นใหม่ได้หรือไม่ สำหรับการเรียกดูข้อมูล ให้ตรวจสอบการแบ่งหน้า ขีดจำกัดอัตราการเรียก การดึงข้อมูลแบบเพิ่ม และการจัดการการแก้ไขข้อมูลย้อนหลัง
การทำให้เป็นมาตรฐานโดยไม่สูญเสียหลักฐาน
สถานะที่ทำให้เป็นมาตรฐานช่วยให้ขั้นตอนงานข้ามผู้ให้บริการง่ายขึ้น แต่การลดทอนมากเกินไปจะลบบริบทที่มีประโยชน์ ควรเลือกโมเดลที่เก็บเหตุการณ์ที่ทำให้เป็นมาตรฐานไว้พร้อมคำอธิบายหรือรหัสดั้งเดิมจากแหล่งข้อมูลเมื่อมี
จัดเก็บระเบียนดิบที่ได้รับแยกจากกฎทางธุรกิจที่แปลงระเบียนเหล่านั้นเป็นสถานะบนแดชบอร์ด วิธีนี้ช่วยให้คุณแก้ไขการจับคู่ได้โดยไม่สูญเสียหลักฐานเดิม และทำให้ตรวจสอบสถานะที่แสดงต่อลูกค้าได้ง่ายขึ้นเมื่อแตกต่างจากการตีความของทีมปฏิบัติการ
การตรวจสอบด้านการค้าและการกำกับดูแล
ขอคำอธิบายเป็นลายลักษณ์อักษรเกี่ยวกับหน่วยที่ใช้เรียกเก็บเงิน ค่าสมาชิก การขนส่งที่ติดตาม ตู้คอนเทนเนอร์ คำขอ API และการแจ้งเตือนไม่ใช่หน่วยที่ใช้แทนกันได้ ควรชี้แจงว่าการลองส่งซ้ำ การลงทะเบียนซ้ำ การค้นหาข้อมูลย้อนหลัง และการขนส่งที่เปิดใช้งานอีกครั้งส่งผลต่อค่าใช้จ่ายอย่างไร แทนที่จะสันนิษฐานถึงรูปแบบราคาใดรูปแบบหนึ่ง
นอกจากนี้ควรทบทวนการเก็บรักษาข้อมูล การควบคุมการเข้าถึง การหมุนเวียนข้อมูลรับรอง การใช้ข้อมูลต่อในระบบปลายทางที่อนุญาต การยกระดับปัญหาไปยังฝ่ายสนับสนุน และข้อผูกพันด้านบริการ ควรแยกการรับประกันตามสัญญาออกจากการสาธิตผลิตภัณฑ์และข้อความทางการตลาด
อย่าสันนิษฐานว่า API ติดตามทั่วไปตรงตามข้อกำหนดของการขนส่งทางทะเล
ควรเลือก API ติดตามจากโมเดลข้อมูลที่ตรวจสอบแล้ว ไม่ใช่จากป้ายกำกับหมวดหมู่ การอัปเดตการจัดส่งพัสดุและการมองเห็นตู้คอนเทนเนอร์ทางทะเลอาจรองรับขั้นตอนงานที่แตกต่างกัน แม้ทั้งสองอย่างจะเรียกว่าการติดตามการขนส่ง
หาก 17TRACK อยู่ในรายชื่อผู้ให้บริการที่คุณพิจารณาแล้ว ให้ใช้ หน้าการติดตาม API อย่างเป็นทางการ และ เอกสาร API เป็นจุดเริ่มต้นในการตรวจสอบข้อกำหนด ยืนยันหมายเลขอ้างอิงทางทะเล เหตุการณ์ของตู้คอนเทนเนอร์ ช่วงการขนส่ง และฟิลด์ ETA ที่แอปพลิเคชันของคุณต้องการอย่างชัดเจน ก่อนถือว่าการผสานระบบติดตามทั่วไปใดๆ เป็นโซลูชันสำหรับการขนส่งทางทะเล คู่มือนี้ไม่ได้ยืนยันความสามารถเฉพาะด้านการขนส่งทางทะเลของ 17TRACK
ควรใช้มาตรฐานการยอมรับเดียวกันกับผู้สมัครทุกราย ได้แก่ สาธิตข้อมูลที่จำเป็นด้วยการขนส่งตัวแทนและอธิบายข้อจำกัดของระบบ กระบวนการติดตามจากผู้ให้บริการหลายรายที่ครอบคลุมกว่าอาจมีประโยชน์ในส่วนอื่นของห่วงโซ่อุปทาน โดยไม่สามารถทดแทนฟีดเหตุการณ์ตู้คอนเทนเนอร์เฉพาะทางได้
ทำ Proof of Concept โดยยึดการตัดสินใจด้านปฏิบัติการเป็นหลัก
Proof of Concept ที่แข็งแกร่งเริ่มจากการตัดสินใจที่ทีมของคุณต้องทำ ไม่ใช่การสาธิตแดชบอร์ด เลือกการขนส่งตัวแทนจากการดำเนินงานจริงของคุณ รวมทั้งเส้นทางที่ตรงไปตรงมาและกรณียากที่ก่อให้เกิดงานด้วยตนเอง
- กำหนดเกณฑ์การยอมรับ ระบุหมายเลขอ้างอิง เหตุการณ์ สถานที่ ความหมายของเวลา และวิธีจัดการข้อมูลที่หายไปที่ยอมรับได้ก่อนทดสอบ
- ตรวจสอบตัวตน ยืนยันว่าผลลัพธ์ทุกชุดเป็นของการขนส่งและเส้นทางตู้คอนเทนเนอร์ที่ต้องการ รวมอุปกรณ์ที่นำกลับมาใช้ซ้ำและการจองที่มีหลายตู้เมื่อเกี่ยวข้อง
- เปรียบเทียบกับระเบียนต้นทาง ตรวจสอบเหตุการณ์สำคัญที่ส่งคืนกับระเบียนของผู้ให้บริการขนส่งหรือท่าเทียบเรือที่เข้าถึงได้ โดยคำนึงถึงความแตกต่างของเวลาการอัปเดต
- ทดสอบการแก้ไขและความล้มเหลว ทดสอบการแจ้งเตือนซ้ำ เหตุการณ์นอกลำดับ เวลาที่แก้ไข แหล่งข้อมูลที่ไม่พร้อมใช้งาน และระบบปลายทางขัดข้อง
- จำลองขั้นตอนงานทางธุรกิจ ตรวจสอบว่าข้อมูลสนับสนุนการดำเนินการที่ต้องการหรือไม่ เช่น การตรวจสอบการเชื่อมต่อที่ล่าช้าหรือการอัปเดตค่าประมาณสินค้าขาเข้า
- ทบทวนช่องว่างที่ยังแก้ไม่ได้ บันทึกว่าช่องว่างแต่ละรายการเกิดจากแหล่งข้อมูลพื้นฐาน การประมวลผลของผู้ให้บริการ หรือการผสานระบบของคุณ และตกลงแนวทางแก้ไขก่อนขยายการใช้งาน
สำหรับการทดสอบ ETA ให้เก็บการคาดการณ์แต่ละครั้งเมื่อได้รับ และเปรียบเทียบกับเหตุการณ์จริงในท้ายที่สุดของเหตุการณ์สำคัญเดียวกัน อย่าประเมินการคาดการณ์การมาถึงท่าเรือเทียบกับการรับสินค้าเข้าคลัง หรือรวมการคาดการณ์ที่จัดทำขึ้นล่วงหน้าด้วยระยะเวลาต่างกันมากให้เป็นคะแนนเดียวที่ไม่มีคำอธิบาย
กฎในการคัดเลือกนั้นตรงไปตรงมา: เลือกการผสานระบบที่แสดงให้เห็นอย่างชัดเจนว่าสนับสนุนการตัดสินใจที่จำเป็นของคุณด้วยเหตุการณ์ที่ตรวจสอบย้อนกลับได้ ค่าประมาณที่เข้าใจได้ และพฤติกรรมการส่งข้อมูลที่กู้คืนได้ หากการวางแผนรับสินค้ายังต้องใช้ความพร้อมของท่าเทียบเรือ สถานะการปล่อยสินค้า หรือการนัดหมาย ให้ตรวจสอบข้อมูลเหล่านั้นแยกต่างหาก แทนการอนุมานจากการมาถึงของเรือ
คำถามที่พบบ่อย
ฉันสามารถติดตามการขนส่งทางทะเลโดยใช้เพียงหมายเลขตู้คอนเทนเนอร์ได้หรือไม่
ขึ้นอยู่กับแหล่งข้อมูลและ API ขั้นตอนงานบางประเภทอาจต้องใช้ตัวระบุผู้ให้บริการ หมายเลขอ้างอิงการจอง หรือหมายเลขอ้างอิงเอกสารการขนส่งด้วย เนื่องจากอุปกรณ์ถูกนำกลับมาใช้ซ้ำ ให้ยืนยันว่าเหตุการณ์ที่ส่งคืนเป็นของเส้นทางที่ต้องการ ไม่ใช่อาศัยเพียงหมายเลขตู้คอนเทนเนอร์
การมาถึงจริงของเรือหมายความว่าตู้คอนเทนเนอร์ของฉันพร้อมรับหรือไม่
ไม่ใช่ การมาถึงของเรือ การขนถ่ายตู้ ความพร้อมของสินค้า และสิทธิ์ในการรับสินค้าเป็นข้อเท็จจริงด้านปฏิบัติการคนละเรื่องกัน ทั้งนี้ขึ้นอยู่กับการขนส่ง การรับสินค้าอาจต้องใช้ข้อมูลการปล่อยสินค้าและการนัดหมายกับท่าเทียบเรือด้วย ให้ตรวจสอบเงื่อนไขที่เกี่ยวข้องกับฝ่ายที่รับผิดชอบ
การติดตามเรือด้วย AIS ทดแทนการติดตามตู้คอนเทนเนอร์ได้หรือไม่
ไม่ AIS เกี่ยวข้องกับข้อมูลการระบุและการเคลื่อนที่ของเรือ แต่ไม่ได้ยืนยันสถานะการบรรทุก การขนถ่าย การปล่อย หรือการนำตู้ออกของตู้คอนเทนเนอร์แต่ละตู้ การเคลื่อนที่ของเรือช่วยให้มีบริบทได้ แต่ยังต้องยืนยันว่าตู้คอนเทนเนอร์เชื่อมโยงกับเที่ยวเรือนั้น
API ติดตามทางทะเลควรอัปเดตบ่อยเพียงใด
ไม่มีช่วงเวลาที่เหมาะสมเพียงแบบเดียวสำหรับทุกขั้นตอนงาน ควรกำหนดข้อกำหนดตามความเร็วที่ทีมของคุณต้องดำเนินการหลังข้อมูลจากแหล่งที่เกี่ยวข้องพร้อมใช้งาน วัดความล่าช้าจากแหล่งข้อมูลแยกจากความล่าช้าในการส่งผ่าน API และยืนยันว่าจะเกิดอะไรขึ้นเมื่อแหล่งข้อมูลไม่เผยแพร่เหตุการณ์ใหม่
เหตุการณ์การติดตามสามารถใช้คำนวณค่าฝากตู้เกินกำหนดหรือค่ากักตู้ได้หรือไม่
เหตุการณ์ต่างๆ สนับสนุนไทม์ไลน์ได้ แต่ไม่ได้กำหนดการคำนวณค่าใช้จ่ายที่สมบูรณ์ คุณยังต้องใช้เงื่อนไขตามสัญญา กฎระยะเวลาปลอดค่าใช้จ่าย การนับวัน และเงื่อนไขเริ่มต้นกับสิ้นสุดที่เป็นแหล่งอ้างอิง อย่าคำนวณจำนวนเงินที่ต้องชำระจากเหตุการณ์สำคัญทั่วไปเพียงอย่างเดียว
แหล่งข้อมูล
- DCSA: มาตรฐาน Track & Trace — กรอบอ้างอิงสำหรับเหตุการณ์ของการขนส่ง ช่วงการขนส่ง และอุปกรณ์ในการขนส่งตู้คอนเทนเนอร์
- DCSA: ที่เก็บข้อกำหนด OpenAPI — ข้อมูลอ้างอิงทางเทคนิคสำหรับคำจำกัดความ API และโครงสร้างเหตุการณ์ของ DCSA ควรตรวจสอบเวอร์ชันข้อกำหนดที่ใช้เมื่อออกแบบการผสานระบบ
- องค์การทางทะเลระหว่างประเทศ: ระบบระบุอัตโนมัติ — ข้อมูลพื้นฐานเกี่ยวกับ AIS และข้อมูลเรือที่ระบบจัดหาให้
- 17TRACK: Tracking API และ เอกสาร API อย่างเป็นทางการ — จุดเริ่มต้นสำหรับตรวจสอบความเหมาะสมของผลิตภัณฑ์ ไม่ใช่หลักฐานในที่นี้ว่า 17TRACK รองรับเหตุการณ์ตู้คอนเทนเนอร์ทางทะเลหรือ ETA แบบคาดการณ์
