Community mailing list archives

Re: Accounting v9: updated specifications

Nhomar Hernandez
- 10/25/2014 18:46:09
Hello Fabien.

In line specific answers.

2014-10-25 11:16 GMT-04:30 Fabien Pinckaers <>:
Dear Odoo community,

Following our accounting workshop with community members (around 25
attendees from UK, NL, BE, CH, FR, RO, DE), we updated the accounting
specifications for version 9:

We still have a few open questions for the community:

1/ does anyone use "Python" computed taxes for another reason than:
rounding (at 0.05 in Switzerland) or division computation (like in
Bolivia or Brazil)
In Venezuela, Mexico and Colombia we developed an external "Scale" (In spanish Baremo), which allow import some variables used by goverments to manages tax rates.

The example is complex and probably if we improve (instead hide) the python code computation of taxes it can be useful for such feature.

Just as an example:

In VE:

If you sale services (product_id.type) AND \ 
the amount is higher of a base amout (taken from an external table that looks like currency one) AND \
the customer (partner_id.fiscal_Type [which is computed from a set of legal definitions]) AND \ 
summatory of invoices is greater than X and les than Y in the same period THEN:

withholding == the the RATE is A.

When you combine all the options only one tax (which is a "withholding") you can face something like 150 options for the same tax.

And this tax must be computed and declared in a separate account, with an specific report.

May be improve the python code computation to be able of use all those variables on invoice time, and countries with complex tax systems only need to create data modules with python code.

The example I gave from Bolivian one was the simpliest one we used to customize.


And ona VERY important concept is that, tax by tax we can declare and taxes based on "Cash" on or "Documents".


VAT in Venezuela is based on "Documents" not on "Cash".


Withholding (for the same document) is based on Cash not on Document.

When you base a tax on Cash basically the flow with payments in advance works like a "Promise" in ajax jeje ;-) it means.... the tax is "suposed on a rate that you configure in a tax of such type in your tax system" AND one time you reconcile the invoice (which has the correct information) then the reconciliation process take this into account.

And this is only talking about the normal flow, I will not talk about the inverse way (Credit notes) ;-).

I strongly believe you can achieve a BEAUTIFUL python code computation system if you understand the importance of such, if you decide it is not important because it is "too complicated" then you will never help to achieve such feature.

Me in your place left the python code computation as it is with a good unit testing to be sure always works.

We actually "Don't use the python code computation" but the real reason is that it is too basic for us and doen't allow (at least not easily) for example change accounts, works with the contextual documents fields, contextual partner fields and so on, and we improve everything with our module. But it can change if you improve such features.
2/ does anyone have refund Tax accounts that are different from the tax
account of the related invoice? (I mean account.account, not
In MX VE and CO, refund and invoice at accountant decisition can be managed in different accounts.

And not only taxes.

- Income.
- Payable.
- Taxes.

On different accounts.
3/ do you sometimes have for THE SAME invoice, some lines which are with
tax included in price and other lines with tax excluded of the price?
Yes we do VE and CO and MX. (but as I explained above we didn't use it because we externilize to other objects the computation).

We have taxes with are mentioned explicit in the invoice.
Other that are included in prices
Other explicit over the base amount (VAT). 
4/ did you ever needed a tax with two levels? (a tax that has children
and those children also have children)

No never, I think at our begining it can help us but when you mix different levels with python code is totally a mess.

But not because the feature can not help, mor because as it is today is unusable. :-( 
Please have a look at this document and check if it matches with your
country requirements.

I made some comments in the document....

Really good job!, with the time I think you are doing a great job, but be care we have pending some concepts not mentioned on the document (at least not explicitly).

- Standard of reports (IFRS) not mentioned in any place, just the "Killing Feature" of reports, we should think there on Standards (Standard in the professional term not in the context of the "Commonly accepted only").
- I insist believe the bank reconciliation will replace the voucher concept is a BIG mistake, people in Cash doesn't load Account Move Lines they load "Vouchers" and the "Vouchers" can be taxed even, think on that.


Fabien Pinckaers
Odoo Founder

Phone: +
Twitter: @fpodoo

Instant Demo:

Post to:

Saludos Cordiales
Nhomar Hernandez