二次开发

值得开发的三类需求：

• 系统接口：与 PLM/ERP 交换物料、BOM、项目数据，人工搬运频繁且易错
• 批量处理：几十上百个项目要统一改图框、改属性、导数据，手工做不现实
• 特制输出：报表格式特殊，软件自带配置改不出来，且格式长期稳定

不建议开发的三类需求：

• 一次性任务：只做一次的数据整理，写脚本的成本高于人工
• 本可以用配置解决：编号规则、图框字段、报表列，多数能在项目设置与模板里完成，开发反而增加维护负担
• 流程尚未定型：流程还在变，先把代码写死，后面每次调整都要改程序

一个实用判断：把需求写成一句话，问“这个动作一年会发生多少次”。几十次以内，人工或半自动更划算；上千次且规则稳定，才值得开发。还有一条常被忽略：开发交付的不只是程序，还有接口文档、字段映射表、异常处理约定和升级预案。没有这些，程序半年后就是黑盒。

BOM 打不通，八成不是接口技术问题，而是三处口径不一致：

• 物料编码：设计库里的部件号与 ERP 物料号不是同一套，或同一物料两个号
• 层级定义：图纸上的 BOM 是“功能结构”，ERP 要的是“装配结构”，层级关系对不上
• 变更时点：设计变更后，什么时候同步、同步哪些字段、历史版本怎么处理，没有约定

落地顺序建议：1. 先做物料主数据治理：确定唯一编码源，是 ERP 主还是设计库主，二选一，不允许双写2. 再定字段映射表：设计侧字段、ERP 字段、是否必填、转换规则、异常值处理，逐列写清3. 然后定同步策略：全量还是增量、单向还是双向、失败重试与人工兜底4. 最后才是写接口与联调接口形态通常是中间表、API 或文件交换，选哪种取决于两边系统的能力与 IT 约束，不取决于偏好。验收要盯一件事：同一项目，从设计端导出的 BOM 与 ERP 接收后的 BOM，逐行逐列比对，差异为零。做不到这一步，接口只是“能跑”，不是“能用”。

评估一个二次开发项目，看四个变量：

• 接口数量与方向：几个系统、单向还是双向、实时还是批量
• 字段复杂度：映射字段多少、是否有取值转换、是否存在一对多
• 异常分支：数据缺失、重复、超长、编码冲突时怎么处理，这部分常被低估，实际能占一半工作量
• 环境约束：能否拿到测试环境、是否有权限限制、联调窗口是否可控

合理的推进方式是“先单点、后扩展”：选一条最有价值的链路（例如某类项目的 BOM 导出到 ERP），做成闭环并验收，再复制到其他链路。一上来做“全系统集成”，需求会在过程中不断膨胀。关于费用，我们不在网页上给数字，原因不是回避，而是区间没有意义：同样是“EPLAN 对接 ERP”，字段 10 个和 80 个、单向和双向、有无测试环境，工作量差数倍。正确做法是先出一页需求边界说明（做什么、不做什么、验收标准），再据此评估。合同里建议明确三件事：需求变更怎么计价、源码与文档是否交付、软件升级后接口适配是否包含。

会影响，但风险可控，关键在于开发时依赖了什么：

• 依赖官方公开 API：升级后通常只需适配少量签名变化，风险最低
• 依赖内部数据结构或未公开接口：版本一变就可能失效，风险最高
• 依赖文件格式直读直写：格式微调就会出错，需要版本兼容层

降低升级风险的四条做法：

• 只用厂商公开的 API 与扩展点，不碰内部实现
• 把版本判断写进程序，不同版本走不同分支，而不是假设只有一个版本
• 接口层与业务层分离，升级时只改接口层
• 交付时附一份“升级适配说明”：依赖了哪些 API、哪些地方需要回归测试

还有一件常被忽略的事：升级前要留回滚方案。测试环境先升，跑一遍关键链路（打开项目、导出 BOM、生成报表、打印），再动生产环境。如果插件是几年前由其他方开发的、没有源码也没有文档，升级前先做一次“可维护性评估”，比升级后救火便宜。