记一次SAP新业务开发项目

       直到笔者写这篇博文的时候，这个开发项目名义上已经上线，但其实开发以及优化的工作还在继续，数据的修复也仍在继续...

       IT系统环境很简单，一个基于JAVA+Mysql的Web平台，一个是宇宙第一的SAP系统，彼此之间用的是Webservice的方式数据对接；

       在此之前，公司的业务形式上都是买进卖出，不留库存。虽然有一个所谓“集采”的业务，但其实根本没有在走单，系统能不能走得通都还是未知数。于是现在又有一个新的业务上来了，买与卖不平衡导致了会有库存差异，而之前的业务和开发都是基于零库存的模式下进行。这就意味着之前的业务模式走不通，需要重新设立新的业务场景，做一定程度的开发扩展。因为这个业务跟“集采”有所类似，所以打算大部分沿用“集采”的接口，我们把它叫做“贸易通”。“贸易通”中采购端与销售端并没有直接的单据关联（部分），下单，收货，开单，出货，对账等都是独立的。

        

        开发过程如下：

        一、Web下单时采购价格确定

        Web调用SAP的接口，利用Bapi生成销售订单或采购订单。但是在采购价格确定的时候，之前是参考的销售价，但因为销售与采购分离，需要Web上指定一个采购价格。但是调用Bapi的时候，老是会出错，报错说采购价格必须大于0。看来创建采购订单的时候系统会去取信息记录，可是既然用户指定了采购价格就应该用人工指定的。这个问题偶尔会发现，于是直到上线了也没根断。后面经常报错，我突然记起来应该是一个增强搞的鬼。那个增强是在采购创建和修改的时候，跟价格有关的就会强制重新定价，就是这个错误。于是把增强去掉，此问题解决。

        我很好奇当初顾问做这个增强的意义在哪里，而且我也曾经把这个增强给去掉了，如今又冒出来，不解。

         

        二、Web平台发货签收

        Web平台上对采购做发货确认，顺利通过接口到达SAP做过账。但问题是生成的Mseg表并没有记录到签收单号，以至于后面对采购订单做发票预制的时候会提示找不到入库凭证而报错。而之前的零库存订单在对账的时候做过账，而且系统会记录这个单号信息。这个问题其实很严重，但当初给忽略掉了，因为接口里沿用的是原来零库存的业务类别，但这样会跟实际实物不相符。修改此接口添加相关栏位信息即解决；

 

        三、Web平台收货确认

        Web上对销售做收货确认的时候，新的单据类型就是直接过账了，与零库存的业务在对账时过账不同。但还是当初业务模式没有界定清楚，把单据类型定位零库存的类型，于是这也跟实际库存业务不相符。但既然用了“集采”的单据类型，就意味着Web平台那边需要修改。哪知道修改的时候Web平台因为技术原因一直开不了服务，折腾了大半天才搞定！但就是因为这样的错误，业务在补单的时候提交了非常多的单据，也在系统里面生成了非常多的自建表垃圾数据。所以还得IT人工在SAP里面一条一条修正，非常费力。

       收货确认的时候，Web首先会去读SAP上转单的库存，取的是MATDOC这表移动类型为413的记录，意思是只取从仓库库存转到销售订单库存的数据。但实际上这个大错特错。作为IT人员，永远不要想着框死限制用户的操作。所以商务在系统中补单的时候，是各种操作都会出现，比如从销售订单库存转销售订单库存，从销售订单库存转仓库库存，甚至还有很多冲销的单据。如果这些都不考虑进去的话，Web上显示的永远都是错的。所以这个接口又得大概，变成了取实时销售订单库存表Mska。问题才彻底得到根绝！

       因为开发接口的时候太局限了，考虑的场景单一，也给后续IT的维护和扩展阻碍了不少！

       

        四、采购对账

        既然在发货签收的时候采购就做了过账，所以采购对账的时候只是就基本上没有采购啥事儿了，只是生成了对账单而已。但整个对账单正确与否直接关系到后续的发票预制。

 

        五、销售对账

        “贸易通”的销售对账事儿也很多。因为收货确认环境里就已经做了过账，所以在对账的画面这些记录的状态都是不对的，过账会报错。同时更搞的是一旦碰到月初补单，而财务未完成月结未开账就会出现Web上收货确认到系统中只是做了一个交货单创建而已，实际上连过账都过不了，而对账的这个画面的记录状态自然也都是错的，经常会提示签收单修改失败或开票失败等情况。对账画面本身也有缺陷，并没有考虑到月初补单的情况，也会出现账期未开的报错。还得让用户手动去修改交货单里面的实际交货日期，再过账，这个是很不对的操作方式。

        因为“集采”/“贸易通”的对账程序存在跟业务不符的情况，比如把仓库发货到客户的环节（S5）当成是退货来处理，这点就很匪夷所思了，并没有测通或者没有考虑完全的情况，因此依旧会出现对不了账的情况，甚至还会出现开票金额出现错误的情况。

       

       六、接口模式问题

       本来SAP提供的RFC是非常完美的跟第三方接口的解决方案，但不知道为何当初乙方顾问就摒弃了RFC模式改为Webservice。导致了现在SAP里面所有跟Web的接口都整合在一个Webservice地址里，这样每修改一次接口（涉及到传入传出结构调整），就要发布一次Webservice，非常的麻烦。而且一旦有两个开发项目都动用到了接口，因为共用一个Webservice地址的原因，会出现“串位”的情况，给IT的开发和维护带来超极大的不便麻烦。用RFC通通没有以上那么多的原因。

        有心推翻现有模式，对SAP来说并没影响，但Web那边，就哭天抢地了，无能为力...

         

        以上大概记录这次“贸易通”项目的开发情况。感慨的是作为IT人员，对解决方案的制定以及业务模式的理解，并完美得落地到系统中并不容易，总是会有遗漏疏漏得地方，就得后期一笔一笔来修复数据，耗费极大的时间。对项目的后期测试尤其重要，多测试几个场景，不能怕修改，不能怕麻烦，但考虑的地方尽可能周全，也不要抱有希望去限定和框定用户的操作方式。对用户的培训也是至关重要的一个环节，否则数据会产生很多不必要的垃圾。方案制定的人需要具有非常灵敏敏感的头脑，对接口模式的制定也需要考虑到后续的扩展性。就像Webservice的方案，完完全全就是一个糟糕的设计，真心不像是一个乙方顾问应有的专业体现出来的。