Improvement to payment and receipt forms

Absolutely! One of the hallmarks of Manager has always been the freedom to activate only the tabs you need.

Definitely not! Your philosophy has always been not to force users to do things your way, but only to encourage proper accounting where necessary. There is absolutely no reason to force users to enable the Customers tab and define a customer to enter a one-time sale in an environment where there will clearly be no reason to ever run a customer statement or issue a sales invoice. You are forcing users to activate tabs they don’t need.

I’m sorry, but this seems like what is best for the developer, not the user.

Yes, separate, but closely related. You have imposed your vision of what is best for the user by ruining years’ of records and mandating activation of potentially unnecessary tabs.

This will not help when the user does not want to activate Customers and Suppliers tabs and define everyone with whom they’ve had a transaction. You are forcing a huge amount of tedious work onto users. In many cases, your envisioned benefits will not materialize, because the user had no reason to activate those capabilities in the first place.

On this basis if you don’t care about tracking receipts by customers or suppliers, you won’t enable customer or supplier tabs.

That’s not how I see it. You do not need to use Payee or Payer fields on receipt / payment forms and if you don’t, no need to enable customer / supplier tabs. Actually, the argument could be made that Payee / payer fields should be visible only if customer / supplier tabs are enabled.

Anyway, I’m going to take one step back because it’s not important to me at the moment whether the old free text field capturing payee or payer is in Manager so I’m going to put it back the following way.

In the latest version (20.8.91) there is now dropdown menu where you select whether payee / payer is Customer, Supplier or Other.


If you select Other then you will get free text field.



Thank you!!

I guess we will continue to disagree about the need for the “other” payer/payee option. Your view seems to be that a receipt or payment can be like a cash register slip with no identification. Mine is that we need the ability to name the other party without having to predefine them. This solution seems like the right one, subject to full exploration.


Thanks a lot, this is certainly much better. Still there are some improvements to be made, but in that short time it’s like a miracle.

However, I have to side with @Tut on the matter of having to address the receipt or payment to someone, even if they have no account. Consider this case:

One of my clients is a lawyer that accepts collections on behalf of his clients for their receivables in exchange for a percentage. The GL lines for this transaction are:

  • Debit – Cash in hand (control account made up of cash accounts)
  • Credit – Collections on behalf of customer (control account made up of customers)

The payer has no account or no mention whatsoever anywhere in the transaction, but for legal reasons, they need their name and personal ID on the receipt as a proof they paid (especially since we are looking at a lawsuit). That is a case for someone who is not a customer, has no account with us but their name and ID must appear on the receipt.

There are similar cases for people whose names must show on a payment form in order to establish the fact that we paid someone regardless of whether they have an account or not.

I support entering customers and suppliers as the reporting consequences are so much better.

For the walk in who the user does not want to enter data leave it blank or create a customer “Customer” and a supplier “Supplier” and select the generic entry for those cases

8 posts were split to a new topic: Product change rollout philosophy

Thank you @lubos you have addressed the two most important prior deficiencies in Manager which in my opinion were accurate tax coding and enabling customers and suppliers to be linked to “cash” transactions.

Could I suggest some small detail changes to further enhance Managers usability.

  • When creating a new receipt, please use “Customer” as the default Payer not “Other”. Similarly when creating a new payment please use “Supplier” as the default Payee not other. The reason is two fold, these are the settings users will actually want in the vast majority of cash transactions and, it encourages users to use linked database entries not the fee text field.

  • When the Payee or Payer is set to “Customer” but an actual customer is not yet selected, then please assign all tax codes to sales and disable line item entry of a customer or supplier. Similarly if the Payee or Payer is set to “Supplier” but an actual supplier is not yet selected, then please assign all tax codes to purchase and disable line item selection of a customer or supplier. This will enable the Payer/Payee setting to always clearly indicate which tax code part a transaction will effect. It also enables user to accurately use tax codes without opening the supplier or customer tabs.

  • When the Payee or Payer is set to “Other” then set the default sale / purchase based on if the line item is a credit or debit. Also enable line item specification of customer / supplier. The reason is other is the optimal setting for a count trade / Recipient-created tax invoices transaction. This is because for a Recipient-created tax invoices transaction the ABN of all parties must be displayed, so symmetrically specifying all other parties at the line item level is optimal. Also for a count trade / Recipient-created tax invoices transaction the most likely sales / purchase assignment is determined by the debit credit status. This behavior also enables support for historical data (free text payee / payer and credit / debit determined sales / purchase tax code component).

  • I liked the From To layout with money going from left to right. I thought it was an excellent intuitive innovation. Was there a reason we lost it, or is it’s absence just temporary?

I agree. This will educate the users to the new functionality.

I disagree for two reasons:

  • The current implementation matches the old workflow by default. So users will only need to do something new (select a type) when they choose the new feature (using a customer or supplier). Things they have always done a certain way can continue being done the same way.
  • Other is the default option no matter whether the form is a receipt or payment. They both start from the same place. Likewise, the rest of the list remains in the same order. Muscle memory will prevail, and fewer deviations will simplify entry.

Do you really believe the old implementation is better than the new. Using free form contact entry per transaction and no linkage between transactions, to customers, or to suppliers other data.

I strongly believe the new way is far better. And to achieve the benefits there is a consequence at data entry.

If you believe like me linking transactions to customers and suppliers enhances the programs functionality, then why would any sane user interface encourage users to get worse performance from the program?

That depends what you mean by “the old implementation.” If you mean the implementation we suffered under for years, no, it was not better. I was, after all, the one who initiated the idea that resulted in this change.

But if you are referring to the initial implementation of linking customers/suppliers to payers/payees, I definitely believe the latest iteration is better. It provides more options and reduces the need for some users to enable the Customers/Suppliers tabs and create customers and suppliers. I have a real business, as one example, in which about half my sales are via sales invoice and half via receipt. The receipt sales involve one-time customers I know I will positively never encounter again due to the nature of the service. For them, I will never need a statement or report. But I still need to document the sale with a form that has their name on it, and not just in a custom field. For that particular business, I have never needed a purchase invoice. Every expense is paid directly from a supplier’s bill. So the Purchase Invoices and Suppliers tabs are not enabled.

The initial implementation of customer/supplier linkage left me with 780 orphaned receipts and payments involving almost as many customers and suppliers and would have required me to enable two previously unnecessary tabs in the program, create all those subaccounts, and reassign hundreds of payers and payees in order to have the records legally necessary for the business.

The latest iteration restored everything. For remaining receipts associated with defined customers, 10 minutes of Batch Update brought everything into a better condition than before. I can now obtain full records and reports of the repeat customers I had defined. That is definitely welcome. And that is just for one relatively low volume business.

The final iteration is definitely better. It gives users who want to define all their customers/suppliers the ability to fully integrate. It also provides flexibility for those who don’t need or want that capability at no penalty for those who do. In this case the benefits of the way you wish to conduct your own business are now available at no consequence to data entry except that you need to select the payer/payee type. And you will also be able to upgrade your prior records quickly using Batch Update the same way I did for my repeat customers. So you can be better off, not just going forward, but historically, too.

I believe that in some circumstances it does, but in others it offers no benefit. Having the ability to link is a definite enhancement. I have waited years for it, from before the ideas category existed and I begged the developer privately.

I don’t think that is a question that needs to be asked or answered after the latest iteration. Users who prefer either approach have full flexibility available to them. Those who find a hybrid optimal, as I happen to in the particular business I described above, get to use both approaches. In my opinion, everybody wins.

I actually think the default starting point should not have opinion either way.

So the latest version (20.8.93) shows the field empty.


Where you can select Customer, Supplier or Other which will reveal the sub-field. In future these options will be variable based on what tabs you have enabled. For example, if you don’t have customers or suppliers tabs enabled at all, then there is only one option Other and in that case we can show text field right away.

If you want to show some option by default, there are Form Defaults which already handle that.

1 Like

Even better!

Please retain the option to specify the transaction is for a customer or supplier but if the tab is not open do not show the selection menu to choose a specific supplier or customer. That way users who do not need the tab (eg external POS system) will still be able to process returns.

Tut - Thanks for all your efforts in getting this straightened out and maintain flexibility. We now have the best of both worlds (scenarios) and I think it may finally be safe to update. I’ve been holding off recently while watching this develop.

I suppose there is a hundred different ways for this tab (Payments and Receipt) to be designed. I would personally like to see this tab split up into two different tabs, to help eliminate errors. More than once I found myself recording a payment when it was suppose to be a receipt and visa versa. Just last month I found an error that I made in January.

To me it is very simple how this should be laid out.

Depending on which tab you are in you would get that respective screen.

On the Payments tab if you select a supplier from the payee menu, its name and other contact info would populate the Contact box.

If you don’t select a supplier, the contact box would be a free text box were you could fill in the person or company name and address if you so desire.

If it was a refund you would select the Refund check box, and then you would be able to select a customer from the Payee drop down menu.

The receipt tab would be the same way.

To me this seems like a logical design that would work, it is my opinion however, and I am sure that somebody will find something wrong with it.

This is not as big a problem as you might think. Nor would it eliminate errors. You could still accidentally go to the wrong tab. But the current implementation only requires you to switch the Type field. You do not need to re-enter the transaction. If you were in different tabs, you would have to delete one transaction and enter another in a different tab.


I’m having difficulty actually doing that
Receipt or Payment form defaults

Form default appear to apply to both a receipt or payment. So I can set both to show customer or both to show supplier as the default. However by far the more common requirement is

  • Receipt is from a customer
  • Payment is to a supplier

Perhaps I just need to be patient as it is a feature not yet implemented, or perhaps I’m doing something wrong.

1 Like

Yes, I saw this problem too, there should be form defaults for both Payment and Receipt, not both together.

There will always be errors, I understand that it would not eliminate errors. But I think it could help.

Another option would be is to have a header, (Payment or Receipt) depending on the type selected, in a big bold font. So we dont have to guess which type is selected.