1. Create a tax table with multiple rates, i.e. Full VAT: 20% Reduced VAT: 10% 2. Create an Invoice using both rates: Other Stuff, full, 10$ Food, reduced, 10$ 3. Open the report The whole invoice is shown in the "Full VAT" group Shouldn't it be split in both groups?
Hi I assume the account structure used was Asset:Bank Income:Sales VAT:Input and the split amounts are apportioned appropriately e.g. if the full vat component was $10+20% = $12, and the reduced vat component $10+10%=$11, then the transaction would hold the following splits: Asset:Bank +$23 Income:Sales -$20 VAT:Input -$2 VAT:Input -$1 If I'm right then the report cannot distinguish between the full-VAT and reduced-VAT components based on the splits. It only picks up the amounts from individual accounts. The way it was designed (and I'm open to modifying the report) is that each VAT rate would get its own account as follows. Then it should work well. By default the Sales VAT would show $3, but with optional toggle, can split the tax accounts into individual ones: Asset:Bank +$23 Income:Sales -$20 VAT:Input:Full -$2 VAT:Input:Reduced -$1 Let me know if this makes sense.
oops s/Input/Output in the above model
No, the transaction contains: Income:Sales:FullRate: 10 Income:Sales:ReducedRate: 10 Liabilities:VAT:FullRate: 2 Liabilities:VAT:ReducedRate: 1 Assets:A/R:VATrelated: 23 And later on payment Assets:A/R:VATrelated: -23 Assets:Bank: 23
... which should work. Mind posting the test datafile here?
Created attachment 373086 [details] Demo multiple rates in one invoice The example file
Ah. This is what's happened: It is a single-transaction with splits to both FullVAT and ReducedVAT. The split query will ensure that no transaction is duplicated. i.e. the account FullVAT has 1 split which is analysed to produce amounts for sales-without-tax, tax-on-sales, and gross-sales. By default these columns are summed, and you can tick "display/individual sales columns" and "display/individual tax columns" to separate into full-sales, reduced-sales, full-vat, reduced-vat columns. when the account ReducedVAT is then queried, the transaction is not duplicated. The purpose of ensuring unique transactions is to prevent double-counting. So to solve this, you'll want to tick both "display/individual sales columns" and "display/individual tax columns" to separate them. You will *not* want to tick "display/individual purchase columns" which will usually produce too many columns. -- If you really wished to separate fullVAT and reducedVAT then you'll want to do them into separate invoices. -- Technically I don't think it is obvious how to marry up fullVAT-income and liability:fullVAT, and reducedVAT-income and liability:reducedVAT... so I don't think it'll be feasible to separate the transactions in the report.
Btw I think the real bugs here are that (1) grouping of transactions for the report as it stands is nonsensical, and grouping should be disabled for it. (2) this report is transaction-oriented rather than split-oriented, so, split-type fields (eg memo) should be disabled. Try disabling both subtotals (but enable Display/Grand Total) and display/notes in the sorting tab; I think this will clarify this report?
(In reply to Christopher Lam from comment #6) > So to solve this, you'll want to tick both "display/individual sales > columns" and "display/individual tax columns" to separate them. You will > *not* want to tick "display/individual purchase columns" which will usually > produce too many columns. To get something useful for a i.e. german VAT declaration, I would have to tick all 3. > If you really wished to separate fullVAT and reducedVAT then you'll want to > do them into separate invoices. Think of a small shop selling food (reduced) and other stuff (full rate). > Technically I don't think it is obvious how to marry up fullVAT-income and > liability:fullVAT, and reducedVAT-income and liability:reducedVAT... so I > don't think it'll be feasible to separate the transactions in the report. A position in the invoice has this relation. Other places, which have parts of it are the sales tax table, probably account.tax-info, other tax reports. (In reply to Christopher Lam from comment #7) > Btw I think the real bugs here are that > > (1) grouping of transactions for the report as it stands is nonsensical, and > grouping should be disabled for it. When I choose date as primary key, the group footer looks nicer. But I had to reopen the options to choose another range than monthly. Some users have only to report quarterly or yearly depending on the amounts. > Try disabling both subtotals (but enable Display/Grand Total) and > display/notes in the sorting tab; No, grouping by date is nice. I currently do not know, if others can be useful. > I think this will clarify this report? Shouldn't parts of this discussion go in the documentation?
> --- Comment #8 from Frank H. Ellenberger <frank.h.ellenberger@gmail.com> --- > (In reply to Christopher Lam from comment #6) >> So to solve this, you'll want to tick both "display/individual sales >> columns" and "display/individual tax columns" to separate them. You will >> *not* want to tick "display/individual purchase columns" which will usually >> produce too many columns. > > To get something useful for a i.e. german VAT declaration, I would have to tick > all 3. Ok my reasoning for suggesting untick individual purchase columns is because typically a soletrader/business will have only a handful of income stream accounts (eg Income:Sales:FullVAT, Income:Sales:ReducedVAT) and a couple tax accounts (eg VAT:Output:SalesFull, etc), but will usually have numerous expense accounts (eg Marketing, Utilities, Stationery, Professional, Insurance, etc) which will create an overly large spreadsheet. But ticking all 3 is technically no trouble. >> If you really wished to separate fullVAT and reducedVAT then you'll want to >> do them into separate invoices. > > Think of a small shop selling food (reduced) and other stuff (full rate). Agree 1 invoice with multiple sales&tax rates is not something I'd particularly considered. All I know is that the amounts are correct but the presentation may not be ideal. >> Technically I don't think it is obvious how to marry up fullVAT-income and >> liability:fullVAT, and reducedVAT-income and liability:reducedVAT... so I >> don't think it'll be feasible to separate the transactions in the report. > > A position in the invoice has this relation. Other places, which have parts of > it are the sales tax table, probably account.tax-info, other tax reports. Sure this invoice *could* enquire from invoice details. I have not really considered interrogating a split->transaction->invoice->invoice-details but already you'can see this will increase the complexity of the report, and will mean that users must obligatorily use business features to get a useful GST report. I don't also use the account->tax-info either, because it's US/DE centric. In conclusion here I don't myself understand 100% the relationships between the various invoice / invoice-details / invoice-entries / tax-table / account-tax-info work, and how to extract full-VAT vs reduced-VAT grouping from it. Sorry this is too complicated for me for now. From my basic understanding users would need to record their sales/purchase data in a restrictive way so that the report could extract VAT categorisation from it. FWIW I don't use business features myself -- I put the numbers directly from payslip to a normal transaction, so, I wouldn't have this problem at all myself. > When I choose date as primary key, the group footer looks nicer. > But I had to reopen the options to choose another range than monthly. Some > users have only to report quarterly or yearly depending on the amounts. Good! >> Try disabling both subtotals (but enable Display/Grand Total) and >> display/notes in the sorting tab; > > No, grouping by date is nice. I currently do not know, if others can be useful. > >> I think this will clarify this report? > > Shouldn't parts of this discussion go in the documentation? > Agree :-)
For posterity the https://github.com/Gnucash/gnucash/pull/177/ documents the rationale behind this report and its assumptions...
A section in https://www.gnucash.org/docs/v3/C/gnucash-guide/rpt_standardrpts.html would be better documentation.
