简介本资源面向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再到你迟早要查的底表月底跑付款提案FBZP里配置看着都对F110一执行该付的供应商没付不该付的反而被选中。这种翻车现场做SAP FICO的多少都遇到过。自动付款这条链路配置在FBZP执行在F110中间还夹着供应商主数据、银行主数据、付款条件、例外清单任何一个环节对不上结果就是玄学。更麻烦的是F110跑完之后你想查一笔款为什么被选中、为什么被跳过光看前台日志根本不够必须下探到底表。这篇就把FBZP配置、F110测试数据准备、底表存储这三块串起来讲清楚让你下次跑付款时心里有底出了问题知道去哪张表捞数据。2. FBZP配置拆解付款程序、银行确定与例外规则的联动逻辑FBZP是自动付款的配置入口事务码进去之后左边一列配置节点看着不多但每个节点背后都牵着底表。很多人配置完就跑F110结果付款方式不对、银行账户选错、例外清单没生效回头再查发现是某个节点没维护完整。这一章把FBZP里最关键的几个配置节点拆开说清楚每个节点控制什么、影响哪张底表、F110执行时怎么读取。2.1 付款程序配置付款方式、国家与货币的三角关系付款程序是FBZP里第一个要配的东西。路径是「付款程序的配置」→「付款方式/国家」。这里定义的是哪个国家、哪种付款方式比如T电汇、C支票、对应哪个付款程序。付款程序本身是一段ABAP程序标准的有RFFOD__S、RFFOD__V等分别对应不同的付款媒介。配置的时候每个国家至少要维护一条记录付款方式可以多条。关键字段是「付款方式」和「付款程序」。付款方式来自供应商主数据里的付款条件付款程序决定F110用哪个程序生成付款媒介。这里有个容易忽略的点付款方式在供应商主数据里是挂在公司代码层面的。如果你在FBZP里配了T电汇对应RFFOD__S但供应商主数据里付款方式填的是C那F110跑的时候就会按C去找对应的付款程序找不到就报错或者跳过。底表方面这个配置主要存在T042Z和T042E里。T042Z存的是付款方式的国家分配T042E存的是付款程序的公司代码分配。查配置有没有生效直接SE16看这两张表最快。 查付款方式与国家分配 SELECT * FROM t042z INTO TABLE DATA(lt_t042z) WHERE land1 lv_country AND zwels IN lr_payment_methods. 查付款程序与公司代码分配 SELECT * FROM t042e INTO TABLE DATA(lt_t042e) WHERE bukrs lv_bukrs.上面这段查询第一段从T042Z捞指定国家下所有付款方式的配置第二段从T042E捞指定公司代码下的付款程序分配。实际排查时先确认T042Z里有没有你用的付款方式再看T042E里对应的付款程序是不是你预期的那个。如果T042E里没有记录F110执行时会直接报「付款程序未找到」。参数说明lv_country是国家代码比如CNlr_payment_methods是付款方式范围比如T到Tlv_bukrs是公司代码。查的时候注意T042E的键是公司代码加付款方式不是只按公司代码。2.2 银行确定配置供应商银行、公司银行与排序规则的优先级银行确定是FBZP里最容易出问题的一块。F110执行时需要知道两件事付款从哪个公司银行账户出收款到供应商哪个银行账户。这两个信息分别来自公司代码的银行确定配置和供应商主数据的银行信息。FBZP里「银行确定」节点下有两个子节点「公司代码的银行确定」和「供应商的银行确定」。公司代码的银行确定决定付款时用哪个银行账户、哪种付款方式。供应商的银行确定决定收款方用哪个银行账户。配置逻辑是这样的F110先根据公司代码、付款方式、货币、金额等因素从公司代码的银行确定配置里选出一个「付款银行账户」。然后根据供应商主数据里的银行信息选出「收款银行账户」。如果供应商有多个银行账户还要看排序规则。排序规则在供应商主数据的银行信息里维护有个「排序」字段。F110会按排序顺序依次尝试直到找到一个可用的银行账户。如果所有银行账户都不可用这笔付款就会被跳过。底表方面公司代码的银行确定存在T042I里供应商银行信息存在LFBK里。T042I的键是公司代码、付款方式、货币、银行账户等。LFBK的键是供应商加银行国家加银行账户。 查公司代码银行确定配置 SELECT * FROM t042i INTO TABLE DATA(lt_t042i) WHERE bukrs lv_bukrs AND zwels lv_payment_method AND waers lv_currency. 查供应商银行信息 SELECT * FROM lfbk INTO TABLE DATA(lt_lfbk) WHERE lifnr lv_vendor.第一段从T042I捞公司代码下指定付款方式和货币的银行确定配置。如果这里查不到记录F110会报「银行确定失败」。第二段从LFBK捞供应商的所有银行账户按排序字段排序后F110会依次尝试。参数说明lv_payment_method是付款方式比如Tlv_currency是货币比如CNY。注意T042I里可能有多条记录F110会按优先级选一条优先级跟配置顺序有关。LFBK里的排序字段是BVTYP值越小优先级越高。2.3 例外清单配置为什么你的付款被跳过例外清单是F110里控制哪些供应商、哪些付款方式不参与自动付款的配置。FBZP里「例外清单」节点下可以按公司代码、供应商、付款方式等维度维护例外规则。比如某个供应商因为质量问题被冻结付款就可以在这里加一条例外F110跑的时候就会跳过这个供应商。例外清单的配置存在T042V和T042W里。T042V存的是例外清单的抬头T042W存的是例外清单的行项目。F110执行时会先读例外清单把符合条件的供应商或付款方式排除掉。这里有个坑例外清单的优先级很高一旦命中F110不会再去检查其他条件。所以如果你发现某个供应商明明配置都正确但F110就是跳过第一件事就是查例外清单。 查例外清单抬头 SELECT * FROM t042v INTO TABLE DATA(lt_t042v) WHERE bukrs lv_bukrs. 查例外清单行项目 SELECT * FROM t042w INTO TABLE DATA(lt_t042w) FOR ALL ENTRIES IN lt_t042v WHERE ausbk lt_t042v-ausbk.第一段从T042V捞公司代码下的例外清单抬头第二段根据抬头捞行项目。实际排查时先看T042V里有没有记录再看T042W里有没有你那个供应商。参数说明ausbk是例外清单的标识T042V和T042W通过这个字段关联。T042W里还有供应商、付款方式等字段可以精确到具体供应商。3. F110测试数据准备供应商主数据、银行信息与未清项构造配置检查完下一步就是准备测试数据。F110跑付款提案依赖的是供应商未清项。没有未清项F110跑出来就是空的。所以测试数据准备的核心是造供应商、造银行信息、造未清项。这一章按顺序讲怎么造每步给代码或事务码。3.1 供应商主数据创建FK01里必须填对的几个字段创建供应商用FK01或者用BAPI_VENDOR_CREATE。手工创建的话重点填这几个字段公司代码层面的付款条件、付款方式、银行信息。付款条件在「公司代码」视图里字段是ZTERM。付款方式在「付款交易」视图里字段是ZWELS。银行信息在「银行信息」视图里字段是BANKL、BANKN、BKONT。付款条件决定付款的基准日期和天数F110会根据付款条件算到期日。付款方式决定用哪个付款程序。银行信息决定收款账户。如果测试的是自动付款付款条件建议设成0001立即付款或者000230天方便控制到期日。付款方式设成T电汇银行信息随便填一个有效的银行账号。 用BAPI创建供应商 DATA: ls_vendor TYPE bapivendor, lt_bank TYPE TABLE OF bapivendor_bank, lt_return TYPE TABLE OF bapiret2. ls_vendor-lifnr TEST001. ls_vendor-name1 测试供应商. ls_vendor-land1 CN. ls_vendor-ktokk 0001. 公司代码数据 ls_vendor-bukrs 1000. ls_vendor-zterm 0001. ls_vendor-zwels T. 银行数据 APPEND INITIAL LINE TO lt_bank ASSIGNING FIELD-SYMBOL(fs_bank). fs_bank-bankl ICBC. fs_bank-bankn 123456789012345678. fs_bank-bkont 0001. CALL FUNCTION BAPI_VENDOR_CREATE EXPORTING vendorgeneral ls_vendor TABLES vendorbank lt_bank return lt_return.这段代码用BAPI_VENDOR_CREATE创建供应商同时维护公司代码数据和银行数据。关键参数lifnr是供应商编号bukrs是公司代码zterm是付款条件zwels是付款方式bankl是银行代码bankn是银行账号。执行完记得提交事务BAPI不会自动提交。如果返回表里有E类型消息根据消息号排查。常见错误是供应商编号已存在、银行代码无效、付款条件未维护。3.2 未清项构造FB01与F-43的选择有了供应商下一步是造未清项。造未清项用FB01或者F-43。FB01是通用凭证录入F-43是供应商发票录入。测试自动付款建议用F-43因为F-43直接生成供应商未清项而且可以带付款条件。F-43录入时重点填供应商、金额、付款条件、基准日期。基准日期决定付款到期日。付款条件从供应商主数据带出来也可以手工改。录入完成后用FBL1N查供应商未清项确认凭证已经生成。如果FBL1N里看不到检查凭证是否过账、供应商是否对、公司代码是否对。 用BAPI_INCOMINGINVOICE_CREATE造供应商发票 DATA: ls_header TYPE bapi_incinv_create_header, lt_item TYPE TABLE OF bapi_incinv_create_item, lt_return TYPE TABLE OF bapiret2. ls_header-invoicedocdate sy-datum. ls_header-postingdate sy-datum. ls_header-docdate sy-datum. ls_header-comp_code 1000. ls_header-vendor_no TEST001. ls_header-currency CNY. ls_header-pmnttrms 0001. ls_header-bline_date sy-datum. APPEND INITIAL LINE TO lt_item ASSIGNING FIELD-SYMBOL(fs_item). fs_item-invoice_doc_item 000001. fs_item-po_number . fs_item-item_amount 1000.00. fs_item-item_text 测试发票. fs_item-gl_account 66020001. CALL FUNCTION BAPI_INCOMINGINVOICE_CREATE EXPORTING headerdata ls_header TABLES itemdata lt_item return lt_return.这段代码用BAPI_INCOMINGINVOICE_CREATE造供应商发票。关键参数comp_code是公司代码vendor_no是供应商pmnttrms是付款条件bline_date是基准日期item_amount是金额gl_account是总账科目。执行完同样要提交事务。如果返回E类型消息常见原因是供应商不存在、总账科目不存在、付款条件未维护、金额格式不对。3.3 付款提案测试F110参数设置与模拟运行数据准备好就可以跑F110了。F110的参数设置分几步输入参数、状态、日志。输入参数里重点填公司代码、付款方式、付款日期、供应商范围。付款日期决定F110选哪些未清项。F110会选到期日小于等于付款日期的未清项。所以如果你造的数据到期日是未来F110跑出来就是空的。模拟运行和正式运行的区别模拟运行不生成付款凭证只生成提案日志。正式运行会生成付款凭证和付款媒介。测试阶段建议先跑模拟确认提案结果对了再跑正式。 F110参数设置示例 事务码F110输入参数 公司代码1000 付款方式T 付款日期20250101 供应商TEST001 下一步状态选中所有供应商 再下一步日志选中详细日志 最后模拟运行F110跑完之后看日志。日志里会列出每笔未清项的状态选中、跳过、错误。如果选中了说明配置和数据都对。如果跳过了看跳过原因。常见原因付款方式不匹配、银行确定失败、例外清单命中、金额为零。4. 底表存储F110执行后数据落在哪几张表F110跑完数据落在哪这是排查问题的关键。F110执行过程中会读写多张底表。这一章把最关键的几张表列出来说清楚每张表存什么、怎么查。4.1 REGUH与REGUH付款提案的抬头与行项目REGUH和REGUH是F110生成的核心表。REGUH存付款提案的抬头REGUH存行项目。等等这里写错了应该是REGUH和REGP。REGUH是抬头REGP是行项目。REGUH的键是LIFNR供应商、BUKRS公司代码、BELNR凭证号等。REGP的键是LIFNR、BUKRS、BELNR、BUZEI行号。F110跑完模拟运行数据就存在这两张表里。正式运行后数据会转移到其他表但REGUH和REGP里仍然保留记录。 查付款提案抬头 SELECT * FROM reguh INTO TABLE DATA(lt_reguh) WHERE bukrs lv_bukrs AND lifnr lv_vendor. 查付款提案行项目 SELECT * FROM regup INTO TABLE DATA(lt_regup) WHERE bukrs lv_bukrs AND lifnr lv_vendor.第一段从REGUH捞付款提案抬头第二段从REGP捞行项目。实际排查时先看REGUH里有没有记录再看REGP里有没有对应的行项目。参数说明lv_bukrs是公司代码lv_vendor是供应商。REGUH和REGP通过BELNR关联。4.2 PAYR与PAYR付款凭证的存储正式运行F110后会生成付款凭证。付款凭证存在PAYR和PAYR里。等等又写错了应该是PAYR和PAYP。PAYR是付款凭证抬头PAYP是行项目。PAYR的键是ZBUKR付款公司代码、LIFNR供应商、BELNR凭证号等。PAYP的键是ZBUKR、LIFNR、BELNR、BUZEI。查付款凭证用FBL1N或者FB03。FBL1N查供应商未清项和已清项FB03查凭证本身。 查付款凭证抬头 SELECT * FROM payr INTO TABLE DATA(lt_payr) WHERE zbukr lv_bukrs AND lifnr lv_vendor. 查付款凭证行项目 SELECT * FROM payp INTO TABLE DATA(lt_payp) WHERE zbukr lv_bukrs AND lifnr lv_vendor.第一段从PAYR捞付款凭证抬头第二段从PAYP捞行项目。PAYR和PAYP通过BELNR关联。参数说明lv_bukrs是付款公司代码lv_vendor是供应商。注意PAYR的键是ZBUKR不是BUKRS因为付款公司代码可能和供应商公司代码不同。4.3 其他相关底表T042系列与LFBK除了REGUH、REGP、PAYR、PAYP还有几张表在排查时经常用到。T042Z存付款方式与国家分配T042E存付款程序与公司代码分配T042I存公司代码银行确定T042V和T042W存例外清单LFBK存供应商银行信息。这些表在第二章已经提过这里再列一下方便排查时快速定位。表名存什么关键字段T042Z付款方式与国家分配LAND1, ZWELST042E付款程序与公司代码分配BUKRS, ZWELST042I公司代码银行确定BUKRS, ZWELS, WAERST042V例外清单抬头BUKRS, AUSBKT042W例外清单行项目AUSBK, LIFNRLFBK供应商银行信息LIFNR, BANKL, BANKNREGUH付款提案抬头LIFNR, BUKRS, BELNRREGP付款提案行项目LIFNR, BUKRS, BELNR, BUZEIPAYR付款凭证抬头ZBUKR, LIFNR, BELNRPAYP付款凭证行项目ZBUKR, LIFNR, BELNR, BUZEI排查的时候按这个顺序查先查T042系列确认配置再查LFBK确认银行信息再查REGUH和REGP确认提案最后查PAYR和PAYP确认付款凭证。5. 避坑与排查F110跑不出结果的5个血泪教训F110跑不出结果原因五花八门。这一章列5个最常见的坑每个坑按「现象→原因→解决」写都是实际项目里踩过的。5.1 现象F110日志显示「未找到未清项」原因付款日期设置不对或者供应商没有未清项或者未清项到期日大于付款日期。解决先用FBL1N查供应商未清项确认有未清项。再看未清项的到期日如果到期日大于付款日期F110不会选中。调整付款日期或者调整未清项的基准日期。5.2 现象F110日志显示「银行确定失败」原因公司代码银行确定配置缺失或者供应商银行信息缺失或者银行账户无效。解决先查T042I确认公司代码下指定付款方式和货币的银行确定配置存在。再查LFBK确认供应商银行信息存在且银行账户有效。如果T042I里没有记录去FBZP里补配。5.3 现象F110日志显示「例外清单命中」原因供应商或付款方式在例外清单里。解决查T042V和T042W确认供应商是否在例外清单里。如果在要么从例外清单里移除要么换一个供应商测试。5.4 现象F110跑完REGUH里有记录但REGP里没有原因付款提案抬头生成了但行项目没生成。通常是金额为零或者付款方式不匹配。解决查REGUH里的记录看金额和付款方式。如果金额为零检查未清项金额。如果付款方式不匹配检查供应商主数据里的付款方式和FBZP里的配置。5.5 现象F110正式运行后PAYR里没有记录原因正式运行没跑成功或者付款凭证被冲销了。解决先看F110日志确认正式运行是否成功。如果成功但PAYR里没有查FB03看凭证是否被冲销。如果被冲销查冲销原因。6. 进阶技巧用F110 BADI增强和底表关联查询定位疑难付款F110的标准逻辑覆盖大部分场景但有些特殊需求比如按自定义规则选付款方式、按自定义规则排序银行账户标准逻辑搞不定这时候就要用BADI增强。F110相关的BADI主要有两个F110_PAYMENT_METHOD和F110_BANK_SELECTION。前者控制付款方式选择后者控制银行账户选择。实现BADI的步骤SE18查BADI定义SE19创建实现在实现里写ABAP代码。代码里可以读自定义表、调外部接口、按复杂规则计算。 F110_PAYMENT_METHOD BADI实现示例 METHOD if_ex_f110_payment_method~change_payment_method. 读自定义表按供应商分组调整付款方式 SELECT SINGLE zwels FROM zt_payment_rule INTO DATA(lv_zwels) WHERE lifnr is_reguh-lifnr AND bukrs is_reguh-bukrs. IF sy-subrc 0. cs_reguh-zwels lv_zwels. ENDIF. ENDMETHOD.这段代码在BADI实现里根据供应商和公司代码从自定义表ZT_PAYMENT_RULE里读出自定义的付款方式覆盖标准逻辑选出的付款方式。关键参数is_reguh是付款提案抬头结构cs_reguh是可修改的抬头结构lifnr是供应商bukrs是公司代码。底表关联查询是另一个进阶技巧。F110涉及的表多单表查往往看不出问题需要多表关联。比如查一笔付款为什么被跳过可以关联REGUH、REGP、T042I、LFBK看每个环节的数据。 关联查询查付款提案及银行确定 SELECT a~lifnr, a~bukrs, a~belnr, b~buzei, b~betrg, c~bankl, c~bankn, d~bankl AS vendor_bankl, d~bankn AS vendor_bankn FROM reguh AS a INNER JOIN regup AS b ON a~lifnr b~lifnr AND a~bukrs b~bukrs AND a~belnr b~belnr LEFT JOIN t042i AS c ON a~bukrs c~bukrs AND a~zwels c~zwels LEFT JOIN lfbk AS d ON a~lifnr d~lifnr INTO TABLE DATA(lt_result) WHERE a~bukrs lv_bukrs AND a~lifnr lv_vendor.这段查询把REGUH、REGP、T042I、LFBK四张表关联起来一次查出付款提案、行项目、公司银行账户、供应商银行账户。关键参数lv_bukrs是公司代码lv_vendor是供应商。关联条件里REGUH和REGP通过供应商、公司代码、凭证号关联T042I通过公司代码和付款方式关联LFBK通过供应商关联。我自己的习惯是每次F110跑完先不看日志直接跑一遍这个关联查询。数据都在一张结果表里哪个环节缺数据一目了然。这个习惯帮我省了很多来回查表的时间。希望帮到你。本文还有配套的精品资源点击获取