DurianTradeX
TH中EN
ขอชมระบบ
ตู้รีเฟอร์ทุเรียนถูกยกถ่ายระหว่างเรือที่ท่าเรือต่อเรือ โดยเจ้าหน้าที่ติดตามสถานะผ่านระบบดิจิทัล
TRANSSHIPMENT COLD CHAIN · PRACTICAL GUIDE

Transshipment ตู้ทุเรียน: คุมต่อเรือไม่ให้ Cold Chain ขาด

คู่มือคุม Transshipment ตู้ทุเรียนด้วย Control Sheet 16 ช่อง ติดตามต่อเรือ เวลา Plug-in, Off-power, อุณหภูมิ Route change และหลักฐานแบบรายตู้

โดย · ปรับปรุง · ใช้เวลาอ่าน 14 นาที
EXECUTIVE TAKEAWAYS

คำค้นหลัก: Transshipment ตู้ทุเรียน

  • คำตอบสั้น: ให้บริหาร Transshipment เป็น Cold-chain handover ครั้งที่สอง ไม่ใช่เพียงชื่อท่าในตารางเรือ โดยผูก Container, Lot, Inbound vessel, Connecting vessel, Planned–Estimated–Actual time, Power event และผู้รับผิดชอบไว้ใน Control Sheet เดียว
  • Milestone ขั้นต่ำคือ Discharge จากเรือต้นทาง, Terminal receipt, Plug-in acknowledgement, Off-power/yard move, Load ขึ้นเรือต่อ และ Departure พร้อมเก็บเวลา Time zone และแหล่งข้อมูล ไม่สรุปว่าสินค้าเสียจาก Data gap หรือ Off-power เพียงเหตุการณ์เดียว
  • Schedule และระบบ Monitoring ให้ Visibility แต่ไม่รับประกันการต่อเรือหรือคุณภาพสินค้า ต้องกำหนดเกณฑ์ Escalation, Buyer notification, Evidence pack และผู้อนุมัติตาม Product specification, Contract, Carrier/Terminal capability และสถานการณ์ของ Shipment จริง
01

คำตอบก่อน: Transshipment คือจุดส่งมอบความเสี่ยง ไม่ใช่แค่จุดพักตู้

DCSA นิยาม Transshipment ว่าเป็นการปฏิบัติการที่ Terminal ถ่าย Container หรือสินค้าออกจากเรือลำหนึ่งไปยังอีกลำเพื่อไปถึงปลายทาง ต่างจากบริการ Direct สำหรับตู้ทุเรียน ช่วงนี้รวมทั้งการ Discharge, เคลื่อนย้ายใน Yard, จ่ายไฟซ้ำ, รอ Connecting vessel และ Load ใหม่ จึงต้องควบคุมทั้ง Transport plan, Cold chain และหลักฐานในระดับ Container ไม่ใช่ติดตาม ETA ปลายทางเพียงค่าเดียว

  • แยก Transport leg ทุกช่วงและระบุจุดเริ่ม–จบของความรับผิดชอบ
  • ยืนยัน Inbound vessel/voyage และ Outbound connecting vessel/voyage จากข้อมูลล่าสุด
  • ผูก Booking, Container, Seal, Lot, Product specification และผู้ซื้อให้ค้นย้อนกลับได้
  • กำหนด Owner ทั้ง Shipping, Logistics, QC, Customer service และ Finance
  • ประเมินการต่อเรือจากข้อมูลจริง ไม่ถือ Schedule เป็นคำรับประกัน

หนึ่ง Booking อาจมีหลาย Transport leg

Transport plan ตาม DCSA ครอบคลุมเส้นทางปลายทางถึงปลายทาง รวมทุก Leg, เวลา, Schedule และความเชื่อมโยงระหว่าง Leg ดังนั้นการเปลี่ยนเที่ยวหรือท่าต่อเรือหนึ่งจุดอาจกระทบ ETA, เอกสาร, นัดรับ Buyer, Free Time และอายุการตลาดพร้อมกัน

02

ล็อก 16 ช่องใน Transshipment Control Sheet

รายการนี้เป็นมาตรการควบคุมภายใน ไม่ใช่ Mandatory field ของทุก Carrier หรือ Terminal ให้ปรับตามบริการที่ซื้อ Route, Contract และ Product specification ของ Shipment จริง โดยสร้างหนึ่งชุดต่อ Container และเก็บ Revision ทุกครั้งที่ Transport plan เปลี่ยน

  • 1 Shipment, Booking, Container, Seal, Lot และ Product specification revision
  • 2 Transshipment port/terminal พร้อม UN/LOCODE และ Time zone
  • 3 Inbound vessel/voyage และ Transport leg ต้นทาง
  • 4 Connecting vessel/voyage และ Transport leg ถัดไป
  • 5 Planned–Estimated–Actual arrival และ Discharge time
  • 6 Planned–Estimated–Actual Load และ Departure time
  • 7 Connection buffer, Terminal dwell และ Latest safe connection
  • 8 Setpoint, Ventilation, Humidity/CA และ Setting revision ที่อนุมัติ
  • 9 Actual controller setting หรือหลักฐานยืนยันค่าที่ Carrier ใช้
  • 10 Discharge, Yard move, Plug-out, Plug-in และ Load event
  • 11 Off-power period, Alarm และการตอบสนองของ Carrier/Terminal
  • 12 Monitoring service, Logger ID, Data coverage และจุดขาดข้อมูล
  • 13 Customs/Transit/Authority hold และเอกสารที่เกี่ยวข้อง
  • 14 Route change, Rollover, Port omission หรือ Feeder change พร้อมเหตุผล
  • 15 Product, Buyer, Cost, Insurance และ Claim impact assessment
  • 16 Source, Timestamp, ผู้จัดทำ–ตรวจ–อนุมัติ และ Evidence link
03

แยก Planned, Estimated และ Actual เพื่อเห็นความเสี่ยงต่อเรือจริง

DCSA แยก Planned event ซึ่งอ้างอิงแผนที่ยืนยันแล้ว ออกจาก Estimated event ซึ่งเป็นค่าคาดการณ์แบบ Dynamic และ Actual event ซึ่งยืนยันว่าเหตุการณ์เกิดแล้ว การเขียนทับเวลาเดิมทำให้ทีมไม่เห็นว่าความเสี่ยงเพิ่มขึ้นเมื่อใด จึงควรเก็บทั้ง Baseline, Current estimate และ Actual พร้อม Source และเวลาที่ระบบได้รับข้อมูล

  • ห้ามแทน Planned time ด้วย ETA ล่าสุดโดยไม่เก็บ Revision เดิม
  • ระบุ Time zone และสถานที่ของทุก Timestamp เพื่อป้องกันการคำนวณ Buffer ผิด
  • คำนวณ Connection buffer ใหม่เมื่อ Estimated discharge หรือ Load เปลี่ยน
  • บันทึก Received-at time แยกจาก Event time เพื่อวัดความล่าช้าของข้อมูล
  • ใช้ Actual load และ Actual departure ยืนยันการต่อเรือ ไม่ใช้เพียง Vessel schedule

Route change ต้องมี Change remark และ Impact owner

Operational Vessel Schedules ของ DCSA ช่วยให้แลกเปลี่ยน Schedule และข้อมูลข้อยกเว้นอย่างมีโครงสร้าง แต่ข้อมูลจากหลายฝ่ายอาจมาถึงไม่พร้อมกัน ให้กำหนด Source priority, ผู้ตรวจสอบ และเวลาที่ต้อง Reconcile เมื่อ Vessel, Voyage, Terminal หรือ Port call ไม่ตรงกัน

04

สร้าง Milestone chain ตั้งแต่ Discharge ถึง Departure

DCSA Track & Trace ระบุ Transshipment, Load/Discharge และ Gate event เป็น Milestone สำคัญ ขณะที่ข้อมูลสายเรือแสดงว่า Loaded และ Discharged อาจรวมช่วง Off-power การเห็นเพียงตำแหน่ง Container จึงไม่พอ ต้องทำ Event chain ที่ระบุ Expected event, Actual event, Source และ Exception owner

  • Inbound vessel arrived และ Container discharged
  • Terminal received พร้อม Yard/stack location เมื่อบริการให้ข้อมูล
  • Reefer plugged in และ Setting/Alarm acknowledgement
  • Internal yard moves หรือ Inspection ที่มี Power interruption
  • Container moved to quay และ loaded on connecting vessel
  • Connecting vessel departed และ ETA ปลายทางถูก Reconfirm

Milestone missing ไม่เท่ากับเหตุการณ์ไม่เกิด

ระบบของ Carrier, Terminal และอุปกรณ์ IoT มีรอบการส่งข้อมูลต่างกัน เมื่อ Event หายให้ทำ Data reconciliation จาก Portal/API, Carrier notice, Terminal acknowledgement และ Datalog ก่อนสรุปสถานะ พร้อมเก็บว่าข้อมูลใดยืนยันแล้วและข้อมูลใดยังเป็นการคาดการณ์

05

แยก Off-power, Data gap และ Temperature excursion ออกจากกัน

Hapag-Lloyd อธิบายว่าการ Load, Discharge และ Internal move อาจมีช่วง Off-power และการขาดข้อมูลอาจเกิดจากไม่มีสัญญาณหรืออุปกรณ์สื่อสาร ไม่ได้พิสูจน์ว่า Reefer หยุดทำงาน ส่วน Temperature reading คืออุณหภูมิอากาศจาก Sensor ไม่ใช่อุณหภูมิเนื้อทุเรียนโดยอัตโนมัติ การตัดสินใจต้องดู Timeline, Supply/Return air, Logger, ระยะเวลา, Ambient และ Product specification ร่วมกัน

  • บันทึกเวลา Power off/on และ Movement event ที่สัมพันธ์กัน
  • แยก No signal, No data, Power off, Alarm และ Confirmed malfunction เป็นคนละสถานะ
  • ตรวจ Datalog ย้อนหลังหลังอุปกรณ์กลับเข้าสัญญาณ ไม่ตัดสินจาก Dashboard ช่องว่างทันที
  • เทียบ Controller data กับ Independent logger และหลักฐานก่อน–หลัง Transshipment
  • ใช้เกณฑ์ Product/Contract ที่อนุมัติ ไม่ตั้ง Threshold เดียวครอบคลุมทุก Route
06

รับมือ Rollover, Port omission และ Connecting vessel เปลี่ยน

DCSA Port Call รองรับการเปลี่ยนเวลาและการยกเลิกหรือ Omission ขณะที่ Port omission หมายถึงเรือไม่เข้า Port ที่อยู่ในแผนเดิม เมื่อเกิด Route exception ให้เปิด Incident record ทันทีและประเมินเป็นหลายมิติ ไม่รอให้ ETA ปลายทางเลื่อนไปแล้วจึงแจ้ง Buyer

  • ยืนยัน Container location และสถานะ Load/Discharge จาก Carrier ก่อนประกาศผล
  • ขอ Revised transport plan พร้อม Connecting vessel, Terminal และเวลาใหม่
  • ประเมิน Product life, Temperature evidence, Power continuity และ Need for inspection
  • ตรวจผลต่อ Buyer slot, Import document, Certificate validity และ Customs/Transit
  • คำนวณค่าใช้จ่ายเพิ่ม, Free Time/D&D, Storage, Monitoring และ Insurance notice
  • เลือก Monitor, Escalate, Reroute, Inspect หรือ Claim preservation โดยผู้มีอำนาจ
07

ทำ Evidence pack ให้พร้อมก่อนเกิดข้อพิพาท

ข้อมูล Remote monitoring ช่วยให้เห็น Temperature, Humidity, Location, Milestone และ Off-power ตาม Package ที่ใช้ แต่สิทธิ์เข้าถึง ความถี่ และการเก็บข้อมูลต่างกัน เช่น Hapag-Lloyd ระบุว่าข้อมูลบางส่วนใน Web application เก็บย้อนหลังจำกัด จึงควร Download และเก็บหลักฐานในระบบขององค์กรตาม Retention policy ก่อนหมดช่วงเข้าถึง

  • Booking confirmation และ Transport plan ทุก Revision
  • Container/Seal, Setting, PTI, Loading release และ Product temperature ก่อนออกต้นทาง
  • Carrier/Terminal event พร้อม Event time, Received time และ Time zone
  • Raw datalog, Remote monitoring export และ Independent logger file
  • Email/API acknowledgement, Exception ticket และการตอบกลับของ Carrier
  • Buyer notice, Decision log, ค่าใช้จ่ายเพิ่ม และภาพสินค้าเมื่อเปิดตรวจ
  • Hash, Version, ผู้ดาวน์โหลด และ Chain of custody ของไฟล์สำคัญ
08

เชื่อม Transshipment กับกำไรและคำมั่นต่อลูกค้า

Codex CXC 44-1995 แนะนำให้เลือกบริการขนส่งโดยพิจารณาความเน่าเสียง่าย เวลาเดินทาง คุณภาพบริการ อุณหภูมิ และอายุสินค้าที่เหลือสำหรับการตลาด ดังนั้น Route ที่ Freight ต่ำกว่าอาจไม่ใช่ทางเลือกที่คุ้มที่สุด หากเพิ่ม Connection risk, Dwell, Monitoring cost หรือโอกาสพลาดนัด Buyer

  • เปรียบเทียบ Direct กับ Transshipment ด้วย Total landed risk-adjusted cost
  • ใส่ Expected dwell และ Scenario delay ลงใน Container P&L
  • แยก Cost owner ตาม Contract/Incoterms และ Transport document
  • กำหนด Buyer communication SLA เมื่อ ETA หรือ Route เปลี่ยน
  • บันทึกผลขายจริงและ Claim recovery เพื่อปรับ Route scorecard รอบต่อไป
09

KPI และ AI สำหรับ Transshipment Control Tower

AI ช่วยเชื่อม Booking, Vessel schedule, Track & Trace, Reefer telemetry และข้อความจาก Carrier เพื่อชี้ Event ที่หาย คำนวณ Connection risk และจัด Evidence timeline ได้ แต่ต้องแสดง Source, Timestamp, Confidence และเหตุผลของ Alert ให้คนตรวจ ไม่ควรให้ AI เปลี่ยน Route, Setting, Claim position หรือแจ้ง Buyer โดยไม่มีการอนุมัติ

  • Connection success rate และ Rollover/Port omission rate แยก Route/Carrier
  • Terminal dwell และ Connection buffer เหลือ ณ แต่ละ Revision
  • Off-power event count/duration และเวลาปิด Critical alarm
  • Milestone/Data completeness กับ Event-to-received latency
  • ETA revision-to-buyer notification time
  • Evidence pack completeness ก่อน Data retention หมดอายุ
  • Delay cost, Margin at risk และ Claim recovery ต่อ Container
  • AI alert precision, False positive และ Human override reason
FAQ · คำตอบพร้อมใช้

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

Transshipment ตู้ทุเรียนคืออะไร?

คือการถ่าย Container จากเรือลำหนึ่งไปยังอีกลำที่ Terminal ระหว่างทางเพื่อไปถึงปลายทาง ต่างจาก Direct service ช่วงนี้จึงมีทั้ง Discharge, Yard move, Plug-in, รอเรือต่อ และ Load ซึ่งต้องติดตามเป็น Event chain รายตู้

จะรู้ได้อย่างไรว่าตู้ทุเรียนต่อเรือสำเร็จแล้ว?

ให้ยืนยัน Actual load บน Connecting vessel และ Actual departure โดยเทียบ Carrier Track & Trace, Terminal/equipment report หรือแหล่งข้อมูลที่ตกลงกัน อย่าใช้ ETA หรือ Schedule เพียงอย่างเดียว และตรวจ Container/voyage ให้ตรงทุกครั้ง

ช่วง Off-power ตอนยกตู้แปลว่าสินค้าเสียหรือไม่?

ไม่สามารถสรุปเช่นนั้นได้จาก Off-power เพียงอย่างเดียว ต้องดูระยะเวลา Supply/Return air, Logger, Ambient, Product specification และข้อมูลหลังกลับจ่ายไฟ การ Load/Discharge หรือ Yard move อาจมี Off-power ตามกระบวนการ แต่ทุกเหตุการณ์ต้องบันทึกและประเมินตามความเสี่ยง

กราฟไม่มีข้อมูลหมายความว่าไฟดับหรือไม่?

ไม่เสมอไป Data gap อาจเกิดจากไม่มีสัญญาณหรืออุปกรณ์สื่อสาร เมื่อกลับเข้าสัญญาณข้อมูลย้อนหลังอาจถูกส่งขึ้นระบบ ให้แยกสถานะ No data, Power off, Alarm และ Malfunction แล้วตรวจ Datalog กับ Movement event ก่อนสรุป

ถ้า Connecting vessel เปลี่ยนควรทำอะไรเป็นอันดับแรก?

ยืนยัน Container location และ Revised transport plan จาก Carrier ก่อน จากนั้นคำนวณ Connection/dwell ใหม่ ตรวจ Power–Temperature evidence, ผลต่อ Product/Buyer/Document/Cost และออก Revision ที่ผู้รับผิดชอบทุกฝ่ายรับทราบ

AI ใช้คุม Transshipment ได้แค่ไหน?

AI ช่วยรวม Schedule, Event, Reefer data และข้อความ เพื่อแจ้งความไม่ตรง คาดความเสี่ยงและเรียง Evidence timeline ได้ แต่ต้องอ้าง Source และให้มนุษย์อนุมัติการเปลี่ยน Route, Setting, การแจ้ง Buyer และการสงวนสิทธิ์ Claim

อ่านต่อและนำไปใช้

จองตู้รีเฟอร์ทุเรียน: ล็อก 16 ช่องก่อนยืนยัน Booking↗ไฟดับตู้รีเฟอร์ทุเรียน: คุม Plug-in–Off-power ทุกจุด↗Temperature Logger ตู้ทุเรียน: วาง Sensor ให้หลักฐานใช้ได้จริง↗ตั้งค่าตู้รีเฟอร์ทุเรียน: คุม Setpoint–ลม–ความชื้น↗เคลมทุเรียนตู้รีเฟอร์: เก็บหลักฐานตั้งแต่โหลดถึงรับของ↗Free Time ตู้ทุเรียน: กัน D&D ก่อนกำไรหาย↗

แหล่งข้อมูลทางการ

ตรวจสอบข้อมูลล่าสุด ณ วันที่ 10 กันยายน 2569

  1. Shipping Glossary — Transport Plan and TransshipmentDigital Container Shipping Association (DCSA) · ตรวจสอบ 10 กันยายน 2569
  2. Track & Trace StandardDigital Container Shipping Association (DCSA) · ตรวจสอบ 10 กันยายน 2569
  3. Operational Vessel Schedules StandardDigital Container Shipping Association (DCSA) · ตรวจสอบ 10 กันยายน 2569
  4. Port Call Standard DocumentationDigital Container Shipping Association (DCSA) · ตรวจสอบ 10 กันยายน 2569
  5. Hapag-Lloyd LIVE — Reefer MonitoringHapag-Lloyd · ตรวจสอบ 10 กันยายน 2569
  6. Hapag-Lloyd LIVE — Operational and Data FAQHapag-Lloyd · ตรวจสอบ 10 กันยายน 2569
  7. MSC iReefer Monitoring SystemMSC · ตรวจสอบ 10 กันยายน 2569
  8. Captain Peter — Remote Container ManagementMaersk · ตรวจสอบ 10 กันยายน 2569
  9. CXC 44-1995 — Packaging and Transport of Fresh Fruit and VegetablesCodex Alimentarius (FAO/WHO) · ฉบับแก้ไข 2004 · ตรวจสอบ 10 กันยายน 2569
← ดูบทความทั้งหมดทดลองใช้ระบบ ↗