© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
We suffered, the same problem.
But this field sould be allowed to enter manually - in case when OpenERP is not configured to perform it automatically or manual entries should be made. I agree, that at least in EU I do not see the case when it should be different either from debit or credit.
So probably it can be automatically filled from debit or credit and leaving option to change if it is necessary in some other countries.
At the same time I see very useful this field separated for discovering errors, when users enter wrong taxes while creating invoices.
For now it is broken for foreign trade anyway:
At the moment there are situation when it is not possible to calculate this field automatically at all.
For example: when you do an import operations from third countries to EU, it is not possible to calculate this field, because VAT base can be calculated on customs only - e.g. after Import Taxes has been aplied.
In my mentioned case manual entry is not sollution either, there sould be another "amount_untaxed" field implemented - we did it in our localisation.
There are situations, at least in ver. 6.0 (and I believe it isn't ot fixed even o ver. 7.0), when this hits very painfulfy especially dealing with foregn currencies and rates.
Standard situation:
- User created Suplier Invoice (USD) from Purchase Order on lets say February 21th and did not set invoice date, and the currency rate (Feb 21, USD/EUR) and left it in draft state.
- On March 1 user received goods and real invoice, entered missing data (set real invoice date NOTE! Feb 23th!!! Different from invoice creation date!) and accepted it (state Open). In this situation Invoice will generate accounting entries based on currency rate of Feb 23th - thus leading of significant difference of tax_amount and accounting (debit/credit) entries.
We fixed it in our localisation by adding constraint while confirming an invoice when accounting entries doesn't match tax amounts unless manual is set to true along with backport of Akretions's decimal fixes.
Normunds
Alistek Ltd