两个 iFlow 在几秒之内先后修改同一张 Sales Order，第一条消息正在处理，第二条消息几乎立刻返回V1 042。Sales document 1 is currently being processed by 2这种场景在 SAP Integration Suite Cloud Integration、传统 SAP PI 或 PO、自建 RFC Wrapper、批量接口程序里都很容易碰到。看到这个错误时，团队里很容易出现两种判断，一种认为 Cloud Integration 并发太高，在 iFlow 里加几秒Delay就行；另一种认为 SAP 后端性能不够，把 RFC Timeout 或重试次数调大一点就能解决。但沿着BAPI_SALESORDER_CHANGE的标准代码真正追进去以后，会发现方向并不在 CPI，也不在 HTTP 或 RFC 网络层。问题发生在 Sales Document 自己的标准锁机制里。而且最容易误判的一点在于，第二次调用并不是等了一段时间才超时，它可能在零点几秒甚至几十毫秒内直接返回V1 042。这是标准程序有意设计出来的行为。在两个实验系统中检查过这一调用链，一个是 SAP S/4HANA 2020，对应SAP_BASIS 755，另一个是 SAP S/4HANA 2023，对应SAP_BASIS 758。两个版本在这一段核心