In my opinion making the payee/payer label a menu is a far better solution
can be set to most common default ie customer for receipt, supplier for payments
enabling users without the customer or supplier tabs open to enter appropriate tax codes
set to “counter trade” for line item level specification of supplier or customer. If a blank option was allowed that would mean no tax codes were allowed
can readily be extended to add expense claim payers, employees to the menu. If capital accounts were added then a “capital account sale” and “capital account purchase” menu options would probably be required
the list the users need to wade through during data entry remain short an accurate
the type of contact is clearly shown during transaction review / auditing so tax code implications evident
The problem with grouping all external entities together is while the program knows if the UUID corresponds to a customer or supplier or employee or expense claim payers. The user has to guess
Similarly a list twice or thee times as long makes no difference to a computer, but it makes a big difference to the users experience
Not necessarily. Some users have thousands of customers. So even separating into categories (which I support) could leave a very long list. But I don’t see any way around that.
There is not a problem really, you can still keep all of the existing UUIDs unchanged. In fact this will solve this problem and many others. You create an generalized object (lets call it External entity) that will keep what makes the entity unique (name, legal ID) and be a parent to various objects like:
multiple customer accounts: 1 under Account Receivable control account, another under Unearned Subscriptions (current assets) another under Unearned Subscriptions (Non-current assets) … etc;
multiple supplier accounts: 1 under Accounts Receivable control account, another under Advances to Suppliers … etc; as well as
a capital account (i.e one of the partners).
The child objects (customer accounts, supplier accounts, capital account … etc.) will inherit their parent attributes and will only contain information specific to the type of relationship (i.e. contract reference/attachment, specific contact for such relationship, credit limit and payment terms … etc.) and will have their UUID in the exact way that they currently have. They will also appear in their current tabs. If you find it burdensome, you can also leave everything unassigned to an External Entity since you will never have to mention that in any transaction.
At the end of the day, since all of these accounts are under the External Entity object, you can run a summary report for all of its accounts and find out systematically without any human intervention what is the absolute net balance. In my example that entity was a shareholder who’s also a customer as well as a supplier, pay them their dividends net, without ever forgetting to include any of their accounts – they can have 100s of accounts.
Because there could be dozens of customers, for example, named Robert Jones. Don’t misunderstand me. I am not suggesting there is an alternative. I was just responding to @Patch’s comment that the list would be short if you broke it into categories. The problem is no different than what you now have for invoices. So, as I said, I do not see an alternative.
I am in total agreement with you @Tut. I was just commenting about this particular part of @Patch comment:
However, as far as common names problem, you already have multiple Bob Jones in customers as well, and multiple entries in suppliers and also employees. So this problem is not unique to the combined list.
Another business who is using QuickBooks will also have the same problem. So this problem is not unique to Manager as well.
While you can do nothing about these problems, you can still distinguish between customers, suppliers and employees by utilizing the codes.
Personally I use C_ at the beginning of customer codes, V_ at the beginning of supplier codes and E_ at the beginning of employee codes.
The accuracy I was referring to was when a user is data entering a receipt from a customer, They
choose new receipt
customer is pre selected from the payer menu (and they change it if they want to do something unusual)
they then select the customer applicable to this receipt.
The accuracy benefit realised at this time as there is no chance of accidentally selecting a similar sounding supplier or the suppliers contact entry and resultant error in tax reporting.
Similarly during auditing. When an auditor is looking a transaction but is not aware of all the businesses suppliers and customer, the tax code implications do not have to be deduced from the name shown in the contact field.
I also agree with you completely, @Patch. For me that is a must have.
In fact I am sure that even as we speak, @lubos must be working hard silently to get this back to working, but to be fair, this is to be expected when you introduce a huge change like this.
When an auditor looks at a transaction to investigate tax code allocation, the tax code implications are clear independent of knowing the details of each business suppliers and customers.
Another advantage of the approach is form options can be changed based on the type of the contact.
In addition tax codes can be allocated without having the customer or supplier tabs enabled
So you are in favor of separating the tax codes into purchases and sales.
I don’t know why this was not done already especially since it would have been much easier and safer, but from my experience with Manager.io I knew that things are always done differently. However, I did not expect it to go this way.
As far as I am concerned, if the tax issue hadn’t been handled the way it have been, I wouldn’t really have had anything to complain about, everything would have been fine for me.
But now since we are here, I think even if the taxes were resolved your way, I still think that External Entities idea deserves its own thread if @Tut would allow it and you would support it
This is likely too simple of an item to mention here, and possibly the wrong place entirely, BUT - could a tax code actually be attached to a customer/supplier account so that when used on an invoice or payment/receipt, the tax code is automatically filled in for each line item? I know here in the USA out taxes are far less complicated but I have a large number of customers who are tax exempt. At this point I have to go through every line item individually and set the tax code for each one rather than have them come up correctly based on the customer. Just a thought while this is being adjusted for the program.
Thanks.
Your idea sounds simple, @KrisK. But you already have the ability to set default tax codes for inventory items, non-inventory items (different ones for buying and selling), inventory kits, and profit and loss accounts. And there are situations where customers could be exempt from tax on some items but not others. Or they may be exempt in one jurisdiction but not another. The determination of which tax code designation or exemption rule governs could quickly become complex and might not be handled uniformly across jurisdictions. And when program behavior is controlled by things unseen, users can be confused.
I’m not saying it isn’t possible, only that it might lead to more than you think.
As I said, US taxes seem very simple themselves as opposed to VAT. For me, I sell the same items to general customers a I do to schools/churches so I cannot set an appropriate tax code at the item level. Now when I sell 10 or so items (not uncommon for my invoices), I must go through every item line and set the tax code for each. This happens with both types of customers since I’m afraid that if I set an inventory item to a particular tax code, I might miss changing it for a different type of customer. I’d rather it some up by customer and then have the option to change something if for some reason it needs to be.
Perhaps try using inventory kits? I’m not so sure about this suggestion of mine as well, but it might be worth a shot.
So this is how I think this can be setup.
First, the main inventory items should not have their tax codes set. Then, create an inventory kit with the same quantity for its bill of material and output material. Just add a description or code on the output to specify if it’s for General Consumers, Tax Exempt, and so on. This way, your overall inventory count will not be affected. You’ll continue to purchase these items under the main inventory item account and sell them as kits specified for each kind of customer based on their tax classification.
I appreciate the thought but almost every sale would end up with a different inventory kit. We sell video production systems so a main system - one of several options), one of 3 or 4 controllers, monitors of different types, back up hard drive or extra drives for recording, other add-on software programs, etc. It would be like having a buffet set up as a variety of inventory kits. Rarely would two people get the same items.
AND for most companies, they want individual line items with serial numbers and costs so that they can give it to their insurance people for coverage since the systems are rather expensive. I do have some inventory kits for small items and, if I remember correctly, they don’t show all the individual items in the kit on the invoice when you add it as an item.
Correct. You can use an inventory kit not only to aggregate inventory items but also to subdivide one of them and to set different attributes from the main kit. You can also set custom fields on inventory kit.
