Improvement to payment and receipt forms

I’m not looking for new features, I’m looking at it from the User Access control side of things. This will also reduce the chances of data entry errors (mistakenly making a receipt a payment). I do not see why a cashier who issues receipts should have the Payment function as well.

I dont mind them under one tab and then have two sub tabs the way it is now.

image

That part is fine and is actually kinda nice.

What I dont like the most is that you can be in Payment tab and hardly know it. and all you have to do is change the type and its a receipt. To easy for errors in my book. I would get rid of the type selection and then the only way can go from Payment to Receipt is to go back to the previous page and select the Receipt tab.

2 Likes

A possible solution is

  • If a user want to have “Other” (or any other value) as the default, they set it in form defaults

  • If the user does not have the customer tab enabled then “Customer” in the payee/payer menu is still an options but no menu for specific customers is shown, however all line items still use the sales component of the tax code. Similarly if a business does not have the supplier tab enabled then “Supplier” in the payee/payer menu is still an options but no menu for specific suppliers is shown, however all line items still use the purchase component of the tax code.

  • If nothing is set in form defaults for the payee/payer menu then for receipts it defaults to “Customer” and for payments it defaults to “Supplier”

The net effect is where the customer or supplier is constant for every line item, the type (and optionally specific contact) can be set at the transaction level. Where other than this applies, “Other” is selected.

Importantly it streamlines the most common case

  • A receipt is most commonly from a single customer and all line items are positive
  • A payment is most commonly to a single supplier and all line items are positive

In addition it enables consistent extension to less common transactions such as

  • Returns - a sub set of a consistent supplier or customer for all line items

  • Counter trades - Different supplier or customer for one or more line items.

  • Once off sale or purchase where user does not want to enter contact information → leave it blank

  • Sale or purchase tab is not enabled in a business ->. specific menu is not shown

  • Other options could be added to the payee / payer menu later to provide explicit support for other entities.

  • A blank option could be added to payee / payer which would disable tax codes. Perhaps more logical for financial transactions between bank accounts. Not a priority for me but a solution for those not wanting a label not relevant to some transactions

Edit
Removed suggestion to replace “Customer” with “Sale” when the customer tab is not open as it confuses the Payee/Payer label and is less intuitive as users add new tabs. Similarly for Suppliers.

In my opinion the above could be further improved by

For a new customer (or supplier)

  • When entering a customer (or supplier) and none are found to match the entered text (menu zero matching items), there should be an “Add” button or menu item.

  • If the add button/menu item is selected a new customer (or supplier) is creates a with the entered name and allows other information to be entered.

  • With this facility when a new customer presents the user can choose to enter just this is a sale to a customer (leave the specific customer menu blank but select payer is a “Customer” so all line items are sales) or enter specific customer data and it is added to the customer database and associated reports.

Payee / Payer “Other” setting

  • Used for maintenance of old data entries (free form text payee / payer)

  • Also used for new transactions where some line items have a different customer or supplier (eg counter trade). For these new entries the customer and supplier data entry must all be done at the line item level, not at the transaction level.

  • For new data entry Manager should not show the free text box, or at least it should be phased out (which maybe a controversial idea).

I don’t think that this will be feasible until the drop down menu will be extended to every other contact list. And even in this case you can have a contact which cannot be mapped by Manager. Yesterday we made a Payment as a guarantee to a grantor which is a notary public. He is not and will never be a client/supplier.

1 Like

No. I am quite new user and is the only thing that I am concerned about as we have more people working on the accounts and some have difficulty. As argued here it is obvious that if one would activate Payment then only Supplier and Other should be selected in Payee field and similar for Receipt either Customer or Other. Ideally one should not have other in any case but a prompt to add new customer or supplier, but that would be a step backward as then import of bank statements and assigning these would become tedious at best and weaken what is actually a very convincing reason to adopt Manager, the way you handle bank statements (although I have issues with the insistence on single column that puts payment and receipts together which conversions we do manually!). The issue I raised would be simplified if one tab for receipts and one tab for payments if these would also alllow for bank statements with 2 columns

If that is your conclusion, you have misunderstood the discussion. The issues from post #46 onward were never whether to allow customers as payees and suppliers as payers. The issues were:

  • Whether to allow payers and payees who were not customers or suppliers
  • What the default options should be
  • Whether receipts and payments should be in the same tab
  • Whether payers and payees who are not customers and suppliers should be placed automatically by the conversion script into a custom field

The need to be able to choose both customers and suppliers as payers or payees has always been recognized as a necessity. Otherwise, you cannot handle refunds, let alone barters and counter trades.

I am closing this topic. It has become too long and addressed too many topics to remain useful. Those wishing to raise related subjects should start new posts.