On 18 Jan 14:32, Mathias Behrle wrote: > * Cédric Krier: " [issue3600] Add history to taxes" (Fri, 17 Jan 2014 21:58:45 > +0100): > > > New submission from Cédric Krier <cedric.kr...@b2ck.com>: > > > > We need a way to evolve taxes overtime but just changing the tax is not > > enough > > because we need to have both version depending on the time. > > Only handling taxes this way is not enough. The following objects coming to my > mind need consideration of timeline, too: > > - accounts
I don't understand. But maybe, you are talking about account that must no more be used after a specific date? > - account types Neither this one, this things is a pure Tryton invention for reporting. Except if again it is just about hide it after a date. > - tax rules Maybe and it will not be too difficult but I would prefer to have a use case for it before bloating it. > - tax codes Idem as others > - ... > > > So here is a proposal to historize the taxes, we just add a start/end date > > on > > the taxes and the compute method just skip the taxes that are not in the > > range. So the idea will be to create a main tax of type "none" and many > > children taxes with different date ranges so only one will be take for > > computation. > > Indeed it is not historization, but timeline. Because we need to know not only > in the past, but also in the future. It works. > I would like to request the general needs in other countries as Germany. I > think with the unification of standards in the EU those needs shouldn't be too > different. Please elaborate the needs. > We are using so far a different approach than the one in [1]. We added > timeline > features to accounts (tying them to fiscalyears) and additionally defined > successors/predecessors. What does it mean? How does it work? What is it trying to solve? > The latter is a requirement, if you need to know, > which account will replace another in a following fiscal year (e.g. we had a > tax change in Germany, where we had to handle the following problem: > after the cutoff date the tax account for payments with the old tax changed to > a new account with different code, and the account with the former code > changed > description and tax value). You mean that the taxes are not collected based on invoice but on payment? > So tying accounts to fiscalyear Such design just broke all the flexibility of the current accounting module. > and defining date ranges for the tax side > provided us the needed flexibilty for the scenarios we were encounterd with > and could imagine. > > Highly appreciating the input of the needs in other countries, In Belgium, the current design is by far enough (it even has too much options). Apparently France, they often play with the taxes rate so the current historization should be good enough. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpNx5cVmbBqE.pgp
Description: PGP signature
