（sap实施）浅谈 SAP期末
清帐和重分类
浅谈 SAP 期末清帐和重分类
通常企业都会制定完善的应收应付管理制度,ERP应该能提供及时登记往来款项和准确反映
应收应付帐款的形成、回收、支付及增减变化情况并按月进行核对与清理的功能。
SAP提供了强大的应收应付管理,简单列举几个其应收应付功能:
(1).购销合同中明确各项条款
应收应付从购销单据开始就可明确各种条款,通常,顾问们会倾向于使用采购/销售文本(请
参考相关篇幅)功能来定义各种条款,这些条款被写入采购订单或销售订单主数据,主要包括
付款方式、付款日期、运输情况、包装方式、送货期限甚至违约违约责任,这些条款将随采
购订单或销售单据被打印或被传真并形成法律效应,SAP提供了 OutputMessage来完成打印
或传真功能,可以将来发生争端时根据寻求诉讼保全。
(2).双方往来对帐
一个公平竞争的市场环境下整个企业链应该是双盈的,在 SAP财务模块提供了阶梯式的往来
通信功能,包括:
a. 信函功能(Correspondence)
典型的信函有支付通知(Paymentnotifications)、对帐单(Accountstatements)、
余额确定单(Balanceconfirmations)等,支付通知实际上也包括到期需要付给人家的款
项,应收过大容易形成坏帐,应付过大也容易造成资不抵债高负债运营。
b．自动支付（Tcode：F110）
SAP提供了自动支付功能，可以自动找到到期的应付形成付款，当然企业可以根据其支付计
划进行一定调整，按照国外习惯,到期即需付款,延期的应收和应付需要计息,而按国内
实情,显然自动付款实现不大现实。
c.催款(Dunning,Tcode:F150)
相对普通信函而言,催款更加正式,SAP提供了多级催款,甚至在催款时可以计算利息,当
然催款也包括企业的应付帐款的催款(自催)。
（3）.制定激励政策
SAP对商业折扣,现金折扣,销售返利等业务提供了相应处理方案。
(4).评估和信用机制
SAP有供应商评估和完善客户信用控制功能。
国内 ERP管象预付冲应付、预收冲应收等业务处理叫核销，SAP管这些业务叫结帐/清帐，清
帐一般包括平时手工清帐和月末自动清帐两种方式。
手工清帐相关 Tcode:
(1).F-03/FB1S:手工清 G/Laccount未清项（针对使用了未清项管理的一般总帐科目）
(2).F-44/FB1K:手工清 Vendor未清项（各供应商的应付未清项清帐）
(3).F-32/FB1D:手工清 Customer未清项（各客户应收未清项清帐）
(4).F-04:G/Laccount的带清帐的过帐
(5).F-51:Vendor的带清帐的过帐
(6).F-30:Customer的带清帐的过帐
F-04,F-51,F-30这些 Tcode初始屏幕显示的默认凭证类型不同而已,可以使用 OBU1设置，使
用这些 Tcode在平时记帐时就可清帐。
SAP中的应收应付模块和总帐集成设计简洁，如下：
第一步：应收应付/预收预付/其它应收其他应付被设置成为统驭科目，这些科目或被设置到
供应商/客户主数据或被设置为特殊总帐标志，在记帐时是直接输入供应商/客户（或
+特殊总帐标志）自动带出的，而国内传统做法是记帐时输入应收应付/预收预付/
其它应收其他应付这些科目再将供应商/客户作为辅助核算字段。
显然，SAP不大可能会出现应收应付和 GL不匹配的业务场景。
第二步：SAP提供了一套表来记录供应商/客户已清项（ClearedItems）和未清项（OpenItems），
典型的 Table：BSIS/BSAS|BSIK/BSAK|BSID/BSAD。
平时实际上就可使用 F-44或 F-32及时清帐，比如将某供应商的一笔预付去清某笔应付，而
不需等到月底凑热闹统一去做。在本书的相关章节，曾论证了 SAP应付帐款未清行项中为什
么没有带采购订单号+利润中心，实际上供应商的一笔预付可能是针对某采购订单的应付未
清项，此时 SAP没有提供默认解决方案，原因是 SAP供应商发票校验时可能根据多个采购订
单集中校验，这些采购订单可能采购了多个利润中心的多个物料，汇总的一笔应付无法钩稽
到采购订单+利润中心，而在有些企业的实务中可能应付是唯一对应到一采购订单和利润中
心的，在这种情况下，如果需要加强清帐功能，可以考虑使用 SAP的凭证增强功能写入采购
订单和利润中心。
除了手工清帐，SAP还提供了自动清帐功能。
自动清帐相关 Tcode:
(1):不带清帐货币（针对未清项管理的总帐应收应付和 GR/IR科目自动清帐）
(2)F13E:带清帐货币的自动清帐
手工/自帐清帐规则
A．无论手工清帐还是自动清帐，相关科目一定要需设置未清项管理。
B．使用手工清帐,科目主数据“创建/银行/利息”屏的的自动过帐标致不能选上。
C．自动清帐可以针对应收应付和特殊总帐标置的预收预付其它应收其它应付间进行,
注意：A和 W默认的特殊总帐标志不能进行自动清账处理。
自动清帐还包括进行未清项管理的一般总帐科目,特别强调一下 GR/IR科目的自动清帐。
D．自动清账通常根据借方贷方金额相同，和辅助条件字段如采购订单+采购行项目或分配字
段相同项目归类清帐，典型的如 GR/IR科目，清帐字段是可配置的。
E．自动清帐也可在满足清帐条件的多个借贷项进行处理。
F．自动清账适用于银行待清账户的处理（比如实施了电子银行的的电子对帐单），由于手动
清账的灵活性，多数情况下，企业还是愿意采用这种方式，特别是清帐时需要人为职业
判断的情况下，不准确自动清帐有时还会造成帐龄分析问题。
下图为清帐的配置路径，清帐配置包括定义清帐过帐码、清帐规则和自动清帐的附加规则。
自动清帐规则（Tcode：OB74）
自动清帐规则默认可以根据分配号进行（BSEG-ZUONR），这个分配号对应到 Tcode：OB16
定义所谓的排序码。
如图-[5]的 GR/IR科目 2121970000的自动清帐规则是采购订单和采购订单行项目，实际上，
在运行 F．13自动清帐时则会将收货时产生的 GR/IR贷方和发票校验时产生的 GR/IR借方自
动根据采购单和行项目清帐。
GR/IR科目的自动清帐
SAP默认设置使用 ZUONR分配字段做清帐条件,意思是说如果一群 openitems碰在一起,只要
assignment字段相同,且满足 TotaldebitAmout=TotalCreditAmount,他们就两清了。
现在来说说 GR/IR,举一个 BT点的例子，假设某采购订单的一行项目对应的物料采购数量为
100PC,MIGO收货 3次,数量为 30/30/40,则 GR/IR记录在贷方 3次,而假设供应商送了两次
发票,发票校验 MIRO时为 50/50,GR/IR记录在借方 2次,假设分配字段 ZUONR字段记录
PO+POitem,运行自动清帐 时 3个贷方和 2个借方就自动对清。
排序码（Tcode：OB16）
排序码可以分配到会计科目主数据、供应商和客户的主数据中，排序码最多可由 4个字段组
成，比如排序码 010则对应采购订单+采购行项目，这样在记帐时如果科目使用了该排序码，
分配字段将被写入采购凭证+采购行项目。
从某种意义上来讲，除了用清帐外，分配字段还类似一个可由用户灵活自定义的保存辅助信
息的字段。
应收应付自动清帐困惑
GR/IR和采购订单+行项目是一一对应的，即其每个行项目必定能带上采购订单和行项目，
这是 SAP的设计特点，GR/IR作为中间科目，在收货和发票环节实际上余额（包括凭证货
币、本位币和附加本位币）必定平衡。可应收应付就不那么容易了，以应付为例,和 GR/IR
不同的是,因为后勤发票校验时是多个采购订单或一个采购订单多个行项目，所以它不大可
对应到采购订单+行项目，应收也同样，所以，应收应付使用好自动清帐是不容易的，不过，
财务如果连付钱和收钱都懒的去做好而等着系统自动做的话，你老板又怎么可能放心呢？
什么科目需使用未清项管理?
需要清帐的会计科目在建立时(Tcode：FS00)需在“控制数据”Tab页必须选上“未清项管理”
标志,首先进行未清项管理的科目必须是 BS科目,通常包括有银行清帐科目|现金折扣清帐科
目|GR/IR和类 GR/IR即应计的运输费,保险费,报关费等应计的采购附加费用科目等，而象应
收应付预收预付等各种统驭科目默认必须进行未清项管理，因此这些统驭科目本身不能打上
“未清项管理”标志。
使用未清项管理的相关科目的业务数据将被分成为已清项和未清项两类。
清帐图例实解
可以使用 TcodeFBL3N/FBL1N/FBL5N来查看各种未清项。
如图 1,展示的是 FBL3N查看某供应商应付帐款未清项的一个截图。
图 1-[1]-[2]:两个重要的行项目 Status标志和 DueDate(注：GR/IR只有未清项标志,GR/IR
科目本身无所谓的到期概念)。
DueDate是表示该应收应付是否已经到期,它是根据未清行项目的基限日期
(Baselinedate)和 OME2定义的付款条件的日期计算而来。
图 1-[4]:你必须在 Layout选上“Cleared/openitemssymbol”和“Netduedatesymbol”两个
字 段 ， 才 会 出 现 图 1-[1]-[2]的 两 个 标 志 ,你 还 可 选 择 “ Netduedate” 和
“Arrearsafternetduedate”对未清行项目分析,这样对该单个供应商所有未清项的
帐龄直接就有非常清晰的了解。
借贷方金额相同的清帐实例
图 2显示的一个 F-44清 Vendor未清项的一个实例,选择 DocumentNumber5100000052和
5100000051的未清项对清,金额是 ,因为清帐的 Dr/Cr金额完全相同,于是产生了只
有凭证头没有行项目的清帐凭证 0100000228。
注：剩余付款产生的新的未清项的基准日期(该日期将计算出到期日，与帐龄分析和催款密
切相关),一般是默认从原行项中 Copy过来,当然可按实际需求更改 baselinedate，比如
你和供应商或客户和你约定部分付款后剩余部分到期日往后延迟一段时间。
如果在收付款时剩余部分不能从原行项目带出支付条件和基线日期，则需要检查配置 Tcode：OBA3。
收付款的部分和剩余清帐
无论是部分还是剩余收付款(收款:F-28,付款:F-53),以付款为例,当本次付款金额恰好等于
选择的行项目金额和,当然行项目自动变成已清项.
假设某 Vendor的一笔 10000RMB的未清项(凭证号假设是 5100000063,类型一般是 RE/KR,RE
由 LIVMIRO而来,KR通常是手工记帐),本次付 9000.
如果采用部分付款时通常会产生一 KZ的付款凭证,原来的 5100000063依旧是未清项.本次付
款产生的付款凭证如下:
Dr:应付(某 vendor)9000HKD
Cr:银行存款 9000HKD
其中产生的应付借项也是未清项(注意该付款凭证的贷方行项目是银行存款没有所谓的未清
项),金额是 9000HKD..
如果采用剩余付款,则 5100000063会变成已清项,同时产生一新的未清项凭证如下:
Dr:应付(某 vendor)10000HKD(5100000063成已清项清帐凭证为该次付款凭证)
Cr:应付(某 vendor)1000HKD(未清)
银行存款 9000HKD
最后剩下的是贷方 1000HKD成为新的未清项,原来的凭证 5100000063则成已清项,新的未清
项的 baselinedate自动为 5100000063的 baselinedate,除非你手工更改它,这也很合理.
注意清帐日期和部分内清帐带来的麻烦。
使用不同货币的清帐
图 3是一个实际付款的例子 ,凭证 5100000045是 MIRO进行 LIV产生的凭证 (类型
RE).companycode5100的 本 位 币 是 HKD,POcurrency是 USD,MIRO时 的 是
1HKD=,确定应付 80USD,折合 ,假设 F-53使用剩余付款方法付出
500HKD.
图 3-[3]显示的凭证 5100000045的两个行项目(AP和 GR/IR科目都使用未清项管理)对应的
清帐凭证(1500000026是 F-53剩余付款 500HKD产生的,如图 4,凭证 100000121则是 自
动清帐产生的,如图 5).
图 4,显示的是 F-53剩余付款产生的凭证 1500000026,在图 3中的 localcurrencyamountHKD
金额是 ,Documentcurrencyamount是 80USD.
在付款时汇率发生变化,1HKD=,SAP的凭证产生逻辑是付出 500HKD,根据此时汇率
()转成 ,还剩下 ,转 HKD为
时 80USD=.
因为图 3确定应付 80USD,付款应以付清 80USD为准.然而,SAP的清帐原则是:
确保 Documentcurrencyamount,localcurrencyamount和 groupcurrencyamount(本书是 USD,
假设你设置了 parallelcurrency并使用 GroupcurrencyUSD做第 2本币的话)三种货币同时
平衡.
这样就会产生一汇兑损益行 ,documentcurrency和 groupcurrencyamount都是 0,而
localcurrencyamount为 (根据 SAP的清帐逻辑,这种由于汇率变化某一货币金额为 0
而其中另外某币别的金额不为 0情况在 MIRO时汇率变化时也经常发生,所以在 SAP中,不要
以为 Documentcurrency为 0,localcurrencyamount就一定为 0).
汇兑损益科目在 OB09或 OBA1(KDF)中定义,通常各种 AP/ARRecon.科目和 GR/IR都要定义对
应的汇兑损益科目.
图 5显示的是使用 (SE38:SAPF124)自动清 GR/IR的结果,实际上一般会将 MIGO收货产生
的贷方 GR/IR和 MIROGR/IR借方金额根据一定规则(详细请参考接下来的自动清帐处理)自动
抵消.
同为供应商和客户的应收应付对清
有时候,企业可能向某家Vendor采购原材料同时又销售商品给这家Vendor,或反之,此时产生
的应收应付就可相互清帐，当然是进项和销项增值税是必须缴纳的。
设置供应商/客户主数据
图 7-[2]： 在 vendor的 control页 的 Accountcontrol的 Customer填 上
Customername80005803。
表示供应商 1000389将对应客户 80005803。
图 8-[2]：在 paymenttransactionaccountings页选上“ClngwithCust.”标志。
图 9和图 10,在 Customer80005803设置对应供应商 1000389和“ClearningwithVendor”标
志。
只要在对应的客户/供应商主数据中设置好后，在处理相应的应收（应付）未清项时就能同
时看到看到相应的应付（应收）未清项。
集团内的公司间清帐（Tcode:OBYA）
1．跨公司代码的记帐，比如
Dr：费用公司代码 A
Cr：应付公司代码 B（B为 A代垫或接受 A的劳务，直接记帐的）
2．总部公司的管理费用分配到各分子公司，跨公司分配，需要配置 OBYA。
应收应付重新分类（Tcode：F101）
Tcode：F101的应收应付重新分类,比如某客户的应收贷方需要分类到应付帐款或供商的应付
借方需要重分类到应收。某客户的应收贷方需要分类到预付帐款（最好建立专门的预收帐款
科目，原因在此不分析）。
