Community mailing list archives

Re: Accounting v9: updated specifications - Poland

OpenGLOBE, Grzegorz Grzelak
- 10/27/2014 11:19:00
Answers from Poland:

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)

Yes, we plan to use Python computed taxes.

We have special tax rule for buying personal cars. You get invoice with 
23% tax but you have to split it to two parts (40% and 60%), Only 60% 
you can take as VAT tax, 40% has to go as usual cost (like net). But it 
is condition that the part 60% cannot exceed 6000zlotys (PLN). 
Everything above 6000PLN has to go as a net cost.

So we implemented division of 40%/60% by tax children and leave 
condition checking of 6000PLN to perform by accountant manually. We plan 
to improve this solution to check condition using Python code and adjust 
whole calculation by Python automatically.

But I agree python calculation is not nice solution in tax configuration 
and mostly is not enough anyway. Fe. in our case we have to teach 
accountant that particular car has to be always separate product to be 
able to calculate its price paying monthly leasing payment for 
particular car.

So I suggest to almost remove python code calculation but leave good 
programming entries for localisation developers. I mean you should make 
many places for inheriting. I can imagine also that instead of Python 
code you allow user to enter function name which will be created by 
localisation developer. Such solution is fe. in ir.cron object.

2/ does anyone have refund Tax accounts that are different from the tax
account of the related invoice? (I mean account.account, not


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?

No. (read: it is acceptable limitation)

4/ did you ever needed a tax with two levels? (a tax that has children
and those children also have children)


Regarding other changes in Odoo Accounting:

I cannot understand why you make assumption that CoA hierarchy is 
complex. Every accountant understand it and treat it as fundamental 
feature of CoA. So I don't understand why hierarchy ought to be optional 
in account Tags. I seem that I will revert usual hierarchy in Polish 
localisation when I see your result.

Another thing I cannot find in the document is Virtual CoA and 
Consolidation (Internal) Type of Account.

P&L Statement and Balance Sheet in prior versions of Odoo based on 
Account Type was unusable in Poland. I see that P&L and BS will be based 
on Account Type in 9.0 too. We implemented Profit and Loss Statement and 
Balance Sheet using Virtual Chart of Accounts functionality. We had to 
develop such virtual CoA once for whole country. What is wrong or 
complex in such predefined CoA for whole country once? Customer work was 
only to assign Financial Accounts FROM normal CoA TO P&L and Balance 
Sheet Accounts. All accounts of Profit and Loss Statement and Balance 
Sheet are Consolidation Type (apart of View Type). I hope we can use 
this type of functionality in 9.0 because I fear that some generic idea 
of P&L or BS will be unusable in Poland again. I see Account Type called 
Aggregated. Is it new name of Consolidation?

Generally I think you can leave more specific thinks to localization 
development because it is impossible to cover everything by you but you 
have to keep basic structure like hierarchical CoA and make a lot of 
wise programming entry points for local development.

All the best
Grzegorz Grzelak