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.
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.
@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.
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 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.
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.
Even simpler. If the drop-down field is unused the free payee field appear and can be set. If it is used the free payee field disappear and the drop-down “wins”.
I agree, but I also understand why he didn’t do this. Even in my own receipts and payments I have some double entries where the free-form has received mixed case supplier names, it’s going to create endless duplicates when users don’t properly search or enter data. But that should be on the user.
Also free-formed is going to bring back an earlier problem of how the tax is dealt with, but in my opinion I don’t think that’s an issue because you treat it like a receipt or a payment, but lubos is relying on the payer/payee field being the determinant. Not the payment/receipt type. At least that’s how I think he’s implemented it. I haven’t tested it as I haven’t “upgraded”.
I think the difference in our thinking is that you want to give users flexibility of choice. I want to push users in certain direction.
And the reason why I want to push users this particular direction is because then software will be able to give them better functionality if everything is properly linked-up.
For users to have a choice, it puts mental overhead on them to decide. “Should I create this payer under Customers tab or just enter contact name as free form text.”
We know that if they create payer under Customers tab, it will pay off in the long run - better data quality, less typos, better reports and who knows what new ways we discover to leverage this data in future. So isn’t this what we should insist users end up doing?
OK, but now we are mixing up two issues here.
how software should be designed to be the best for the user onwards
how to deal with historical entries
Both need to be viewed separately.
I have new feature work in progress which will allow to find & recode any field across any tab. This will allow to find all receipts/payments with specific contact and recode them to specific customer/supplier.
I have read this very lengthy topic and I agree that the issue of historical entries needs to be urgently addressed as a priority. I am however in agreement with you Lubos. I quite like the new customer/supplier linking on payments and receipts and am happy to get rid of the free form option. You are quite correct, you can link up far more now because the payee, payer fields are no longer freeform. In time, I think people will come to see the benefits of linking up everything.
But I do agree with @Tut two major complaints. The historical entries need to be moved to the new payee/payer fields (urgently as this really is a problem) and secondly and more importantly, you have still not answered his question of how should one handle cash transactions (that have no individual customer) or a supplier that you will only ever use once etc?
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.
