SAP标准的银企直连功能是EPIC，但这功能包在了标准程序中，现实中很多项目需要自定义开发，并连接到自定义的程序中，所以整理打包一个银企直连的功能类，此类功能也是原自于标准的EPIC,但做了自定义开发，可支持大部份银行的银企直连功能（支付WEBSERVICE ,HTTP操作协议的所有接口功能），更多细节请联系。
标准EPIC,可从这里了解。
标准的EPIC，功能很强大，细节也很多，但之前用过的几个项目都没使用标准的EPIC来做银企直连接使用，猜想可能与以下几点有关，
- EPIC需要另外购买授权，也就是还要另外化钱；
- 功能太复杂了，一般的FICO功能可能搞不定，还得找专业的顾问来进行实施，也是钱的问题；
- 好多时候我们只想简单的完成对供应商，客户，或者个人进行转账付款就成了，没有标准EPIC那么复杂的需求；
- 标准EPIC，在自定义需求时，还是局限性太多，不方便完全自由的进行自定义开发；
- 标准EPIC，为了通用性，一些设置（配置）逻辑还是太麻烦了，比如他定义银行通讯时，是主键是定义到公司/开户银行/账户标识，这样的结果就是，有多少个付款账号那就要做多少人通讯配置，这以后新增一个付款账号，那还得找业务顾问进行配置，这太麻烦了，我也不确认是不是我理解错了。
所以才会有自定义的EPIC功能，又或者用第三方的银企直连接（拜特、九恒星）进行资金管理。项目中也曾使用过 拜特 ，但其实也就把 拜特 当成了一人与银行进行交互数据的接口软件，他的资金管理功能也是全没使用，但由于增加了一层第三方，出问题时查询的更长了，当然这第三方的成本应该不会比用标准EPIC的成本低了。所以，如是只是银企直连，是自定义的功能，不使用的标准EPIC的话，用自定义的EPIC功能，可能是最好的选择。
1.优势：
- 可配置性，支付新增加银行，新交易码功能，错误码等各种参数设置；
- 独立性，每个银行独立的类，每个交易码都独立的类，可独立开发，开发互不影响，这样方便多银行同步开发，分期 上线；
- 安全性好，支持SSF数据加密验证，支付USERKEY验证。
- 更自由，相对于标准的EPI来说，可以自由的使用自定义表，方便做更用户化的自定义开发。
2.已有功能：
- 发送支付指令；
- 查询支付状态；
- 余额查询；
- 交易明细查询；
- 电子回单；完善中
- SNC用户加密uKEY，加密及权限验证
事实上，如有其它交易码需求的话，参照已有的交易也能快速的实现其它的银行交易支持，其中中国银行就做了票据的开票，开立等功能。
3.当前代码已支持银行：
- 中国银行
- 建设银行
- 工商银行
- 农业银行，此银行使用的是SOCK，需要JAVA开发支持
- 交通银行
- 中信银行
- 民生银行
- 江苏银行
SAP中连接使用功能细节请联系。
在连接银行时，农业银行，南京银行使用的是SOCKET方式，而SAP不支持这各方式的连接，在ECC时，只能做一个SOCKET与WEBService之间的转换服务来完成，在HANA S4时，据说是可能使用WEBSOCKET来实现SOCKET的，但我没试过，可以参看DEMO_SEND_AMC，DEMO_APC_TCP_CLIENT。
银行错误代码整理