GGB0/OB28/OKC7/GGB1/OBBH/OKC9 FICO增强详解编程语言

FICO的增强通常包括替代和有效性检查,替代的目的是根据自定义逻辑替换凭证的字段内容,而有效性检查顾名思义就是对凭证的内容进行检查,常用Tcode包括:

GGB0/OB28/OKC7:全部/FI/CO有效性检查

GGB1/OBBH/OKC9:全部/FI/CO替代

GGB4:ALL Rule Class

GS01：配置集

IT虾米网

*以下增强均包括替代和有效性检查。

以凭证有效性检查为例,目前,很多企业在不同的项目为不同的模块满足不同的校验需求建立了大量的检查步骤,有的竟多达上百个步骤,给后续维护带来很大不便, 常见的问题有:在检查的先决条件中比如写死会计科目/成本中心等条件造成新增科目或成本中心遗漏检查;由于有效性检查(或替代)是覆盖性传输,造成后续增加步骤由于难于找到和生产机同步的配置而不得不直接在生产系统中操作, 在集中ERP服务器中该问题尤其突出。

那么,如何避免过多的FICO增强步骤? 本人觉得可以通过规范使用增强达到目的，参考做法如下：

(1).事先规划好有效性检查步骤,每个步骤的检查使用Exit(Exit被译为图1的”退出”)例程,例程可按集团公用还是企业私有划分,如集中服务器分”企业有效性检查例程”U800和”公用有效性检查例程”U900俩例程,将所有的有效性检查逻辑全部放在此两例程,如集团BCS项目相关会计科目过帐合并事务类型必输校验,实际上对所有企业逻辑是一样的，可以放在公用例程U900中;再如集团会计基础项目的自动会计凭证根据不同凭证类型的自动行文本摘要替代,也可放在公用例程U900,也就是说每个企业的FICO凭证检查和替代,将只能看到对应公共和私有例程的2个步骤，这样在后续的校验或替代逻辑增加中，只需修改例程就行。

   或者，按不同主题划分增强步骤，例如,有的企业为了给ERP自动集成凭证替代行项目文本,每种凭证类型1个替代步骤,造成了一大堆的替代步骤,实际上只需建立1个比如叫”行文本替代”的主题步骤+1个行文本替代例程就可,可以非常方便地将其他企业的逻辑复制过来使用。  

(2).禁止企业随意新增步骤，避免凭证检查和凭证替代的使用混乱和后续维护的困难。

     下面以BCS项目检查相关科目合并事务类型必输为例说明如何增强的规划使用,步骤如下：

(一).首先,如图1,建立1个科目“合并事务类型必输”主题步骤, 当然,为了避免增强步骤过多,可以建立1个更大的如叫”科目记帐检查”的主题步骤,注意图1中检查使用的是U900例程。

(二).在例程中尽量使用可配置的逻辑代码,我们应该从可配置性的SAP系统中学习并应用好这点。

(三).科目设置可使用Tcode:KDH1或GS01建立科目集,以应交税费科目必须输入合并事务类型C00(税金–年初未交（退）数)、C01(税金–本期应交（退）数)、C11(税金–本期已交数–本年)或C12(税金–本期已交数–非本年)为例,首先KDH1建立科目组ZSWLX_YJSF,该科目组的科目由用户自行定义,接下来只需要在U900编写以下参考代码就可检查应交税费科目的合并事务类型必须输入且必须以C开头。

同样，如果需要判断应付职工薪酬科目必须输入I开头的事务类型，只需要增加如下代码就可。

*职工薪酬类科目事务类型必须是I开头

    when ‘ZSWLX_ZGXC’.

      if i_swlx1 = ‘I’.

         b_result = b_true.

      else.

         b_result = b_false.

      endif.

   endcase .

   这种使用例程的增强好处非常明显,按主题管理的增强步骤非常明晰;新增检查逻辑时只需修改例程就行,方便维护;可配置的科目在科目发生变化时无需重传请求等，遗憾的是,目前我们很多企业在实施ERP时并未在意FICO增强的统一规划,多数企业的FICO增强使用都比较混乱,说白了,就是随时随意增加步骤,给后续维护带来不小麻烦。

例程的增强有个小小的缺点,就是需具备基本的ABAP知识,这不是什么问题,作为顾问和关键用户,了解基本的ABAP知识应是必须的,况且，在多数增强中,我们往往只是简单复制代码稍事修改。

—————————————————————————————————————

目前BCS项目中需进行合并事务类型必输检查的完整的代码如下表：