SAP公司数十年如一日的一直在对SAP软件系统做升级，从早期的R2，到后来的R3， ECC，一直到现在S4HANA以及Cloud。在升级改造的过程中，早期产品里发现的BUG，得到了修复；一些功能得到了扩展，一些老的功能被废弃；软件产品家族越来越庞大，功能越来越齐全，以致现在SAP软件系统成为企业管理软件中的翘楚，市场占有率保持头位。世界500强中国500强等诸多大公司纷纷启用该软件系统，并将该系统作为一个战略平台或者ERP核心平台，成为大公司背后的管理大师。
不过笔者发现，在SAP系统历次升级换代过程中，一些在项目实践中被发现并不太好用，或者有待于提升改造的地方，并没有被优化好，而是一直保持着老的版本里的模式。而SAP公司好像也并不打算在后续的产品升级换代中去优化这些看起来有待于优化和提升的功能。
以MM模块顾问熟知的事务代码MRKO为例，该事务代码用于在寄售采购和管道采购场景中，定期根据我方消耗的管道物料和寄售库存数据，去创建发票，方便后续的支付，实现与供应商之间的定期结算。笔者认为有如下三点值得在未来SAP产品升级换代中做一些优化。
1，MRKO中的DISPLAY和SETTLE功能应该分开。
MRKO事务代码里2个主要功能，一个是导出我方指定时间段内实际使用的管道物料或者供应商寄售库存数量清单，然后与供应商清单，即初始界面上的'Display'(显示)功能；一个是根据我方在指定时间段范围内使用过的管道物料的数量或者供应商寄售库存的数据，触发采购发票，形成我方的应付款，即初始界面上的‘Settle’（结算）功能。
项目实践中，多是采购部门导出数据跟供应商对账，而由财务部门执行结算功能，触发发票凭证。也就是说，显示和结算功能是由不同的业务部门执行的，权限上需要分开，尤其是结算功能，很多企业是规定只能由财务部门用户才能执行，采购部门不能执行该功能。但是SAP系统的权限控制，并不能实现使用标准的权限对象将'显示'与'结算'功能分开的效果。所以项目实践中往往需要基于该事务代码创建一个新的类似ZMRKO的事务代码，这个事务代码里将结算功能屏蔽掉，开放给采购部门用户使用，而将MRKO事务代码不开放给采购部门用户。这样是可以实现权限的分开和控制的。
SAP在未来的产品升级换代和优化中，是不是可以将MRKO里的display和settle功能分开? 要么将该事务代码分成2个，一个只有Display的权限，一个只有Settle权限;或者设计2个不同的权限对象，一个是执行Display，一个是执行Settle。这样项目实践中，就少了自定义的开发了。
2，MRKO事务代码应该能让用户输入过账日期。
MRKO在结算选项里，不能按用户指定的过账日期产生发票凭证，只能以服务器当前日期作为生成的发票的‘过账日期’。SAP这么设计自然有其道理，但是业务实践中，往往因各种缘故，希望过账日期是过去的某个日期。尤其是在月结的时候，用户应该在月底执行MRKO触发发票形成该月的应付款，未能及时执行MRKO事务代码，而是等待下个月初才去执行该事务代码，却发现生成的发票里的过账日期无法是过去的日期，这自然会带来业务上的困惑。
未来SAP产品的升级换代是否可以考虑给用户一个机会去输入一个他认为合适的过账日期呢？
3，MRKO生成的Invoice应该能用一个简单的事务代码直接Reverse。
MRKO事务代码一旦成功触发了发票凭证，业务人员如果发现数据不对或者操作失误，发现普通的取消发票的事务代码MR8M不能冲销该发票凭证，而是需要将相关的货物移动冲销掉，然后根据这些冲销后的物料凭证号去执行MRKO产生一个新的发票，就是与之前的发票相反的发票凭证。也就是说想要取消MRKO触发的发票凭证，比较复杂，手工工作量比较大。
未来SAP产品的升级换代是否可以考虑做一个类似MR8M冲销发票的事务代码，用于直接冲销MRKO触发的发票凭证呢？这样方便业务人员的操作，简化系统操作步骤，减轻工作量。岂不是更好？
聪明的你，有什么更好的建议呢？
2020-02-03 写于苏州市。
