Enable quick capture of payments for a batch of orders

The problem/need

A hub manager is using OFN and has customers who pay on delivery, onsite. When she wants to quickly capture payments after the sale has happened, he has to filter the orders, capture payment for the first order, but then the page reload and the filter is lost, so he has again to reapply the filter, capture payment for second order, etc.
See the time it takes and the unfriendliness of the UX here:

Possible solutions

1- Keep the filter, when you apply a filter, keep it visible and active, don’t reset the form. If a payment is captured and page reload, the filter remains applied. So that he can capture the payments one by one but at least doesn’t have to reapply filter each time.
2- After applying the filter, select all the orders he want to capture and have a bulk action “capture payment” that in one click capture payment for all orders selected.
3- Reload the list of orders like we do when navigating from one page to another? (the filter part remains fixed) and not the whole page.

@Kirsten @sstead @SineadOFNUK @Rachel what do you think? It is indeed confusing that the filters are lost when the page is reloaded when an action is performed on one order, no? But for the user need, maybe option 2 would add more value more quickly (as it seems with bulk invoice printing if might be easy to add a second bulk action on selected orders?)

Value-ease matrix discussion

Given discussions below, it seems option 2 seems to be the option bringing the more value. Not sure about easeness we would need some dev inputs on those three options, but seems pretty straightforward once we have finished developped the possibility of bulk actions on orders…

Option 1 and 3 would enable quicker capture of payments one by one, but not really enable to handle capturing 50 payments quickly…

I tried a google drawing you can amend here

Do you agree with that analysis? In that case I would Say option 2 could be our feature candidate as add pretty much more value for not so much more effort than option 3 or 1.

Hello !

There are several aspect here and I think we should treat them separately.

*1. identify quickly the orders of specific customers

Pleaaaase please don’t add columns :sob: if first name and family name are used the most by a majority of users, let’s replace other columns by these two. Do we have any other feedback than this customer? Can we open another wishlist for that?

  1. capture quickly payments for those orders

I think this has to be thought not only around capture payments but any other action : edit, ship…

Option 2 has the advantage of proposing something global and unified.

An option 3 would be to know if we are actually forced to reload the whole page, or if we could just reload the list of orders like we do when navigating from one page to another? (the filter part remains fixed). That would be a quick win if it is possible.

Option 2 would then be used only for actions that need previews (new page to open). What do you think?

What if the user could select which columns show by default, as on the products page?

I think 2 is obviously ideal. Enterprises don’t want to waste time clicking- especially as many manage invoicing external to OFN (e.g. quickbooks). Food Connect comes to mind - they have dozens of customers, and FC never mark orders as paid because it’s too time consuming - thus all customers accounts look like customers have never paid for their orders.

Options 3 and 1 would be improvements but far from the benefit of option 2.

As suggested by @Rachel I separated the two needs and opened another draft icebox for “adding customer name on order line”: Enable to identify customer on orders view
On enable quick capture of payments for a batch of orders, I moved that wishlist to icebox draft as we are discussing feature candidates already so doing some inception. I also made it a wiki so others can add other possible solutions. I will clean the first post as well so that it only talks of that need as we separated both issues, and added your option 3 solution @Rachel.

@danielle @Rachel @Kirsten I try something here on remote collaborative solution brainstorming and analysis :wink: We need some quick dev input as well here so great if a dev can give a quick feedback on the value matrix. We need to discuss how we organize that in dev time :wink:

I added one vote on this one as seems like a small thing when bulk invoice is done, try to balance small and big things that seems most annoying for users.

@Kirsten this has been a recent feature request from Prom Coast, perhaps worthy of an Aus vote in the next round of voting.

Yes, do vote on it Aussie team, join the French team ! Our users also requested that ! Now that bulk action is enabled (bulk invoice) it should be X or even XS no to add a new bulk action “capture payments” so just to click as paid a bunch of orders at once ? @luisramos0 or @Matt-Yorkley if we can have a super quick t-shirt size it would be great :slight_smile:

I have another big and hearty vote on delivering 2. I am considering nominating this as a ‘papercut’ - now that bulk invoicing is done it seems that it must be a very minor task to allow ‘capture payments’ on a group of orders that have the boxes ticked. It seems that there is broad agreement on this solution at least to the payment collection part.

Thoughts on making it a github issue - likely both ‘good first issue’ and ‘papercut’?
@lin_d_hop @Rachel @MyriamBoure @danielle

I would like to suggest an alternative that I would find the best UX and the simplest to implement:

When a user clicks on the capture button, it sends the query without reloading the page. The success of the action is shown by the capture button disappearing. Instead, the ship button appears. There should be progress indicator in between so that people know that they successfully clicked the button.

This version needs one less click than the checkboxes solution and is more aligned with our new API approach.

Depending on the complexity of UI feedback, I would estimate this between 3 and 6 hours.

oh i like this . .
it is potentially a bit counter-intuitive ux wise in that we have all those checkboxes sitting there and an action box with only one action! but would do the trick to make SO MANY PEOPLE happy :slight_smile:

hey there, so we haven’t actually decided on the papercut process in terms of what it should be or how it is dealt with. Seems we sort this out ASAP before we bandy the term about without a clear understanding of what it means?

yep I know that - doing a bit of this deliberately to nudge the process :slight_smile: I don’t care what we call them, but getting to some clarity around a list of tiny changes with massive user value will be critical to matching our progress on tech debt with progress on ‘making it great’ :wink:

Agree. And if anything, right now it’s all we have capacity to focus on in the pipe. Small and beautiful, incremental improvements.

Issue created at https://github.com/openfoodfoundation/openfoodnetwork/issues/4377