/ 货代整合 / 系统迁移 / 异常升级
货代并购整合期间怎样更新业务升级联系人
货代完成并购后，客户可能陆续收到品牌、邮箱、系统账号或账单主体变更通知。企业若一次性替换全部资料，正在运输的货物可能失去原操作入口；继续沿用旧联系人，也可能错过新系统和新责任人。任何通知没有写清适用国家、运输模式、客户号和生效日期时，先暂停改账号、改付款资料或关闭旧入口。
并购完成日不等于所有业务完成迁移
DSV 在 2025 年 4 月 30 日宣布完成对 Schenker 的收购，公告说明合并后的业务覆盖空运、海运、合同物流和陆运。交易完成属于公司层面的事实，不能据此推断每个国家分支、客户合同、订舱系统或未结运单在同一天切换。
DSV 2025 年年度报告称，Schenker 整合在 2025 年底约完成三成，2026 年仍需管理系统复杂度与整合风险。这类集团进度只提供背景。企业要向本地客户经理确认自己的迁移批次，不能用集团百分比判断某个账号已经生效。
从正在执行的订单建立现状表
选取未提货、运输中、待清关、待开票和索赔中的货物，记录订单号、旧客户号、订舱号、运输单号、路线、合同主体、开票主体、付款账户、使用系统和操作邮箱。每一行写清信息来源及核对日期。
DSV 当前支持页仍分别提供 DSV 与 Schenker 货件跟踪，并让过渡期用户按原有账号选择两套 myDSV 登录入口。官方数字解决方案页面也提示，原 Schenker 客户在收到迁移通知前仍可使用原系统。并行入口说明企业必须按具体货件选择系统，不能只看网站已经合并到哪个域名。
按业务环节拆开联系人
客户经理负责合同和商业方案，订舱团队负责接受运输请求，操作团队处理提货、航班或船期及交付，报关团队管理授权与申报，账单团队处理发票，索赔团队管理时限和证据。一个销售联系人很难覆盖全部环节。
联系人表为每个环节保留姓名、部门、办公地、企业邮箱、电话、工作时区、替补人和升级人。再标明适用运输模式与客户号。联系人的邮箱域名发生变化时，通过已知电话、官方分支机构页面或原客户经理复核，不直接信任邮件里的新地址。
合同、开票和收款账户分别核对
品牌统一后，合同相对方、承运责任、当地税务主体和发票抬头仍可能按分支逐步变化。法务或采购保存原合同、补充协议、正式迁移通知和生效日期。旧合同未转让或变更时，不因页面换了品牌就自行修改采购订单主体。
财务把新发票与客户号、运输单号、报价和当地注册信息对齐。收款银行、账户名或币种变化时，使用企业已有联系方式进行独立回拨，并保留复核人和时间。邮件同时要求改主体、改账户并催促紧急付款，属于暂停付款的信号。
给旧系统和新系统设一段并行期
系统负责人记录旧登录入口、新入口、用户权限、双重验证方式、历史文件导出范围和停用日期。先用一票低风险货件测试报价、订舱、标签、跟踪、文件下载、异常通知与发票，再决定是否扩大迁移。
使用 EDI 或 API 的企业还要冻结字段映射，包括客户号、地点代码、运输模式、状态事件、时区、费用代码和附件类型。新平台能显示货件，不代表状态含义与旧平台相同。测试报告应同时保留输入、返回结果和人工核对结论。
给未结货件保留旧编号与新编号的对应关系
货代如果为迁移货件生成新编号，物流负责人应保存旧订舱号、旧运输号、新编号、转换日期和货代确认。供应商、仓库、报关代理和客户通知都引用同一张映射表，避免一方查旧号、另一方只认新号。
货件进入异常处理后，工单必须带上两个编号以及最近一个已确认节点。团队向新联系人转交历史邮件、运单、费用批准和现有问题，不要求对方从零猜测背景。旧联系人是否退出处理，也要在邮件中得到明确答复。
异常升级表要写触发条件
升级表不能只有一串电话号码。每个问题都需定义第一级负责人、等待时间和下一层接收人。例如未按约提货由当地操作处理，错过航班或甩柜转至产品平台主管，海关资料卡住交给报关负责人，账单差异由应付账款团队受理。
企业根据货值、交付窗口和客户影响设内部阈值。货物失联、冷链偏差、危险品拒收、账户安全异常或法定索赔期限临近时，可以越过日常排队路径。升级邮件写明货件身份、已发生事实、所需决定、最晚回复时间和联系人。
索赔与账单不能跟着操作联系人一起丢失
运输完成后仍可能存在货损、短少、延误费用或错误账单。合同管理员保存适用条款、通知时限、索赔入口和证据要求。并购通知若未说明旧货件由哪个实体受理，就让货代书面确认，不把一般客服回复当作索赔已登记。
财务对未开票货件建立清单，记录报价主体、预计开票主体、采购订单号、预提金额和争议状态。新旧系统出现两张发票时，先按运输号、费用期间和税务主体排查重复，确认前不做合并付款。
把迁移纳入业务连续性安排
ISO 22301 提供建立和维护业务连续性计划、系统与流程的管理框架。企业可以据此识别关键运输活动、最长可接受中断时间、替代联系人、备用订舱方式和恢复后的资料核对。该标准不会决定某家货代的具体合同或赔偿责任。
迁移期间至少保留一条经批准的备用联络路径和必要的货件资料副本。关键订单还可预先核对替代货代，但切换前要明确取消原订舱、数据授权、报关衔接和新增费用，避免同一票货出现两套互相竞争的指令。
让客户和内部页面引用当前责任数据
客户服务页面、交付通知和内部通讯录经常保留旧客服电话或旧追踪入口。物流负责人确认迁移范围后，内容负责人再更新页面，并在内部保留旧入口适用的货件截止日期。公开页面不展示个人手机号，也不发布尚未确认的系统切换时间。
凯乐丰的数字化业务流程可帮助制造企业把订单、货件编号、联系人版本和异常工单放在同一记录中。系统负责提醒和留痕，合同主体、付款账户及货代责任仍由采购、财务和物流人员核实。
出现这些情况时暂停迁移或付款
- 通知没有列明适用国家、运输模式、客户号或生效日期。
- 正在运输的货件在新旧系统中都查不到，或状态互相冲突。
- 合同主体、发票抬头和收款账户同时变化，尚未独立回拨核验。
- 旧订舱号与新运输号没有形成可追溯的对应关系。
- 报关授权、数据权限或历史文件迁移范围不清楚。
- 异常联系人只给出口头承诺，没有企业邮箱或工单确认。
- 索赔、账单争议或未结货件无人书面接手。
采购负责人批准合同和供应商主数据，物流负责人维护系统与操作升级表，财务核验发票及账户，报关负责人确认授权，信息技术人员测试接口和权限。各项都有证据后，再关闭旧账号或替换正式资料。
工作清单
- 按未结货件冻结合同、客户号、订舱号和使用系统。
- 分别确认销售、订舱、操作、报关、账单及索赔联系人。
- 通过独立渠道复核主体、邮箱域名和收款账户变化。
- 建立新旧货件编号、状态事件和文件版本的映射。
- 用低风险货件测试新平台、权限及 EDI/API 数据。
- 为延误、失联、货损、清关和账单问题设置升级阈值。
- 书面确认旧账号停用和未结业务移交日期。
本文参考的一手资料
- DSV：完成收购 Schenker 的公告用于核对交易完成日期和合并业务范围，不用于推断单个客户迁移状态。
- DSV 支持页面用于核对过渡期并列的 DSV 与 Schenker 跟踪和登录入口。
- DSV 数字解决方案与 Schenker 自助服务用于说明原 Schenker 客户在收到迁移通知前的系统使用边界。
- DSV 2025 年年度报告用于核对截至 2025 年末的整合进度以及2026年的系统复杂度和整合风险说明。
- ISO：ISO 22301 业务连续性用于支持关键活动、替代路径、响应与恢复的管理框架。
适用边界：本文根据截至 2026 年 8 月 24 日可见的 DSV 官方资料整理内部迁移核对方法，不构成对 DSV 或 Schenker 具体客户、地区和货件状态的确认，也不构成合同、索赔、税务或法律意见。实际主体、系统及联系人以当地正式通知和书面确认为准。