SAP期末清帐.doc

浅谈sap期末清帐和重分类通常企业都会制定完善的应收应付管理制度,erp应该能提供及时登记往来款项和准确反映应收应付帐款的形成、回收、支付及增减变化情况并按月进行核对与清理的功能。sap提供了强大的应收应付管理,简单列举几个其应收应付功能:(1).购销合同中明确各项条款应收应付从购销单据开始就可明确各种条款,通常,顾问们会倾向于使用采购/销售文本(请参考相关篇幅)功能来定义各种条款,这些条款被写入采购订单或销售订单主数据, 主要包括付款方式、付款日期、运输情况、包装方式、送货期限甚至违约违约责任, 这些条款将随采购订单或销售单据被打印或被传真并形成法律效应,sap提供了output message来完成打印或传真功能,可以将来发生争端时根据寻求诉讼保全。(2).双方往来对帐 一个公平竞争的市场环境下整个企业链应该是双盈的,在sap财务模块提供了阶梯式的往来通信功能,包括:a. 信函功能(correspondence)典型的信函有支付通知(payment notifications) 、对帐单(account statements) 、 余额确定单(balance confirmations)等, 支付通知实际上也包括到期需要付给人家的款项,应收过大容易形成坏帐,应付过大也容易造成资不抵债高负债运营。 b自动支付（tcode：f110） sap提供了自动支付功能，可以自动找到到期的应付形成付款，当然企业可以根据其支付计划进行一定调整，按照国外习惯,到期即需付款,延期的应收和应付需要计息,而按国内实情,显然自动付款实现不大现实。c.催款(dunning,tcode:f150) 相对普通信函而言,催款更加正式,sap提供了多级催款,甚至在催款时可以计算利息,当然催款也包括企业的应付帐款的催款(自催)。（3）.制定激励政策sap对商业折扣,现金折扣,销售返利等业务提供了相应处理方案。(4).评估和信用机制sap有供应商评估和完善客户信用控制功能。国内erp管象预付冲应付、预收冲应收等业务处理叫核销，sap管这些业务叫结帐/清帐，清帐一般包括平时手工清帐和月末自动清帐两种方式。手工清帐相关tcode:(1).f-03/ fb1s:手工清g/l account未清项（针对使用了未清项管理的一般总帐科目）(2).f-44/ fb1k:手工清vendor未清项（各供应商的应付未清项清帐）(3).f-32/ fb1d:手工清customer未清项（各客户应收未清项清帐）(4).f-04:g/l account的带清帐的过帐(5).f-51:vendor的带清帐的过帐(6).f-30:customer的带清帐的过帐f-04,f-51,f-30这些tcode初始屏幕显示的默认凭证类型不同而已,可以使用obu1设置，使用这些tcode在平时记帐时就可清帐。sap中的应收应付模块和总帐集成设计简洁，如下：第一步：应收应付/预收预付/其它应收其他应付被设置成为统驭科目，这些科目或被设置到供应商/客户主数据或被设置为特殊总帐标志，在记帐时是直接输入供应商/客户（或+特殊总帐标志）自动带出的，而国内传统做法是记帐时输入应收应付/预收预付/其它应收其他应付这些科目再将供应商/客户作为辅助核算字段。 显然，sap不大可能会出现应收应付和gl不匹配的业务场景。第二步：sap提供了一套表来记录供应商/客户已清项（cleared items）和未清项（open items），典型的table： bsis/bsas | bsik/bsak | bsid/bsad。平时实际上就可使用f-44或f-32及时清帐，比如将某供应商的一笔预付去清某笔应付，而不需等到月底凑热闹统一去做。在本书的相关章节，曾论证了sap应付帐款未清行项中为什么没有带采购订单号 + 利润中心，实际上供应商的一笔预付可能是针对某采购订单的应付未清项，此时sap没有提供默认解决方案，原因是sap供应商发票校验时可能根据多个采购订单集中校验，这些采购订单可能采购了多个利润中心的多个物料，汇总的一笔应付无法钩稽到采购订单 + 利润中心，而在有些企业的实务中可能应付是唯一对应到一采购订单和利润中心的，在这种情况下，如果需要加强清帐功能，可以考虑使用sap的凭证增强功能写入采购订单和利润中心。除了手工清帐，sap还提供了自动清帐功能。自动清帐相关tcode:(1)f.13:不带清帐货币（针对未清项管理的总帐应收应付和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的自动清帐规则是采购订单和采购订单行项目，实际上，在运行f13自动清帐时则会将收货时产生的gr/ir贷方和发票校验时产生的gr/ir借方自动根据采购单和行项目清帐。gr/ir科目的自动清帐sap默认设置使用zuonr分配字段做清帐条件,意思是说如果一群open items碰在一起,只要assignment字段相同,且满足total debit amout = total credit amount,他们就两清了。现在来说说gr/ir, 举一个bt点的例子，假设某采购订单的一行项目对应的物料采购数量为100 pc,migo收货3次, 数量为30/30/40, 则gr/ir记录在贷方3次, 而假设供应商送了两次发票,发票校验miro时为 50/50, gr/ir记录在借方2次, 假设分配字段zuonr字段记录po+po item, 运行自动清帐f.13时3个贷方和2个借方就自动对清。排序码（tcode：ob16）排序码可以分配到会计科目主数据、供应商和客户的主数据中，排序码最多可由4个字段组成，比如排序码010则对应采购订单+采购行项目，这样在记帐时如果科目使用了该排序码，分配字段将被写入采购凭证+采购行项目。从某种意义上来讲，除了用清帐外，分配字段还类似一个可由用户灵活自定义的保存辅助信息的字段。应收应付自动清帐困惑gr/ir和采购订单+行项目是一一对应的，即其每个行项目必定能带上采购订单和行项目，这是sap的设计特点，gr/ir作为中间科目，在收货和发票环节实际上余额（包括凭证货币、本位币和附加本位币）必定平衡。可应收应付就不那么容易了，以应付为例,和gr/ir不同的是,因为后勤发票校验时是多个采购订单或一个采购订单多个行项目，所以它不大可对应到采购订单+行项目，应收也同样，所以，应收应付使用好自动清帐是不容易的，不过，财务如果连付钱和收钱都懒的去做好而等着系统自动做的话，你老板又怎么可能放心呢？什么科目需使用未清项管理?需要清帐的会计科目在建立时(tcode：fs00)需在“控制数据” tab页必须选上“未清项管理”标志, 首先进行未清项管理的科目必须是bs科目, 通常包括有银行清帐科目| 现金折扣清帐科目| gr/ir和 类gr/ir即应计的运输费,保险费,报关费等应计的采购附加费用科目等，而象应收应付预收预付等各种统驭科目默认必须进行未清项管理，因此这些统驭科目本身不能打上“未清项管理”标志。使用未清项管理的相关科目的业务数据将被分成为已清项和未清项两类。清帐图例实解可以使用tcode fbl3n/fbl1n/fbl5n来查看各种未清项。如图1,展示的是fbl3n查看某供应商应付帐款未清项的一个截图。图1-1-2:两个重要的行项目status标志和due date(注：gr/ir只有未清项标志, gr/ir科目本身无所谓的到期概念)。due date是表示该应收应付是否已经到期,它是根据未清行项目的基限日期(baseline date)和ome2定义的付款条件的日期计算而来。图1-4:你必须在layout选上“cleared/open items symbol”和“net due date symbol”两个字段，才会出现图1-1-2的两个标志, 你还可选择“net due date”和“arrears after net due date” 对未清行项目分析,这样对该单个供应商所有未清项的帐龄直接就有非常清晰的了解。借贷方金额相同的清帐实例图2显示的一个f-44清vendor未清项的一个实例,选择document number 5100000052和5100000051的未清项对清,金额是8.33hkd,因为清帐的dr/cr金额完全相同,于是产生了只有凭证头没有行项目的清帐凭证0100000228。注：剩余付款产生的新的未清项的基准日期(该日期将计算出到期日，与帐龄分析和催款密切相关),一般是默认从原行项中copy过来,当然可按实际需求更改baseline date，比如你和供应商或客户和你约定部分付款后剩余部分到期日往后延迟一段时间。如果在收付款时剩余部分不能从原行项目带出支付条件和基线日期，则需要检查配置tcode：oba3。收付款的部分和剩余清帐无论是部分还是剩余收付款(收款:f-28,付款:f-53),以付款为例,当本次付款金额恰好等于选择的行项目金额和,当然行项目自动变成已清项.假设某vendor的一笔10000 rmb的未清项(凭证号假设是5100000063,类型一般是re/kr,re由liv miro而来,kr通常是手工记帐),本次付9000.如果采用部分付款时通常会产生一kz的付款凭证,原来的5100000063依旧是未清项.本次付款产生的付款凭证如下:dr:应付(某vendor) 9000 hkd cr:银行存款 9000 hkd其中产生的应付借项也是未清项(注意该付款凭证的贷方行项目是银行存款没有所谓的未清项),金额是9000hkd.如果采用剩余付款,则5100000063会变成已清项,同时产生一新的未清项凭证如下:dr: 应付(某vendor) 10000 hkd (5100000063成已清项清帐凭证为该次付款凭证) cr: 应付(某vendor) 1000 hkd(未清) 银行存款 9000 hkd最后剩下的是贷方1000hkd成为新的未清项,原来的凭证5100000063则成已清项,新的未清项的baseline date自动为5100000063的baseline date,除非你手工更改它,这也很合理.注意清帐日期和部分内清帐带来的麻烦。使用不同货币的清帐图3是一个实际付款的例子,凭证5100000045是miro进行liv产生的凭证(类型re). company code 5100的本位币是hkd,po currency是usd,miro时的exch. rate是1hkd=0.12000usd,确定应付80usd,折合666.67 hkd,假设f-53使用剩余付款方法付出500hkd.图3-3显示的凭证5100000045的两个行项目(ap和gr/ir科目都使用未清项管理)对应的清帐凭证(1500000026是f-53剩余付款500hkd产生的,如图4, 凭证100000121则是f.13自动清帐产生的,如图5).图4,显示的是f-53剩余付款产生的凭证1500000026,在图3中的local currency amount hkd金额是666.67hkd,document currency amount是80usd. 在付款时汇率发生变化,1hkd=0.12900usd,sap的凭证产生逻辑是付出500hkd,根据此时汇率(0.12900)转成64.50usd,还剩下15.50usd,转hkd为15.50/0.12900= 120.16hkd.可以看到此时80usd=620.16hkd.因为图3确定应付80usd,付款应以付清80usd为准.然而,sap的清帐原则是:确保document currency amount,local currency amount和group currency amount(本书是usd,假设你设置了parallel currency并使用group currency usd做第2本币的话)三种货币同时平衡.这样就会产生一汇兑损益行,document currency和group currency amount都是0,而local currency amount为46.51(根据sap的清帐逻辑,这种由于汇率变化某一货币金额为0而其中另外某币别的金额不为0情况在miro时汇率变化时也经常发生,所以在sap中,不要以为document currency为0,local currency amount就一定为0). 汇兑损益科目在ob09或oba1(kdf)中定义,通常各种ap/ar recon.科目和gr/ir都要定义对应的汇兑损益科目.图5显示的是使用f.13(se38:sapf124)自动清gr/ir的结果,实际上一般会将migo收货产生的贷方gr/ir和miro gr/ir借方金额根据