When copying from Purchase to Sales Invoice (or sales invoice to purchase invoice) ideally, the account should be excluded. Very rarely will the sales and purchase accounts be the same.
With the account being copied on to the newly created transaction, it is natural to overlook the inaccuracy as one would see it filled and skip to fill in data where fields are empty.
While cloning, it makes sense to keep the account.
While I understand the thinking behind this suggestion, I disagree with such a change for three reasons:
Consistency. Copying behavior should be uniform throughout the program so users know what to expect. If every other copy action carries over accounts, a user is just as likely to overlook an empty account among populated fields as to forget to change it. Then there would be a transaction in Suspense to correct. When correcting the transaction in Suspense, there would be no clues as to what the right account might be. But if a review of income account, for example, shows all sales invoices and one purchase invoice, the errant transaction is easy to find and the fix is obvious.
Lack of Applicability. The most obvious reason to copy from sales to purchase invoice or vice versa is when buying and selling inventory items not normally carried in stock. When an invoice is copied to the other type, the accounts automatically change. For example, when a sales invoice is copied to a purchase invoice, the Inventory - sales account for an item is changed to Inventory on hand. In fact, in neither copying direction can the account for an inventory item or non-inventory item be changed anyway.
Conflicting behavior. Related to #2 above, if line items other than inventory and non-inventory items are present, their accounts would vanish, but those for defined items would remain. Users would be confronted with apparently random behavior, having to fill in some accounts but not others.
I would be curious, @Paparazzi, to read some specific examples of use cases where losing the account would actually be helpful. While the assertion that accounts will be different is easy to make, it is not so obvious to think of examples where vanishing accounts will actually be helpful. But maybe you have something definite in mind.
@Tut, I currently use this method to cross verify:
… a review of income account, for example, shows all sales invoices and one purchase invoice, the errant transaction is easy to find and the fix is obvious
We are into the business of transport brokerage (sort of, if that’s how it is called). Something similar to Uber if you would like but more on a manual level. A client in need of transport approaches us, we find independent truck owners at fares lower than a “transport company” would normally provide at, add a minimal margin and bill the client.
We therefore first make a purchase invoice debiting the expense account and crediting the transport provider. Immediately thereafter, we copy the purchase invoice to a sales invoice, bump up the figure by 5 or 10% and raise the sales invoice.
Based on the way Manager currently works, the credit for the sales invoice goes to the expense account automatically unless the accountant is careful enough to switch to an income account.
I do understand and accept the need for consistency across the program when copying across various transactions but just thought that this is a case where copying is certainly not correct and hence brought it up.
@Paparazzi, I suspected you were doing something like this, but did not know what you were selling. You can do exactly what you describe with non-inventory items and have the account changed automatically. The example in my point #2 is similar.
Define a non-inventory item under settings. Specify the income and expense accounts you want to use. Create a purchase invoice including the non-inventory item, and it will be posted to the expense account you chose. Copy the purchase invoice to a sales invoice, and it will automatically be shifted to the income account you designated. You will, of course, need to specify a customer, because the supplier no longer is relevant.
If you want, you can also specify purchase and sales prices, although those might not be constant for you. But if you do, they will change automatically, too. For example, if you set up your non-inventory item as 1 km of transport, purchased for 10 AED and sold for 11 AED, you would make 10% profit on every km sold. As you enter a trip, you would specify the number of km involved.
You would actually get even stronger guarantees against accidental mistakes than with the method you suggested. And if you have different rates for different situations, you could set up additional non-inventory items.
Oh! Wow! Thanks @Tut,
Did not know the Manager could be all that powerful! It’s late night here, but I will certainly try it out tomorrow and hope to get it working.
Will certainly let you know. You’ve been very helpful as I take my baby steps here
As I thought more about your situation, I realized you might want to set up non-inventory items based on:
Some of these will be purchased from your subcontractors. Others could simply be fixed charges you add to sales invoices after copying over the purchase invoice. And nothing prevents you from using several at once.
Really excited now. Looking forward to tomorrow
One other thing. Make sure to designate these non-inventory items as able to be both purchased and sold.
Working well with the inventory type of approach @Tut
Just need to find a way to hide the “Code” column on the sales invoice.
Thanks for the tip. It was very helpful.
There is a Guide on account codes that covers that.
I’m removing this from ideas on the basis that non-inventory items elegantly solve this issue.
This is because non-inventory items can have associated “swinging” account based on whether transaction is a sale or purchase. So if one is using non-inventory items, not only copying from purchase to sales invoice will clear the purchase account, it will also set the right sales account.