2014-01-25 Cédric Krier <cedric.kr...@b2ck.com>: > On 25 Jan 14:08, Mathias Behrle wrote: >> * Mathias Behrle: " Re: [tryton-dev] Add history to taxes" (Sun, 19 Jan 2014 >> 12:34:37 +0100): >> >> > * Cédric Krier: " [tryton-dev] Add history to taxes" (Sat, 18 Jan 2014 >> > 16:18:39 +0100): >> > >> > > What does it mean? How does it work? What is it trying to solve? >> > >> > Detailed answer will follow later (after packaging of the bug fix >> > releases). I >> > will try to present some use cases. >> >> First of all, I am not an accountant, but will do my best to shed some light >> on >> the situation in Germany. If someone knows better or different, please make >> your voice heard. >> >> As an example coming to my mind we had the VAT tax change 2005 in Germany >> with >> the following situation: >> >> until 31.12.2005: [1] >> >> code description value >> (input taxes) >> 1575 Abziehbare Vorsteuer 16% 16% >> 1576 Abziehbare Vorsteuer 15% 15% >> (output taxes) >> 1775 Umsatzsteuer 16% 16% >> 1776 empty >> > > So you can buy at 15% but not sale at 15%. > So who can sale at 15%? > >> >> from 01.01.2006: [2] >> >> code description value >> (input taxes) >> 1575 Abziehbare Vorsteuer 16% 16% >> 1576 Abziehbare Vorsteuer 19% 19% >> (output taxes) >> 1775 Umsatzsteuer 16% 16% >> 1776 Umsatzsteuer 19% 19% >> > > I guess this is the change: > > 16% -> 19% > 15% -> 16% > > So I just see a tax rate change and they point to other accounts. > And indeed even if they have the same number, it is new accounts. > As the old one normally should be in the near future balanced, it is > just a matter of no more showing them after the date if the balance is > zero. > >> >> Please don't discuss with me, if you find such layout useful. It is provided >> by >> Datev, the de-facto standard in Germany, to which we have to comply >> (practically all german accountants are using their software). >> >> - They overwrote an old account (1576) with a new one. > > For me, it is the same account. > >> - For customer payments after 1.1.2006 refering to invoices before you had to >> use the old tax (1775) > > I don't understand why you are talking about payments. Taxes are > computed on the invoice base, not the payment. Because you have to give > the invoice to get paid and the invoice must contain the taxes. > >> - For customer payments after 1.1.2006 refering to invoices after you had to >> use the new tax (1776) >> - For supplier payments after 1.1.2006 refering to invoices before you had to >> use the old tax (1575) >> - For customer payments after 1.1.2006 refering to invoices after you had to >> use the new tax (1576) (which was used before for tax 15%) >> >> Our needs are: >> >> - Get for payments the correct accounts per fiscal year > > Still don't understand why speaking about payments. > >> - Get for deferrals the correct follower in the following fiscal >> year/predecessor in the previous year > > Of course you can move the balance of old tax account to new ones but I > would find it strange because it will not have the right description. > >> - Be as flexible as possible with respect to the date ranges (IIRC a VAT >> change >> in Spain happened under year). > > Done with the current proposal.
I'd like to introduce another scenario which I think should also be handled in the future but it would be a different patch in my opinion. Sometimes tax changes simply increase an existing tax type (yes, it's always increasing ;-). So for example you've got the "standard vat" and the "reduced vat". Standard VAT is at 18% and is increased to 21%, for example. In other cases, though, it is a set of products that are changed from "Reduced VAT" to "Standard VAT" even if the percentages of those types do not change. This would require making taxes on products depend on dates. In this case, not sure about the others, it seems it'd be somewhat better to define a "Tax Period" that defines the date interval the taxes should be applied. This way, encoding would be faster and less error prone than having to specify for each product the date and the tax. > >> - Preserve for correct reporting all old accounts, taxes and tax codes, >> related >> in a timely manner. > > No problem because everything is copied from tax. > > > To summarize, I just see a new need (for polishing) to be able to hide > accounts from reporting after a date and if balance is zero. But most of > the reports already hide accounts if balance is zero. And probably an > other one to be able to prevent booking on an account outside a range. > > -- > Cédric Krier - B2CK SPRL > Email/Jabber: cedric.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
