Transaction的status profile上可以配这么一个东西：
但是我们现在的ZSRV上没有配任何status profile… 这个to be distributed即使设成Forbidden一样会发， 下图是我测试的status profile
代码里写的是如果status是for postprocessing I1143就不发，我没有在代码里看到检测 to be distributed 的地方。
如果你们可以成功重现不让One order通过middleware 往outbound queue发数据，麻烦告诉我详细操作步骤。
iv_no_bdoc_send
lv_send_bdoc
现在差异就是：
配了status profile，订单能编辑
Status profile为空，则不能编辑
Status profile为空，点Edit后Error message 是在这个IF里抛得。只要order的状态带有transferring,则报error message
配了status profile时，order save后状态是I 1002, E 0001, 不含transferring状态，所以不报错。
没配PROFILE， 则save后状态如下，包含I1054 transferring，所以报错。
所以问题根源就是搞清楚报错order时，这个status迁移是怎么实现的。
Service order transaction type若不维护任何status profile，则save之后无法编辑，点edit 时报error message
如果维护了status profile，能够编辑
One order在edit button点击时会check order是否含有transferring状态，如果有，报error message
n 两种情况下，save order时系统都会试图去给order设置transferring状态，但是只有第一种情况会设置成功。
第二种情况，因为status profile里forbidden flag（后台value：3）的存在，
检测程序里检测到这个3，就会拒绝修改，所以order状态不会变成transferring，所以UI能edit
有两种solution disable这个行为：
(1) CRM_ORDER_SAVE call line 56行的CRM_ORDER_SAVE_OW时，IV_NO_BDOC_SEND没有指定value，所以传进来的是默认值ABAP_FALSE,
这里我们强制改成TRUE, 就会破坏要上传的那三个条件的第一个，导致不会进入上传的分支。
(2) 如果只是想disable 某种特定transaction type的document，call这个function module：
CRM_ORDER_SET_NO_BDOC_SEND_OW， 输入order的guid，会添加一行entry到GT_NO_BDOC_SEND里，
这样会破坏IF判断里中间那个条件，也能实现不上传的目的。
条件2少截一张图：
条件2： LV_SEND_BDOC = TRUE
读这个global的internal table，如果读不到，置为TRUE,AG9上读不到，所以为true，这个条件也满足了。
line 325的function module会负责通过outbound queue往外发，
只有当line 321的IF里的三个条件同时满足才会进入：
条件1： IV_NO_BDOC_SEND = FALSE, AG9上这个参数用的默认参数false，满足
条件3： LV_SKIP_ASYNCRONOUS_FUNCTION = INITIAL
如果该order的状态置为POST PROCESSING, 则该变量值为true，但是AG9上我们的status是open，所以这个条件也满足
三个条件同时满足，所以通过middleware里往outbound queue发数据。