SAP现金管理.doc

第五章 银行会计过去，受管理工具和技术手段的制约，很多集团企业对资金的管理幅度、监控能力和时效性并不尽如人意，资金管理出现如下弊端：1.集团总部监管力度弱,资金运动不透明，违规操作多。2.时效性不足，信息不对称,集团决策者无法实时收集资金信息和掌握集团整体资金状况，造成决策延误，控制失效。3.集团内部资金短缺与闲置并存,在集团整体资金充足的情况下部分下属成员单位由于局部资金短缺仍向商业银行借款的现象，加大了集团整体财务费用的支出等等。近几年来,随着中国银行业电子化服务的飞速发展,各个商业银行都不同程度地建立起自己的网上银行系统,使集团企业跨地域的电子支付、资金集中管理具备了实现的基础.这就为企业集团实现资金集中管理提出了一种新的模式-银企直联模式. 银企直联是指银行与企业之间采用直联方式连接，企业可以在集团内部的财务结算系统中反映银行账户的变化。银企直联方式将进一步加强银行与企业之间的联系，为企业，特别是集团企业的财务结算带来便利并进一步提高企业的工作效率。忽悠大使赵大叔将“忽悠”这词忽悠得全国皆知，忽悠无处不在，Long Time以前，俺曾参加一次管理软件研讨会，一位“著名“管理软件专家神情恍惚语无伦次絮絮叨叨反反复复抛出各种飘渺理论并再三强调要做适合中国国情的管理软件，真乃祥林大嫂再生，唐僧大叔重世也，将俺忽悠的直打瞌睡，口水横流，所以接下来就不忽悠了，在这一章简单介绍下银企直联的设计思路和现金日记帐。图1-1：定义开户银行（House bank）,初,我LP说House bank就是家里面的银行,我对其英文水准大为叹服之余不免忧虑,要是不法分子听到此话止不定要上俺家抢钱。LP笑道:如今世道变了,相公不用担心，这年头只有银行抢咱们钱的份。 更详细请参考本章第一节银企直联和自动付款。图1-2：定义锁箱（LockBox），在美国，企业可以通过锁箱帐号处理支付业务，支付被自动记帐而未清项目则被结算。锁箱被分配到客户和供应商主数据。图1-3：票据市场是货币市场的重要组成部分，是主要从事短期交易或融资业务的场所，作为货币市场的重要组成部分，主要包括商业票据（commercial paper）和银行承兑汇票（bankers acceptances）。目前国内企业信用还不完善，处于商业风险考虑，有些企业拒收商业票据，并且国内票据时间较短，只有3-6个月，不象发达国家可能有数年的票据，因此，带息票据也是在票据贴现时将利息一次计入财务费用，所以，直接使用F-33|F-36|F-40等Tcode手工处理应收应付票据就Ok，这里也就不用过多讨论。图1-4：现金日记帐配置和操作请参考本章第二节现金日记帐。第一节 银企直联和自动付款相关Tcode：FS00|XK01|XD01 / FI01|FI12|FBZP|F110下面简单叙述一下业务操作步骤。第一步：建立银行代码（Tcode：FI01）图1-1：建立银行代码，通常各家银行都有自己的编码体系,假设编号为1002000037。图1-2：如果涉及国际结算，需要填写银行的SWIFT码。图1-3：按此在弹出窗口中填写银行详细通信地址。SWIFTSWIFT 是“环球同业银行金融电讯协会”（ Society for Worldwide Interbank Financial Telecommunication）的英文缩写，它是一个国际银行间非盈利的国际合作组织，该组织成立于1973年5月,总部设在比利时的布鲁塞尔。SWIFT银行识别码唯一标识世界上的任一家银行，它由以下几部分构成：银行代码（Bank Code）：由四位易于识别的银行行名字头缩写字母构成；国家代码（Country Code）：根据国际标准化组织的规定由两位字母构成；地区代码（Location Code）：由两位数字或字母构成，标明城市；分行代码（Branch Code）：由三位数字或字母构成，标明分支机构。同时，SWIFT还为没有加入SWIFT组织的银行，按照此规则编制一种在电文中代替输入其银行全称的代码。所有此类代码均在最后三位加上“BIC”三个字母，用来区别于正式SWIFT会员银行的SWIFT地址代码。第二步：设置开户行银行帐号（Tcode：FI12）图2-1：新建开户行名称“X工行”，然后选择左边的“银行帐户“设置帐户标识。 图2-2：在此行开设了两个帐户标识“G9998”和“G9999”，企业在同一银行如果开设了多个帐户，标识可取帐户号码的后4位，注意此处的开户行和银行标识都只是一个用户定义的标志而已。Copy G9998换个会计科目看看，假设Y集团需要在加拿大某行设置一个银行账户接收加元和美元(假设用户懒不想开两户)，系统允许对同一银行帐户设置加元和美圆两个会计核算科目，相当于一个银行帐号下的两子帐号。接下来需要将开户行和FI01定义的银行联系起来，如图3，系统真TMD绕。图3-1267：开户行和帐户标识，输入第一步时建立的银行代码1002000037，自动带出相关信息，此时开户行标识“X工行”就唯一标识一家银行的银行代码联系了。图3-35：在此输入企业在银行开设的银行帐号，系统设置了一个Very Stupid的最高18位限制（如图4），所以可以使用备选科目编号对超过银行账号号码长度范围作补充说明。图3-4：对该银行帐号设置总帐和汇票核算科目。图4是设置国家特定的检查（SE16:V_005_B），可以看到系统限制了银行帐户号码的最高位数是18，银行代码最多只能用4位，这也能折腾出一个配置，哎！F110集中付款,对于需要大量处理应付款的公司(要是应收也这样整,收钱也不小心点收,自动付款后应付款应该是已清可是依旧发现在BSAK已清项中?付款后可以run RFFOM100产生SWIFT MT100格式文件,中午文会乱码?F110银行科目回自动assign dummy profit center . 3KEH无办法?好象必须任何BS科目必须在3KEH中,否则即使退代都无效果? 3KEH-KEDO(包括3KEI)第九章 现金管理和预算控制现金管理模块用来监控企业的支付流程和保证资金流动性安全,各个企业都会制定其现金管理制度，现在来看看ERP是如何实现现金管理的，以前挂在TR模块的现金管理子模块在新总帐中被安排成为财务供应链管理的一个子模块，现金管理子模块的主要功能和特点有:1. 现金管理和FI/MM/SD高度集成,从这些模块中收集相关数据。2. 提供电子银行自动支付和银行对帐单功能。3. 现金头寸和流动性预测业务分析。 现金头寸：指几天内银行帐户的余额状况.通过现金头寸报表，对影响银行帐户余额的经济活动重新组织,从而反映当前的现金头寸。现金头寸报表是以银行总帐帐户和银行清理帐户为基础的分析报表。流动性预测：是以应收/应付模块中的客户/供应商帐户为基础，一般反映的是在相对较长期间的资金流入和支付交易情况。现金流动性管理是现金管理的核心，流动性管理是指集团内现金头寸及其他资产转化成集团可即时支配使用的现金，并且不造成资源损失的能力。对集团现金和流动性作细致衡量和持续监控，可确保企业有足够的资金来源支付短期债务，并且利用不可预见的投 资机会获得更大收益。4. 资金集中和现金池功能帮助实现集团跨地区的自动化的资金集中管理。5. 支付监控功能，防止企业支付危机等等。有一天,俺问一个做TR介绍下现金管理等模块的功能,好家伙,刷地列举了这模块数十条功能,一个劲拼命夸这东西好使,最后俺受不住了,对他说:兄弟,你可以夸TR好使,可也用不着往死里夸呀;你可以忽悠俺,可不能抱着”让我一次忽个够”的想法非要把俺忽悠昏不可,忽悠俺这种ERP界少有的老实结巴的好人儿您心里过意得去吗?现金头寸和流动性预测区别 ,如下表:现金头寸流动性预测短期的现金管理和预测中长期的现金管理和预测现金/各种银行存款/银行结算科目客户/供应商的各种应收应付支付建议现金存款过帐银行结算 现金管理其他业务交易手工备亡录采购订单/销售订单Vendor Invoice&Customer billing现金管理其他业务交易预测时间0-5天，可每天监控通常是1周或更长下面简单分析一下现金管理模块的相应配置。第一节 现金管理配置首先明白一个组织单位概念：财务管理区域。财务管理区域是现金管理，现金预算管理和预算控制的一个重要的最高层次的组织架构，是计划、控制、监控基金及承诺预算的组织单位，在一个财务管理范围内，可以进行统一的现金管理、现金预算管理以及预算控制。图1是一个合成图。图1-1：定义财务管理区域，IMG Path:企业结构-定义-财务会计-维护财务管理区(SE16:V_FM01_A)，假设定义一个财务管理区域叫 2800。图1-2：分配公司代码，IMG Path:企业结构-分配-财务会计-给财务管理区分配公司代码(SE16:V_T001_FM)，将公司代码2800/2801/2802分配给财务管理区域2800 。 一个公司代码只能分配给一个财务管理区域,多个公司代码可以分配给同一个财务管理区域，财务管理区域的货币最好和分配的各公司代码的本位币相同，对一个在世界各地都有业务的跨国集团，各公司代码本位币一致基本是不可能的，新版本提供了一个功能可以让使用不同本位币的公司代码分配给同一个财务管理区域，那就是让财务控制范围再使用各公司代码的附加本位币比如集团货币，我们知道一个公司代码最多可使用包括两个附加本位币共3个本位币，现在假设Tcode：OB22检查公司代码2800/2801/2802的附加本位币如下表：公司代码第一本位币（10）第二本位币（30）第三本位币（40）2800CNY无任何附加本位币2801USDCNYUSD2802CNYCNYUSD图2中，公司代码2800/2801/2802的控制范围货币也是30，货币类型30在Tcode：OY01中设置，集团货币正是SCC4定义的Client 标准货币，关于ERP的货币本书相关章节已有相当详细描述，在此Review一下。注：旧版本中，需要将控制范围分配到财务管理区域（SE16：V_TKA01_FM），并且控制范围和财务控制范围需要包含相同的公司代码，在新版本不再需要如此，旧版本的Link成本中心/利润中心/内部订单/WBS元素的FRC1-FRC9已经推出历史舞台，被Tcode：FMDERIVE替代，实际上这是一个基金对象的派生规则，类似CO-PA的Tcode：KEDR ，在后面将有更详细描述。图1-34：使用Tcode：OFUP定义财务管理区域的集团货币,货币类型为30,则可将本位币不同的公司代码2800/2801/2802分配给同一财务控制范围2800 .Tcode：OF32定义财务管理区域的会计年度变式，理论上讲,也可采用和公司代码不一样的期间变式。回顾：图1中，可将本位币不同的几个公司分配到使用集团货币30的财务管理区域，这很有必要,假设国内某集团在美国有公司代码2801，有两种处理方法，一是专门为该公司建立一个使用USD的财务管理区域，以前的版本好象需要这样做; 二是使用集团货币30 CNY做财务管理区域附加货币，这样整个集团可使用同一个财务管理区域。分析下图3的几个基本配置，在新总帐中，现金管理是财务供应链管理下的一个子模块。图3-1：定义默认起息日（Value Date），指出当输入行项目的时候当前日期作为起息日的缺省值使用，通常在银行帐户和银行子帐户中使用该起息日，可用于利息计算和现金头寸分析（这是别人告诉我的，如果你家不是使用起息日去自动计算利息，可以问他去）。F-28/F-53收付款初始界面就可以当前日期做缺省的默认值,这种小东西也搞一个配置，服了。图3-2：定义源符号，源符号是自定义的一个任意标志，用来标识现金头寸和流动预测，源符号还可用来进一步细分计划级别，如图4，定义了BNK/PLN等几个源符号，BNK将对应到各种现金和银行存款科目，PLN则对应到集团资金计划。图4-12的源符号BNK和PLN选上了“现金头寸CM”标志表示和现金头寸分析相关，源符号PSK将对应各种收付款和流动预测相关。图3-34：定义计划级别，计划级别在源符号的基础上（两者结合）可更加细分现金状态和流动预测的分析层次，计划级别将被分配到现金科目，应收应付科目，可在建立会计科目（Tcode：FS00）为这些科目输入计划级别，除了这些会计科目外，计划级别也可分配到特别总帐交易，收付款请求，采购订单，采购申请，销售订单和销售开票计划等业务交易。定义的级别应该是唯一的 ，不要为多于一个的应用或者活动定义相同的计划级别,这将影响现金状态和流动预测分析的清楚性。定义计划级别如下表：在上表中，可以看到源符号BNK和计划级别（计划层次）B1-B7将现金和银行存款科目分成7个级别，PSK和K1-K8则将流动预测收付款细分。图3-5：定义计划组，计划组通常被分配到供应商和客户主数据中，计划组用来细分收付款业务或业务关系，比如可以设置这样的计划组：国外供应商|客户，国内再分集团内集团外供应商|客户，风险客户等等。图5是一个定义计划组（现金管理组）的画面，将客户和供应商进行了归类，你也针对客户/供应商的信誉程度分组比如这是危险客户组等，注意计划组对应的计划级别（层次）。图6-1：在客户主数据加入现金管理组（即计划组）ZD01，对应计划级别K2(Tcode:XD01)。图6-2：在供应商主数据加入现金管理组（即计划组）ZK01,对应计划级别K6(Tcode:XK01)。图6-3：在外币存款科目中加入计划层次(即计划级别)B4(Tcode:FS00)。 注：现金和银行存款会计科目中只能选择“现金头寸”类的计划级别。回顾：（1）.现金管理和流动性计划分三个主要层次的，第一层次是计划源（源符号），分BNK（现金和银行存款），PSK（应收应付），PLN（资金计划），MMF（采购订单和合同），SDF（销售合同预测）；第二层次是使用计划级别比如将PSK细分为K1-K8包括应收应付/定金/定金请求/其他应收应付/应收应付汇票等；对于各类应收应付，在第三个层次上还可对客户和供应商划分计划组。(2).现金和存款类科目只到计划级别层次，计划级别维护在科目主数据，各种应收应付类科目不在科目主数据中维护“流动预测“类计划级别，而是通过维护供应商和客户主数据的现金管理组(Tcode:XK01|XD01,比如应收应付)和特殊总帐标志(Tcode:OBXR|OBYR|OBXT,比如其他应收应付预收预付等)定义计划级别(层次)。记住3个名词：计划源（源符号）|计划级别|计划组 。新解一下ERP,实际上也是旧解。1.ERP- Enhancement and Repair Project修修补补的破项目; 2.ERP-一拉皮,一拉人扯皮?3.ERP三不曲:E?这东西真的好使?(选型前);R?花了这么多钱财和人力? (实施后);P!什么破烂玩意(使用后)！来分析图7的13项配置。图7-1:定义现金管理科目名，如图8，现金管理帐户（CM帐户）是现金管理的一个东东,它和财务模块的会计科目一一对应,比如你需要使用现金集中FF73就需要指定一个目标帐户的 现金管理帐户,ERP设计者比较喜欢玩这种游戏,有这么些东西:(1).集团科目/合并项目是报表合并”科目”,它被填写在会计科目主数据中。(2).国家指定备选科目，被填写在会计科目主数据，用来出指定国家财务报表。(3).承诺项目(类似国内财务软件预算模块的预算项目) 被填写在会计科目主数据，是预算模块的“科目”。(4).初级成本要素直接对应到损益科目，是CO模块的“科目”。(5).现金管理帐户在此和现金银行存款类科目联接上，是现金模块的“科目”。 这些“科目”和会计科目互相联系，却又在各自模块中记录交易数据。图8-23定义银行存款类总帐科目和CM帐户的对应关系，CM帐户实际上只是一个标识而已，注意在此定义了一个叫“CASHCC”的CM帐户，在第二节的业务分析中将使用该帐户做现金集中用。图7-2 3: 分组和建立层次显示结构，定义分组和维护结构不过是用来做现金头寸和流动预测分析而已（比如Tcode：FF7A/FF7B显示），如图9。图9-134：定义分组ZST0100，每个分组都需设置两种显示行类型，E-等级，即计划级别，所以是两位，所以+则表示显示所有的计划等级，G则表示显示计划组或科目，如图9-4的ZD+/ZK+的汇总条款（标题）是应收/应付款项，在本节上表中定义的计划组正是以为ZD/ZK开头的四位字符，也就是说，在Tcode：FF7A/FF7B如果选择分组ZST0100，则供应商/客户的应付/应收将分别汇总显示在汇总条款“应付款项”/“应收款项”下。注：分组ZST0100并非一个实际的完全的分组，你可以根据实际业务定义更详细的“汇总条款“。图9-25：定义一个现金集中玩玩的分组ZST0300，在第二节的业务操作将用到。图7-45: 在现金头寸和流动预测分析中，对于不确定项可以分开显示，比如将一个尚未经老总批准确定的付款建议金额100000元（老板有80%可能不核准这个建议）在期望批准日显示80%即8万，在接下来的两周每周显示10%，可以在此设置一下。图7-7: 手工计划,在此定义手工计划的编号和凭证类型,比如使用Tcode:FF63建立收付备往录就可以选择次手工计划凭证类型。如图10。图10是设置手工计划类型和建立支付备忘录的一个合成图。图10-12：在此建立计划类型CC对应“流动预测“类计划级别K9，计划类型CD则对应”现金头寸“计划级别B1。图10-34：如果选择计划类型CD，带出源符号BNK，计划层次B1，在计划细节中填写科目名称，注意这里的科目名称指现金管理科目CM帐户。图10-56：如果计划类型选择CC，带出流动预测源符号PSK，计划级别K9，此时在计划细节中出现的则是计划组。图7-8:定义后勤计划层次，如图11。对于后勤模块，如何实现流动预测呢？ERP系统内置了5种内部码：1-采购申请|2-采购订单|3-计划协议|101-销售订单|201-销售代理,内部码是系统写死的, ID 2就表示采购订单,ID 101就表示销售订单,在此配置想对应的计划层次。销售订单采购订单