I see in recent update the New Receipts button is gone and we mus now Copy to/New Receipt.
We have a lot of docuemntation and users famiiar with the new receipt button. This is not a helful change. It also requires additional clicks.
Is there any reason that we could not have both the button and the copy to? It definately changes workflow and left users who never use the copy to function confused.
Could we please consider bringing the button back. I expect its use is a very established practice for many.
These little surprise UI changes can be a bigger deal to users than they may seem. We just redid a bunch of user guides/training documents which of course are now all different than the forms now show.
@lubos, I have to agree with all other comments on this change, and feel the need to comment. Please revert this core button back to itâs original position and not hide it in a submenu.
I would like to understand the propose of this change, was it just to make space for future buttons on that particular view?
You are usually always spot on with the usability and feel of the program and itâs core button placements, it surprised me when you highlighted this change.
However, the same logic applies to Copy to Credit Note for instance, you are creating a new transaction type which is linked to the original. In this sense the copy to Receipt now follows the same logic. I would net argue that we need Copy to and Create for options.
The reason New Receipt and New Payment are not meant to be standalone buttons on invoice views is that if they are, they imply that these buttons need to be used as part of a certain workflow. But there are also workflows that do not require ever clicking these buttons.
For example, if your customers always pay by bank transfer, you would typically never create receipts manually. You would import your bank transactions and then have receipt rules to allocate already-created receipts to the correct customer. You never create a new receipt from scratch.
Moving the New Receipt button under the Copy to button makes the function appear more like a utility rather than something special. For those who are creating new receipts manually, it is still the first option under the Copy to button (which takes one extra click). For those who donât create new receipts manually, the button is not there to imply they should. Itâs a compromise.
If your argument is that âOne extra visible button surely cannot hurt anyoneâ, this is not just about one button. Itâs about the general principle of keeping Manager simple. If I would cave in to everyone who says âjust put there a button/checkbox/option - itâs just one - who doesnât need it can ignore itâ, Manager would look completely different. Iâve seen accounting software where creating a simple account in the chart of accounts came with 50 different form fields. No doubt there is a passionate user behind every form field but when you zoom out, itâs a complete mess nobody wants to use.
If your argument is that this button is used by many users so exception can be made. Fair enough. But still. Where do I draw the line? How many users is enough to justify the exception. I donât know. So I err on the side of consistency. Every View screen in Manager has identical buttons.
I donât think the presence of a buttom implied that a workflow NEEDED to be used. It certainly could be used and often is for many users. What itâs presence did do was add to useability without the need to hunt for the button.
For what it is worth, we donât have readily accessible bank feeds for US transactions on a daily basis and many checks (cheques) still come by mail. Most (for us) pay one invoice so we want them applied to the the invoice and to the customers account when we receive them so we typically apply them from the invoice. We are certainly not going to deposit them to the bank, wait for them to clear and then import the bank statement we get at the end of the month (which of course, at least with our bank, groups the amount on the statement into as a total deposit (there is seprate detail). So yeah, I suspect I am far from alone in this being the primary (though certainly not the only possible) workflow.
Likewise a Print button doesnât imply a workflow in which I must print, nor does the Email button imply a workflow where I must email it. They are all simply there, readily visibile and accessible when and if needed.
Sure you can make an argument that no button is absolutely necessary on View screen. There is a workaround for every button on View screen. But the remaining buttons on view screen are generic to every other view screen so you donât really question them. New Receipt button was rather odd one out because it was only present on one specific view screen.
This argument boils down to how I perceive the software from the inside and how many users perceive it from the outside. I donât like the fact that sales invoice view screen is somehow special because it needs to carve some special button for itself. And this special button is not even universally applicable.
This is good disussion. Thank you for being willing to engage. I am viewing this not from the âoutsideâ but from the perspective of a functional user, working on the OTC (order-to-cash) and PTP (precure-to-pay) processes. You are correct, that I am not currently wearing my developer hat, rather I am providing âuser storyâ for consideration as many application forms in many systems do vary with resepect to some buttons etc. in order to accomodate the specific user stories and business processes to which they relate.
I will leave it at that, I appreciate the conversation and appreciate my and other users stories being considered. Thank you.
And here I feel you have gone against that principle.
In the earlier days of Manager.io, those buttons were called Receive Money and Spend Money - ultra user friendly for the non accountant then changed to New Receipt, New Payment when the individual tabs were introduced.
Those buttons have always been there, the way you designed it from the start, most intuitive way.
Now, moved to a dropdown where a basic user may find it less intuitive.
Itâs not a lot of extra clicks, you are right, and will quickly get used to it, but I am thinking of the new users here.
Thank you itmoto. Agreed - The keeping it simple principle should apply first and foremost to the user experience and then secondarily to the development experience.
While clicking on the balance due amount in the sales invoices screen will allow entry of a new receipt, the button really did make sense in the view screen. Having all pertinent information visible prior to deciding if the invoice is the proper recipient of the payment is very helpful. The current method smacks of perfect world, not real world, programming.
I donât think the argument that invoice view screens should not be âspecialâ fully works here, because they already are special.
Sales and purchase invoice view screens now have âNew Receiptâ and âNew Paymentâ under âCopy toâ. Other document view screens do not have equivalent actions. So the invoice screen already has invoice-specific workflow items.
Also, receipts and payments are not just another document copied from an invoice. They are part of settling or concluding the invoice. That makes them different from creating a quote, order, credit note, or recurring invoice.
So the issue is not whether invoices should be treated differently. They already are. The issue is how to give faster access without cluttering the screen for users who do not need it.
A good compromise would be to keep âNew Receiptâ and âNew Paymentâ under âCopy toâ, but add quick access for frequent users. For example, C, R for New Receipt and C, P for New Payment, only active on view screens and not while typing in fields.
Another good option would be letting users pin these actions to the toolbar.
That keeps the interface clean for users who rely on bank imports, while not slowing down users who manually create receipts and payments every day.
I think that given each object sales invoice, receipt, purchase invoice, payment is is part of a particular process OTC (Order to cash), PTP (procure to pay etc). these buttons are not âspecialâ, rather each object has a couple of context specific buttons. Having a couple of context specific buttons should be considered standard not special.
This process is applicable only for a group of users not all users. Hence the real benefit of consistency for all users over a minor inconvenience for some users.
@Patch, we are of different opinions, which is fine.
My take is that OTC and PTP apply to all and of course there are valid variants to each process. I do not agree that the user experience should focus primarily on the process flow for one group of users and bury or hide the process for others. All variants of process are valid and the application should support those users âuser storiesâ best it can and not pick favourites.
I think a good number of users disgaree with this change. Forms can be consistent while still having a couple of context sensitive buttons - e.g. New Receipt on a Sales invoice and New Payment on a Purchase Invoice. We shall see if we are heard..