企业官网建设流程全解析

简介：本资源面向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是国家代码，比如CN；lr_payment_methods是付款方式范围，比如T到T；lv_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是付款方式，比如T；lv_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（立即付款）或者0002（30天），方便控制到期日。付款方式设成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存供应商银行信息。

这些表在第二章已经提过，这里再列一下，方便排查时快速定位。

排查的时候，按这个顺序查：先查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跑完，先不看日志，直接跑一遍这个关联查询。数据都在一张结果表里，哪个环节缺数据一目了然。这个习惯帮我省了很多来回查表的时间。希望帮到你。

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