On Jun 7, 2008, at 3:41 PM, Jacopo Cappellato wrote:
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.
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
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?
For point #3 we can identify the party to be paid via AP, AP treated
as liability of the organization. In AP a entry should be there which
shows that, to which party how much amount is to be paid, including
the reason; why a organization is paying. Is it correct approach.
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
5) <complain-mode>Was it really 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>
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.
Jacopo
