简介这份PDF文档围绕SAP中国本地化产品EPICElectronic Payment Integration for China展开系统讲解银企直连的整体方案面向SAP财务与实施顾问、企业财务信息化负责人用于解决付款、收款、对账三类业务问题。内容从银企直连的定义与价值切入梳理ERP与商业银行通过专线或互联网接口对接的架构说明采购、销售、会计等适用场景以及会计报批、经理审批、出纳支付、总监复核的操作流程。主体部分详解电子支付中心包括应付项自动发现与批量支付、多级与批量审批、一键向多家银行下达转账指令、账户余额与明细实时查询、回单自动对账清账并覆盖RFC调用、http目的地、XML报文、银行前置机等集成链路与实施建议。压缩包仅含1个PDF文件约4.07MB轻量便携。已有3500人学习下载可作为方案宣贯、项目预研与接口设计的参考。1. 一份 2011 年的 SAP EPIC 银企直连方案放到今天还能当实施手册用吗财务共享中心上线第三个月出纳桌上还是两块屏左边 SAP 里挂着未清项右边网银页面输账号、抄回单号。问为什么不上直连答案通常是“接口做过但没人敢让它自动发钱”。SAP EPICElectronic Payment Integration for China资料里常写成 SAPEPIC 连写处理的正是这一段流程把付款、余额与明细查询、对账单回传这三件事从网银搬回 ERP 内部让钱的动作和账的动作在同一个系统里闭环。这份 PDF 是当年全球化服务部的方案演示稿讲背景、适用场景、功能拆解和实施建议页面不新但里面那张“应付项 → 审批 → 电子支付中心 → 银行前置机 → 银行”的链路图以及按角色切分的操作流程到今天仍然是多数本地化项目的骨架。适合三类人翻正在做 EPIC 实施的顾问、接手了半套直连的运维、被要求评估“能不能上直连”的财务 IT。下面不复述 PDF只拆这份材料里能落地的部分以及落地时容易踩到的地方。2. 拆开一条付款报文的链路从 F110 到银行前置机的六个环节2.1 为什么 EPIC 是在 F110 上叠加而不替换它先把最容易混淆的一层说清楚。F110 是 SAP 标准的自动付款程序它干的事是根据到期日和支付方式跑付款建议、审核、执行付款运行、生成付款凭证、调用支付媒介程序产出文件。这套东西在 EPIC 出现之前就在跑EPIC 没有把它推翻而是在它后面接了三段 F110 本身不负责的能力。第一段是审批。F110 自带的是付款建议的冻结与解冻粒度粗也不适合做成多级、批量、可追溯的审批组。EPIC 把“哪些应付项进入本次支付”“谁审、审到第几级、审完能不能退签”做成了独立的工作台审批状态和付款凭证解耦付款运行成功不等于钱能出去这是很多财务总监真正关心的点。第二段是银行通信。F110 的支付媒介最终产出的是一个文件传统做法是导出来人工上传网银。EPIC 把这段换成系统内直发报文按银行要求的 XML 结构生成通过 HTTP(S) 送到银行前置机前置机再经专线转银行主机。多银行、多格式、同步与异步回执都是在这一层收拢的。第三段是状态回写与对账。报文发出去之后银行受理、成功、退回这些状态要回到 ERP 里落在这笔付款凭证上出问题能一眼看出卡在哪。回执和对账单再把清账动作带回来减少手工 FF.5 的活。所以选型上有条很实在的判断线如果只有一两家银行、一种报文格式、每月几十笔、审批在线下签纸F110 出文件加人工上传完全够用硬上 EPIC 只是多一层要维护的东西。反过来银行超过三家、付款笔数上千、审批必须留痕、财务要求实时看账户余额那 EPIC 就是省事的。判断维度F110 直出文件上 EPIC银行数量12 家3 家以上且格式各异月付款笔数几百以内上千批量占比高审批要求线下签字、纸质留档系统内多级、可批量、可退签状态可见性靠人工登记报文状态回写凭证对账手工导入、手工清对账单自动导入匹配这张表不是绝对标准但它能挡掉一批“为了直连而直连”的项目。我见过一家企业只有一家开户行、付款方式单一做完 EPIC 之后维护成本比手工上传还高最后还是退回 F110 出文件。这不是 EPIC 的问题是场景没匹配上。2.2 六个环节一条报文到底经过哪些对象PDF 里反复出现的那张图中间是“电子支付中心”左边是 SAP ERP 的应付、应收、资金管理右边是银行前置机。拆成可操作的对象大致是六个环节每个环节都对应一个能查、能配、能出问题的地方。环节主要对象或事务码产出物出问题先看哪1 付款建议与运行F110、FBZP 支付方式配置付款凭证、支付媒介请求付款建议日志、凭证状态2 支付请求生成EPIC 付款处理工作台EPIC_PROC支付请求头与行项目请求里的笔数、总额、账户3 审批EPIC 审批视图与审批组配置审批状态、审批历史审批组人员、权限对象4 报文生成银行接口格式配置、DMEE 格式树XML 报文文件格式树节点、字段映射5 传输SM59 目的地HTTP 类型 G、ABAP 类型 3、PI/POHTTP(S) 请求与响应目的地测试、消息监控6 回执处理银行异步回执接口、清账程序状态回写、清账凭证回执日志、凭证更新记录第 4 和第 5 环节最容易理解错。文档里画的是“RFC 远程功能调用 http 目的地 XML 报文”实际运行时是两段SAP 内部通过 RFC 把报文交给通信框架框架再按 HTTP 目的地把 XML 发出去目的地址指向银行前置机。RFC 解决的是“谁来发”HTTP 解决的是“发到哪”XML 解决的是“发什么”三者别混成一件事去查。第 6 环节要特别区分同步和异步。有的银行接口是同步返回受理结果调用完立刻知道成功还是失败有的是先返回“已接收”真正的处理结果要等银行异步推回来或者由 ERP 定时回查。这两种在配置和排查上完全是两条路配错了就会出现“报文发出去了、状态一直不动”的经典现象。2.3 用三个动作确认链路是通的链路排查不要一上来就翻代码按从外到内的顺序做三件事绝大多数问题能在十分钟内定位。第一件绕开 SAP 直接打前置机。用一台能访问前置机的应用服务器拿一份脱敏后的测试报文直接发 HTTP 请求。这一步能把“SAP 配置问题”和“网络/证书/银行侧问题”彻底分开。# 直连银行前置机做连通性验证仅用于测试环境 curl -k -sS -o resp.xml -w http%{http_code} time%{time_total}s\n \ --cert ./client.crt --key ./client.key \ -H Content-Type: application/xml; charsetutf-8 \ --data-binary payment_test.xml \ https://gateway.example.com/epic/pay参数逐个说清楚-k跳过证书链校验只在排查“是不是证书链问题”时临时用正式链路必须去掉--cert和--key是双向认证的客户端证书和私钥银行侧通常要求--data-binary而不是--data是为了保持报文原始字节避免 curl 把换行或特殊字符做处理导致银行侧解析失败——这个坑我踩过测试报文在本地看完全正常发出去就是格式错最后发现是换行被改了-w输出状态码和耗时用来判断是超时还是被拒。返回200但业务失败说明传输没问题、报文内容有问题返回401/403查证书连不上查前置机地址和端口。第二件回到 SAP 里测目的地。SM59 里找到对应目的地HTTP 类型G的连接会带 URL 和认证方式ABAP 类型3看的是目标系统和登录凭据。点“连接测试”拿返回码这一步能确认 SAP 应用服务器到前置机的网络路径和凭据没问题。如果链路中间过了 PI/PO再去 SXMB_MONI 看消息有没有进来、有没有出去。第三件查应用日志和凭证变更。EPIC 的应用日志入口在 EPIC_ 前缀的事务码下具体名字在 SE93 里按EPIC*搜一遍最稳不同版本略有差异。日志里能看到每次调用入参、返回码、错误文本。如果怀疑是有人在付款后改了银行账号走标准变更历史更快 查付款凭证在一段时间内的字段级变更用于定位账号被改动的情况 SELECT c~objectid, c~changenr, c~udate, c~utime, c~username, p~fname, p~value_old, p~value_new FROM cdhdr AS c INNER JOIN cdpos AS p ON p~objectclas c~objectclas AND p~objectid c~objectid AND p~changenr c~changenr WHERE c~objectclas BSEG AND c~udate BETWEEN lv_date_from AND lv_date_to INTO TABLE DATA(lt_changes) UP TO 500 ROWS. 输出时按凭证号排序重点看 fname 为银行相关字段的行 SORT lt_changes BY objectid changenr.这段 OPEN SQL 用cdhdr变更抬头关联cdpos变更行objectclas BSEG取的是会计凭证行的变更时间区间用变量传避免全表扫。fname是字段名value_old和value_new是前后值看账号、金额、付款方式这三类字段就够了。行数限制UP TO 500 ROWS是防止一次拉太多把会话撑爆真要做审计报表再换成分页。三件事做完问题基本落在某一层curl 通、SM59 不通是 SAP 侧网络或目的地配置两个都通、日志报错是报文格式都正常但状态不动是回执那一层。这条排查顺序比从头读代码快得多。3. 主数据与接口配置的落地顺序先建账户还是先配格式树3.1 银行账户这条线FI12 建好只是第一步EPIC 的所有报文最终都要落到一个具体的银行账户上这个账户在 SAP 里的根是 FI12 维护的 house bank银行代码 账户 ID。很多人以为 FI12 建完就完事实际上后面还有两层要接上。第一层是账户与接口的映射。同一个 house bank 下可能有多个账户走不同的银行接口、不同的报文格式、不同的证书。EPIC 里要把“哪个公司代码 哪个 house bank 哪个账户 ID”对应到“哪个接口编号 哪个格式 哪个签名配置”这个映射关系是整个直连的路由表配错一个字段报文就会发到错误的通道或者被银行拒收。第二层是账户属性的准确性。账号有没有前导零、有没有空格、开户行行号是不是最新的、账户币种和实际是否一致这些在主数据里看不出问题到了银行侧就是匹配失败。常见的翻车场景是测试环境用一套账号生产切换时账号多了一个空格报文发出去银行返回“账户不存在”排查半天以为是接口问题。我一般按这个顺序推先在 FI12 建 house bank 和账户再用一个最小付款场景单笔、小额、同公司代码跑通端到端确认账号、行号、币种全对然后才批量导入其他账户。反过来先批量建、再逐个调出了问题根本分不清是哪个账户的哪个字段。3.2 支付方式要按“银行 × 币种 × 是否电子”拆开F110 的支付方式payment method在 FBZP 里配它决定了付款建议怎么分组、走哪个支付媒介、用哪棵格式树。EPIC 项目里这一步最容易被糊弄过去直接把所有付款都塞进一个支付方式结果是本币、外币、大额、小额全走同一条报文审批流也没法按金额分流。合理的拆法是三个维度银行、币种、是否电子直连。比如某行人民币电汇走 EPIC 的支付方式 A某行美元走 SWIFT 手工的支付方式 B某行人民币但金额特别小的走支付方式 C 走网银批量。这样拆的好处是F110 跑出来的付款建议天然分组EPIC 的报文格式按支付方式挂审批规则也能按支付方式加金额区间配。拆的时候要注意两件事。一是支付方式的数量别失控超过十来个之后维护成本会明显上升业务也记不住哪个是哪个命名规则要统一比如“银行简称 币种 电子/手工”三段式。二是历史数据迁移老支付方式停用之前要先确认没有未清的付款建议还挂着不然跑 F110 会报“支付方式不存在”或者更隐蔽地跳过某些项。3.3 接口配置清单一张表把该配的东西列全EPIC 的实施材料里最容易漏的是接口清单因为付款只是其中一条余额、明细、对账单各是独立的接口配置项也不一样。下面这张表是按业务方向整理的实际项目里按银行拆成多行。接口方向常见报文格式触发方式关键配置日志入口付款指令ERP → 银行银行自定义 XML同步受理 异步结果格式树、证书、目的地应用日志、支付请求状态付款结果回执银行 → ERPXML / 固定长度文本异步推送或定时回查回执解析映射、匹配键回执日志、凭证更新记录账户余额查询ERP → 银行XML同步账户映射、超时时间查询日志账户明细查询ERP → 银行XML / CSV同步按日期区间日期格式、分页参数查询日志对账单获取银行 → ERPMT940 / 银行 XML / CSV定时拉取或推送文件落盘路径、格式映射导入日志、对账单状态清单要做两件事才有用。一是每个接口都要写清楚“失败之后谁负责”付款失败是退回到付款请求还是直接冲销凭证余额查询失败是重试还是跳过这些规则不写下来上线后就是每次出问题现场决策。二是日志入口要写具体不能只写“看日志”要写到哪个事务码、看哪个字段、保留多少天。这份清单做扎实了后面接手的人不用再问一遍。顺带说一句找资料的时候用 EPIC 或者 SAPEPIC 连写去搜能命中一批早年的实施笔记和论坛帖里面关于格式树节点和回执匹配的细节比官方文档更贴近实际但要注意版本差异别人环境里的事务码名字在你这里可能不一样以 SE93 搜出来的为准。4. 付款、余额查询、对账单三件事的实操序列4.1 付款从支付请求生成到状态回写的完整动作付款这条线是 EPIC 的主干动作顺序不能乱乱了就会出现“钱发了、账没清”或者“账清了、钱没发”。第一步F110 跑付款建议。参数上重点是公司代码、支付方式、下次付款日期建议跑完先看日志里的例外项有没有因为银行主数据缺失、账户不存在被跳过的。这一步的产物是付款建议还没真正生成凭证。第二步审付款建议并执行付款运行。执行之后生成付款凭证同时产生支付媒介请求。到这里为止行为和传统 F110 没有区别区别在后面。第三步在 EPIC 的付款处理工作台里生成支付请求。工作台会把到期的、已审批的应付项汇总成支付请求一个请求包含头和若干行头上有总笔数、总金额、付款账户行上是每一笔的收款人、金额、参考号。这一步要核对三个数笔数、总额、账户三者任一不对就不要往下走。第四步审批。审批组和审批级别是配置出来的支持批量提交和批量审批也支持退签。审批动作要留痕谁在什么时候审了哪几笔后面出问题这是唯一的依据。第五步下达转账指令。系统按支付方式对应的格式树生成 XML通过目的地发到前置机。发送动作要么手工触发要么挂在后台作业里定时跑。PDF 里强调的是“一步下达转账指令、自动下达至多个银行”实际做的时候建议先单笔小额验证再开批量。第六步回执处理。银行返回受理结果异步的还要等最终结果。状态大致会经过待审批 → 已审批 → 已发送 → 银行已受理 → 成功 / 退回。每个状态的停留时间要有监控停在“已发送”超过约定时间就要有人看。-- 在 SE16N / SQVI 里先摸清本系统有哪些 EPIC 自定义表 -- 不同版本表名有差异用数据字典反查最稳 SELECT tabname, tabclass FROM dd02l WHERE tabname LIKE EPIC% AND as4local A ORDER BY tabname;这段查询查的是数据字典里的透明表和结构as4local A取的是激活版本。跑出来会看到支付请求、对账单暂存、审批状态这几类表具体表名各版本不完全一致所以我不在这里写死某个表名——写死了反而是坑照着抄结果发现表不存在白折腾。拿到表名之后再去看字段重点确认三样有没有业务流水号用于幂等、有没有银行返回码、有没有时间戳。4.2 余额与明细查询实时性是有边界的余额查询用起来很直观配好账户映射选账户、点查询返回可用余额和账面余额。但它的“实时”是有前提的取决于银行接口本身。有的银行接口是真正实时的调用即返回当前余额有的银行只提供日终余额或者准实时比如五分钟一刷新还有的银行对查询频率有限制一分钟内超过多少次就拒绝。这三种情况在界面上看起来一模一样都是“查出来一个数”但业务含义完全不同。配置阶段就要把每个账户的查询能力标注清楚否则财务拿着一个日终余额当成实时余额去做资金决策风险不小。明细查询还多一个参数问题日期区间。银行侧对区间长度通常有限制比如单次最多查三十天或者九十天超了直接报错。批量查多个账户时如果串行调用十几个账户能把一个后台作业拖到超时我一般会拆成并行作业或者错峰跑并且给每个调用设独立的超时避免一个账户卡住拖垮整批。超时值怎么定不能拍脑袋。方法是拿测试环境跑几十次记录 P95 耗时超时设成它的两到三倍。设太短会误判失败设太长会把后台作业占死。查询类接口失败通常重试一次就够不要做无限重试银行侧被刷多了会直接封。4.3 对账单导入、映射、匹配、例外处理四步对账单是三条业务线里最考验配置的一项因为银行给的文件格式千奇百怪有标准 MT940有银行自定义 XML也有直接给 CSV 甚至 Excel 的。EPIC 的对账单导入入口在 EPIC_ 前缀的事务码下导入之后进暂存再做匹配和清账。第一步导入。要确认的是文件落盘位置、编码、分隔符、表头行数。CSV 最常见的问题是编码银行给的是 GBK系统按 UTF-8 读中文户名全是乱码其次是金额列的小数点和千分位有的银行金额写成1,234.56直接按数值解析会失败。第二步映射。把银行文件的列映射到系统字段记账方向借/贷、金额、起息日、交易日期、对方户名、对方账号、摘要、银行流水号。映射里最容易错的是记账方向和金额符号有的银行用一列正负数表示有的用两列分别表示借贷映射配反了就是全量对不上。第三步匹配。自动清账规则一般按优先级排先按“金额 银行流水号”精确匹配再按“金额 参考号”匹配再退到“金额 日期容差 对方账号”。规则越往后误匹配风险越高所以要设阈值比如容差匹配必须人工确认。第四步例外处理。匹配不上的挂起不能直接冲销。挂起的原因通常是付款报文里的参考号和银行回单不一致、手续费单独扣了一笔、跨月到账。这几种要分开处理手续费要单独配置费用科目跨月要检查期间是否已关参考号不一致要回头查报文生成时的字段长度是不是被截断了。PDF 里提到“格式转换可灵活配置、PDF 方式显示和归档”这在实操里对应的是对账单的展示层和归档策略。展示层要能让财务直接看到原始文件长什么样归档要能按公司代码 账户 月份检索否则审计来了翻不出来。5. 避坑与排查EPIC 上线后最容易翻车的五处细节5.1 现象同一笔付款银行收到两次这是最严重的一类问题一旦发生就是资金风险。现象是银行流水里出现两笔金额、收款人完全相同的记录而 ERP 里只有一笔付款凭证。原因通常不是系统重复发送而是人在超时之后手工重发。报文发出去前置机没在超时时间内返回出纳以为失败在工作台里点了重发实际上第一笔已经到了银行。系统层面如果没有幂等控制两笔都会被执行。解决要分两层。系统层支付请求必须带一个全局唯一的业务流水号银行侧按这个号去重这是最硬的一道防线同时把发送超时的处理策略改成“只查不发”超时后先调银行的付款状态查询接口确认没成功才允许重发。流程层工作台里重发动作要加权限控制不是所有出纳都能点重发记录要留痕。上线前拿测试环境模拟一次超时看流程会不会走到重发这一步别省。5.2 现象状态一直停在“已发送”钱其实已经到账现象是付款请求状态几天不动财务以为没发出去实际银行早就处理完了。原因多半在回执这一层。一是异步回执接口没开或者地址配错银行推不回来二是银行侧升级了回执格式多了一个节点或者改了字段名解析程序直接报错但没人看日志三是定时回查作业没配只依赖推送推送失败就永远不知道结果。解决方式是双通道推送和回查都要有回查按固定间隔跑比如每三十分钟查一次超过两小时还没终态的请求。回执解析要加监控解析失败的报文落一份原始文件不能直接丢弃。状态停留时间要设阈值告警超过阈值自动通知运维而不是等财务发现。5.3 现象ERP 总额和银行到账总额差几分钱现象是笔数对得上总额差几分甚至几毛反复核查找不到原因。原因通常是三选一。币种小数位不一致比如日元没有小数位、某些币种两位小数报文生成时按固定两位格式化就会产生尾差四舍五入方式不一致SAP 和银行侧一个用银行家舍入一个用四舍五入汇总行和明细行的计算基准不同汇总按已舍入的明细加总还是按原始金额加总两种算法结果不同。解决是在报文里同时带明细和汇总校验字段总笔数、总金额让银行侧先校验再处理不一致直接拒收把问题挡在发送环节而不是到账之后。金额格式化统一走配置不要在代码里写死小数位。测试用例里专门准备一组多币种、带尾差的付款每次改动报文格式都跑一遍。5.4 现象对账单导入成功但一笔都匹配不上现象是文件导进去了暂存表里有数据自动清账跑完匹配率为零。原因一般是日期。银行给的日期格式是日/月/年系统按 月/日/年 解析比如 03/04/2024 被读成 3 月 4 日实际是 4 月 3 日差一天就全部匹配失败。另一种是起息日和交易日记混用匹配规则配的是交易日期数据里填的是起息日。还有一种是跨期银行文件包含上月最后两天的交易导入时会计期间已关匹配上了也过不了账。解决是导入前做格式校验日期字段解析失败直接拒绝整批不要“尽力解析”。导入界面要显示解析出的前几条样例人工确认无误再执行。跨期问题在导入时检查记账日期所属期间状态已关期间的单子单独挂起走特殊期间或者下期调整不要硬过。5.5 现象审批通过了收款账号还是被改了这是权限设计的问题不是接口问题。现象是付款审批完成之后有人在付款凭证或者支付请求里改了收款账号钱打到了新账号。原因有两个字段级权限没做能改凭证的人就能改银行字段审批和锁定没联动审批通过只是改了个状态底层数据仍然可编辑。解决是三步。敏感字段收款账号、开户行、收款人名称配字段级权限只有特定角色能改审批通过后锁定相关字段要改必须退签重审所有变更走变更历史留痕定期审计。这三步里第一步最容易被跳过因为配置起来琐碎但它是唯一能在事前挡住的。6. 把 EPIC 跑成可复盘的系统报文留档与回归重放EPIC 上线只是开始真正决定它能不能长期稳定跑的是出问题之后能不能复现。我的做法是强制留一份“报文四件套”请求 XML 原文、响应 XML 原文、精确到毫秒的时间戳、业务流水号再带上操作人和公司代码落到一张自建日志表里按月份归档。这张表不参与业务逻辑只做黑匣子。出问题时按流水号一查请求发了什么、银行回了什么、什么时候回的一目了然不用再去猜是网络问题还是格式问题。第二件事是回归重放。银行侧改报文格式、系统打补丁、改格式树这几种变更最容易悄悄破坏报文结构。做法是拿一批历史脱敏报文当基线每次变更后用新配置重新生成一遍比对节点结构差异。import xml.etree.ElementTree as ET from collections import Counter def walk(node, path, out): tag node.tag.split(})[-1] # 去掉命名空间前缀只比结构 key path / tag out[key] 1 for child in node: walk(child, key, out) def profile(file_path): root ET.parse(file_path).getroot() counter Counter() walk(root, , counter) return counter base profile(payment_baseline.xml) # 变更前的基线报文 new profile(payment_after_patch.xml) # 变更后新生成的报文 for key in sorted(set(base) | set(new)): if base.get(key, 0) ! new.get(key, 0): print(f{key}: 基线 {base.get(key, 0)} 次 - 新报文 {new.get(key, 0)} 次)这段脚本只比节点路径和出现次数不比节点值因为值里有金额、账号脱敏之后比对意义不大结构才是银行最在意的东西。walk递归展开整棵树用路径做键Counter记每个路径出现几次两边取并集遍历只打印数量不一致的路径。实际用的时候跑出来最常见的是“某个必填节点从 1 次变成 0 次”那就是格式树改坏了比等银行拒收再回头查快得多。第三件事是状态对账。每天固定时间跑一次核对ERP 里状态为“已发送”超过阈值的请求、银行侧流水里 ERP 没有对应凭证的记录、对账单里挂起超过三天的条目。这三张清单每天看一眼比出了事再翻日志强。这套动作听着笨但它把“玄学问题”变成了可查的记录。血泪经验是早年间一个项目报文格式改了一版测试环境用旧报文跑通了就上线结果生产第一批付款全被银行退回原因是新格式少了一个必填节点而测试用的还是老文件。从那以后我每次做 EPIC 的格式变更都强制走一遍“基线重放 结构比对 单笔小额实发”宁可多花两天也不想半夜被电话叫起来查重复付款或者漏付款。希望帮到你。本文还有配套的精品资源点击获取