Refactor Catalyst Orders panel to work with multiple fulfillment methods

[kieckhafer]

Catalyst's (Operator UI) Orders panel is out-of-date, and doesn't work as needed with our multiple fulfillment group updates (#5027, #5024, #5020, #5019, #5018, #5010).

To make the panel up-to-date, we need to do the following work:

• Display multiple fulfillment methods, and items inside the methods separately (Currently, we combine all items from all methods into a single group)

• Make sure the methods are displayed correctly (Currently, we display multiple method sections, but we just replicate a single method over and over, which is not correct)

• Hook up the new mutations to allow for order manipulation with the new methods

This list is not comprehensive, it is simply what was noticed at first pass through. This ticket will be updated with additional work when it's discovered.

[kieckhafer]

@aldeed I have a few questions about how all the new mutations work:

1. we don't have a cancelOrder GQL mutation, we just have cancelOrderItem. Is this on purpose? Is the thought to cancel an order, we loop over all order items and cancel them individually? Based on the comment in the code it seems like this might have been the intention:

If this results in all items in a fulfillment group being canceled, the group will also be canceled. If this results in all fulfillment groups being canceled, the full order will also be canceled.

1. it doesn't look like the cancelOrderItem mutation performs any refunds, or inventory updates. I remember you mentioning the inventory should be done independently, so maybe we need to call the inventoryUpdate separately after an item is cancelled? What about for refunding items that are cancelled? It looks like we might still need to create a mutation for that?
2. Language wise, is cancelling an item the same as refunding an item? As in, if I press the cancel button, should I automatically be refunded? If i press the refund button, should it automatically be cancelled? Or are these two separate actions that need two separate trigger buttons, one cancel and one refund?

[jrphilo]

@kieckhafer Re: question #3, the difference between a cancellation and a refund is dependent on whether the item is pre- or post- shipping. Essentially, when a Customer places an order, a payment authorization is put in place, but no money is taken. Funds are only drawn against a Customers card when an item ships. So an item is "Cancelled" before it has shipped (usually because the item cannot be found in the warehouse). Once it has shipped, payment will have been taken, so any return of the item would now trigger a "Refund". Let me know if any of this is unclear or if you want to discuss any further.

[rymorgan]

@jrphilo Follow up question regarding refunds specifically. For a refund, are there use cases for partial refunds? As in should we provide a way to add a custom refund amount. Or, are all refunds based on the item and item amount? And a follow up if the answer is both, do you have a rough guess as to what percentage of the time it's one or the other.

[jrphilo]

@rymorgan Yep - definitely use cases for partial refunds. These are often issues when a customer failed to receive a certain promotional price and/or offer and the customer rep adjusts the order to reflect this. In this sense, no specific item is refunded, but part of the price is refunded for an item in the order. This occurs on c. 10-15% of refunds. The rest are item specific refunds. Hope that helps. Let me know if you have any follow ups.

[rymorgan]

@kieckhafer @aldeed I think James' comments give enough context and clarity for us around a refund approach. What do you y'all think?

[aldeed]

Yes all the requirements here are in line with how the backend APIs now work. So it should just be a matter of wrapping up UI changes that match. @kieckhafer and I have separately discussed his questions above (essentially everything is completely separate but some UI actions might trigger or prompt for both cancellation and refund).

There is one related server-side issue that I'm aware of: we have some work to do on the concept of "adjustments" in general. For example, some refunds and/or cancellations might need to recalculate tax and some might not. Some should cause a selected shipping method to be unavailable and force re-select, which in turn might or might not impact totals and taxes. Similar considerations for promotions. If the total is impacted upwards, you should be able to charge/bill the additional amount. Etc. etc. And all of these adjustments should be visible on the invoice and customer account. One specific related issue is https://github.com/sportsdirect/reaction/issues/333

I mention this only in that it might impact the UI design decisions.

[kieckhafer]

Has been resolved with #5158