Community mailing list archives
Re: [Odoo] accounting roadmap v9: a survey and a doodleby
as there is no other pre-discussion medium, of which I would have knowledge so far. I'll use this thread for making an amplified suggestion about a different tax code design, I have in mind. I would be looking forward to hear your opinion...
(I also put this for the records of odoo on the survey, hope this is a good practice, to help with the stage gate process)
- Make a tax include definitions for sale and purchase on a single tax (so there is no need to set up and maintain two taxes of the same concept) - reduction by half or increase of granularity with little extra cost (step to IFRS XBRL-readyness)
- Make tax code a 1:1 storage account of a tax. wich is silently linked and created and without need of maintainance- doesn't even appear. (move "printable" concept to tax) This "muted" account should hold 8 values: Sales-Base, Sales-Tax, Sales-Base-Refund, Sales-Tax-Refund; Purchase-Base, Purchase-Tax, Purchase-Tax-Refund, Purchase-Base-Refund (if the base for example is only a % of the transaction amount this logic would be maintained on taxes as it is right now.
- Change what is now accessible to the user as Tax Codes to a mere view definition factory, where the user should be able to define aggregation views in a flexible way on the granulary information. It should be possible to include the same value in multiple view definitions, as well as group concepts in children view and reuse them multiple times (for maintainibility)
I hope you understand the motivation and ideas behind this sugestion, which are - for a check: maintainability/conveniance, flexibility, xbrl-readyness, granularity, spead/performance (!) and genericality.
AFAIK this is consistent with the new tax design to come.
Quentin De Paoli (qdp)