You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bob Morley <rm...@emforium.com> on 2009/10/26 18:38:29 UTC

Can someone help me with "SUP_" prefixed StatusItem entities

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.
-- 
View this message in context: http://n4.nabble.com/Can-someone-help-me-with-SUP-prefixed-StatusItem-entities-tp277041p277041.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.