ERP 没有 API，如何集成？文件交换、数据库读取、RPA 还是替换系统

没有现代 API，并不代表旧 ERP 的所有流程都无法集成。应先核查厂商支持的文件导入导出、可购买的集成模块，以及经过批准的只读数据访问。中间件负责协调这些接口。只有实际部署环境和故障恢复可行时，才考虑界面自动化；如果必要的业务结果无法以可支持的方式安全实现，再评估系统替换。

关键不是能否成功搬运一次数据，而是企业能否区分已接受、已拒绝、重复以及结果仍然未知的业务操作，并在 ERP 升级或夜间任务失败后继续保持这种能力。

本文讨论没有 API 的旧 ERP 如何集成，不做连接器报价比较，也不是通用 ERP 选型指南。产品文档核查日期为 2026 年 9 月 29 日。文中产品仅用于说明具体接口边界，不表示这些产品本身没有 API，也不表示您的已安装版本具有相同功能。建议和场景属于我们的评估框架，并非实际 ERP 产品横评结果。

“ERP 没有 API”究竟意味着什么？

选择技术前，先记录产品、版本档次、准确版本号、托管方式及支持服务商。所谓“没有 API”，究竟是没有 REST 端点、没有访问许可、找不到文档、网络无法连接，还是缺少某个业务操作的接口？这些问题需要不同的可行性判断。

向厂商询问是否有受支持的 SDK、SOAP 服务、EDI 接口、定时报表、命令行导入器或有文档的暂存机制。购买一个模块可能比操控屏幕更合适。确认它覆盖的业务对象和持续使用权，不能把宣传材料或合作伙伴演示直接视为验证结果。

分开定义读取、写入以及过账或审批。读取库存用于仪表盘，不等于预留库存；创建订单草稿，不等于批准放行；导出发票明细，也不能证明付款已经分配。应明确可验收的最终业务状态，以及谁有权触发它。

对于已经提供 API 的系统，我们的 Odoo API 集成限制指南讨论另一类问题：如何围绕现有 API 的约束设计架构。本文的第一项交付物应是有证据支持的可用接口清单，而不是新建一个后端。

文件、数据库、中间件、RPA，还是替换系统？

应按操作选择访问方式，而不是为全公司强行选择一种技术。合理方案可能同时包含只读报表数据流、受支持的订单导入，以及由人工处理的异常队列。

这个决策比一般的定制软件与现成软件比较更具体。评估完全可以建议保留 ERP、购买已有模块，或继续保留一个人工步骤。

什么情况下，受支持的文件交换已经足够？

不要因为传输方式看起来较旧，就排除 CSV 或 XML。Microsoft 在 Business Central 数据交换框架中记录了字段映射、转换和验证机制。Microsoft：文件映射与验证这证明产品具有结构化文件处理能力，不代表每一种单据和部署都具备无人值守导入功能。

取得实际规范，以及成功和失败的示例文件。确认字符编码、日期和小数格式、币种、单位、前导零、空值、公司标识及主数据前置条件。核实多行单据是整体接受，还是可能留下部分状态。银行文件功能不自动等于销售订单接口。

明确交接协议：不可变的批次标识、逐对象来源编号、模式版本、记录数、完整性校验，以及明确的上传完成信号。消费端不能处理尚未完成的上传。WinSCP 对二进制 SFTP 传输记录了先使用临时文件名、完成后再重命名的机制。WinSCP：完整上传交接应测试所选服务器的行为，并让导入器忽略临时文件；不能假设任意 FTP 或共享目录都有相同语义。

还要区分“收到文件”和“接受业务对象”。NetSuite 文档指出，afterSubmit 报错时记录可能已经创建或更新，此时不应重跑整个导入。Oracle：NetSuite 导入结果因此，单凭一个“错误”标签无法决定是否重试。

可投入运营的文件流程应显示：每个来源对象对应哪个 ERP 单据，哪些未通过验证，哪些仍需调查。约定源文件和证据的保留周期，尽量减少敏感字段。将调度器、凭据、存储、监控和人工异常处理计入运营成本。在无人值守执行得到实际支持并经过测试之前，每天手动上传文件的员工仍是流程的一部分。

经批准的只读访问能解决什么，不能解决什么？

应先申请有文档的报表视图、受支持的查询服务或获批副本，而不是直接索取生产数据库的无限制凭据。例如，NetSuite 的 SuiteAnalytics Connect 明确是只读服务，不能更新 NetSuite 数据。Oracle：Connect 的只读边界受支持的查询访问面，与直接访问应用物理表不是同一回事。

不要把只读项目悄悄变成对 ERP 交易表的非文档化写入。SAP Business One SDK 的 Recordset 文档允许对用户表执行 DML，但警告系统表写入不受支持并存在数据损坏风险。SAP：Recordset 支持边界这是该 SAP 接口的具体规则，不是对所有 ERP 合同的笼统判断。厂商批准的暂存表或有文档的业务对象接口，应另行评估。

对于数据提取，请 ERP 负责人解释每个字段的业务含义。“数量”是实物库存、可用库存，还是已分配库存？金额是否含税？这一行属于哪个公司和哪种单据状态？连接键和源时间戳本身还不是完整的数据契约。

只读不等于对运行没有影响，也不自动保证一致性。Microsoft 警告，SQL Server 的 NOLOCK/READUNCOMMITTED 可能读到未提交数据，以及重复或遗漏的记录。Microsoft：SQL 读取一致性警告不能把这种提示当作解决集成负载的通用办法。应由 DBA 批准一致性策略、超时、查询计划及运行时段，并在有代表性的 ERP 活动下测试。

增量提取还要证明如何发现更新、删除和更正。SQL Server Change Tracking 要求核查仍保留的最低版本；过期的同步位置需要重新初始化。Microsoft：变更跟踪恢复开启 Change Tracking 或 CDC 是独立的管理与支持决策，不是获得读取权限后自动拥有的权利。按修改时间筛选，并不能证明删除或延迟更正都会被捕获。

定义初始快照、可恢复的同步位置，以及与权威 ERP 视图的定期核对。还要定义数据过期时下游用户能看到什么提示。报表副本不能在无人察觉的情况下变成库存预留或财务过账的权威数据源。

中间件能补充什么，不能凭空创造什么？

中间件可以负责映射、调度、队列、凭据、标识和异常分派。它可以对新门户提供 API，而内部使用文件或获批查询接口。此时门户 API 是您自己定义的集成契约，不是 ERP 内部突然增加了新的交易 API。

网络连通性也是独立问题。Microsoft 的本地数据网关使用出站连接，无需为此开放入站端口。Microsoft：网关连接模型这种部署方式不会授予数据库权限，也不会增加缺失的业务操作。应核查所选网关支持的数据源、运维负责人及升级责任。

为每个业务对象保留持久记录：来源系统和公司、来源标识、操作、载荷版本或哈希、ERP 标识、已观察状态以及下一项允许的动作。区分已接收、已验证、已提交、已确认、已拒绝和结果未知。不能仅因文件已上传或任务已入队，就显示“已同步”。

AWS 的幂等性指南区分请求身份与相同内容，并解释去重记录和业务修改为何需要原子处理。AWS：请求身份与安全重试我们将其应用于旧 ERP 时的结论是有限的：中间件日志本身无法保证 ERP 业务效果恰好发生一次。ERP 提交成功后、日志记录成功前，仍可能发生崩溃。

重试前，必须证明可通过受支持的方式按稳定参考编号查找结果，或使用其他可靠确认机制。在目标系统具有相应能力时，应测试并发提交下的唯一性。用相同标识提交不同内容，必须触发明确冲突或获批更新流程，而不能静默创建第二张订单。缺乏确定性时，应暂停调查，而不是把未知结果变成重复业务。

何时可以合理采用界面自动化？

把界面自动化视为某个具体流程的候选方案，而不是“ERP 没有 API”的默认答案。UiPath 记录了基于元素属性、而非仅依赖坐标的选择器；变化的布局或动态属性仍需要处理。UiPath：选择器行为应测试实际旧客户端，而不是现代演示应用。

部署形态会影响可行性。Power Automate 无人值守文档说明了会话限制，并提醒无人值守运行的显示分辨率可能与开发会话不同。Microsoft：无人值守会话限制开发者在旁观察时执行成功，不能证明夜间运营模式成立。

虚拟桌面需要单独核查。Microsoft 要求在受支持的远程自动化中使用 Power Automate 虚拟桌面代理，并列出了平台限制。Microsoft：虚拟桌面要求确认准确的 RDP 或 Citrix 配置、安装许可及版本兼容性；能看到远程屏幕，不表示能够使用与本地安装相同的控件能力。

我们建议的上线条件包括明确的输入验证、获批凭据、允许的会话模式、对当前公司和记录的核查，以及权威结果验证。业务影响需要时，保留人工审批。不要为了让机器人持续运行而关闭 MFA、终端防护或补丁更新。

测量代表性吞吐量时，应包括登录、等待、校验对话框和异常处理。测试人工并发使用、超时、凭据过期、标签变更、记录锁定和机器重启。明确失败运行的负责人，以及可接受的最大积压。

Computer-use 模型不会消除这些验收条件。模型生成的一次点击，仍需要权限、受限输入，以及对最终业务状态的证明。对于敏感过账或付款，看似成功的截图不足以支持自动重试或放行。有价值的方案可以是有人监督的单据准备，最终决定仍由员工作出。

故障处理：120 次提交不等于 120 笔业务完成

以下为假设场景，不是客户项目结果：一个批次包含 120 张来源订单。集成确认了 117 张 ERP 单据，得到两项明确的验证拒绝，另有一次提交的响应丢失。对账应为 120 = 117 已确认 + 2 已拒绝 + 1 结果未知，而不是“有三个失败需要重试”。

保留 117 项已确认的来源与 ERP 映射。更正两张被拒订单，并在确定没有业务单据提交成功后才重新发送。对于未知结果，通过获批接口按稳定参考编号查找并检查相关状态。不要盲目重放整个批次。如果没有可靠方法查明未知结果，无人值守提交就没有通过一项重要的可行性门槛。

记录数只是第一层核对。还要比较业务标识、公司、单据状态、明细数量、币种及相关总额。测试修订、取消和乱序到达。总额相同仍可能掩盖错误的单据分配，因此应保留逐对象证据，而不仅是仪表盘上的绿色数字。

恢复并不总是技术回滚。Microsoft 将补偿描述为与业务相关、且可能需要人工介入的处理过程。Microsoft：业务特定的补偿对于 ERP 集成，应与业务负责人约定受支持的取消、更正或冲销路径。不能为了撤销一个重复操作而删除交易表行，或恢复整个生产数据库。

明确谁调查未知结果、谁批准更正、如何暂停后续业务，以及何时升级处理。用失败案例演练运行手册。没有业务责任人的重试计数器，不构成恢复流程。

付费集成可行性评估应该回答什么？

先购买一个有依据的决策，再购买实施。以一个有代表性的流程及其成功标准为起点，优先验证影响最大的不确定性。提供脱敏样本、接口文档、部署细节、相关许可条款，以及有授权的 ERP 联系人。通过批准的流程授予访问，不要在邮件附件中发送密码。

诚实标注证据状态：厂商文档支持、已在被评估环境确认、仅在测试中演示、方案建议、受阻或未测试。原型只能证明在所述条件下实际观察到的内容，不能单独证明生产可靠性、升级兼容性或持续峰值吞吐量。

评估无法消除仍未解决的厂商依赖。缺少文档或访问可能使最终实施估算无法成立。有价值的付费结论可以指出这一阻碍及重新评估所需的具体证据，而不是基于假设承诺固定开发价格。

采购方应坚持测试哪些失败场景？

以下可作为建议验收包。演示前约定通过标准和负责人，并保存每项相关测试的证据。“不适用”需要理由；“未测试”不能视为通过。

三个假设场景，三种不同的合理结论

需要次日早晨完成同步的分销商

假设已安装 ERP 支持订单导入、定时库存导出和逐对象结果，业务接受夜间延迟。应从这些文件能力出发，只增加验证、安全传输和异常处理所需的协调逻辑。REST 看起来更现代，并不足以证明全面替换或 UI 机器人合理。先验证重复提交和部分接受的行为。

需要报表，而不是交易录入的制造商

假设获批报表视图覆盖所需实体，DBA 也接受提取负载。可以采用带有明确时效标识和对账的只读提取，库存预留及过账仍留在 ERP。之后若要求即时库存承诺，这是范围变化，需要受支持的写入路径，不是报表数据流的小幅增强。

低业务量、只能通过屏幕操作的流程

假设厂商允许该访问方式，实际界面可自动化，且最终单据必须由员工批准。有人监督的准备流程可能已足够。如果改为要求无人值守、不可逆的过账，却没有可靠结果查询或受支持会话模型，就不能按原设计继续。应评估厂商模块、受控的人工边界或系统替换。

这些是虚构的决策场景，不是项目估算。它们不说明哪种方案普遍最便宜，也不承诺交付时间或投资回报。应以真实现状为基线，为通过验收的流程及其持续责任定价，包括业务异常处理工作。

何时应该替换、推迟或作出不实施结论？

如果设计依赖未经批准的访问、不受支持的交易写入、绕过安全控制，或重复执行无法查明结果的不可逆操作，应停止该设计。若要求的数据新鲜度超过来源可观察的更新能力，或无人接受运营责任，也应停止。

停止一个设计，不等于替换整个 ERP。可以缩小到只读报表、保留有人监督的导入、购买获批模块，或等支持条件改善后再推进。需要区分“不方便的限制”和“无法满足关键业务需求”。

Microsoft 的 Strangler Fig 指南介绍渐进式迁移，同时指出无法拦截请求或无法修改旧系统源码时可能不适用。Microsoft：渐进式迁移限制不能假设给封闭的桌面 ERP 套上透明 API 外观，就能让旧系统逐步消失。

应证明业务边界可以拆分，确定新旧并行期间哪个系统拥有权威数据，并规划历史数据访问、对账、切换和支持。分阶段迁移是一种候选架构，不是“零中断”承诺。在真正移除依赖之前，新旧两套运营成本可能同时存在。

明确付费集成可行性评估的范围

准备一个流程、ERP 及版本、脱敏样本、已有接口文档、时效要求和典型异常。评估范围应明确包含访问批准、故障处理、可支持性，以及是否继续的建议。评估费用和交付物应与后续实施分别约定。

Wavect 的定制软件开发服务是讨论明确范围集成项目的商业入口。MyMerch 流程自动化案例提供相关交付背景，但不能证明该项目实施过无 API ERP 集成，也不证明与您的系统兼容。

在委托完整解决方案前，申请付费 ERP 集成可行性评估。后续提案应服从证据：配置、轻量适配器、有人监督的自动化，或不实施。