After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 371581 - RFE: For taxable items, automatically add split transaction to income and sales tax account
RFE: For taxable items, automatically add split transaction to income and sal...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
unspecified
Other All
: Normal enhancement
: ---
Assigned To: David Hampton
Chris Shoemaker
: 364378 (view as bug list)
Depends on:
Blocks: 473506
 
 
Reported: 2006-11-06 16:04 UTC by oliver
Modified: 2018-06-29 21:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description oliver 2006-11-06 16:04:26 UTC
+++ This bug was initially created as a clone of Bug #364378 +++

Example:
Let's say an American supermarket sells a t-shirt for cash 10.00 US$ (net), 11.00 (gross). The sales tax (sales tax 10%). . 
The supermarket accountant enters a new split transaction in GnuCash:

Bank(+) 11 -> Sales (+) 10.00
                    -> Sales Tax(+) 1.00

The problem with this is that the accountant allways has to enter a split transaction when a taxable item is sold. That can be a lot of work if he/she has several thousand transcations! Therefore I would like Gnucash to automatically create a split transaction when a taxable product/ service is sold allowing the GnuCash user to save a LOT OF TIME if he has many transactions. So when the accountant adds a new account like "Sales" GnuCash should allow him/her to define whether the sales are taxable and if so what is the sales tax percentage. Then each time he books to the sales account the transaction is split into sales and a separate sales tax account.

Adding this feature to GnuCash would probably significantly save many accountants a lot of time!
Comment 1 Christian Stimming 2006-11-09 10:54:36 UTC
*** Bug 364378 has been marked as a duplicate of this bug. ***
Comment 2 Christian Stimming 2006-11-09 10:55:39 UTC
Changing severity to enhancement because it's just that.
Comment 3 Frank H. Ellenberger 2007-04-17 21:24:41 UTC
Alternative Solution: weaken the restriction in the account selection, so one could also select bank, cash, cheque and so on instead of liabilities/receivables in the invoice handling.

I agree with Derek, that VAT handling should be done in the business module and nowhere else. But the current invoice handling is not very handy. With the weakened restriction one could create one client "sold against cash" and enter sales straight forward.

Of course the invoice should be marked as paid, depending of the selection.

But One Question, I see: how could it be applied on bank import?

Comment 4 Rolf Leggewie 2007-04-25 16:29:01 UTC
could this be made into a bounty?
Comment 5 Rolf Leggewie 2007-04-26 10:56:48 UTC
There is some interesting information on the "theoretical" background at https://lists.berlios.de/pipermail/kontenrahmen-devel/attachments/20061204/51d6f4a9/attachment-0001.txt (German only, désolé, use one of the online translators)
Comment 6 Rolf Leggewie 2007-08-21 04:21:25 UTC
Oh, and in the German context this does not apply only to sales and the merchant but also to purchased goods (costs) since a business can deduct the VAT portion of the price and claim payment from the tax authorities.
Comment 7 runger 2008-01-11 11:01:31 UTC
I'd like add +1 vote for this enhancement/feature request.

Over here in Europe (in my case specifically Austria) we would save a lot of time if this feature were cleanly implemented.

I imagine it to work as follows:

* It is already possible to define Tax Tables, which are used in the Invoicing module. The same tax tables definitions can be used for this feature.

* A new requirement would be to make it possible to declare an Account as having "Automatic Tax Entries" and associate it with a "Default Tax Table" from the tax table definitions.

* Now, when entering a transaction in such an account, the following logic is applied:
   1. The transaction is made into a split transaction
   2. In addition to the lines entered by the user, an additional non-editable line(s) is added at the end for the taxes. One such line is added for each account associated with the tax table definition.
   3. The amounts in the tax lines are calculated according to the tax table definition, and the preference setting "Tax Included". The accounts against which they are booked are specified in the tax table definition.
   4. The amounts are updated when the user changes the amounts in the other lines.


That would solve most of my problems very nicely. This is essentially what the invoice module already does when you enter invoices into the ledger, but then you have to use the invoice module, which is still a bit of a kludge, IMHO. 

Also, for many transactions the invoice module is overkill - I don't want to have to create a supplier and supplier-invoice every time I buy some office supplies - but I still want the logic to deduct the taxes when I enter the transaction directly in the ledger!

That's why I think it would be better to move the tax handling logic down a level from the invoices into the ledger, thus making it more generally available and useful...

Finally:
* Bonus Feature if you're feeling underchallenged by the above: In addition the user should have the ability to override the "Default Tax Table" on a per-line basis within the transaction. The tax calculation logic would be the same, but instead of applying one tax table definition to all lines of the transaction, each line could be handled by a different tax table definition, leading to more tax-lines at the bottom for the all the different taxes that apply.

This would allow setting different taxes for the different line-items in a transaction, as is the case for example in Austria for Restaurants, which have to apply different taxes to food, alcoholic drinks and non-alcoholic drinks within the same bill.

Comment 8 Jannick 2008-07-12 08:05:14 UTC
12 points from me if this makes all the way down to GnuCash. 

It would be a really fantastic improvement of GnuCash to be much more attractive for SMEs - and here I am not only thinking of Germany. 
Comment 9 John Ralls 2018-06-29 21:15:04 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=371581. Please continue processing the bug there and please update any external references or bookmarks.