浅谈SAP期末清帐与重分类.docx
《浅谈SAP期末清帐与重分类.docx》由会员分享,可在线阅读,更多相关《浅谈SAP期末清帐与重分类.docx(14页珍藏版)》请在冰豆网上搜索。
浅谈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的未清项对清,金额是8.33HKD,因为清帐的Dr/Cr金额完全相同,于是产生了只有凭证头没有行工程的清帐凭证010*******。
注:
剩余付款产生的新的未清项的基准日期(该日期将计算出到期日,与帐龄分析和催款密切相关),一般是默认从原行项中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时的Exch.Rate是1HKD=0.12000USD,确定应付80USD,折合666.67HKD,假设F-53使用剩余付款方法付出500HKD.
图3-[3]显示的凭证5100000045的两个行工程(AP和GR/IR科目都使用未清项管理)对应的清帐凭证(1500000026是F-53剩余付款500HKD产生的,如图4,凭证100000121那么是自动清帐产生的,如图5).
图4,显示的是F-53剩余付款产生的凭证1500000026,在图3中的localcurrencyamountHKD金额是666.67HKD,Documentcurrencyamount是80USD.
在付款时汇率发生变化,1HKD=0.12900USD,SAP的凭证产生逻辑是付出500HKD,根据此时汇率(0.12900)转成64.50USD,还剩下15.50USD,转HKD为0.12900=120.16HKD.可以看到此时80USD=620.16HKD.
因为图3确定应付80USD,付款应以付清80USD为准.然而,SAP的清帐原那么是:
确保Documentcurrencyamount,localcurrencyamount和groupcurrencyamount(本书是USD,假设你设置了parallelcurrency并使用GroupcurrencyUSD做第2本币的话)三种货币同时平衡.
这样就会产生一汇兑损益行,documentcurrency和groupcurrencyamount都是0,而localcurrencyamount为46.51(根据SAP的清帐逻辑,这种由于汇率变化某一货币金额为0而其中另外某币别的金额不为0情况在MIRO时汇率变化时也经常发生,所以在SAP中,不要以为Documentcurrency为0,localcurrencyamount就一定为0).
汇兑损益科目在OB09或OBA1(KDF)中定义,通常各种AP/ARRecon.科目和GR/IR都要定义对应的汇兑损益科目.
图5显示的是使用F.13(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的应收应付重新分类,比方某客户的应收贷方需要分类到应付帐款或供商的应付借方需要重分类到应收。
某客户的应收贷方需要分类到预付帐款〔最好建立专门的预收帐款科目,原因在此不分析〕。