Hi Jacopo,
From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
I think that there are some issues in the current implementation of
customer returns.
Here is a list of the main ones:
1) the ReturnHeader.needsInventoryReceive field is misleading because
it actually means the opposite: if set to Y then the manual receive
step is skipped and when the return is approved it is automatically
received and completed; if set to N then you have to manually receive
it in order to complete the return. Of course the name of the field is
wrong (or I just don't understand it) and in fact in the UI for the
ReturnHeader its label is (more appropriately) "Auto-Receive On
ACCEPT"; however, IMHO, there is no need for such a field: we could
have just provided a "quick receive return" link (similar to the
"quick receive order" link) to provide a short path to the receive/
completion goal.
+1 for a "quick receive return" link. Where do you expect to put it, in ordermanager (like "quick receive order" link) order view I
guess ?
2) the two ways a return is processed according to the
ReturnHeader.needsInventoryReceive flag are quite different, i.e. they
produce different results (which is not good):
2.a) if ReturnHeader.needsInventoryReceive is Y: when the return is
approved, the system in one step performs the following tasks:
* approves the return
* creates a "customer return shipment"
* receives the return (the shipment)
* creates a "customer return invoice"
* creates a payment to the customer (if the return is of type "refund")
* applies the payment to the invoice (that is then moved to the paid
status)
* completes the return
2.b) if ReturnHeader.needsInventoryReceive is N: then the user has to
manually perform the following tasks:
* approve the return
* receive the return (there is no way, that I am aware of, to create
the shipment)
* then the return is automatically completed and a payment is created
to the customer
The main issue is that no "return shipment" and no "return invoice"
are created and the payment is unassigned. In my opinion we should do,
also for #2.b, what we do for #2.a
+1 : from your information, the 1st workflow seems more complete and adequate this reinforce the need for a "quick receive return"
link.
Are there some cases where a manual process could be needed ?
3) if the return is of type "refund" but the order was paid offline
(no cc), when the return is received it is marked as completed but no
payments are created; instead we should create an open "return
invoice" so that we have a reminder that we have to pay it to our
customer... what do you think?
+1, this makes sense : we need to send a payment
4) if ReturnHeader.needsInventoryReceive is Y and you approve a
"replacement" return, then two replacement orders are created instead
of one; this doesn't happen when the if
ReturnHeader.needsInventoryReceive is set to N
What is the difference between the two replacement orders, are they the same ? If they are doubled I would say it looks like a bug
(no time to look at the code sorry)
5) <complain-mode>Was it real2ly necessary to set the return type
(refund/replacement etc...) in the order item instead that in the
order header? this makes the logic much more complex and in my
opinion, if two different order items need to be returned with two
different methods (i.e. refund and replacement) it would be acceptable
(and maybe even better) to create two returms. Also, is it really
necessary to allow return items from different orders in the same
return?</complain-mode>
As long as we are able to track the returned items I can't see any problems
with creating a return for each returned item
I'm sorry for the long post, but I have tried to summarize the main
issues I've discovered while testing this stuff.
I'd like to get your feedback, then I will try to commit the fixes for
some of them (that I really need for a customer project) and I will
put in Jira the other stuff.
I will review, simplify and making reliable this part of the workflow is really
important
Thanks
Jacques
Jacopo
