DHL 的分散結構推動了大部分的複雜性——您需要為每個區域實體（如 DHL Express AB 或 DHL Freight GmbH）分別取得 API 認證和測試，他們的 XML 基礎 API 因地區而異，具有不同的服務名稱（在一個市場中的 Economy Select 在另一個市場中變成 EUROCONNECT）。Cargoson 或 ShipTheory 等中介軟體簡化了多實體的困擾，並處理 DHL 特定功能，如電子運單生成和 CMR 文件，但增加了按您的需求規模化的月度授權費用。真正的範圍擴張發生在您超越基本標籤列印，轉向 CO2 排放量追蹤（跨實體）、多個倉庫的實時 ETD 計算或結帳時的 PUDO 位置選擇等功能時——每一項都需要在 NetSuite 中進行自訂欄位對應，因為 DHL 的資料結構與標準運輸欄位不能整齊對齐。

是的。HS codes、申報價值、原產地及產品描述均從 NetSuite 商品記錄中提取，透過 DHL 的 API 生成商業發票與海關申報單。您只需在單一位置維護數據，該數據即可自動流轉至所有需要它的貨運。

通常需要 4 到 6 週。第一週用於範疇界定：您使用哪些 DHL 服務（Express、eCommerce、Freight）、資料需要流向何處，以及您的倉庫目前如何處理出貨。建置和測試需要 3 到 5 週，包括一個平行期間，在此期間自動化出貨會根據您現有的流程進行驗證。

該整合可與其他承運商連接並行運作。NetSuite 的履行工作流程可以根據您定義的規則路由至 DHL、FedEx 或本地承運商 - 包括目的地國家、包裹重量、服務等級或成本。DHL 不需要是您唯一的承運商也能運作。

DHL Express、DHL eCommerce 及 DHL Freight。各項服務採用不同的 API，並回傳不同的資料。大多數電商企業會先採用 Express 服務來處理時效性要求高的國際訂單，並使用 eCommerce 服務進行標準配送。我們會在探索階段釐清您所需的服務。

每筆出貨的成本會過帳至原始銷售訂單或項目履行。當 DHL 的月度發票送達時，您可以根據 NetSuite 已按出貨記錄的內容進行對帳。無需再將單一大額日記帳分錄過帳至運費帳戶。