统一SAP财务增强

《统一SAP财务增强》由会员分享，可在线阅读，更多相关《统一SAP财务增强（3页珍藏版）》请在装配图网上搜索。

1、SAP财务增强的统一规划作者：付鸿杰 集团在实施和推广ERP大都会采用统一和集中原则， 然而，由于集团业务庞杂，ERP统一和集中曲折之路往往难以避免，下面以实例简单介绍下SAP财务增强统一规划和管理思路。一、用户增强简介SAP系统预留有3类增强：菜单增强(Menu ENTRY)、屏幕增强(SubScreen)和功能增强(Function Enhancement)，顾名思义，屏幕增强，就是诸如采购订单、资产卡片或内部订单等主数据允许客户化子屏幕和相应辅助字段，扩展分析维度；而功能增强就是在事务码(Transaction Code,简称Tcode)对应标准程序中留下出口，允许用户插入自定义逻辑代码

2、，因此这类增强亦称用户出口(User Exit)。二、理解FICO增强FICO模块也有自己特定的增强，财务增强分为两类：替代(Substitution)和有效性检查(Validation)，替代允许根据用户逻辑替换会计凭证字段的原始内容，例如，当FICO标准凭证生成功能无法满足集团对会计核算的明细需求时，就可使用替代将相应辅助核算信息填充完整，对无法手工干预的自动会计凭证来讲，替代尤为重要；而有效性检查则是根据核算需求对会计凭证内容进行“完整性”检查，预先避免不完整的核算数据进入系统形成垃圾信息。常用的FICO增强Tcode如下：GGB0（全部有效性检查）/OB28/OKC7 :FI/CO有效

3、性检查GGB1（全部替代）/OBBH/OKC9: FI/CO替代 财务增强有特定执行顺序，不妨假设检查某核算字段内容缺失时报告错误，如果检查优先执行，则可能因内容确实报告错误，事务直接终止，而实际上该核算内容是启用替代来填入的，信息并不缺失，不应报告错误，由此推断，替代显然应该优先执行。无论替代还是有效性检查最后都形成代码，从技术角度来看，任何管理软件无非是代码+数据库表的集合,而从代码角度,替代和有效性检查的区别仅仅在于替代可以替换内容,而检查不能,如果替代代码中只做检查,它就是有效性检查,简单理解,就是替代功能有效检查功能,因此,财务增强统一只注重替代的统一就足够。三、优化财务增强基本思路

4、(1).统一和简化增强配置 传统财务增强处理方法是分步骤的，适合于中小企业应用,毕竟,中小企业管理维层次和业务维度不会很大,图-1显示的是一个典型的行项目替代步骤，它的缺点在于,这些步骤属于覆盖性配置且需要传输, 当开发系统和生产系统未同步时,就存在较大风险；统一的思路是使用唯一的步骤，该步骤中只包含一个“唯一退出”，对应到统一的财务替代例程ZFITD。 替代分为凭证抬头、凭证行项目和完全凭证等种类，使用不同的调用点，当然命名必须规范，图2显示的是示范公司代码2331的替代命名规则:.字母T开头+4位公司代码表示凭证抬头替代,调用点1；.字母A开头+4位公司代码表示行项目替代，调用点2；.字母

5、C开头+4位公司代码表示完全凭证替代，调用点3。 需要强调的是,这3种替代都只使用一个简单的“唯一退出“步骤，且都对应到ZFITD,事实上，所有公司代码的3种增强都使用子例程ZFITD,现在来统一下认识,财务增强包括2个组成部分:增强配置和增强代码,传统的步骤法实际上是在配置步骤中包含了增强代码,不适合超大集团应用，也不利于运维，而这些步骤代码往往是重复逻辑简单堆砌，而优化后是将财务增强配置提升一个新高度，就是它必须统一，并且和增强代码彻底分开。(2).增强程序的规划 公用主程序的预留Tcode:GCX2定义有一公用增强主程序，也应尽量避免随意修改，假设增强主程序为ZRGGBS00,如图3。从

6、图3可以看出，该程序包括2种include子程序:Zpublic:该include包含总部财务应用各企业必须统一的公用逻辑代码，由总部统一维护和 发布。Z2331: 该include包含公司代码2331私有逻辑,每家公司都对应有一个私有include。 在主程序ZRGGBS00中只涉及一个子form PFITD,因为所有企业的增强都指向它，它负责的任务是指引各企业执行对应增强代码，它就是一个调度器，如此而已，主程序不再做其他任何逻辑判断，这样主程序就基本固定。PFISUB的示范代码如下表：FORMPFISUB. “负责引导各公司代码执行财务增强的调度器performppublic. “执行总部

7、集中财务增强代码,所有公司代码都必须强制执行select case 公司代码 case 2331. performp2331. “执行include z2331的私有增强代码 case 其他任何公司代码. “可以为各公司预留代码 执行相应公司的财务增强私有子例程endselect .endform. 为了在集中的还是分散的服务器彻底统一主程序,再玩深一点的技术，SAP的公司代码都还能随意增加呢？使用动态程序生成技术,比如集团的ERP服务器A将运行100家业务，那就做100个include,或者，做一个可视化界面，只要输入100个或者更多公司代码，主程序就自动形成，当然，实务中没有必要这样折腾，

8、毕竟，主程序逻辑基本固化，增加公司代码只涉及主程序的简单调整。企业私有例程示范 所有公司代码的私有增强对应一名为Z+公司代码的include，图4显示的是include Z2331的示范代码，其中P2331子例程实际执行的是抬头、行项目和完全凭证3个子例程，它在满足公司代码为2331时，由主程序调度器PFISUB调用。僵化和灵活的平衡传统的配置步骤法过于僵化，将配置和代码分开后，需要将各增强步骤迁移，通常这些代码都是简单逻辑的堆砌，迁移十分容易，现在的问题是，各企业涉及数十条甚至上百条增强，能否研究一个统一的方法，能否使用灵活的自定义表？还是放在私有程序中让各单位舞姿折腾？个人认为，过于灵活也

9、未必是好事，适度僵化比灵活更灵活，灵活过度会造成另一种僵化，我们可以考虑将特征明显的增强应用做成可视化配置，其它增强处理放在私有例程，给企业自由发挥空间，怎么才能算特征明显？我来举两个应用实例：.会计基础工作凭证打印所必须的行文本摘要想像一下，如果自定义应用表包括公司代码、利润中心、凭证类型、行文本或其他字段，放在总部统一管理的公用例程，按此表配置内容执行就可以，当然，如果凭证类型和行文本摘固定，Hard-coding写死也无妨，平衡僵化和灵活很重要。.BCS总部应用的部分科目合并事务类型必输同样可以通过自定义应用表包含需要控制的会计科目，这样只需少数几行代码就可以实施控制。当然，增强代码也需要规范，切忌将事情再度复杂化，很多时候，业务复杂往往是自己挖坑将事情人为复杂化，最后特别强调，这种思路同样适合其他模块的增强管理，尤其是中石化这种大型企业的集中服务器上，将增强分为公有和私有，避免相互影响，意义非凡。方向决定格局，细节决定成败，宏观和微观技术上把握好,就能有效改进ERP工作。