1、刚才有个程序，调用bapi创建po，顾问测试的时候，说价格有的时候不对。
另外一个资深业务说，这个是因为系统会自动复制上个对应物料、供应商、采购组织的上个采购订单的价格。然后，我就去bapi_po_create1里看了一下传入页签的参数。里面有个no_price_from_po。
搞定了
我觉得系统不会傻逼到不提供这种参数控制
遇到问题不可怕
最开始想的是去设置bapi的conditions内表参数
但是这个太麻烦了，肯定也能解决
我们业务说，可以设置一下个人参数，有个parameter id可以控制这个
有的人就准备用这个方式去做了
就是别人怎么说 她就怎么做
反正咱们一定要习惯去否定
否定别人 否定自己 否定常规
2、1、连续调用bapi，不是说连续调用某一个bapi，比如loop里调用bapi，这个不是我说的连续调用bapi
连续调用bapi，是说调了bapi1然后调用bapi2
2、关于缓存，bapi1和bapi2如果是业务相关的，则很有可能调用了共同的模块池的程序，导致程序堆栈里存了不同模块池的变量
收货、发货是这样，维护工单、维修通知单是这样
3、destination 'NONE'的作用。加了这个语句之后，bapi1在当前的服务器上运行，bapi2在destination 'NONE'上运行。两个程序在不同的destination上运行，程序堆栈也是不一样的，这样也就起到了清缓存的作用。
4、的note（1923267）里，提到了rfc_connection_close这个函数，关闭destination，清掉destination的缓存，这就更好了。假设连续调用时，还有bapi3，bapi3也可以指定在destination上运行了
5、关于隐式提交。call function 'xx' destination 'none'，会触发隐式提交，但是是在当前的服务器上触发隐式提交。
第一列，代码顺序。第二列，当前服务器的执行操作。第三列，NONE上的执行操作
一、技术
oo的操作 是在pbo以后显示出来控件，在控件上操作的动作。不允许有e消息，不然就被程序认为oo错误然后退出了。一般oo里的操作不会触发pai，进不了pbo，所以主窗口也就不会刷新。，同样你操作完主屏幕，不回车就去操作oo，oo里也读不到屏幕上的新值，需要用dynp的那个get函数
二，业务
需求调研，知道自己问什么，关注什么
蓝图设计，知道蓝图设计的意义,这两点xx做的都不好
这些是后续工作的基础,
蓝图设计出来，有几个目的：
1、指导后续的业务工作流程，让业务操作有据可依，没有漏洞符合内控要求
2、指导后续的实现工作，标明哪些是sap标准的，哪些是接口的，哪些是需要开发的
3、指导后续的权限工作，如何收集和分配用户权限
所以，蓝图，一定要仔细
想成为专家，就要精益求精。有些时候需要跳出来思考，有些时候需要就细节讨论。这种把控比较难
有大方向的考虑，有小细节的考虑。我比较擅长后者
当你发现自己有成长的时候，这是最关键的时候，你要抓紧总结自己，看看自己为啥在别人身上学到了，看看自己为啥没想到，比如，我来到这边看人家的调研问卷，设计的真是牛逼，我就觉得人家问的问题确实牛逼，我就觉得人家看问题的高度不一样啊，到了蓝图设计阶段，我发现,他们还是很多问题不够清楚，还是要用户一遍又一遍的解释他们的现状，我又了解了之前没了解的东西，这就说明他们调研是有问题的，虽然很细，但是还是有问题，调研的问题里，哪里设计的不合理，这个需要在工作中慢慢的去总结了，意思就是，做项目，第一次坎坎坷坷没关系，但是要总结。根据后续工作中的坑，反过来思考前期工作的缺漏，前车之鉴后事之师，要做到这个，你作为业务的话，根据业务实现的工作过程（是工作过程，而不是结果）反过头来思考你的调研阶段，这个是很重要的，
