DHL 的分散结构是导致大多数复杂性的原因——您需要为每个地区实体（如 DHL Express AB 或 DHL Freight GmbH）单独申请 API 凭证和进行测试，其基于 XML 的 API 因地区而异，服务名称也各不相同（一个市场中的 Economy Select 在另一个市场变成 EUROCONNECT）。Cargoson 或 ShipTheory 等中间件简化了多实体的复杂性，并处理 DHL 特定功能，如电子运单生成和 CMR 单据，但会增加随您需求扩展的月度许可费用。真正的范围蔓延发生在您超越基础标签打印功能时——例如跨实体的二氧化碳排放追踪、多个仓库的实时 ETD 计算或结账时的 PUDO 地点选择——这些都需要在 NetSuite 中进行自定义字段映射，因为 DHL 的数据结构与标准运输字段并不完全一致。

该集成可与其他快递商连接一起使用。NetSuite的履行工作流可以根据您定义的规则将订单路由到DHL、FedEx或本地快递商——包括目的地国家、包裹重量、服务级别或成本。DHL无需是您唯一的快递商，此集成就能发挥作用。

DHL Express、DHL eCommerce 和 DHL Freight。它们各自使用不同的 API，并返回不同的数据。大多数电商公司通常先使用 Express 处理时效性要求高的国际订单，并使用 eCommerce 进行标准配送。我们在需求调研阶段明确您需要哪些服务。

可以。HS代码、申报价值、原产国和产品描述从NetSuite物料记录中提取，通过DHL的API生成商业发票和海关申报单。您在一个地方维护数据，它会流向每一个需要的货运。

通常需要 4 到 6 周。第一周是范围确定:您使用哪些 DHL 服务(Express、eCommerce、Freight)、数据需要流向何处,以及您的仓库目前如何处理货运。构建和测试需要 3 到 5 周,包括一个平行期,在此期间自动化货运会根据您现有的流程进行验证。

每笔货运的成本都会记入原始销售订单或商品履行。当 DHL 的月度发票到达时,您可以根据 NetSuite 已按货运记录的内容进行对账。不再需要向运费账户过账单一汇总日记账分录。