I know this has been floating around for a while, but in my previous accounting programs I had a customer set up as ‘Cash Sale’ and a supplier set up as ‘Cash Purchase’. It was then a simple matter of adding any further ‘one of’ details such as Names, Addresses etc. in the address field, which by default was blank.
Seems to me to be a simple solution, however I am not the developer…
1 Like
this is a must have, i was deluded when i saw that i cant use cash sales for existing consumers.
invoice and spend/receive is not time efficient.
Please try to implement it as soon as possible
@lubos majority of us have voted for this feature to be implemented, so please when is it coming. It’s really a MUST-have improvement to payments and receipts, where it can be linked to customers and suppliers sub-accounts for cash sales or purchases. Thank you.
1 Like
I would really like to see this implemented as it is something I need for my business. Thank you
This has really become an issue for me. I now have three contractors that allow there workers to pay cash/card for items, Others must buy off purchase orders and I invoice the companies.
My thinking, and I know I’m not the programmer, would be to have a customer called ‘Cash Sale’ from a drop down list of customers (much the same as we have now) and I could use that for general sales to the public.
This would enable all sales to a particular customer to be included in customer reports, regardless of whether they have been invoiced or paid by cash/card.
It would also enable a statement to the customer that shows all purchases for the month.
Please, please, please incorporate customers into the Receipt option…
I do no think this is actually an issue as I don’t see the value in having manual entry into a system field which is never used again (ie the existing payee/payer field). Instead I agree with vacuumdog, that it makes more sense just to always use the existing customer and supplier databases
However what is required it for the user to be able to choose if the customer or supplier database is used, ie is the user making a cash sale or cash purchase. The user directly specify this maintains efficient data entry and also solves
I see it as simply entering a receipt/payment with the addition of a Cash Sale customer or Cash Purchase Supplier. If entering a receipt it users the Customer field, the same as invoices, instead of the current Payer field. The same with Payments and Purchase Invoices using the Supplier field instead of the current Payee field.
Basically the receipts and payments using the same forms as Sales Invoices and Purchase invoices respectively, except that with receipts/payments you can select an account to debit/credit i.e. cash or bank.
I believe this would bring it int line with other programs I have used in the past but in some cases more efficient.
Here is an example from QuickBooks 2019 desktop version. I am not sure if this is allowed in this form. Sometimes it is not good to compare like this, but sometimes it is. I thought I would show it as an example. I know there are a lot differences between QB and Manager and how they work.
There are two options. I can either select a customer from the drop down list and it will fill in the “sold to box”, or if it is a one time customer I can just fill in the “sold to box” manually.
1 Like
Good Idea, Make it Optional, You can have drop down menu (customer list linked with sales invoice) selected and it will prefilled the ‘sold to’ space. or just filled in sold to box without using drop down menu which indicates new entry for contacts, not query to customer list.
That makes it more complicated than Manager’s current sales invoice functionality. I would be more than happy with the same functionality as an invoice. If the need was their both could be enhanced at a later time (but to me that would be a minimal incremental advantage over having a “cash customer” or entering the customers details in another browser tab).
Having any ability to link a customer or supplier to a receipt or payment transaction is far more valuable to me.
For example when a user clicks on “New Payment”, the payment screen should default to a type purchase and enable the user to select a supplier (if the supplier tab has been enabled).
Should the payment be to a customer (ie a refund) then the user could change the type to Sale, in which case a Customer could be selected from the drop down list.
Similarly when the user clicks on “New receipt”, it should default to type Sale and selection of a customer (if the customer tab has been enabled).
Note, I don’t see the need to change between a Payment and a Receipt after it has been selected (either manually of via bank import rules) when the ability illustrated above is added enabling the transaction to be clearly labeled as a sale or purchase and link it to a supplier or customer.
@Patch, I think your suggestion is potentially quite confusing. A payment is a payment, and a receipt is a receipt. Designating a payment as a sale implies that money is coming into the business, when the opposite is true.
The original concept for this idea was simply the ability to link the payment (or receipt) to a supplier (or customer) when the payee or payee was one. What I envisioned was much like the example given for the other accounting program:
- There would be an optional customer/supplier field. The dropdown menu in it would change depending on whether the transaction was a receipt or payment. (The label could change, too.)
- If a customer/supplier was chosen, that would automatically fill the payer/payee and address fields.
- If no customer/supplier was chosen, manual entries to payer/payee and address would be possible.
3 Likes
I agree a payment is a payment and a receipt is a receipt.
- However when you want to link a payment or receipt to another entity, you have to choose which address book you want to look up.
- When making a payment you mostly want to link it to a supplier (the group you purchase from), so that is what Manager should do by default.
- When making a receipt, you mostly want to link it to a customer (the group you make sales to), so that is what Manger should do by default
In contrast Quick books has no “Receipt” screen only a “Sales Receipt” hence customers are linked.
I had assumed it would be clearer that a Manager screen with “Sales” on it would link to customer, but if most people find it clear that a Manager screen with “Receipt” on in links to customers then I can work with that too (as that is what I’m already using to allocate my GST sales vs purchases).
The screen for a “Payment” and the option to select a Supplier would be:
And changing the Type to Receipt would enable selection of a customer (if the customer tab was enabled).
An issue with using Receipt to display customers and thus clarify the line items all pertain to a sale, is how to handle negative line items in old transactions. I had assumed all line items would be interpreted as a sale (or purchase) when that variable was set, however linking it to a customer (or supplier) could instead be used by the software.
Yes, so you probably need a checkbox or dropdown to choose between them. Because in refund situations, you could making a payment to a customer. Or you could just have optional dropdown fields for both; selection of either would autofill the payer/payee field.
But, as noted above, you still need the ability to flip for refunds and other situations that reverse the normal choice. Maybe the checkbox on a receipt could be labeled “Change to supplier” and when creating a payment it could say “Change to customer”. One way or the other, you need the ability to allocate both receipts and payments to either customers or suppliers. That capability probably would not be used often.
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:
- not set or “Neither”
- Cash sale
- Cash purchase
The effect of these options would be:
-
“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.
-
“Cash sale”: would tell Manager this is a cash sale so support linking to a customer and entering VAT/GST
-
“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).
This is dropdown where you can select customer or supplier.
Selecting customer or supplier will show their billing address when viewing the transaction.
Clicking on Email button will pre-fill the email address.
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.