l10n_nl_intrastat should only show revenu of revenu accounts

[oca]

l10n_nl_intrastat should only show revenu of revenu accounts

[astirpe]

Hi @jvOrsouw,
there is a flag "Exclude invoice line from intrastat if this tax is present" available in account.tax.
Isn't it covering your needs?

cc @CasVissers

[jvOrsouw]

Indeed, not very intuitive, and I think maybe the wrong way round, because it will still show the lines without a tax-code (like a downpayment)

[CasVissers-360ERP]

@jvOrsouw
What solution do you propose?

[jvOrsouw]

I propose to base the ICP report on the same lines as the 'aangifte omzetbelasting', so based on the 3a (omzet) Tag and journal lines, and have a seperate report to 'show' the errors in the tax reports, f.e. no country, no TINcode, tax-code doesn't match fiscal position, no partner on the revenu-line

[astirpe]

@jvOrsouw your proposal seems more a overall redesign/rewrite of the module.

The module l10n_nl_intrastat was written long time ago for ancient versions of OpenERP.
At that time, the tax tags were not yet available in the system, and that's why the module was implemented the way it is.
During the porting to v9 and v10 we didn't think about any redesign of the module. We just made the pure porting.

For me is OK to think of a redesign, but I would ask @Therp and @StefanRijnhart for their opinion, since they are the authors of the actual module.

[hbrunn]

whoever wants to redesign stuff should go ahead and do it, in the PR we'll see/discuss if the community likes the redisgn. No general complaints from Therp's side in any case.
It might make sense to first create an issue to discuss the details of the redesign so that interested parties (not me) can participate in the discussion.

[StefanRijnhart]

I'm curious after a proper example that demonstrates the problem. You mention downpayments, but it seems that VAT actually applies to downpayments.

[jvOrsouw]

Whether or not there should be VAT on a downpayment is not the question here (Yes, VAT should be on a downpayment, but I'm not the judge if anyone chooses not to apply VAT). Case is that the ICP report should be a representation of the values of rubriek 3b of the tax report, and if an amount is not in 3b, it should also not be in the ICP-report. Also, if a customer is not valid for an ICP report (not in the EU, or a domestic company), but an invoice has the wrong VAT-codes and the revenu ends up in rubriek 3b, the customer should be visible in the ICP report. Checking that report will then cause the accountant to realize the mistake and take action.

[ploegvde]

IMO the Tax Report and ICPO report should be based on the same data. The total amount in 3b should be exact the same as the total on the ICP. So you should not use for the Tax report the account move line and for the ICP the invoice lines.

I agree that changing this is not a good idea for the current module. I would propose a new ICP module. We will start working on this. I will also consult Odoo on there solution, while Odoo will add the report standard ion V11. A backport of their solution is maybe the wises choice.

[StefanRijnhart]

I like the fact that the reports are created from a different perspective as a cross-check on the integrity of the data.

[RoelAdriaans]

Having more data to do cross checks is fine, but the POS module doesn't create invoices, only move lines.
But, they create move lines with taxes, do using only invoices will skip data..

(Another way do fix this is to create an invoice for every pos transaction, but that's not always needed)

[jvOrsouw]

To my opinion, cross-checks are good to have, but that is not the purpose of this report. I would rather have a seperate report that checks all the (likely) possible tax-errors, than abuse this report for that purpose. If you by accident sent an ICP report to the dutch tax authorities that is different from your tax statement, they'll soon audit your entire company. If you find the error yourself and correct it in a later statement, there's no harm done.

[StefanRijnhart]

Indeed, this module does not include transactions from POS. The fact that this report is based on invoice lines is definitely a legacy issue that warrants a refactoring. As @hbrunn has said, any suggested changes will be judged on its own merits.

[astirpe]

I'm working on a new ICP report, as discussed above. PR is #151

In that PR I'm proposing a new module l10n_nl_tax_statement_icp that extends l10n_nl_tax_statement in order to provide an ICP report coherent with the 3b-omzet line of the BTW aangifte report.

You may want to have a look at it.