财务增强浅谈(娱乐版).doc

财务增强浅谈（娱乐版） 集团在实施和推广ERP大都会采用统一和集中原则， 然而，由于集团业务庞杂，ERP统一和集中曲折之路往往难以避免，如果规划不当，无异于雪上加霜，下面以实例简单介绍下SAP财务增强统一规划和管理思路。一、用户增强简介 SAP系统预留有3类增强：菜单增强(Menu ENTRY)、屏幕增强(SubScreen)和功能增强(Function Enhancement)，菜单增强暂且不表，屏幕增强，顾明思义，就是诸如采购订单、资产卡片或内部订单等主数据允许客户化子屏幕和相应字段，无非是扩展分析维度，满足明细分析需求；而功能增强就是在事务码(Transaction Code,简称Tcode)对应标准程序中留下出口，允许用户插入自定义逻辑代码，因此这类增强亦称用户出口(User Exit)。二、理解FICO增强 FICO模块也有自己特定的增强，财务增强从用途上分为两类：替代(Substitution)和有效性检查(Validation，以下简称检查)，替代允许根据用户逻辑替换会计凭证字段的原始内容，例如，当FICO标准凭证生成功能无法满足集团对会计核算的明细需求时，就可使用替代将所需核算字段信息填充完整，对无法手工干预的自动会计凭证来讲，替代尤为重要；而检查则是根据核算需求对会计凭证内容进行“完整性”检查，预防不完整核算信息。我想读者对这两个概念应该很容易理解。常用的FICO增强Tcode如下：GGB0（全部有效性检查）/OB28/OKC7 :FI/CO有效性检查GGB1（全部替代）/OBBH/OKC9: FI/CO替代 财务增强有特定执行顺序，不妨假设检查某核算字段内容缺失时报告错误，如果检查优先执行，则可能因该字内容缺失报告错误，事务直接终止，而实际上该字段内容是启用替代来填入的，并不应报告错误，显然，替代应该优先执行。无论替代还是检查最后都形成代码，从代码角度,替代和检查的区别仅仅在于替代可以替换内容,而检查不能,如果替代只编写检查逻辑,它就是有效性检查,简单理解,替代功能检查功能,因此,财务增强统一只注重替代就可以。三、优化财务增强基本思路(1).统一和简化增强配置传统财务增强处理采用步骤法，适合于中小企业或增强极小的企业，图1-1显示的是一个典型行项目替代，包括若干步骤，在大型企业的集中服务器上，往往运行了很多公司的业务，如果总部很多应用或企业实务需要很多财务增强，采用步骤法缺点就非常突出，首先，不利于迁移,树状结构的配置无法一次性复制出来，有的企业增强步骤高达上百条，而很多时候ERP项目往往遵循的一期挖坑、二期填坑、三期整改、四期优化诸如此类的实施方式，当系统切换时间，旧系统的增强步骤需要财务顾问反复一条条新建，效率很低；其次，财务增强步骤是覆盖性配置，集团往往有几十台ERP服务器，即使采用云计算和虚拟机技术时不时去同步配置，而顾问和用户们往往需要在非生产系统培训或测试增强，开发和测试机本来有时就是用来玩耍的，谁也不能保证没有顽皮的同学，当玩到开发系统和生产系统配置不同步时，传输就存在很大风险，你认为将会发生的悲剧往往它就必定发生；不利于管理，财务增强是以公司代码为基本控制单元的，以某省公司为例，设想下该公司下存在近百个以利润中心为代表的独立核算单位，那得要多少个步骤呀,就不再为步骤法罗织更多“罪名”了,有人说,步骤法的优点就是可让不懂编程序的同学能在可视化的友好界面上做增强,有时我在想,为什么别的模块的增强就直接是出口程序呢,不也搞个用户界面,在SAP CO-PA增强中，花哨动作更多，什么推导、派生等，我想可能是历史条件下，编程是很崇高的工作，一般人玩不来，看看现在是什么时代，新时代的人才基本要求是什么？财务、英语和电脑等等，一个也不能少，好了，尤其是象财务模块这样的增强，代码往往非常简单，一般只要认识3个单词if、then和message，很多人多次反映读不大懂我的思维,为了保险起见,我觉得还是需要亲自将这三个单位用中文翻译一下，如果没有记住，回家每词认真默写30遍就可。If:如果Then:那么Message:消息 假设您已经记住了这3个单词，现在，用程序语言来表示财务增强：1).替代就是If 条件then 字段 = *.2).检查就是：If 不满足检查条件 then message E001(00) with *不完整.既然财务增强代码如此简单，我想大家应该都不会反对统一使用代码吧，实在不会使用代码的，可以请教开发人员。有个财务顾问觉悟就很高，总结的很好：技多压身,不会做也非坏事,多做算白做,出错还找骂。如何统一财务增强呢？就是所有的增强只有一个唯一步骤，且该步骤中只包含一个“唯一退出”，对应到统一的财务替代例程ZFITD。 替代分为凭证抬头、凭证行项目和完全凭证等种类，使用不同的调用点，当然命名必须规范，图2显示的是示范公司代码2331的替代命名规则:.字母T开头+4位公司代码表示凭证抬头替代,调用点1；.字母A开头+4位公司代码表示行项目替代，调用点2；.字母C开头+4位公司代码表示完全凭证替代，调用点3。需要强调的是,这3种替代都只使用一个“唯一退出“步骤，且都对应到例程ZFITD,事实上，所有公司代码的3种增强都对应到例程ZFITD，再来统一下认识，财务增强包括2个组成部分:增强配置和增强代码,传统的步骤法实际上是在配置步骤中直接包含增强代码,而这些步骤代码往往是重复逻辑的简单堆砌，优化后则是将增强配置提升到一个新高度，新高度这词领导一般爱听，作为配置它就必须统一，并且是纯配置，有多纯呢？先讲个故事，我在编写本文时LP恰在身边，我很郁闷地问她：为什么我的思维别人总很难理解呢？难道我的认识比他人境界要更高？我LP很不屑地撇了我一眼：高什么高？你有多高，咱穿高跟鞋都高过你呢，你就是语言表达有问题，幼儿园时间语文估计就总不及格,要想人家看的懂，就多打浅显的比方。我觉得财务增强配置比我LP的买的5个9黄金戒指还纯，纯度100%，不夹杂一丝代码，拆迁容易，使用方便。接下来就是如何规划增强代码了，有人问为什么要将财务增强配置和代码独立出来呢？前面已经列举了很多步骤法的缺点，我又来打个比方，应该是18年前，我刚毕业在一小县城工作，街头极少车辆，我隔壁的隔壁的隔壁,隔了多少壁我没有认真数国,有个小毛同学,不知从哪花了6000元买了辆破吉普,除了车喇叭按住不想全车身都想的那种,每天从遥远的天际由远及近传来可怕的轰鸣声时,我们就知道,小毛回家了, 当时有个小车那算是相当的成人士,反正那时我月工资275元,还好多了25元,我不大记得当时的成功人士是喝茅台还是喝拉菲,但我记的很清楚,就是各个街道绝没有一盏红绿等,因为车少。18年后我漂到北京，每天我骑自行车经过被堵的豪车旁，都要身出2个指头，做V状，“Yep”,单车就是比汽车跑的快。什么状况呢？时代变了，人拥进北京了，车多了，道路没规划好，堵了；ERP集中了，企业多了，应用多了，不规划好，挤一块，照堵。今年春节回家，现在县城也堵的慌，开车还不如散步。 (2).增强程序的规划 公用主程序的预留 Tcode:GCX2定义有一公用增强主程序，也应尽量避免随意修改，假设增强主程序为ZRGGBS00,如图3。从图3可以看出，该程序包括2种include子程序:Zpublic:该include包含总部财务应用各企业必须统一的公用逻辑代码，由总部统一维护和 发布。Z2331: 该include包含公司代码2331私有逻辑,每家公司都对应有一个私有include。 在主程序ZRGGBS00中包括一个重要的例程ZFITD,因为所有企业的增强都指向它，它负责的任务是指引各企业执行对应增强代码，简单理解，它就是一个公用增强调度器，ZFITD的示范代码如下表：FORMZFITD. “负责引导各公司代码执行财务增强的调度器performppublic. “执行总部集中财务增强代码,所有公司代码都必须强制执行select case 公司代码 case 2331. performp2331. “执行include z2331的私有增强代码 case 其他任何公司代码. “可以为各公司预留代码 执行相应公司的财务增强私有子例程endselect .endform.企业私有例程示范 所有公司代码的私有逻辑对应一名为Z+公司代码的include，图4显示的是include Z2331的示范代码，其中在P2331子例程调用抬头、行项目和完全凭证3个子例程，P2331可以理解为企业的私有增强调用器，它在满足公司代码为2331条件时，由主程序调度器ZFITD调用，简单理解，就是主程序的公用增强调用器只调用私有程序的私有增强调用器，这样，增强们就不会混在一起吃大锅饭，产权明晰，责任到位。如果销售省公司2331下有一大堆利润中心代表的独立核算加油站,无非将Z2331中的抬头、行项目和完全凭证子例程按利润中心分解而已，建议一不要加在主程序中，主程序只处理到公司代码级，因为加油站随时增加，不要越级去骚扰主程序。设想一下，以后ERP要搞拆迁，代码直接从就系统复制在新系统中粘贴。如何处理已经存在于各家企业的多步骤增强，老城区改造也不是直接使用推土机暴力拆迁，新系统采用新规划，老城区呢，后续再有增强采用新的方法，再慢慢转移到私有例程中去。僵化和灵活的平衡传统的配置步骤法过于僵化，将配置和代码分开后，在增强代码中可以适当使用自定义表，增加灵活性，但是，过于灵活也未必是好事，不偏不倚，过犹不及。北京首都机场搞了1、2和3号航站楼，疏通空交，大气，很好；某个地区也搞一个大机场，领导说是高瞻远瞩，考虑未来发展，一年也见不到几架飞机，莫非考虑的是未来1万年后的发展？这就是典型的自己挖坑。可以考虑将特征明显的增强应用做成可视配置表，怎么才能算特征明显？举两个主题应用实例：.应用一、会计基础工作凭证打印所必须的行文本摘要想像一下，如果自定义文本摘要配置表包括公司代码、利润中心、凭证类型、行文本或其他字段，放在公用程序Zpublic中，实际上，如果凭证类型和行文本摘要整个集团要求一致，文本摘要表就两个字段凭证类型和文本摘要就可以，或许有人说也可以写死呀，考虑到几方面情况，建议使用自定义表。1).未来凭证类型会新增加；2).未来行文本摘要可能要重新描述；3).自定义表代码要远比一一列举凭证类型简洁，你有几十个凭证类型，一一列出简洁还是 只用几行代码读表简洁，显然读表看的更舒服。.应用二、BCS项目要求部分科目合并事务类型必输 同样，在集中服务器中，一个自定义表和几行简单代码就可以控制住所有企业。 十几年前，我曾主导开发过一个小型ERP系统，从业务建模到数据库表甚至字段，亲自操刀，小心谨慎。增强管理必须规范，从程序、变量甚至注释，如上面的两个应用，一定要在每个应用后