从你的 ERP 到一份已签名的 eCoC：CoCDesk 如何与第一阶段和第二阶段整车制造商集成

eCoC 数据本就存在，难点在于交接。

当一辆车驶下你的生产线时，eCoC 所需的每一个字段其实都已经在你的系统某处生成并完成审批：

• 型式批准号以及变型/版本代码保存在你的认证主数据中。
• VIN、选装配置、质量、轴荷、尺寸来自生产订单或配置器。
• 发动机、变速箱、排放等级、燃料类型与变型相关联。
• 生产一致性（CoP）记录由你的质量系统写入。

问题不在于数据不存在，而在于这些数据如今分散在ERP、MES 和认证数据库中——要靠人工把它们抽取出来填进 IVI XML 模板，再人工校验、人工签名、人工上传到国家接入点。这种方式应付几辆车还行，但应付一年几百上千辆就行不通了。

CoCDesk 如何接入

CoCDesk 的设计初衷就是消费你已有的数据。根据你 IT 架构的成熟度，我们采用三种集成模式：

CoCDesk 支持的 ERP 和 MES 系统

我们已经交付或评估过的集成，针对的正是欧盟各改装厂、第一/第二阶段制造商实际运行的系统：

如果某个系统不在列表上，集成模式也是一样的——我们会针对你的数据契约构建一个映射器。复杂之处在于你的业务规则，而不是连接器本身。

端到端的数据流

上方的示意图描绘了完整路径。从生产系统出发，CoCDesk 运行针对每位客户的映射器，生成经过模式校验的 IVI 2.0 XML，使用来自欧盟可信清单上合格信任服务提供商（QTSP）的 XAdES 签名，再提交到目的地国家接入点（NAP）——当目的地成员国接受通过外国 NAP 提交时，则采用 EUCARIS 检索。

回执以及任何被拒原因都会回写到你 ERP 或 MES 中的原始记录上——这样生产系统就会在车辆旁边直接显示 eCoC 状态，而不是另存在一张单独的电子表格里。

第一阶段 vs 第二阶段：多阶段交接

集成形态会因你是制造基础车还是完成整车而有所不同。

一个集成项目是什么样的

以一家运行 Sage X3 或 proAlpha 的典型改装厂为例：

• 第 1 周——数据映射工作坊。我们与你的认证负责人和 ERP 管理员一起，把 IVI 2.0 模式与你的字段逐一对照。产出：一页纸的数据契约。
• 第 2–4 周——构建连接器并指向你的测试环境。我们用样本车辆生成测试 eCoC，并提交到 NAP 测试端点。
• 第 5–6 周——并行运行。CoCDesk 与你现有流程并行生成 eCoC；输出逐字段进行比对。
• 第 7 周及以后——生产切换。手工生成 eCoC 的方式正式退役。

对于运行 SAP S/4HANA 的第一阶段制造商，调研和安全审查会耗时更久，但由于源数据更干净，技术构建反而更快。

集成何时能收回成本

实践中，手工生成 eCoC 的现实上限是每年不到 50 份 eCoC。IVI 2.0 XML 本就不是为人眼设计的格式——它密集、嵌套很深，充满了看似可以互换、实则不能互换的代码列表值。在任何有意义的体量上手工录入都难免出错，而每一个错误都意味着一次 NAP 拒收外加一轮重新签名。超过那个阈值后，ERP/MES 集成就不再只是成本优化——它是唯一站得住脚的工作流。

团队往往还低估了另一点：集成不仅仅是为了更快地生成 eCoC。由于同一个真实数据源同时供给生产和认证，你还消除了一整类生产记录与提交给主管机关的文件之间的不一致——而这恰恰是生产一致性审核最容易紧张的地方。