Issues with customer returns

[Jacopo Cappellato-3]

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?

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

[Sumit Pandit-3]

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
>

[Jacques Le Roux]

Hi Jacopo,

From: "Jacopo Cappellato" <[hidden email]>

>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
>