企业官网建设流程全解析

简介：这份PDF文档围绕SAP中国本地化产品EPIC（Electronic Payment Integration for China）展开，系统讲解银企直连的整体方案，面向SAP财务与实施顾问、企业财务信息化负责人，用于解决付款、收款、对账三类业务问题。内容从银企直连的定义与价值切入，梳理ERP与商业银行通过专线或互联网接口对接的架构，说明采购、销售、会计等适用场景，以及会计报批、经理审批、出纳支付、总监复核的操作流程。主体部分详解电子支付中心，包括应付项自动发现与批量支付、多级与批量审批、一键向多家银行下达转账指令、账户余额与明细实时查询、回单自动对账清账，并覆盖RFC调用、http目的地、XML报文、银行前置机等集成链路与实施建议。压缩包仅含1个PDF文件，约4.07MB，轻量便携。已有3500人学习下载，可作为方案宣贯、项目预研与接口设计的参考。

1. 一份 2011 年的 SAP EPIC 银企直连方案，放到今天还能当实施手册用吗

财务共享中心上线第三个月，出纳桌上还是两块屏：左边 SAP 里挂着未清项，右边网银页面输账号、抄回单号。问为什么不上直连，答案通常是“接口做过，但没人敢让它自动发钱”。SAP EPIC（Electronic 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 就是省事的。

这张表不是绝对标准，但它能挡掉一批“为了直连而直连”的项目。我见过一家企业只有一家开户行、付款方式单一，做完 EPIC 之后维护成本比手工上传还高，最后还是退回 F110 出文件。这不是 EPIC 的问题，是场景没匹配上。

2.2 六个环节：一条报文到底经过哪些对象

PDF 里反复出现的那张图，中间是“电子支付中心”，左边是 SAP ERP 的应付、应收、资金管理，右边是银行前置机。拆成可操作的对象，大致是六个环节，每个环节都对应一个能查、能配、能出问题的地方。

第 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; charset=utf-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 的实施材料里最容易漏的是接口清单，因为付款只是其中一条，余额、明细、对账单各是独立的接口，配置项也不一样。下面这张表是按业务方向整理的，实际项目里按银行拆成多行。

清单要做两件事才有用。一是每个接口都要写清楚“失败之后谁负责”，付款失败是退回到付款请求还是直接冲销凭证，余额查询失败是重试还是跳过，这些规则不写下来，上线后就是每次出问题现场决策。二是日志入口要写具体，不能只写“看日志”，要写到哪个事务码、看哪个字段、保留多少天。这份清单做扎实了，后面接手的人不用再问一遍。

顺带说一句，找资料的时候用 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 的格式变更，都强制走一遍“基线重放 + 结构比对 + 单笔小额实发”，宁可多花两天，也不想半夜被电话叫起来查重复付款或者漏付款。希望帮到你。

本文还有配套的精品资源，点击获取