统一SAP财务增强

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 （全部有效

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

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

5、 2331 的替代命名规则 :.字母 T开头+4位公司代码表示凭证抬头替代, 调用点 1；.字母 A开头+4位公司代码表示行项目替代，调用点2；. 字母 C开头 +4位公司代码表示完全凭证替代，调用点3。需要强调的是, 这 3 种替代都只使用一个简单的“唯一退出 “步骤，且都对应到ZFITD,事实上， 所有公司代码的3 种增强都使用子例程ZFITD, 现在来统一下认识, 财务增强包括2个组成部分 : 增强配置 和增强代码 , 传统的步骤法实际上是在配置步骤 中包含了增强代码, 不适合超大集团应用， 也不利于运维， 而这些步骤代码往往是重复逻辑简单堆砌， 而优化后是将财务增强配置提升一个新高度，

6、就是它必须统一，并且和增强代码彻底分开。(2).增强程序的规划公用主程序的预留Tcode: GCX2 定义有一公用增强主程序，也应尽量避免随意修改，假设增强主程序为 ZRGGBS00, 如图 3。从图 3 可以看出，该程序包括2 种 include子程序 :Zpublic : 该 include包含总部财务应用各企业必须统一的公用逻辑代码，由总部统一维护和发布。Z2331:该 include包含公司代码2331 私有逻辑 , 每家公司都对应有一个私有include。在 主程序 ZRGGBS00中只涉及一个子form PFITD, 因为所有企业的增强都指向它，它负责的任务是指引各企业执行对应增强

7、代码，它就是一个 调度器 ，如此而已， 主程序不再做其他任何逻辑判断，这样主程序就基本固定。PFISUB 的示范代码如下表：FORM PFISUB .“负责引导各公司代码执行财务增强的调度器performppublic.“执行总部集中财务增强代码, 所有公司代码都必须强制执行select case公司代码case2331 .performp2331.“执行 include z2331的私有增强代码case其他任何公司代码.“可以为各公司预留代码执行相应公司的财务增强私有子例程endselect .endform.为了在集中的还是分散的服务器彻底统一主程序, 再玩深一点的技术，SAP 的公司代码

8、都还能随意增加呢？使用动态程序生成技术, 比如集团的ERP服务器 A 将运行 100 家业务，那就做 100 个 include,或者，做一个可视化界面，只要输入100 个或者更多公司代码，主程序就自动形成，当然，实务中没有必要这样折腾，毕竟，主程序逻辑基本固化，增加公司代码只涉及主程序的简单调整。企业私有例程示范所有公司代码的私有增强对应一名为Z+公司代码的include，图 4 显示的是includeZ2331 的示范代码，其中P2331 子例程实际执行的是抬头、行项目和完全凭证3 个子例程，它在满足公司代码为2331 时，由主程序调度器PFISUB 调用。僵化和灵活的平衡传统的配置步骤法

9、过于僵化 ，将配置和代码分开后，需要将各增强步骤迁移，通常这些代码都是简单逻辑的堆砌，迁移十分容易， 现在的问题是， 各企业涉及数十条甚至上百条增强，能否研究一个统一的方法，能否使用 灵活的自定义表？还是放在私有程序中让各单位舞姿折腾？个人认为，过于灵活也未必是好事，适度僵化比灵活更灵活，灵活过度会造成另一种僵化， 我们可以考虑将特征明显的增强应用做成可视化配置，其它增强处理放在私有例程，给企业自由发挥空间，怎么才能算特征明显？我来举两个应用实例：.会计基础工作凭证打印所必须的行文本摘要想像一下，如果自定义应用表包括公司代码、利润中心、凭证类型、行文本或其他字段，放在总部统一管理的公用例程， 按此表配置内容执行就可以， 当然，如果凭证类型和行文本摘固定， Hard-coding 写死也无妨，平衡僵化和灵活很重要。 .BCS 总部应用的部分科目合并事务类型必输同样可以通过自定义应用表包含需要控制的会计科目，这样只需少数几行代码就可以实施控制。当然，增强代码也需要规