什么会导致数据不一致，归根结底多半还是Commit/Rollback。
这个message的始末大概是这样
一开始：
这个FM ASSORTMENT_MAINTAIN_MATERIAL里面有功能是populate material segment (e.g. MARC)，但是有个问题就是它每处理好一部分就会dequeue掉，却没有commit work。这样就容易出现DB01的锁，别人要用，enqueu成功，确碰上DB锁。有时候甚至有deadlock。所以必须要改进。
后来：
开发同意改，但是不愿意改dequeue的问题，只是在每处理好一部分后就commit一下。--当然是在判断不是update wp之后。 当时觉得这个fix可以啊，貌似没有什么大问题。
再后来：
客户在pos inbound的时候出现了不少不一致的问题，比如有billing doc没有material doc。当时知道肯定是建material doc当中有问题有commit什么的。代码是先建billing再建material doc的。大家都想去看看user exit/enhancement里面有没有commit。没有想到是这个pilot note。最后知道原因再倒过来才想到，在那个FM里面写commit肯定有问题的，因为我们不能保证这个是怎么调用的，不能只想到常规的listing，因为还有这样的sequent listing的情况（就有更多的application doc），不能随便的commit的。
这个有billing没material doc就是因为：
- billing doc创建成功了，因为structured article在billing不展开（？）
- material doc要展开，举例如果有2个以上的componenet都没有marc。第一个去subsequent listing，然后commit了，那么billing就生成了，然后第二个subsequent listing，但是人家在用，锁住了不能处理，最后fail。这样就没有material doc了。
未解之迷：
客户有两种问题，虽然类似仍有不同：
1-有billing 没有 material doc，status = 51 （已解）
2-有billing 没有 material doc，status = 53，但是log表里面有错误信息说一个component没有maintain。
我还是无法理解为什么status会是53，因为照理status是最后写的，只要有一点错误status都会包括。