记一次SAP新业务开发项目

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

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

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

        

        开发过程以下：

        1、Web下单时采购价格肯定

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

        我很好奇当初顾问作这个加强的意义在哪里，并且我也曾经把这个加强给去掉了，现在又冒出来，不解。

         

        2、Web平台发货签收

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

 

        3、Web平台收货确认

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

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

       由于开发接口的时候太局限了，考虑的场景单一，也给后续IT的维护和扩展阻碍了很多！

       

        4、采购对帐

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

 

        5、销售对帐

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

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

       

       6、接口模式问题

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

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

         

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