产品的重量记录在物料管理模块中。再生料比例记录在配方系统中。供应商的证书以PDF格式存储在网络驱动器上。产品护照需要将这三项信息整合到一个数据记录中，而这正是集成项目的核心所在，而非两个系统之间的连接。
“无缝的ERP集成”是一个标准承诺，但在实践中往往随之而来的是一个为期三个月的项目。我们发布这份指南，是为了让您的IT部门在签署合同前，能够核查实际需要获取哪些数据。 本文将说明产品护照需要从您的系统中获取哪些数据、数据通过哪三种途径传输给我们，以及为何两周内即可完成。
您的ERP系统实际上必须提供什么
为了生成产品护照，我们需要针对每种产品获取以下信息：
-主数据 - - 产品编号、名称、变体、重量、尺寸、图片 -物料清单数据 - - 包含数量和再生材料比例的组件 -来源数据 - - **生产地、批号、生产日期 -环境数据 - - 单位二氧化碳当量、用水量、能耗 -供应商数据 - - **哪家供应商提供哪些组件 （用于履行尽职调查义务）
理论上，您的 ERP 系统中应包含所有这些数据。但实际上，这些数据分散在 4 到 7 个模块中：物料管理、生产、质量、供应商主数据，有时还有一个单独的环境数据模块，有时配方和物料清单则由独立系统管理。
集成问题不在于： “您的 ERP 是否向 DPP 提供数据？”，而在于：“如何将来自 5 个子系统的数据整合成一个连贯的数据集？”
三种行之有效的方法
方法 1：从 ERP 中提取数据
该方法适用于现代ERP系统（SAP S/4HANA Cloud、Dynamics 365、Odoo）。DPP供应商通过ERP接口（技术上采用OData或REST）提取数据。仅提取变更数据，这些数据可能是按计划更新的，也可能是由特定事件触发的。
优点：您无需进行大量开发，只需提供读取权限，由供应商负责数据转换。
缺点：若没有额外的接口层，则无法与较旧的 SAP ECC 系统兼容。您需要制定明确的规则，规定谁可以读取哪些数据。
方案 2：转发变更
您的 ERP 系统将每次变更作为事件进行报告（通过 SAP Event Mesh、Apache Kafka 或 RabbitMQ），DPP 服务商接收这些事件。
优点：近乎实时，可随业务扩展，系统之间互不依赖。
缺点：配置要求较高，且需要基础设施支持，而并非每个 IT 部门都具备这些条件。对于小型企业而言，通常过于复杂。
方案 3：利用现有的集成层
您已经在 ERP 与外部系统之间部署了集成层（如 Mulesoft、Boomi、Informatica、Azure Data Factory）。该层即为“契约”：DPP 供应商通过该层进行通信，绝不直接与 ERP 交互。
优点：可利用现有投资，规则保持稳定，第三方无法直接访问 ERP。
缺点：集成层的成本会随之增加。
我们在具体项目中的独特做法
许多供应商希望直接连接到您的 ERP。 而我们原则上会增加 一个中间步骤：我们的接口接受中立的数据格式（一种 JSON 模式），您可以使用自选工具对其进行填充。这意味着：
- 您可以使用团队熟悉的工具自行处理数据
- 您可以更换服务商 - - 该中立格式具有可移植性
- 您可以随时导出全部数据 - - 支持 CSV、XLSX、JSON-LD 和 SQL 格式，也可通过 REST-API 获取
- 我们提供导入验证工具，可在上传前对您的数据进行检查
完整的格式和所有查询已在API 文档 上公开描述，作为符合 OpenAPI 标准的接口说明。您的 IT 部门可以在签署合同之前检查该接口 - - 包括示例请求、错误响应和身份验证详细信息。
采用此方法的实际时间安排：
-第 1 至 2 天：映射研讨会。ERP 中的哪个字段对应 DPP 中的哪个字段？ -第 3 至 5 天：从 ERP 系统导出首批 JSON 数据，并通过我们的验证器进行验证。 -第 6 至 8 天：故障排除（字段缺失、编码不一致）。 -第 9 至 10 天：首批 DPP 上线。
只需两周，而非三个月。关键在于映射研讨会 - - 数据质量在此阶段就已定调。
可能出错的情况：最常见的陷阱
产品主数据分散在多个系统中：SAP 存储产品编号，PIM 存储图片和营销文案，PLM 存储物料清单。 没有人能获得一致的信息。解决方案：在项目开始前，明确定义哪个系统是哪个字段的主数据源。
PDF格式的证书：供应商将GOTS、OEKO-TEX或REACH证书以PDF扫描件形式提供。这并非结构化数据源。 解决方案：认证机构越来越多地提供通过接口查询的服务（OEKO-TEX 走在前列，GOTS 则稍显滞后）。或者：手动录入，但需注明有效期，以确保 DPP 中不会出现过期的证书。
配方保密：特别是在化妆品、食品和制药行业，完整的配方属于商业秘密。 难道要让DPP将其公开吗？解决方案：ESPR的三层模型。产品类别对公众公开，而监管机构可查看完整的配方。这几乎不会成为障碍，但必须尽早明确。
基于供应商的二氧化碳数据：您的供应商提供其整个产品组合的平均值，而非按批次提供。解决方案：暂时接受，长期调整供应商合同。ESPR要求从某个基准日起提供具体产品的数据，但目前的做法是一种折中方案。
本地语言版本：您的ERP系统仅包含德语和英语的产品名称。对于27个欧盟国家，您需要更多语言版本。解决方案：结合术语数据库进行机器翻译，我们对此有专门的文章介绍。
项目启动前您应考虑的问题
在向三家供应商发送 RFP 之前，请先在内部回答以下问题：
- 多少个产品/货号应包含 DPP？（10 个、10,000 个、100 万个？）
- 目前哪些系统存储着与 DPP 相关的数据？
- 每个系统分别由哪个部门管理？
- 是否有应使用的集成层？
- 是否已有通过您的ERP运行的接口？
这些答案将决定三种方案中哪一种最适合您。
这些答案将决定项目是持续两周还是六个月。
关于这篇帖子的提问
仅靠 REST 接口就够了吗，还是需要中间件？
接口就足够了。这三种模式的区别在于转换发生的位置，而非我们接收的内容 - - 我们的接口接受中立的 JSON 模式，无论您使用何种工具生成它。 无论是从现代ERP系统拉取数据、事件流，还是现有的集成层，最终都会汇聚到同一个端点。如果您原本就运行着中间件，且希望将其作为与第三方签订的合同的一部分，那么使用中间件是值得的。如果目前没有，那么为了产品护照，请不要专门为此购买。
在映射研讨会上将做出哪些决定？
哪个ERP字段对应哪个主字段 - - 以及当多个系统保存相同值时，哪个系统是主导数据源。该研讨会安排在第1天和第2天，是整个项目的关键所在，因为数据质量的决定将在此时做出，而非在后续的代码开发阶段。 请务必让负责系统维护的人员参与进来，而不仅仅是项目负责人 - - 主数据、生产、质量和采购部门很少集中在一个部门。此后的一切工作，即数据导出、验证和故障排除，都属于技术性操作。
我们的证书只有PDF扫描件。我们该怎么处理？
扫描件并非结构化数据源，因此无法用于护照。有两种可行方法：认证运营商越来越多地提供API查询服务；若无此类服务，则需手动录入数据，但务必注明有效期，以确保已过期的证书不会保留在已发布的护照中。 请将手动操作视为一项周期性工作，而非一次性任务。
在我们签字之前，我们的IT部门能否先检查一下这个接口？
是的。完整的架构和所有接口均以 OpenAPI 规范的形式发布在API 文档 上，其中包含示例请求、错误响应以及身份验证详情。 这些内容均无需通过销售洽谈即可获取，因此您的集成团队可以在签订合同之前就评估所需的工作量。如果供应商在此阶段不公开其接口，这也是一种答复。
如果我们更换服务提供商，我们的数据会怎样？
它们都会被导入。该接口接受中立的JSON模式而非专有格式，您的全部数据将以CSV、XLSX、JSON-LD和SQL格式输出，或通过REST API导出。 这是刻意为之的设计 - - 您用于导入的格式具有可移植性，因此切换格式只需进行一次导出，无需重新构建数据。在映射研讨会开始前，请向每位服务商提出相同的问题，因为研讨会结束后，您的字段名称将纳入对方的模型中。
实际连接需要多长时间？
在我们参与的项目中，整个流程为两周 - - 两天用于数据映射，三天完成验证器生成的首批导出数据，三天用于故障排除，两天发布首批数字护照。 真正的难点从来不在于代码，而在于验证器发现的问题 - - 缺失的字段、不统一的编码，以及无人负责的数值。请预留好这些时间，而不是压缩它们。如果某个项目跳过了这些环节，那么发布时这些漏洞也会一并公之于众。
我们必须一次性将所有产品接入系统吗？
不。请从那些首先需要“通行证”的产品开始，并选用一个源系统 - - 中立的模式既支持部分产品目录，也支持完整的产品目录，且导入操作可重复执行，因此后续运行会更新库存。 这样也能将映射研讨会控制在较小的规模，确保两天内完成。此后的扩展属于映射任务，而非新项目。
