尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

SAP FICO自动付款配置与F110执行全流程:从FBZP到底表存储

发布时间:2026/9/23 20:17:16

资讯中心
01
ARTICLE

SAP FICO自动付款配置与F110执行全流程:从FBZP到底表存储

SAP FICO自动付款配置与F110执行全流程:从FBZP到底表存储
简介本资源面向SAP FICO顾问、财务信息化实施人员及需要掌握自动付款功能的运维学习者围绕F110自动付款的配置、测试与底表存储展开帮助解决银行主数据维护、收付程序设置及付款建议生成等实操问题。压缩包内共1个docx文档约11.4MB以图文操作手册形式呈现内容按系统配置、T银行汇款演示、W银行承兑汇票演示及其它补充四大模块组织涵盖FI01、FI12_HBANK、NWBC、FBZP、FBL1N、F110、S_P99_41000099等事务码的具体操作路径。读者可据此完整走通从维护银行主数据、创建开户行与账户标识、维护供应商付款信息到查询未清明细、创建并检查付款建议、生成付款凭证的全流程同时理解测试数据在底表中的存储逻辑与验证方式。目前已有396人学习下载适合需要对照配置步骤、排查付款异常并沉淀实施笔记的从业者参考。1. SAP FICO 自动付款到底在解决什么问题从 FBZP 到 F110 的一次完整跑通月底财务关账前应付会计面对几百上千条未清供应商发票手工逐条勾选、逐笔付款、逐张打印付款凭证这种场景在上了 SAP FICO 之后本不该再出现。自动付款配置就是把这套动作交给系统你在 FBZP 里把公司代码、付款方式、银行账户、排序规则、打印格式一次性配好之后用 F110 批量跑付款建议、生成付款凭证、输出付款媒介文件整个过程可重复、可追溯。它解决的核心痛点是批量、准确、可审计——尤其是当供应商主数据里付款条件、付款方式、银行信息都维护到位时F110 一次能处理上千条未清项。这篇文章面向已经接触过 SAP FICO 模块、想真正把自动付款跑起来并搞清楚底表存储逻辑的从业者从配置、测试数据、执行到排错一步步拆开讲。2. FBZP 配置全流程五个必配节点与参数含义FBZP 是自动付款的配置总入口事务码进去之后左侧是一棵树节点顺序基本就是配置顺序。很多人第一次进去会被十几个节点吓到其实真正影响付款能否跑通的只有五个公司代码、付款方式、银行确定、排序规则、打印格式。下面按顺序拆。2.1 公司代码层最小付款金额与付款方式勾选进入 FBZP 后第一个节点是「公司代码」这里要做两件事一是给公司代码分配允许的付款方式二是设置最小付款金额。付款方式如 C 表示支票、T 表示电汇、A 表示 ACH必须在这里勾上否则 F110 跑的时候根本不会带出这个付款方式。最小付款金额这个参数容易被忽略。它的作用是如果某笔付款金额低于这个阈值系统不生成付款。常见做法是设成 1 或者 0.01避免出现金额为 0 的异常付款。但如果你设成 100那所有小于 100 的付款都会被静默跳过F110 日志里只会显示「未达到最小金额」新手很容易在这里翻车。提示公司代码层的付款方式勾选是「允许」不是「默认」。默认付款方式是在供应商主数据里维护的两者要匹配才能跑通。2.2 付款方式配置格式、银行账户与凭证类型第二个节点「付款方式」是配置量最大的地方。每个付款方式C/T/A 等在「付款方式/公司代码」层级下要维护参数含义常见取值凭证类型生成付款凭证用的凭证类型KZ供应商付款付款媒介输出文件的格式支票用 CHK电汇用 XML 或 IDOC银行账户付款出账的银行账户需先在「银行确定」里配好打印格式付款建议和付款媒介的打印程序标准程序 RFFO* 系列凭证类型这里要特别注意KZ 是供应商付款的标准凭证类型如果你用了自定义凭证类型要确认它的号码范围已经维护否则 F110 生成凭证时会报「号码范围不存在」。付款媒介决定了最终输出什么文件。支票场景输出的是打印文件电汇场景通常输出 XML 或者 IDOC 给银行。这一步配错后面 F110 跑完你会发现「付款凭证生成了但没有输出文件」。2.3 银行确定供应商银行与自家银行的匹配逻辑「银行确定」这个节点是很多人卡住的地方。它的逻辑是系统根据供应商主数据里的银行信息国家、银行代码、账号和自家公司代码的银行账户匹配出一条出账路径。配置时要维护「银行确定」的排序规则通常是按国家 银行代码 账号。如果供应商主数据里的银行信息不完整比如只填了银行代码没填账号银行确定就会失败F110 日志里报「未找到银行确定」。常见做法是先在「银行确定」里为公司代码维护好自家银行的出账账户然后在供应商主数据FK02里把银行信息补全。两边都到位银行确定才能通过。2.4 排序规则与打印格式决定付款顺序和输出样式排序规则Ranking Order决定 F110 生成付款建议时同一供应商的多笔未清项按什么顺序合并或拆分。标准排序规则有按到期日、按凭证日期、按金额等。如果你不做特殊合并用标准排序规则即可。打印格式节点配置的是付款建议和付款媒介的打印程序。标准程序是 RFFOD__S付款建议和 RFFOD__P付款媒介但不同付款方式对应的程序不同。这里配错F110 打印时会报「程序不存在」。2.5 配置检查用 FBZP 的检查功能提前排雷FBZP 右上角有一个「检查」按钮可以对你当前配置做一致性检查。建议每次改完配置都点一下它会告诉你哪些节点还没配、哪些参数冲突。这个功能比跑一遍 F110 再回头查日志高效得多。配置完成后可以用事务码 FBZP 的「显示」模式再走一遍确认每个节点都是绿色勾。如果某个节点是黄色或红色F110 大概率跑不通。3. 测试数据准备供应商主数据、未清项与银行信息配置好了不代表能跑通测试数据不到位F110 照样给你脸色看。这一章讲怎么准备一套最小可跑的测试数据。3.1 供应商主数据的三个关键字段供应商主数据FK01/FK02里和自动付款直接相关的字段有三个付款条件Payment Terms决定到期日和付款基准日。比如 0001 表示立即付款0002 表示 30 天。付款条件不对F110 算出来的到期日就是错的。付款方式Payment Method在「付款交易」视图里维护必须和 FBZP 里公司代码层勾选的付款方式匹配。银行信息Bank Details在「银行明细」视图里维护包括银行国家、银行代码、账号。这三个字段是银行确定的输入。常见做法是先用 FK01 建一个测试供应商付款条件设 0001付款方式勾 C 和 T银行信息填一个完整的测试银行账号。然后用 FK02 检查一遍确认没有遗漏。3.2 用 FB60 或 MIRO 制造未清项有了供应商下一步是制造未清项。最简单的方式是用 FB60 直接做一张供应商发票或者用 MIRO 做一张采购发票。关键点是发票的付款条件要带出来到期日要落在你计划跑 F110 的日期之前。比如你计划 2025-06-15 跑 F110那发票到期日最好设在 2025-06-01 到 2025-06-14 之间这样 F110 的「到期日」选择条件能把它带出来。如果到期日在未来F110 默认不会选中它除非你改了选择参数。 用 FB60 做一张测试发票的关键输入 供应商TEST_VENDOR_001 金额1000.00 USD 付款条件0001 基准日2025-06-01 到期日系统自动算出 2025-06-01上面这段不是代码是 FB60 录入时的关键字段清单。逻辑是付款条件 0001 表示立即付款基准日就是到期日。这样这张发票在 2025-06-15 跑 F110 时一定会被选中。3.3 银行信息不完整的典型报错与补数方法如果供应商银行信息不完整F110 跑的时候会在日志里报「银行确定失败」。这时候要去 FK02 的银行明细视图补全。补的时候注意银行国家、银行代码、账号三个字段必须和 FBZP 里银行确定的配置匹配。如果供应商有多个银行账号还要维护「银行确定」的优先级。标准做法是在供应商主数据里给每个银行账号分配一个银行确定 ID然后在 FBZP 里按 ID 排序。注意测试数据准备阶段建议至少准备 3 个供应商一个银行信息完整、一个银行信息缺失、一个付款方式不匹配。这样跑 F110 时能一次性看到三种典型结果方便对照日志排查。4. F110 执行与底表存储从付款建议到凭证落表配置和数据都到位后F110 就是最后一步。但 F110 不是一个事务码跑完就结束它分四个阶段参数录入、付款建议、付款凭证、付款媒介。每个阶段都会往不同的底表写数据。4.1 F110 四个阶段的操作顺序与参数F110 的界面从上到下是参数录入输入公司代码、付款方式、下次跑批日期、供应商范围等。付款建议点「建议」按钮系统生成付款建议写入 REGUH 和 REGUP。付款凭证点「付款」按钮系统根据建议生成付款凭证写入 BKPF 和 BSEG。付款媒介点「打印」或「输出」按钮生成付款文件写入 REGUH 的媒介字段。参数录入阶段最关键的是「下次跑批日期」。这个日期决定 F110 选中哪些未清项系统会选中到期日小于等于这个日期的发票。如果你把日期设成今天那所有已到期的发票都会被选中。 F110 参数录入的关键字段 公司代码1000 付款方式C 下次跑批日期2025-06-15 供应商TEST_VENDOR_001 到 TEST_VENDOR_003 状态新建这段是 F110 参数录入的字段清单。逻辑是公司代码 1000 下付款方式 C跑批日期 2025-06-15供应商范围限定在三个测试供应商。这样跑出来的建议只包含这三个供应商的已到期发票。4.2 REGUH 与 REGUP付款建议的底表结构F110 跑完付款建议后数据落在两张表REGUH付款建议头表一条付款建议一行。关键字段有公司代码BUKRS、供应商LIFNR、付款方式RZAWE、付款金额RBETR、银行确定 IDBVTYP。REGUP付款建议行项目表一条未清项一行。关键字段有付款建议号KEYNO、凭证号BELNR、未清项金额DMBTR、到期日ZFBDT。这两张表的关系是REGUH 一条记录对应 REGUP 多条记录。比如一个供应商有三张发票被选中REGUH 里是一行REGUP 里是三行。常见做法是跑完付款建议后用 SE16 查 REGUH 和 REGUP确认建议号和金额对不对。如果 REGUH 里没有记录说明付款建议没生成要回去看 F110 日志。4.3 BKPF 与 BSEG付款凭证的落表逻辑点「付款」按钮后系统生成付款凭证写入 BKPF凭证头和 BSEG凭证行项目。付款凭证的凭证类型是 KZ过账码通常是 25供应商借方和 50银行贷方。关键点是付款凭证生成后原来的未清项会被清掉。你可以用 FBL1N 查供应商未清项确认被选中的发票已经不在未清列表里。如果付款凭证生成失败F110 日志里会报具体原因比如「号码范围不存在」「过账期间未打开」「银行账户未找到」。这时候要回到 FBZP 或者 FI 的期间控制里排查。4.4 付款媒介输出与 REGUH 的媒介字段更新最后一步是输出付款媒介。点「打印」或「输出」按钮后系统根据 FBZP 里配的付款媒介程序生成文件同时更新 REGUH 的媒介字段如 MEDIUM、DTBID。如果输出失败常见原因是打印程序不存在或者输出设备没配。这时候要回到 FBZP 的打印格式节点检查。提示F110 的四个阶段可以分步跑也可以一次性跑完。建议新手分步跑每跑完一步就用 SE16 查对应的底表确认数据落表正确再跑下一步。这样出问题容易定位。5. 自动付款避坑指南五条血泪经验自动付款配置和跑批过程中有些坑是反复踩的。这一章列五条最常见的每条按「现象 → 原因 → 解决」写。5.1 现象F110 跑完没有生成任何付款建议原因最常见的是「下次跑批日期」设错了或者供应商范围没选对或者付款方式没在公司代码层勾选。还有一种可能是未清项的到期日在跑批日期之后系统默认不选中。解决先看 F110 日志日志里会写「选中 0 条」。然后检查三个地方FBZP 公司代码层付款方式是否勾选、供应商主数据付款方式是否匹配、未清项到期日是否小于等于跑批日期。5.2 现象付款建议生成了但付款凭证生成失败原因通常是凭证类型 KZ 的号码范围没维护或者过账期间没打开或者银行账户在银行确定里没配。解决用 OBA7 查 KZ 的号码范围用 OB52 查过账期间用 FBZP 银行确定节点查银行账户。三个都确认无误后再跑一次。5.3 现象银行确定失败日志报「未找到银行确定」原因供应商主数据的银行信息和 FBZP 银行确定的配置不匹配。比如供应商填了银行代码但没填账号或者银行国家填错了。解决用 FK02 打开供应商银行明细逐字段核对。然后回 FBZP 银行确定节点确认排序规则和供应商主数据一致。5.4 现象付款媒介输出为空文件原因FBZP 打印格式节点配的程序不对或者输出设备没配。还有一种可能是付款方式对应的媒介格式和实际输出程序不匹配。解决回 FBZP 打印格式节点确认付款方式对应的打印程序是标准程序。然后用 SE38 直接跑这个程序看能不能输出。如果程序本身没问题检查输出设备SPAD。5.5 现象付款凭证生成了但未清项没被清掉原因付款凭证的过账码或特别总账标识不对导致系统没有把付款和未清项关联起来。常见于使用了自定义过账码的场景。解决用 FB03 查付款凭证看行项目的过账码和特别总账标识。标准配置下供应商借方用 25银行贷方用 50。如果过账码不对回 FBZP 或者 OBYC 检查。6. 进阶技巧用 F110 日志和底表做自动化对账跑通 F110 只是第一步真正在生产环境里你需要一套可重复的对账方法。我一般会做两件事一是把 F110 日志导出来做批量分析二是直接用底表做付款与未清项的匹配。6.1 用 F110 日志定位「静默跳过」的付款F110 日志里有一类信息容易被忽略「未达到最小金额」「付款方式不匹配」「供应商被冻结」。这些付款不会出现在付款建议里但日志里会有记录。我一般会把日志导成 Excel用筛选功能把这些「静默跳过」的记录挑出来逐条确认是配置问题还是数据问题。 用 SE38 跑 RFBABL00 导出 F110 日志 选择条件公司代码、跑批日期、付款方式 输出格式ALV 列表可导出 Excel这段是导出 F110 日志的标准做法。RFBABL00 是 F110 日志的标准报表跑完之后可以导出 ALV 列表然后在 Excel 里做筛选。6.2 用 REGUH REGUP BSEG 做三表联查对账的核心是三表联查REGUH付款建议头、REGUP付款建议行、BSEG付款凭证行。关联字段是付款建议号KEYNO和凭证号BELNR。表关键字段用途REGUHKEYNO, LIFNR, RBETR确认付款建议头和金额REGUPKEYNO, BELNR, DMBTR确认被选中的未清项BSEGBELNR, DMBTR, SHKZG确认付款凭证行和借贷方向联查的逻辑是REGUH 的 KEYNO 关联 REGUP 的 KEYNOREGUP 的 BELNR 关联 BSEG 的 BELNR。这样能确认每一笔付款建议对应的未清项和付款凭证是否一致。6.3 一个我常用的检查习惯每次跑完 F110我不会直接看付款凭证而是先用 SE16 查 REGUH确认付款建议号和金额。然后查 REGUP确认被选中的未清项数量和金额。最后才查 BSEG确认付款凭证的行项目和借贷方向。这个顺序能让我在最早阶段发现配置或数据问题而不是等到凭证生成后才发现金额不对。还有一个习惯每次改完 FBZP 配置先用 FBZP 的检查功能跑一遍再用一个测试供应商跑一次 F110 的付款建议阶段确认建议能生成。这样能在不影响生产数据的前提下验证配置。自动付款这个方向配置一次跑通不难难的是在生产环境里稳定跑、可对账、可追溯。把 FBZP 的五个节点配扎实把测试数据准备到位把 F110 四个阶段的底表搞清楚剩下的就是重复和排查。希望帮到你。本文还有配套的精品资源点击获取
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。