基于 MCP + SAP JCo 打造 AI 可调用的 ERP 工具链：从采购到会计凭证的端到端实战摘要：本文介绍一个纯 Java 实现的SAP JCo MCP 连接器——它把 SAP S/4HANA 的 RFC/BAPI 封装成 17 个标准 MCP 工具，让 AI 助手（如 WorkBuddy）像调用函数一样直接操作 ERP。文章重点讲解三个工程级优化（交货单"先拣配后过账"、批次自动带码、QM 使用决策封装），并用一条采购订单 → 采购收货 → 销售订单 → 交货单 → 发货过账 → 会计凭证的真实业务流做图文实战，全部单据号均来自 S/4HANA 测试系统实跑结果。目录为什么需要 SAP MCP 工具整体架构工具清单（17 个）三个关键工程优化（区别于"裸 BAPI 封装"）图文实战：端到端业务案例踩坑实录（干货）如何运行小结一、为什么需要 SAP MCP 工具做过 SAP 集成的同学都知道，让"外部程序"驱动 ERP 通常只有两条路：人工搬运：在 GUI 里点完，把单据号抄给 AI；或者让 AI 生成 ABAP/脚本，再人工执行。一次性接口：为每个场景写个 RFC/BAPI 调用程序，换个需求就重写。这两种方式都没法让 AI 自主、复用地操作 SAP。而MCP（Model Context Protocol）正好补上这块拼图：它把"能力"标准化成工具（tool），AI 通过 JSON-RPC 调用，参数、返回值都是结构化数据，天然适合 ERP 这种强结构化的系统。本文的连接器就是这么一个MCP stdio 服务器：AI 在左边说"帮我建个采购订单"，连接器在右边调BAPI_PO_CREATE1，把返回的订单号结构化回传。注：本文所有实跑结果均来自一台 S/4HANA 测试系统（SID=S4Q，客户端 800），公司代码 2010。二、整体架构整个链路零业务依赖，只引入 SAP 官方sapjco3.jar：层技术说明AI 客户端WorkBuddy / 任意 MCP 主机通过 stdio 收发 JSON-RPC 2.0MCP 服务器纯 Java（JDK 8+）解析tools/list、tools/call，路由到桥接层桥接层SapJcoBridgeSAP JCo 3.0注册DestinationDataProvider，封装 RFC/BAPI 调用、事务提交SAP 后端S/4HANARFC_READ_TABLE、各类 BAPI关键设计：连接参数走sap-config.properties（或SAP_*环境变量），密码只留在本机，不进任何配置文件之外的位置；所有写类工具（create/post）commit默认true真实过账，测试时可设false仅校验参数映射。三、工具清单（17 个）连接器把常用 RFC/BAPI 归为四类，共 17 个工具：通用类工具说明sap_ping连通性测试（返回系统 ID / 客户端 / 主机）sap_call_rfc任意 RFC 函数透传调用sap_read_table/sap_read_tablesRFC_READ_TABLE单表 / 多表读取MM（物料管理）工具说明sap_material_stock查 MARD 库存（物料号自动补零到 18 位）sap_po_read读 EKKO+EKPO（PO 补零到 10 位）sap_goods_movementBAPI_GOODSMVT_CREATE收货/发货（commit默认 true）SD（销售与分销）工具说明sap_sales_order_read读销售订单sap_sales_order_createBAPI_SALESORDER_CREATEFROMDAT2sap_delivery_read读交货单sap_delivery_createBAPI_OUTB_DELIVERY_CREATE_SLS（按 SO 参考建交货单）sap_delivery_postBAPI_OUTB_DELIVERY_CONFIRM_DEC发货过账 PGIsap_customer_read读 KNA1+KNVV 客户主数据FICO（财务）工具说明sap_accounting_doc_read读会计凭证（透明索引表优先，回退 ACDOCA）sap_accounting_doc_postBAPI_ACC_DOCUMENT_POST记账sap_cost_center_read读 CSKS+CSKT 成本中心sap_gl_account_read读 SKA1+SKAT 总账科目四、三个关键工程优化（区别于"裸 BAPI 封装"）如果只是把 BAPI 透传出去，实战中几乎每一步都会撞墙。下面是本连接器真正"打磨过"的地方。4.1 交货单过账：先拣配，再过账BAPI_OUTB_DELIVERY_CONFIRM_DEC做 PGI 前，要求LIKP.KOSTK='C'（拣配完成）。否则会卡在VL 609甚至VR 537。坑点：SAP 安全注记2295840禁止外部 RFC 直接调用WS_DELIVERY_UPDATE（VL02N 里的拣配方法），BAPI_OUTB_DELIVERY_CHANGE的ITEM_DATA也没有拣配量字段。方案：在 SAP 侧建一个客户包装函数Z_SD_DELIVERY_PICK（内部调WS_DELIVERY_UPDATE，因为 CPROG 变成 Z 函数名从而绕过 2295840），连接器里sap_delivery_post默认pick_first=true，过账前先拣配：// SapJcoBridge.deliveryPost 的核心顺序// 1) 先拣配：Z_SD_DELIVERY_PICK（内部 WS_DELIVERY_UPDATE，UPDATE_PICKING='X'）booleanpickOk
基于SAPJCO实现AI Agent对SAP的操作
发布时间：2026/7/29 11:32:53
基于 MCP + SAP JCo 打造 AI 可调用的 ERP 工具链：从采购到会计凭证的端到端实战摘要：本文介绍一个纯 Java 实现的SAP JCo MCP 连接器——它把 SAP S/4HANA 的 RFC/BAPI 封装成 17 个标准 MCP 工具，让 AI 助手（如 WorkBuddy）像调用函数一样直接操作 ERP。文章重点讲解三个工程级优化（交货单"先拣配后过账"、批次自动带码、QM 使用决策封装），并用一条采购订单 → 采购收货 → 销售订单 → 交货单 → 发货过账 → 会计凭证的真实业务流做图文实战，全部单据号均来自 S/4HANA 测试系统实跑结果。目录为什么需要 SAP MCP 工具整体架构工具清单（17 个）三个关键工程优化（区别于"裸 BAPI 封装"）图文实战：端到端业务案例踩坑实录（干货）如何运行小结一、为什么需要 SAP MCP 工具做过 SAP 集成的同学都知道，让"外部程序"驱动 ERP 通常只有两条路：人工搬运：在 GUI 里点完，把单据号抄给 AI；或者让 AI 生成 ABAP/脚本，再人工执行。一次性接口：为每个场景写个 RFC/BAPI 调用程序，换个需求就重写。这两种方式都没法让 AI 自主、复用地操作 SAP。而MCP（Model Context Protocol）正好补上这块拼图：它把"能力"标准化成工具（tool），AI 通过 JSON-RPC 调用，参数、返回值都是结构化数据，天然适合 ERP 这种强结构化的系统。本文的连接器就是这么一个MCP stdio 服务器：AI 在左边说"帮我建个采购订单"，连接器在右边调BAPI_PO_CREATE1，把返回的订单号结构化回传。注：本文所有实跑结果均来自一台 S/4HANA 测试系统（SID=S4Q，客户端 800），公司代码 2010。二、整体架构整个链路零业务依赖，只引入 SAP 官方sapjco3.jar：层技术说明AI 客户端WorkBuddy / 任意 MCP 主机通过 stdio 收发 JSON-RPC 2.0MCP 服务器纯 Java（JDK 8+）解析tools/list、tools/call，路由到桥接层桥接层SapJcoBridgeSAP JCo 3.0注册DestinationDataProvider，封装 RFC/BAPI 调用、事务提交SAP 后端S/4HANARFC_READ_TABLE、各类 BAPI关键设计：连接参数走sap-config.properties（或SAP_*环境变量），密码只留在本机，不进任何配置文件之外的位置；所有写类工具（create/post）commit默认true真实过账，测试时可设false仅校验参数映射。三、工具清单（17 个）连接器把常用 RFC/BAPI 归为四类，共 17 个工具：通用类工具说明sap_ping连通性测试（返回系统 ID / 客户端 / 主机）sap_call_rfc任意 RFC 函数透传调用sap_read_table/sap_read_tablesRFC_READ_TABLE单表 / 多表读取MM（物料管理）工具说明sap_material_stock查 MARD 库存（物料号自动补零到 18 位）sap_po_read读 EKKO+EKPO（PO 补零到 10 位）sap_goods_movementBAPI_GOODSMVT_CREATE收货/发货（commit默认 true）SD（销售与分销）工具说明sap_sales_order_read读销售订单sap_sales_order_createBAPI_SALESORDER_CREATEFROMDAT2sap_delivery_read读交货单sap_delivery_createBAPI_OUTB_DELIVERY_CREATE_SLS（按 SO 参考建交货单）sap_delivery_postBAPI_OUTB_DELIVERY_CONFIRM_DEC发货过账 PGIsap_customer_read读 KNA1+KNVV 客户主数据FICO（财务）工具说明sap_accounting_doc_read读会计凭证（透明索引表优先，回退 ACDOCA）sap_accounting_doc_postBAPI_ACC_DOCUMENT_POST记账sap_cost_center_read读 CSKS+CSKT 成本中心sap_gl_account_read读 SKA1+SKAT 总账科目四、三个关键工程优化（区别于"裸 BAPI 封装"）如果只是把 BAPI 透传出去，实战中几乎每一步都会撞墙。下面是本连接器真正"打磨过"的地方。4.1 交货单过账：先拣配，再过账BAPI_OUTB_DELIVERY_CONFIRM_DEC做 PGI 前，要求LIKP.KOSTK='C'（拣配完成）。否则会卡在VL 609甚至VR 537。坑点：SAP 安全注记2295840禁止外部 RFC 直接调用WS_DELIVERY_UPDATE（VL02N 里的拣配方法），BAPI_OUTB_DELIVERY_CHANGE的ITEM_DATA也没有拣配量字段。方案：在 SAP 侧建一个客户包装函数Z_SD_DELIVERY_PICK（内部调WS_DELIVERY_UPDATE，因为 CPROG 变成 Z 函数名从而绕过 2295840），连接器里sap_delivery_post默认pick_first=true，过账前先拣配：// SapJcoBridge.deliveryPost 的核心顺序// 1) 先拣配：Z_SD_DELIVERY_PICK（内部 WS_DELIVERY_UPDATE，UPDATE_PICKING='X'）booleanpickOk
