We use our unfulfilled tab to pack orders. The problem is that refunded and canceled orders show up under the unfulfilled tab even if I mark them as fulfilled in the bulk options. How can I get these orders out of the unfulfilled tab on the orders page?
Shopify folks, please add a few business people to your development group. These work-arounds are totally unacceptable in a business environment; we need clean and defensible transaction history. No one should have to reconcile activity in their head when viewing a dashboard or a report. If Shopify is to scale with the growth of online businesses, it must take this next step quickly. This is your customers' life blood.
Nick here, the original Shopify responder on this post. I just wanted to share my thoughts with you on this one:
Firstly, I can totally empathise with the frustration a lot of you here are showing. It's understandable, as the unfulfilled reporting message is somewhat glaring and sticks out in your admin, and may not accurately reflect how many of you feel instances like these should be handled by the platform. As such, your feelings on the matter are warranted, which is why I've decided to post in response.
There's one thing I want you to keep in mind when thinking about this: What "State" is the order actually in, and how should fulfillment be shown as a result?
When an order is received by a merchant, it goes through several stages. The order is made, payment accepted, fulfillment initiated, and the the product delivered as a result of that fulfillment. In this, we have four stages to which I'll refer to two of for the rest of this post. In your admin, they are Payment status, and Fulfillment status:
Payment is obviously one which can have many varying reports, and it's not the topic of this post, so I'll leave that one alone, although it's worth noting that the state of payment will often inform how you are feeling about the fulfillment status.
By that, I mean that the issues you are facing above occur mostly with order's payments that are cancelled, refunded, partially refunded and adjusted in some form.
To illustrate my point, I'm going to speak about what stage of fulfilment an order is actually in for the above payment statuses, and what stage they are not in, which informs the reporting for fulfillment you are all worried about.
If an order is refunded:
This means that the payment has been returned to the customer, and we'll assume fulfils has not been hit, as then the reporting would say fulfilled. If you refund an entire order, without having sent products already, then that order, is unfulfilled. Nothing has been sent. There is nothing to send, as it's been cancelled. As such, it is listed, correctly, as unfulfilled. The easy fix for this is when refunding an order, to fulfil it, which will get rid of the reporting, and then not fulfil it in actuality. This will mean you will not see unfulfilled in the orders page for that order. More on this workaround later.
If an order is partially refunded:
The above remains true. Hit fulfil on what parts of the order are to be refunded, but do not actually send them. This type of order is also not ever going to be wholly fulfilled, as there's a return, however if you don't want to see fulfilled, hit fulfil and don't do it really.
If an order is cancelled:
This triggers a refund, as such the first example holds true here also.
Now, there is another very good reason why you should not do the above hacky workaround to remove all unfulfilled reporting messages from the admin. It's very simple, and it has to do with your reporting, both to gain insight in general from reports, with respect to inventory management, consistent reporting of returns, and accurate fulfilment reporting.
If you mark orders that have not been actually fulfilled as fulfilled, IE mark orders which should not be fulfilled (Returns, partials, cancellations), as there is nothing to fulfil, you are not accurately reflecting the state of the order, and this inaccuracy will have to be manually accounted for anyway, as many of you have noted.
Here's an example:
John has 10 orders. 8 are fine, but 2 are cancelled. John fulfils the orders, all of them, but refunds the two that aren't valid, and doesn't actually send the items, in the way I've mentioned above. This will get rid of the unfulfilled reporting in the orders section. As such, John's store will report incorrect fulfillment, as the platform will understand 10 order have been fulfilled, while only 8 have actually been paid for. This will create problems.
The above workaround also adds extra steps, which is annoying, and as mentioned, it will also mess up reporting. This is why there has been no changes to the way we show these orders: Because it is correct. If an order is cancelled, partially refunded, or entirely, then either a part or all of that order, is going to be forever unfulfilled. Like a dream that was never realised, a beautiful product order from your store that can't be paid for, it will never change from the state it is in, as by it's nature, it cannot, without messing up other areas of the store, as it should. The reporting you are seeing, with refunded, cancelled orders showing as unfulfilled, is showing correctly, as that is what those orders are, cancelled, refunded, yet still all unfulfilled orders.
When we take this perspective, we can see that despite the fact that it may not look great on your orders page for some, and not match exactly with how some think it should work, this is the way it is supposed to work, and it is accurately reflecting the state of fulfillment for those orders.
Furthermore, I’ve seen some of you have posted about issues with third party fulfillment services: This is expected when dealing with alternately designed and intended systems. They do not fit together as easily as we would wish. Another mismatch often quoted to me in the same frame of mind is the difference between how Shopify’s analytics work and show data, compared to data shown in google analytics! The simple fact is: They are not the same, are designed, constructed, and intended differently, so any similarity between the two is down to the data being the same or chance. You will always likely have to undertake some work at some stage to get two distinct systems to work together. It’s also the case that many third party services have absolutely no issues with this. As Clement noted above, when using the api one should check if the cancelled_at field is not null to detect cancelled orders, not use the fulfilment variable, the cancelled_at field just needs to be checked first.
In conclusion: This way of reporting fulfilment status is, in no particular order, likely to make your orders page look cluttered, but have your store reporting correctly, it may result in some issues with third party API’s, however they can be accounted for on the third party end.
Thank you for your time and for addressing our concerns. That said, this is a pretty extensive and intricate rationale for the system simply not working as it should. Some of us are overseeing the Shopify process, and not actively involved in executing the transactions. We want to see the volume and size of transactions, and know at a glance whether our people are keeping up with website traffic. I don't want someone sending me filtered reports, I want to see the activity in real time whenever I choose to look at it. It is extremely inefficient for us to open up different transactions to figure out whether they are labeled unfulfilled because they were refunded, or unfulfilled because they haven't been processed. The "Partially Refunded" unfulfilleds are the worst of all. I shouldn't have to read individual emails to figure out what is going on. This is a typical and very standard business process, and should be binary. It's done or it's not. I hope that Shopify will rectify it quickly because clearly it is causing great heartache for businesses accustomed to transacting business normally. If the "Unfulfilled" label is problematic for you, perhaps you can devise another category for these transactions that indicates they don't require action.
Thank you again,
Ditto! The refunded and cancelled order should automatically change the unfulfilled status so we're not always second-guessing the status from here into eternity. Why so difficult?
Needless to say, this is really unfulfilling for me too.
we just need MORE STATUS states ...seriously,
Canceled Closed Refunded...all seem like no brainers! Big commerce gives us TONS! You should be in the market to make those changes
This cannot be that HARD to give us!
Your total "logical" explanation ignores the most fundamental logic of all - its so obvious that even a child would tell you = you don't mark something filled if you didn't really fill it!
This is the worst example of someone not listening to problems but explaining why their system works the way they want it to work - the mistake you're making is YOU ARE NOT THE CUSTOMER - we are! Learn that or you can find out the hard way that you don't have any.
My suggestion is simply remove the "unfulfilled" status from "new orders" because it's confusing everyday to look at the shop and see orders but not know if those are new refunds that were not marked "fulfilled" before refunding or actual new orders.
Lastly - the most obvious problem is that you can't just automatically have the system mark the order as "fulfilled" when any of these actions occur: "refund, partical refund, or cancelled".
This is Madness. Why would I mark an order fulfilled if it was cancelled or refunded and how would it then NOT be fulfilled by our 3PL???
I really am at a loss as to how to remove cancelled and refunded orders from the unfulfilled status
Thanks for taking the time to reply...
My suggestion is "unfilfulled" is a problem for many people so how about just removing it?
Thanks for your help,
I, too, am joining the frustrated group. Customer cancelled. Refunded order 100%, voided it. It's sitting there, "unfullfilled" with the glaring orange, mocking me. It's also included in my total open orders count - the little green number above "orders" in the menu on the left? Very frustrating. Filtering it from display is one thing, a workaround. Getting rid of it in the status is another issue altogether?