As the GPS service provider for the fleet, our platform holds vehicle-level telemetry only — GPS coordinates, plate number, speed, heading, timestamp. We do not hold Maersk business keys such as Work Order or Container Number. Before we build against Supplier Track API v1.1, we would like Maersk to confirm two points. ในฐานะผู้ให้บริการ GPS ของกองรถ ระบบของเรามีแต่ข้อมูลระดับตัวรถเท่านั้น — พิกัด GPS, ทะเบียนรถ, ความเร็ว, ทิศทาง, เวลา เราไม่มีคีย์ทางธุรกิจของ Maersk เช่น Work Order หรือเลขตู้ ก่อนเราจะเริ่มพัฒนาเชื่อมต่อ Supplier Track API v1.1 เราขอให้ Maersk ยืนยัน 2 ประเด็นนี้ก่อน
| Itemรายการ | Valueค่า |
|---|---|
| Endpointปลายทาง | POST /inlandrvp-inboundapi/vendor/positions |
| Authการยืนยันตัวตน | OAuth 2.0 client credentials → Authorization: Bearer + Consumer-Key headerOAuth 2.0 client credentials → header Authorization: Bearer + Consumer-Key |
| Directionทิศทาง | One-way push (we → Maersk)ส่งทางเดียว (เรา → Maersk) |
| Mandatory keys in every payloadคีย์บังคับในทุก payload | workOrderNumber + containerNumber ← we do not have theseเราไม่มีข้อมูลนี้ |
| What we can natively provideสิ่งที่เรามีให้ได้เองอยู่แล้ว | lat, long, plate, speed, heading, GPS timestampพิกัด lat/long, ทะเบียน, ความเร็ว, ทิศทาง, เวลา GPS |
If we don't have it — can Maersk pull GPS positions from the Mappoint system and manage the rest itself? ถ้าเราไม่มี — ให้ Maersk มาดึงตำแหน่ง GPS จากระบบ Mappoint แล้วไปจัดการเองทั้งหมดได้ไหม?
The Supplier Track payload is keyed on workOrderNumber and containerNumber.
These originate inside Maersk's booking/transport-order system and are shared with the carrier —
they never reach a GPS device. Our system therefore cannot populate these fields on its own.
A GPS point tells us which truck is where, not which Work Order / container that truck is
currently carrying. That link is the missing piece.
payload ของ Supplier Track ใช้ workOrderNumber และ containerNumber เป็นคีย์
ซึ่งเกิดขึ้นในระบบ booking/transport-order ของ Maersk และถูกส่งให้ carrier —
ไม่เคยไหลมาถึงตัวอุปกรณ์ GPS เลย ระบบเราจึงเติมฟิลด์พวกนี้เองไม่ได้
จุด GPS หนึ่งจุดบอกได้แค่ว่า รถคันไหนอยู่ที่ไหน ไม่ได้บอกว่า รถคันนั้นกำลังลาก Work Order / ตู้ใบไหนอยู่
ความเชื่อมโยงตรงนี้คือชิ้นส่วนที่ขาดหายไป
Instead of us pushing into /vendor/positions, we expose a read API on the
Mappoint platform that returns live positions keyed by plate number / device ID. Maersk
(which already owns the Work Order ↔ vehicle assignment) pulls from us and enriches with its own
order/container context on Maersk's side.
แทนที่เราจะ push เข้า /vendor/positions เราจะเปิด read API บนแพลตฟอร์ม Mappoint
ที่คืนตำแหน่งแบบเรียลไทม์โดยใช้ ทะเบียนรถ / device ID เป็นคีย์ ส่วน Maersk
(ซึ่งเป็นคนกำหนดว่ารถคันไหนวิ่ง Work Order ไหนอยู่แล้ว) มาดึงข้อมูลจากเราแล้วไปเติมบริบท
order/ตู้เองที่ฝั่ง Maersk
plate, deviceId, lat, long, speed, heading, timestamp (pull or webhook).เราให้: plate, deviceId, lat, long, speed, heading, timestamp (แบบ pull หรือ webhook)1a. Can Maersk consume a GPS position API from Mappoint (keyed by plate/device) and perform the Work Order / Container mapping on Maersk's side, so we never need to send order data?Maersk สามารถมาดึง GPS position API จาก Mappoint (คีย์ด้วยทะเบียน/device) แล้วทำ mapping Work Order / ตู้ ที่ฝั่ง Maersk เอง เพื่อให้เราไม่ต้องส่งข้อมูล order เลย ได้ไหม?
1b. If Maersk requires us to keep pushing to /vendor/positions, who supplies the plate → Work Order → Container mapping to us, in what format, and how often is it refreshed (a truck can serve several Work Orders per day)?ถ้า Maersk ยังต้องการให้เรา push เข้า /vendor/positions ใครจะเป็นคนส่ง mapping ทะเบียน → Work Order → ตู้ ให้เรา ในรูปแบบไหน และอัปเดตบ่อยแค่ไหน (รถ 1 คันวิ่งได้หลาย Work Order ต่อวัน)?
1c. Is there any accepted way to submit a position with a partial key (e.g. plate/device only, order fields blank) that Maersk resolves downstream?มีวิธีที่ยอมรับได้ไหม ที่จะส่งตำแหน่งด้วยคีย์บางส่วน (เช่น มีแค่ทะเบียน/device ปล่อยฟิลด์ order ว่าง) แล้ว Maersk ไปเติมให้เองปลายทาง?
SCE-TMS Standard Web Service API v1.8 is this project's API — the two are not being combined, correct? SCE-TMS Standard Web Service API v1.8 คือ API ของโปรเจกต์นี้ — ทั้งสองตัวไม่ได้ถูกนำมารวมกัน ใช่ไหม?
We are aware of two distinct Maersk GPS interfaces and want to make sure we are building against the right one, with no hidden dependency between them. เราทราบว่ามี Maersk GPS interface อยู่ 2 ตัวที่แยกกัน และอยากมั่นใจว่าเรากำลังพัฒนากับตัวที่ถูกต้อง โดยไม่มี dependency ซ่อนอยู่ระหว่างกัน
| Aspectประเด็น | A · Supplier Track v1.1 | B · SCE-TMS v1.8 |
|---|---|---|
| Originที่มา | Public Developer Portal (Ocean / Inland)Developer Portal สาธารณะ (Ocean / Inland) | Internal spec — Maersk Contract Logistics (this WGCL project)spec ภายใน — Maersk Contract Logistics (โปรเจกต์ WGCL นี้) |
| Hostโฮสต์ | api.maersk.com/inlandrvp-inboundapi |
api.ocf.fulfillment.maersk.com/tms/mys/gps/p/v1/ |
| Directionทิศทาง | One-way push (we → Maersk)ส่งทางเดียว (เรา → Maersk) | Two-way: Maersk calls pairDevice/unpairDevice to us; we call insertHeartbeat/insertEvent backสองทาง: Maersk เรียก pairDevice/unpairDevice มาที่เรา; เรายิง insertHeartbeat/insertEvent กลับ |
| Order/trip dataข้อมูล order/ทริป | We must supply WO + Containerเราต้องหา WO + ตู้ มาเอง | Maersk delivers trip context via pairDeviceMaersk ส่งบริบททริปมาให้ผ่าน pairDevice |
| Payload formatรูปแบบ payload | Plain JSONJSON ธรรมดา | JSON → Base64 → URL-encoded in form field DataJSON → Base64 → URL-encode ใน form field Data |
The WGCL project is delivered on SCE-TMS API v1.8 (Option B). Supplier Track v1.1 (Option A) is a separate, public Ocean/Inland interface. We assume the two are independent and are not merged or chained — i.e. delivering SCE-TMS does not also require us to push into Supplier Track, and vice versa. โปรเจกต์ WGCL ส่งมอบบน SCE-TMS API v1.8 (ทางเลือก B) ส่วน Supplier Track v1.1 (ทางเลือก A) เป็น interface สาธารณะของ Ocean/Inland ที่แยกออกไป เราเข้าใจว่าทั้งสองตัวเป็นอิสระต่อกัน และไม่ได้ถูกรวมหรือต่อเป็นทอด ๆ — กล่าวคือ การส่งมอบ SCE-TMS ไม่ได้บังคับให้เราต้อง push เข้า Supplier Track ด้วย และในทางกลับกันก็เช่นกัน
2a. For the WGCL project, is SCE-TMS v1.8 the sole required interface, with Supplier Track v1.1 out of scope?สำหรับโปรเจกต์ WGCL, SCE-TMS v1.8 เป็น interface เดียวที่ต้องใช้ และ Supplier Track v1.1 อยู่นอกขอบเขต ใช่ไหม?
2b. Are the two APIs fully independent — no scenario where data must flow through both?API ทั้งสองตัวเป็นอิสระต่อกันโดยสมบูรณ์ — ไม่มีกรณีที่ข้อมูลต้องไหลผ่านทั้งสองตัว ใช่ไหม?
2c. If both are ever needed, which is the system of record for a given trip, and how should the same GPS point be routed to each?ถ้าจำเป็นต้องใช้ทั้งคู่ ตัวไหนคือ system of record ของแต่ละทริป และควรส่งจุด GPS เดียวกันไปยังแต่ละตัวอย่างไร?
Once these two points are confirmed, we can finalize the integration design and the delivery timeline.เมื่อยืนยัน 2 ประเด็นนี้แล้ว เราจะสามารถสรุปแบบ integration และไทม์ไลน์การส่งมอบได้