Improvement to payment and receipt forms

A) When entering a Receipt or payment the accounting software need to know

  • When linking contacts, which contacts to list (Customers or Suppliers)

  • When creating tax codes, which total should be update (Sales or Purchases)

  • If neither is required for a particular Receipt / Payment then no additional information is needed or relevant (eg account transfers, owners drawings, invoice payment/receipt).

B) Receipts and payments can be entered by

  • Receipt & Payments tab in Manager

  • Bank import rules

  • A equivalent solution is likely also to be required for Journal entries

  • Any solution chosen would need to work consistently in all these parts of the program.

The user interface to achieved this is less critical to me. Actually having the functionality at all is what I value.

  • Enabling the user to confirm a transaction is a sale or purchase when relevant I thought maybe an easy way to achieve the functionality. A better solution maybe to only show the Customer/Supplier/Tax code options after the user has select if it is a sale or purchase (ie type field has 3 states: not set, sale, or purchase).

  • Different screens and options based on the sign of the overall transaction (payment or receipt) is another. It adds more user interface flexibility but maybe significantly more programing work to implement as it implies separate coding for a) Payment, b) Receipt, d) Bank import credit, e) Bank import debit, f) journal entry.

Edit: Added likely Journal entry requirements & showing dependent fields only when type is defined.

Thinking about this further it maybe clearest for the “Receipt”, “Payment”, Bank rule, and “Journal entry” screens to have a type which supports values similar to:

  1. not set or “Neither”
  2. Cash sale
  3. Cash purchase

The effect of these options would be:

  1. “Neither” / blank: would be used for payment or receipt of an invoice in Manager, moving money between account or similar. For Manager invoiced transaction the supplier/customer details and VAT/GST are recorded on Managers invoice, so not showing the option on the payment/receipt screen would make this clearer. Similarly other transactions which are neither a cash sale or cash purchase should not have VAT/GST or support linking to a customer/supplier.

  2. “Cash sale”: would tell Manager this is a cash sale so support linking to a customer and entering VAT/GST

  3. “Cash purchase” would tell Manager this is a cash purchase so support linking to a supplier and entering VAT/GST

But again, I would be more than happy with any user interface which achieves this threads functionality.

I also like this " Improvement to payment and receipt forms" idea, these improvements would be excellent. Looking forward to their implementation.

I am replying to this post so that it gets noticed again, bringing it to the top. Will this topic ever see the light of day? could we have a rough time frame of when it could happen?

Please share that idea of printing cheques straight from payments

Added to the latest version (20.8.86)

Contact field is being downgraded to custom field and there is now new field on receipts / payment forms called Payee or Payer (depending on context).

image

This is dropdown where you can select customer or supplier.

Selecting customer or supplier will show their billing address when viewing the transaction.

image

Clicking on Email button will pre-fill the email address.

image

And when viewing general ledger transactions, they will have now associated customer or supplier.

@lubos, the availability of customers and suppliers is welcome. But relegation of payers and payees to a a Contact custom field is not. The current implementation is lacking for at least these reasons:

  • This leaves every historical receipt and payment from years worth of accounting records with no recipient on the completed form, because none of them would accept a customer or supplier as the payer or payee.
  • The default custom field after conversion does not even show on printed documents.
  • The Payer/Payee dropdown box includes both suppliers and customers, regardless of whether the transaction is selected as receipt or payment. Was this intentional?

Is it possible to:

  • Restore the old Payer/Payee field in the header of the transaction form as an optional field
  • Rename the current field to Customer/Supplier
  • Allow an entry in only one or the other
  • Display whichever is populated as the recipient on completed forms
  • When a customer/supplier is selected, the transaction should be linked to the appropriate subsidiary ledger of Accounts receivable/payable and show up in Customer/Supplier Statement (Transactions) reports as is now happening
  • Eliminate the Contact custom field. The idea that the payer or payee is just a custom field makes no sense. That is essential information for receipts/payments not associated with defined customers or suppliers.

The information is not lost. It’s currently stored in custom field.

Users can make custom field visible on printed documents.

Yes. If you process refund to customer, it is a payment to customer.

No because we will have two fields which really do the same thing. For new users of Manager, it makes no sense to use this old Contact field at all.

I think this will evolve where you will be able to select any contact (e.g. employees, capital accounts) so payee / payer field is appropriate name.

I agree. This is something I need to improve. There is no need to select customer twice on the form.

This custom field is not created if you are upgrading and never used Contact field on payment / receipt forms. It’s only created to preserve your data if you have any in that field. You can find transactions with Contact field, remove the value and select contact in Payer / Payee field, then remove Contact field altogether.

I have to disagree strongly with some of your responses:

Yes, I know. But users will have hundreds or thousands of historical transactions with no payer or payee. A “contact” listed at the bottom of a form, even if the custom field is edited to show on printed documents, is no substitute. A merchant I paid directly for a purchase is more than a “contact.” They are the other party in a financial transaction and should be shown as such. Save the custom fields for optional or amplifying information, not essential facts.

Yes, I realized that, too. But they should not have to.

No, they will not. The Payer/Payee field will do exactly what it used to do—allow entry of a party to the transaction who is not defined as a customer or supplier. The Customer/Supplier field would link to the subaccounts. And the program would only allow you to fill in one or the other. Many users were previously confused as to why entering a customer or supplier name in the payer/payee field did not result in the transaction appearing on statements. My suggestion would solve that problem.

I do not understand what you mean by this. You have to provide a field for entry of payers or payees who are not customers/suppliers. One labeled as such and placed in the header is more intuitive than a custom field at the bottom labeled as something else (Contact).

I also do not understand this comment. You do not need to select customer/supplier twice. In the portion of my post you were responding to, I was just reiterating the need to keep the existing (but new) linkage between receipts/payments and customer/supplier statements. In other words, this portion of my suggested package is already working correctly.

Again, your response is confusing. First, there never was a field labeled as Contact. You had a field labeled as either Payer or Payee. Contact was used only in various lists as a catchall for both. It seems specious to say the custom field is created only if you had data in that field. Every receipt or payment should have had a payer or payee. Finding the transactions with something in that field means every single receipt or payment since the business was started. Only those involving defined customers and suppliers can be reprocessed by selecting one of the defined entities. All cash sales and purchases will still need their payers or payees, and there is nowhere now to put them except that senseless custom field.

This entire concept seems irrational from the user’s point of view. It feels like a programming workaround and is maddening. I don’t know what to say except that it has to be fixed.

1 Like

Just to clarify terminology. When I say Contact field, I mean the old free-form field where you were allowed to type anything. New Payer / Payee field is where you can select customer or supplier.

But we can’t have both free-form Contact and Payer / Payee fields on the form because they represent the same thing. It’s one or the other.

The reason I made it this way is to discourage using Contact field on receipts & payments completely. And new businesses don’t see this field because the custom field is created by migration script. New businesses do not have this field.

Correct. And it also serves the purpose of Contact field so we do not need separate Contact field anymore. If payee or payer is not a customer or supplier, then we can add more choices to this field (e.g. employees, capital accounts, expense claim payers etc.)

I will be extending payer / payee field so you can select employees, capital accounts and expense claim payers.

Correct. It again comes to that right now you can select only customer or supplier but it can be extended to be able to select employee, capital account, expense claim payer etc.

It’s not a workaround. This is why this feature request has been lingering in ideas for over 3 years because it’s only now becoming obvious how it should be implemented.

The old free-form contact field where you were allowed to type anything is now obsolete. We do not need this field anymore.

@Anuj_Goel This is unrelated. See:

I made some improvements to how “Receipt / Payment” form look like:

From Account to Payee

image

and if Receipt is selected, the second line shows in reverse:

From Payer to Account

image

1 Like

@lubos
May I request if possible adding a filed for Supplier Invoice No where it should be linked to supplier GL Account. and show the invoice no in Supplier Reports.

I like the From To organization.

In my opinion the receipt / payment screen would be better if Payee / payer was click-able so the user could both choose (and see a menu list of)

  • Customer
  • Supplier
  • possibly later expense claim payer or employee

and also clearly see which group and tax codes this transaction applied to. For example in the screen shots posted by lubos, is this effecting sale or a purchase tax codes?

These changes have mucked up my workflow. The Payee details have moved to Contact which means in the Receipts & Payments, I cannot do a search for my Payees!!! It comes up blank unless those details had been added to the Description field.

I liked how a the Payee could be entered by typing it in previously. This is no longer the case.

I suspect the best solution is a “recode” to add the appropriate links

  • Search for one of your payee
  • “recode” to add the appropriate supplier / customer to all old receipts / payments

@lubos I have to completely agree with @Tut.

I have created a customer as a supplier and vice versa, how would I destinguish between the two in a single list?

Are you saying that users will now have to predefine the Payer/Payee in the Customer/Supplier tabs before entering a Receipt/Payment?

I don’t think you should loose the ability to allow entry of a non-defined customer or supplier.

I would strongly recommend a possible two fields on the same row, one main field for (new) Payer/Payee then a checkbox at the end to allow a second field e.g. Non defined Payer/Payee (Contact). The update would the automatically tick the box to reveal the field.

Everyone, I believe, used this field.

For the update script could Manager not handle this change smartly?

Could Manager compare the content of the old free-form Payer/Payee field and check if it matched a predefined Supplier or Customer then convert it to the new Payer/Payee field?

If Receipt/Payment was from credit sale/purchase the Payer/Payee could be filled from Accounts receivable/payable line from existing transactions.

I do not think the Receipt/Payment form should be modified too much or make things more confusing for users.

I fail to see how this could be true. Even my limited, reptilian programming skills can see a way around this. An either/or restriction on the ability to populate the fields and a couple of simple “if” tests when populating the recipient variable for a transaction form would solve this.

That’s all well and good. But you seem fixated on this, mentioning it three times in one post and several times earlier. But you are overlooking the obvious. Users have businesses with no defined customers, suppliers, employees, capital accounts, or expense claims payers. Some or all of those tabs will not even be enabled. Yet they still have monetary transactions with specific outside people or entities and need to be able to enter that information for receipts and payments. In many cases, those will be one-time interactions that will not justify enabling a tab and creating a subledger. They should not have to use a custom field for this purpose and then write a custom theme to place the name in a logical place on the completed form.

Think of a sole trader running a cash retail business who has no employees and has always paid bills from suppliers immediately, without entering purchase invoices. She now has years’ worth of payments and receipts with no payees or payers. This affects drill-downs on accounts, lists in tabs, and the transactions themselves.

Forget the idea of editing the custom field to show on documents. That is easy, but it does not solve the problem. The poor user has to edit or Bulk Update every single payment or receipt ever created. Even when transactions were with customers or suppliers, you currently have nothing. A user will have to go through every receipt or payment and select the customer or supplier to populate the payer/payee field. You have left your users high and dry on this. The promise of extending the field to include other types of payers/payees is no comfort whatsoever. Our business records have been trashed.

I believe @Tut has a valid argument here. Making the the contact field a custom field is not the way to do this

The former contact field needs to be merged into the payer/payee field. The Payer/Payee field needs to have two options. A drop down menu to select suppliers/customers or manual entry for somebody not in the supplier/customer list.

2 Likes

How many new users is this going to bring to the forum this week?

Again, random “improvements” that break how people use the product.

Just think of those lucky cloud users always on the bleeding edge!

@lubos have you ever considered having separate stable and development branches? That way you aren’t using your current user base and their businesses as beta testers.

I know you put a lot of thought into what it is you do, however, you do it without consultation and I really think you would benefit from user input before making sweeping changes.

Anyway, I hope @tut isn’t retiring in the near future.

Stay safe everyone, cheers.