电商后台系统改造项目笔记（7）ERP系统对接

万万没想到，Oracle ERP系统这么难搞。

按照我最初的设想，相当于把ERP架空了，ERP变成了一个类似金蝶、用友这样的纯粹财务系统。新的电商后台系统负责所有业务层的处理，只把处理完成后涉及到对账的凭证给到ERP即可。

但是，在和财务部门领导和同事，以及ERP专家的N次来回沟通后，我明白了：完全在业务操作层上绕开ERP，是做不到的。有些是技术上的限制，如Oracle ERP的信息流数据链非常严密，不能随便切掉某个环节，用外部数据替换。而更多的，则是非技术性的因素导致的。

在项目早期调研阶段，我和财务沟通时，她们就多次表达了类似的观点：咱们公司花了这么大的代价，才上了一套Oracle ERP系统，经过很长时间的改造和磨合，才勉强用起来，虽然不完美，但是不至于出大乱子。潜台词就是，你们最好别动ERP系统，别想改动现有的流程和操作模式。

财务所理解的Oracle ERP，必须是电商业务的主承载系统，订单什么的都要在Oracle ERP里面处理。然而，你去考察下市面上的电商ERP就知道了，根本不是我司这么玩的。我们正在做的这个新系统，就相当于市面上的那些电商ERP系统，从采购到销售都能支撑。我们不得不问自己一个问题：我们这个新系统，意义何在？

说白了，这就是一个“沉没成本”的问题。隔壁部门某同事在了解到这个现状后，说了一句“及时止损”，然而，财务部门对公司有多重要大家是知道的，我们没办法架空已经在运行的ERP系统。

该对接的还是要对接，无非就是多一些开发工作量，架构复杂了一些，以后不太方便灵活扩展罢了。

（一）商品管理机制

领导坚持要以ERP为主，在ERP侧添加和管理商品，参考下图：

仓库同事反对这个方案，因为上面这个方案就意味着：每次新增商品，都要在两个系统分别执行一次，并在新系统中手动关联一次。操作上效率是比较低的。

你可能会感到奇怪：为啥需要在新系统侧手动新建SKU，而不是自动创建？这是因为两个系统的商品命名机制不太一样，无法直接从ERP同步到新系统并自动创建对应商品（反向同步倒是可以的）。有点抽象？看下面这个对比例子你就明白了：

我提议的方案如下：

如上图，只需要在新系统单方创建一次商品（SKU），接下来就让系统自动去完成同步和在ERP侧自动创建商品。

领导不同意我的方案，认为应该以ERP为主来管理商品。这事儿我说了不算，所以最后还是用领导的方案来执行，我只能表示无奈。

（二）采购订单与采购入库

有了最基础的商品数据后，我们接着处理采购的问题。

财务部门认为采购很重要，涉及到很复杂的会计科目计算，不能剥离到新系统去处理。沟通几次未果，只能按照他们的想法来设计处理流程。

如下图，采购下单和数量入库环节放在ERP，但是SN导入环节放在新系统（我们的主要产品是需要序列号管理的）。

此流程对仓库来说有点不顺手，因为需要在两个系统分开操作入库。实际上完全可以把ERP侧的“采购入库”环节放在新系统侧的，但是财务不同意。。。

（三）销售订单与销售出库（正向流程）

销售出库的流程比较简单，无非就是把订单本身和出库结果都告诉ERP那边就行了。

（四）销售退款（仅退款）

还没发货的情况下，销售订单可以执行仅退款的逆向流程，如下图（部分细节做了精简处理）：

（五）销售退货退款

已经发货的情况下，销售订单可以执行退货+退款的逆向流程，如下图（部分细节做了精简处理）：

以上这些流程的处理方案，并不算完美。在诸多现实因素的限制下，和ERP的对接做到这个地步，我也只能说，我们尽力了。。。