Order status: Reversed

Hi everybody,

I am wondering when to use order status "Reversed" ?

Actually I have a case there my customer has returned a product. Now I would like to change order status to "Return received" or "Returned". Any ideas?
Reversed feels like as a wrong word to use for returned.

Reversed usually applies to payments that get reversed for some reason (e.g. chargebacks). You can set whatever order statuses you want in System > Localisation > Stock Statuses

(I am bumping this old thread because it shows up on Google search results, and in 9½ years there apparently has been no progress in even attempting to clarify the default order statuses.)

Johnathan wrote: ↑

Thu Mar 15, 2012 8:48 pm

Reversed usually applies to payments that get reversed for some reason (e.g. chargebacks). You can set whatever order statuses you want in System > Localisation > Stock Statuses

We're using the built-in, default set of order statuses that came with OC 1.x/2.x, and I am seeing a separate status for chargebacks. It literally says: Chargeback. These two have also made to the latest SQL here, where they are even next to each other. This must mean Reversed must have been intended for something else. Either that, or the stuff is all over the place.

UPD: Found Daniel Kerr used it as a standalone term:

if a customers order goes reversed he should know about it

Some payment processors (PayPal mainly) will return a status of Reversed, which is not necessarily the same as a Chargeback. Although it could be as a result of a chargeback.

I think the default list is down to a combination of the status that different payment processors return. Take a look at the PayPal Standard module, there are 10 different statuses that PayPal could return!

I think ADD Creative is right, lots of them seem to be based on PayPal, probably since that was the "main" payment method when Daniel released the first versions of OpenCart. With credit card processors I don't think "Reversed" is necessary, since "Chargeback" seems more appropriate. Fortunately, it's easy enough to tailor the order statuses to whatever your store needs, I'm glad Daniel had that much foresight and didn't hard-code them.

Johnathan wrote: ↑

Thu Sep 30, 2021 10:42 pm

I think ADD Creative is right, lots of them seem to be based on PayPal, probably since that was the "main" payment method when Daniel released the first versions of OpenCart. With credit card processors I don't think "Reversed" is necessary, since "Chargeback" seems more appropriate. Fortunately, it's easy enough to tailor the order statuses to whatever your store needs, I'm glad Daniel had that much foresight and didn't hard-code them.

Except that people still won't be able to compare their stores' order statuses with their payment / shipping service providers' without capturing the right order status names in order for store owners to complete their final settlements.

Sorry, I'm not sure I follow. The entire point is that you CAN change them to match your payment / shipping service requirements --- if Daniel had hard-coded them with particular titles (e.g. "Reversed" couldn't be changed into something else) then that WOULD have caused the problem you mention. As is it now, if you need a particular order status you just create it.

Johnathan wrote: ↑

Fri Oct 01, 2021 9:20 pm

Sorry, I'm not sure I follow. The entire point is that you CAN change them to match your payment / shipping service requirements --- if Daniel had hard-coded them with particular titles (e.g. "Reversed" couldn't be changed into something else) then that WOULD have caused the problem you mention. As is it now, if you need a particular order status you just create it.

The order status is created for the entire store but is not categorized into the orders, and that being, with their service providers. Yes, indeed, store owners can either create and change the order statuses into what they want but there's only one order status option they can select within the order rather than separating the order statuses with their descriptive significance of each parties. Which is why, there's a discussion on Github Opencart repository right now that explains this theory regarding the relationships between the order statuses from the stores and with their service providers since the API documentation between these services may differ their share of views regarding the order statuses names. Rather, these order statuses should be purely divided by the extensions being installed rather than configuring these order statuses all in one-place as a final settlement handling both services at the same time as one being order status as it is now. In the end, the order statuses handled from the stores should be handled as a final settlement only for the store owners to complete the orders whenever the case.

Discussion: https://github.com/opencart/opencart/issues/10231 .

Ah, I see what you mean now. You're right, this would offer more flexibility, so it could have some benefits. However, it wouldn't allow for using standard statuses for the fulfillment flow of the store. For example, lots of stores use Pending > Processing > Shipped > Complete as the flow of their own orders, regardless of what the payment gateway returns as the status. Personally, I'm not sure I'd find it preferable, but if Daniel decides to change it I'm sure I'd adapt.

Johnathan wrote: ↑

Sat Oct 02, 2021 10:11 pm

Ah, I see what you mean now. You're right, this would offer more flexibility, so it could have some benefits. However, it wouldn't allow for using standard statuses for the fulfillment flow of the store. For example, lots of stores use Pending > Processing > Shipped > Complete as the flow of their own orders, regardless of what the payment gateway returns as the status. Personally, I'm not sure I'd find it preferable, but if Daniel decides to change it I'm sure I'd adapt.

I updated the discussion yesterday. It also won't cover the order status IDs of value 0 (abandoned orders) prior from the upgrade versus the upgraded database versions while the orders being transitioned via other order statuses from both service providers. This part is a bit more complicated to deal with as a workaround due to the logic between parties it may require in order to build a flexible solution on this.