I remember we saw this in 6.3 already.
The problem I think is when the process associated with a subprocess task ends with a delay task, the package will not end the parent subprocess task.
This also applies to the components in orchestration plan since the implementation I believe is derived from the subprocess implementation.
If I remember correctly, we had a workaround for this, by placing a null task after the delay task I guess.
Or the alternative proposed above. However, this won't work if you only want to have the delay at the edn when the process flow goes through a aprticular path...
Ok now, when the order execution has gone into wait condition, OSM cannot process amendments at that instant & until the wait period is over.
But, What I have observed is, OSM is throwing exception initially but once the waiting period is over, order is going into amending state.
Well, in that case, you can define some conditions in Order Life Cycle policy => Submit Amendements. Here you have an option of having an XQuery. From the GetOrder.Response, you can get Task details. Write condition around the Task Name and using the Java, you can set the delay inside the XQuery.