Oh, we are back to different behaviour for cash vs invoice transaction.
Does that mean the recommended work around for users who have negative amount sale or purchase line items is to create dedicated tax codes and edit the report transformations themselves?
@Patch Definitely not. I need to think this through though.
With the prior way, the work around for users with counter transaction was the same as users with invoice counter transaction ie enter a purchase and sales document. Not ideal but consistent with Managers behaviour elsewhere.
In contrast there is no user work around for v20.8.67 where a user has a negative amount cash sale or purchase entry.
Please take care.
I think you will find you are miss interpreting the majority. It is more likely the majority assume an accounting program gets tax accounting accurate for them when processing transactions the recommended way.
Most users will care a lot if either method produces results which are different, particularly it they are wrong for their use case.
THANK YOU especially on behalf of all those Users who have Recipient Created Tax Invoices.
That is why the old, now current scheme is superior. The accounting for âsale and purchase at the same timeâ as a single transaction had always existed prior to the introduction of Levy taxes, therefore the accounting for those transactions shouldnât be forced to change after the introduction of Levy taxes, as those taxes are only an ADD-ON to the transaction.
I just wish you would STOP promoting that the difference between cash vâs invoice is somehow wrong behaviour - IT IS NOT. Levy Reporting is about the ACTUAL receipt and payment of the Levy, it is not about the accounting transactionâs posting.
That difference in behaviour, which was clearly explained in the topic âLevy Taxes - an Introductionâ is how it was designed to be when I was a member of GST implementation teams, which in turn, is strongly based upon the European VAT model.
Users who have negative amount sale or purchase donât require a work around.
Exactly true, that is why Lubos had to revert back to the CORRECT model so he could make âreverse charged tax codes to appear in general ledger correctlyâ - that is (in your words) âgets tax accounting accurateâ.
Sorry to say, but at least not for the users who want to make use of the âfamousâ Concept BTW Aangifte.
I think itâs better to warn those users that by making a credit note (sales) or debet note (purchase) or journal entries like @Hennie has described, the figures mentioned in the Concept BTW Aangifte are useless.
I can give you an example where Concept BTW Aangifte says I have to pay taxes (which is not right), whereas the standard tax reports and the general ledger tells me I can claim BTW (which is right).
Until @lubos comes up with a solution to this problem, I implement extra tax codes with corresponding accounts. Like, among others, tax code [VAT 21% Sales] linked to general ledger account [VAT 21% to be paid] and tax code [VAT 21% Purchase] linked to general ledger account [VAT 21% to claim].
Indeed, extra tax codes means more chances bookings go wrong, which burdens the control mechanism.
(It would be nice if the user could determine the order of which the tax codes are shown in the program when making sales and purchase invoices and journal entries).
So until solution is found, I donât make use of Concept BTW Aangifte anymore, but I am using the standard tax-reports to complete the tax form.
Maybe [Custom Reports] can be helpfull in near future.
@Ries, I agree with you.
This has all to do with the fact that the VAT-mechanism in Manager treats every credit entry as a âsaleâ and every debit entry as a âpurchaseâ. This is per definition wrong. A creditnote is a negative sale and a debitnote is a negative purchase. In the P&L it is shown correctly but not n VAT-reports. @Lubos is aware of this. As long as the mechanism isnât changed by @LUbos, we have to deal with this ommision as well as with the problems with journal entries where you can have negative VAT entries as per the examples I have given on this forum.
Anyway I am glad that âreverse charged VATâ is now working fine, but there is still some work to do to have a correct VAT mechanism. I sincerely hope that @Lubos will solve this in very due course as there are in the time between a lot of threads on this forum about this problem.
@ries there is going to be new set of tax codes and new Concept BTW Aangifte report for Netherlands by end of this week.
During transition period, there will be two versions of Concept BTW Aangifte until we can all settle on new one.
Lubos
Managing the transition is probably just as complicated as defining the final solution.
If Manager is eventually going to have independent tax codes for sales and purchases, then ideally a script would be run which converts dual function tax codes to single function tax codes for each line item. Using the assignment Manager has been using for the longest time would be best as that would minimize program changes to old reports (of benefit to other users & I can adapt to any true solution).
I have serious reservation moving forward with Manager using a different method in invoiced compared to cash transaction to determine sales / purchase assignment. Doing so deceives most users.
Good job. Now that youâre at it, please consider changing lines 55 and 56 to:
{% assign 5a_omzetbelasting = 1a_omzetbelasting | plus: 1b_omzetbelasting | plus: 1d_omzetbelasting | plus: 2a_omzetbelasting | plus: 4a_omzetbelasting | plus: 4b_omzetbelasting | floor %}
{% assign 5b_omzetbelasting = taxOnPurchases[BTW_6] | plus: taxOnPurchases[BTW_9] | plus: taxOnPurchases[BTW_21] | plus: 2a_omzetbelasting | plus: 4a_omzetbelasting | plus: 4b_omzetbelasting | ceil %}
I maybe asking something obvious, but can someone write a summary post about what actually is now the default behavior in Mangager, what has changed, or not⊠etc.?
With Manager versions v20.7.30 - V20.8.66 âCashâ transactions were handled in an identical manner to invoice transactions.
With Manager versions prior about v20.7.30 after v20.8.67 cash transactions depend on if the line item is a credit or debit but invoice transactions depend on if the invoice is a sale or purchase invoice.
The effect of which is summarized below
| Manager versions | All existing | Proposed |
|---|---|---|
| Tax codes | Both sale & purchase | Only sale or purchase |
| Sale purchase assignment | Sale invoices are sales, Purchase invoices are purchases | Dependent on tax code type |
| Sales Invoice | line items all sales | Line items with Sales Tax code are sales. Line items with purchase tax code are a purchase counter trade |
| Purchase invoice | line items all purchases | Line items with Purchase Tax code are Purchases. Line items with sales tax code are a sales counter trade. |
| How counter trade is entered | Requires 2 documents Enter other party as supplier and customer. Enter purchase & sale invoice | Enter sale component with sales tax codes, purchase component with purchase tax codes |
| How negative amount line item is entered | Direct entry on a line of appropriate invoice type | Direct entry on a line of appropriate tax code type |
| Property | Prior about v20.7.30 after v20.8.67 | About v20.7.30 - V20.8.66 | Proposed |
|---|---|---|---|
| Tax codes | Both sale & purchase | Both sale & purchase | Only sale or purchase |
| Sale purchase assignment | Credits are sales, debits are purchases | Receipts are sales, payments are purchases | Dependent on tax code type |
| Cash Sales | Credit line items on receipt or purchase | line item on a receipt | Line items with Sales Tax code are sales. Line items with purchase tax code are a purchase counter trade |
| Cash Purchase | Debit line items on receipt or purchase | line items on a payment | Line items with Purchase Tax code are Purchases. Line items with sales tax code are a sales counter trade. |
| How counter trade is entered | Enter counter sale a credit or counter purchase as a debit | Requires 2 documents Enter purchase as a payment & sale as a receipt | Enter sale component with sales tax codes, purchase component with purchase tax codes |
| How negative amount sale or purchase line item item is entered | No user method, requires created contra tax codes & editing report transformation | Direct entry on a line of appropriate payment or receipt | Direct entry on a line of appropriate tax code type |
With the proposed use of different tax codes for sales and purchases there will be more tax codes, but not double as only those needed for a jurisdictions reports will be created. Manager user interface can be optimized to facilitate the most likely tax code selection. As a result tax code menus will not be twice as long.
The most likely tax codes (sale or purchase) can be put at the top of the menus and the other type put in a sub menu at the bottom. Alternatively an invoice (or payment/receipt) could have an option to open a counter trade section where the alternative tax codes could be selected.
Are we supposed to implement this on our own or something is being rolled out within Manager?
@novica I donât fully understand this topic and exactly what transactions are affected. But my understanding is that 99% of the entries in Manager are not affected - regardless of which method Manager is using. The reason being that most sales are credits and most purchases are debits and likewise those same entries on sales invoice are sales and those same entries on a purchase invoice are purchases.
The problem has been very specific entries where a supplier is a customer or vice versa as well and/or something about levies as well as negative sales and negative purchases (basically when you refund I presume?). Neither of these are relevant to nearly all entries in Manager for most businesses.
So I speak under correction, but I believe that nothing will change for most users. But I am not entirely clear on this point as so many of the examples raised are not examples of accounting that I would ever use. I donât really understand the difference between financial and tax reporting which seems to be the cause of all the problems.
So I am admittedly unclear as to whether these changes will affect most users or not, but my impression is no based on what I have read and understood. Not being a charted accountant myself I canât say for sure though.
What I believe is proposed is that Manager will continue to use a single tax code for the vast majority of transactions and add additional (but not double) tax codes for those specific entries which seem to require a different approach. Although how end users like myself will know which entries fall into this category is way above my understanding. So I would have to rely on my accountant for that support.
Then the creation of the âConcept BTW Aangifteâ report itself is the problem and not the tax code model. Let me illustrate: first with a sales invoice, then with a credit note plus the tax reports.
Therefore, if the âConcept BTW Aangifteâ is not showing that result, then the construction of that report is wrong, not that the tax model is in correct.
So as I originally stated âUsers who have negative amount sale (credit note) or purchase (debit note) donât require a work aroundâ. But perhaps the reports which are built from those transactions arenât representing the transactions correctly.
This is not true, refer to above examples where the credit note (a debit entry) appears as a negative Sale. However, it appears, based on @ries comments, that the âConcept BTW Aangifteâ report itself is not translating those credit notes as negative sales. Now to illustrate that point, lets compare those same transactions with the Australian equivalent report - the GST Worksheet - before and after the credit note:
Everything is being handled correctly, so this emphasizes that the problem facing Dutch Users is within the âConcept BTW Aangifteâ report itself, not the tax model, which is further confirmed by @ries comment âI donât make use of Concept BTW Aangifte anymore, but I am using the standard tax-reports to complete the tax formâ.
On this I can concur and in the topic âLevy Taxes - an introduction toâ I highlighted this with:
âJournal Entries are a ârealâ issue, however that could be addressed by having a mandatory dialog dropdown with these three selections - Sales, Purchases, Financial. The data entry lines would only appear after the selection had been made and for Financial, no Tax Code fields would be displayed.â
Thank you for finally confirming that the old, now current, model - âwould be bestâ.
Definitely not. Please donât get suck into the irrelevant distraction between invoice and cash transaction behaviour. Levy reporting is based on law, not accounting software behaviour as some would have you believe.
Financial reporting is Income vâs Expenses whereas Tax reporting is, in your case, Vat received vâs Vat paid.
@Brucanna You somehow manage to get these figures, which look normal, all is Sales:
Why do I get these figures:
Where the amount of euro 200,- reflects a sales invoice, so correct.
Where the amount of euro 10,- reflects a credit note of sales, made by the system Tab Credit Notes,so not correct, as it is in the column [Net Purchases] and should be in [Sales] with a negative amount.
Where the amount of euro 50,- reflects a credit note of sales, made as a negative sales invoice, so not correct, as it is in the column [Net Purchases] and should be in [Sales] with a negative amount.
Is it because I am a Cheesehead⊠
or do you have a solid explanation?
This is what I was referring to. When I do a sales or purchase invoice, I just put in the inventory item and vat etc. I have no idea what the difference between financial and tax reporting is in this context of creating purchase and sales invoices.
Iâm closing this topic because I think I came up with the solution to retain dual purpose of tax codes and at the same time made it possible to provide enough information about transactions to determine whether tax transaction is a sale or purchase.
See:
