银企直连-自定义EPIC

SAP标准的银企直连功能是EPIC,但这功能包在了标准程序中,现实中很多项目需要自定义开发,并连接到自定义的程序中,所以整理打包一个银企直连的功能类,此类功能也是原自于标准的EPIC,但做了自定义开发,可支持大部份银行的银企直连功能(支付WEBSERVICE ,HTTP操作协议的所有接口功能),更多细节请联系

标准EPIC,可从这里了解。

标准的EPIC,功能很强大,细节也很多,但之前用过的几个项目都没使用标准的EPIC来做银企直连接使用,猜想可能与以下几点有差,

  • EPIC需要另外购买授权,也就是还要另外化钱;
  • 功能太复杂了,一般的FICO功能可能搞不定,还得找专业的顾问来进行实施,也是钱的问题;
  • 好多时候我们只想简单的完成对供应商,客户,或者个人进行转账付款就成了,没有标准EPIC那么复杂的需求;
  • 标准EPIC,在自定义需求时,还是局限性太多,不方便完全自由的进行自定义开发;
  • 标准EPIC,为了通用性,一些设置(配置)逻辑还是太麻烦了,比如他定义银行通讯时,是主键是定义到公司/开户银行/账户标识,这样的结果就是,有多少个付款账号那就要做多少人通讯配置,这以后新增一人付款账号,那还得找业务顾问进行配置,这太麻烦了,我也不确认是不是我理解错了。

所以才会有自定义的EPIC功能,又或者用第三方的银企直连接(拜特、九恒星)进行资金管理。项目中也曾使用过 拜特 ,但其实也就把 拜特 当成了一人与银行进行交互数据的接口软件,他的资金管理功能也是全没使用,但由于增加了一层第三方,出问题时查询的更长了,当然这第三方的成本应该不会比用标准EPIC的成本低了。所以,如是只是银企直连,是自定义的功能,不使用的标准EPIC的话,用自定义的EPIC功能,可能是最好的选择。

1.优势:

  • 可配置性,支付新增加银行,新交易码功能,错误码等各种参数设置;
  • 独立性,每个银行独立的类,每个交易码都独立的类,可独立开发,开发互不影响,这样方便多银行同步开发,分期 上线;
  • 安全性好,支持SSF数据加密验证,支付USERKEY验证。
  • 更自由,相对于标准的EPI来说,可以自由的使用自定义表,方便做更用户化的自定义开发。

2.已有功能:

  1. 发送支付指令;
  2. 查询支付状态;
  3. 余额查询;
  4. 交易明细查询;
  5. 电子回单;完善中
  6. SNC用户加密uKEY,加密及权限验证

事实上,如有其它交易码需求的话,参照已有的交易也能快速的实现其它的银行交易支持,其中中国银行就做了票据的开票,开立等功能。

3.当前代码已支持银行:

  • 中国银行
  • 建设银行
  • 工商银行
  • 农业银行,此银行使用的是SOCK,需要JAVA开发支持
  • 交通银行
  • 中信银行
  • 民生银行
  • 江苏银行
银企直连-自定义EPIC - 第1张  | 优通SAP

SAP中连接使用功能细节请联系

在连接银行时,农业银行,南京银行使用的是SOCKET方式,而SAP不支持这各方式的连接,在ECC时,只能做一个SOCKET与WEBService之间的转换服务来完成,在HANA S4时,据说是可能使用WEBSOCKET来实现SOCKET的,但我没试过,可以参看DEMO_SEND_AMC,DEMO_APC_TCP_CLIENT。

银行错误代码整理