学习网络某些家伙的噱头，题目取的吓人一点。
在近20年的IT职业生涯中,前10年做的是管理软件开发设计,后10年做的是ERP软件的实施运维，工作起来总感觉有点别扭,后来一想,武功练反了,没有实施运维的丰富实务经验先去做规划设计,最多也就只能搞搞山寨,多年以后,当我回想起10几年前曾担任某管理软件的总设计时,可谓绞尽脑汁,胡编乱造，至今汗颜,小庖:付同学,你没有这资历做软件这不是坑爹吗? 老屠:你完全错了,也就是坑坑软件公司老板,老板拿这破软件去坑企业,企业再坑用户,人在江湖,身不由己,老付也要混口饭吃,再说,你要从更高的角度来看待问题,如果真能多坑到几个运维用户,这也是为就业和GDP做贡献呀，因此挖坑越深，贡献越大。
各位读者可以权当娱乐。
 
SAP财务增强的统一规划

作者：付鸿杰

    集团在实施和推广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]显示的是一个典型的行项目替代步骤，它的缺点在于,这些步骤属于覆盖性配置且需要传输, 当开发系统和生产系统未同步时,就存在较大风险；统一的思路是使用唯一的步骤，该步骤中只包含一个“唯一退出”，对应到统一的财务替代例程ZFITD。

替代分为凭证抬头、凭证行项目和完全凭证等种类，使用不同的调用点，当然命名必须规范，图2显示的是示范公司代码2331的替代命名规则:

.字母T开头+4位公司代码表示凭证抬头替代,调用点1；

.字母A开头+4位公司代码表示行项目替代，调用点2；

.字母C开头+4位公司代码表示完全凭证替代，调用点3。

    需要强调的是,这3种替代都只使用一个简单的“唯一退出“步骤，且都对应到ZFITD,
事实上，所有公司代码的3种增强都使用子例程ZFITD,现在来统一下认识,财务增强包括2个组成部分:增强配置和增强代码,传统的步骤法实际上是在配置步骤中包含了增强代码,不适合超大集团应用，也不利于运维，而这些步骤代码往往是重复逻辑简单堆砌，而优化后是将财务增强配置提升一个新高度，就是它必须统一，并且和增强代码彻底分开。

(2).增强程序的规划

 公用主程序的预留

Tcode:GCX2定义有一公用增强主程序，也应尽量避免随意修改，假设增强主程序为ZRGGBS00,如图3。

从图3可以看出，该程序包括2种include子程序:

Zpublic:该include包含总部财务应用各企业必须统一的公用逻辑代码，由总部统一维护和

        发布。

Z2331: 该include包含公司代码2331私有逻辑,每家公司都对应有一个私有include。

   在主程序ZRGGBS00中只涉及一个子form PFITD,因为所有企业的增强都指向它，它负责的任务是指引各企业执行对应增强代码，它就是一个调度器，如此而已，主程序不再做其他任何逻辑判断，这样主程序就基本固定。PFISUB的示范代码如下表：

FORM PFISUB.  “负责引导各公司代码执行财务增强的调度器

  perform ppublic.  “执行总部集中财务增强代码,所有公司代码都必须强制执行

select case 公司代码

   case ‘2331’.
      perform p2331. “执行include z2331的私有增强代码

   case ‘其他任何公司代码’.  “可以为各公司预留代码

    执行相应公司的财务增强私有子例程

endselect .

endform.
 

    为了在集中的还是分散的服务器彻底统一主程序,再玩深一点的技术，SAP的公司代码都还能随意增加呢？使用动态程序生成技术,比如集团的ERP服务器A将运行100家业务，那就做100个include,或者，做一个可视化界面，只要输入100个或者更多公司代码，主程序就自动形成，当然，实务中没有必要这样折腾，毕竟，主程序逻辑基本固化，增加公司代码只涉及主程序的简单调整。

企业私有例程示范
    所有公司代码的私有增强对应一名为Z+公司代码的include，图4显示的是include Z2331的示范代码，其中P2331子例程实际执行的是抬头、行项目和完全凭证3个子例程，它在满足公司代码为2331时，由主程序调度器PFISUB调用。

僵化和灵活的平衡

传统的配置步骤法过于僵化，将配置和代码分开后，需要将各增强步骤迁移，通常这些代码都是简单逻辑的堆砌，迁移十分容易，现在的问题是，各企业涉及数十条甚至上百条增强，能否研究一个统一的方法，能否使用灵活的自定义表？还是放在私有程序中让各单位舞姿折腾？个人认为，过于灵活也未必是好事，适度僵化比灵活更灵活，灵活过度会造成另一种僵化，我们可以考虑将特征明显的增强应用做成可视化配置，其它增强处理放在私有例程，给企业自由发挥空间，怎么才能算特征明显？我来举两个应用实例：

.会计基础工作凭证打印所必须的行文本摘要

想像一下，如果自定义应用表包括公司代码、利润中心、凭证类型、行文本或其他字段，放在总部统一管理的公用例程，按此表配置内容执行就可以，当然，如果凭证类型和行文本摘固定，Hard-coding写死也无妨，平衡僵化和灵活很重要。

.BCS总部应用的部分科目合并事务类型必输

同样可以通过自定义应用表包含需要控制的会计科目，这样只需少数几行代码就可以实施控制。

当然，增强代码也需要规范，切忌将事情再度复杂化，很多时候，业务复杂往往是自己挖坑将事情人为复杂化，最后特别强调，这种思路同样适合其他模块的增强管理，尤其是中石化这种大型企业的集中服务器上，将增强分为公有和私有，避免相互影响，意义非凡。

方向决定格局，细节决定成败，宏观和微观技术上把握好,就能有效改进ERP工作。