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，满足

条件2： LV_SEND_BDOC = TRUE

读这个global的internal table，如果读不到，置为TRUE,AG9上读不到，所以为true，这个条件也满足了。

条件3： LV_SKIP_ASYNCRONOUS_FUNCTION = INITIAL

如果该order的状态置为POST PROCESSING, 则该变量值为true，但是AG9上我们的status是open，所以这个条件也满足

三个条件同时满足，所以通过middleware里往outbound queue发数据。