I have been doing a little work on returns for purchase orders and I came across a duplicate set of StatusIds for the RETURN_HEADER when it is a supplier/vendor return vs. a customer return. My initial impression was that this was a poor choice in modeling; combining the status to include additional data in it. The second part was that things like "updateReturnHeader" in order's seca.xml is only configured to execute for "RETURN_CANCELLED" (not the SUP_ prefixed variant).
Here is the ECA as it is defined:
<eca service="updateReturnHeader" event="commit">
<condition field-name="statusId" operator="equals" value="RETURN_CANCELLED"/>
<condition field-name="oldStatusId" operator="not-equals" value="RETURN_CANCELLED"/>
<action service="cancelReturnItems" mode="sync"/>
<action service="createReturnStatus" mode="sync"/>
<action service="sendReturnCancelNotification" mode="async" persist="true"/>
</eca>
My solution was to clone this (removing the sendReturnCancelNotification) for SUP_RETURN_CANCELLED. It would seem to me a better approach would be to leave the the statuses alone and make use of the returnHeaderTypeId (CUSTOMER_RETURN vs. VENDOR_RETURN) when business logic dictates. In this case that would either be in the definition of the ECA or in the "sendReturnCancelNotification" implementation itself.
What I have noticed in our use is that the returnItems do not properly get cancelled when the returnHeader is cancelled (for a PO) (the result of this ECA) and then certain implementations have not been enhanced to consider these "additional" status (ie. OrderReturnServices.getReturnableQuantity near the bottom where it is excluding returnHeader of type RETURN_CANCELLED only).
Am I missing something or can someone point to problem with my logic? I would like to fix up these services, but my preference would be to remove the SUP_* statusIds.
Locked
