RMA flow

[Serabe]

We are experiencing some issues with the request authorization => customer returns => reimbursement flow. I am showing these flows starting with the sample data loaded and shipping the order.

The normal flow seems to be:

• Create a new return authorization:

• Then create a new Customer Returns,

• Finally create a reimbursement and reimburse it
  
  

On the other hand, we can create a new Customer Returns directly as follows (starting point is the same as previous flow):

• Create a new Customer Returns

• Select the item in Other items in order.
  
• You get a flash notice that the Customer Returns was created successfully (it disappears to quick to be easily captured). Furthermore, it is a rejected customer return and get the error {:rma_required => "item requires an RMA"}

• If we try now to create a RMA we cannot do so because the item appears as returned

The new return items that allow the user to do the last flow was introduced in 834a24a. In the commit message "Paves the way for non-return reimbursements." can be read.

The second flow seems a bug to me, but it might be that I am not understanding the way to non-return reimbursements (though I might be mixing two unrelated things here).

[Serabe]

The screenshots are taken from master, but this is happening in 1.2 as well.

[jordan-brough]

@Serabe do you want to require RMAs for returns?

If you don't then you should update this list to remove the RMARequired validator in your app. E.g. in an initializer:

Rails.application.config.to_prepare do
  Spree::ReturnItem::EligibilityValidator::Default.permitted_eligibility_validators = [
    ...
  ]
end

Something important to know: A lot of the returns work was built with automated returns in mind, since that's what Bonobos (who authored most of it) did. E.g. you might provide prepaid return shipping labels inside every box you ship and then you may use a 3rd party warehouse to receive returned items (this was the case for Bonobos).

With that in mind, some definitions: (If we can make sense of all this, I'll try to open a PR to add more documentation to Solidus itself)

A ReturnAuthorization represents a pre-authorization for returning some items. Your store may or may not require pre-authorization, so ReturnAuthorizations might not be necessary for you. Even if you don't require pre-authorization, you might create a ReturnAuthorization to override the default reimbursement method for an item when it arrives, or to set up an exchange to happen when the returned item arrives. ReturnAuthorizations are composed of ReturnItems.

A CustomerReturn represents something being returned to your warehouse. It may or may not have been pre-authorized, and pre-authorization may or may not have been required, but whether it was required or not it was still returned so a CustomerReturn is created and a corresponding ReturnItem is either found from an existing ReturnAuthorization or else a new ReturnItem is created and only linked to the CustomerReturn.

A Reimbursement represents you compensating the customer for an item. It is composed of ReturnItems, just like ReturnAuthorizations and CustomerReturns.

So, a lot of what you're seeing is "expected", though the UX probably needs improvement and it looks like there is some missing functionality for stores that require pre-authorization. For you example: This return was not pre-authorized (no ReturnAuthorization was created beforehand), yet it did arrive at your warehouse (you indicated this by creating a CustomerReturn), your store is configured not to reimburse items that have not been preauthorized (via the RMARequired validator), so the reimbursement failed.

Some thoughts on what's missing:

• Maybe a warning in the admin UI about creating a customer return without having a return authorization, if your store is configured to require pre-authorization?
• Some way to override the reimbursement failure and approve the reimbursement, even though the return was not pre-authorized (I don't think that retroactively "pre-authorizing" the return by adding a ReturnAuthorization after the fact is the right approach, but it might be)

I'm out of time at the moment but would be happy to hear ideas on fixes for this.

Note: "Paves the way for non-return reimbursements" was about something different.

[Serabe]

@jordan-brough thank you for the explanation, now this is all much clearer.

For your second point on what's missing: I don't think creating a the RMA after is a good solution, but the user is left in a state where it cannot fix the situation in any way I have found: the item appears as reimbursed, but such reimbursement is rejected and no other reimbursement can be created.

Your explanation has been much helpful, thank you for taking the time to write it!

[ajkamel]

This would be a great in the wiki or the guides. I'll keep it bookmarked.

[loicginoux]

the user is left in a state where it cannot fix the situation in any way I have found: the item appears as reimbursed, but such reimbursement is rejected and no other reimbursement can be created.

Would it be a solution, for stores that have the validator RMARequired, to not let the user create a CustomerReturn if the RMA item is not already created ?
We would have an error message before creating the "Customer Return" rather than after. This way, it would let the user continue creating other planned returns or customer returns rather than blocking completely what can be done on the interface.