Le 20/04/16 10:56, Nicolas Évrard a écrit : > * Richard PALO [2016-04-20 12:28 +0700]: >> I've been tinkering getting a fully working 'degressive' amortisation >> method in account_assets. >> >> Although initially it was rather quite simple (at it is in theory), >> there *is* a considerable issue encountered when the frequency >> 'yearly' is selected instead of 'monthly'. >> >> I wonder if it is worth the bother keeping the 'yearly' frequence, at >> least on the basis of the current compute_depreciation implementation >> mechanics. >> >> 1. 'yearly' quite unconveniently hardcodes the annuity date to 31/12. >> This naturally doesn't match the the accounting period end date of >> all companies. >> >> For example, in France, many close 31/03 or 30/09 and in the >> states 30/06 is rather common. > > Indeed this is a bug: https://bugs.tryton.org/issue5500 > Thanks for reporting.
I am not sure this is the solution as it only moved the date elsewhere, most likely *still* not to the end_date of the first fiscal year, which is the problem statement I mentioned. It doesn't react to any change to the accounting periode after the first annuity either. > >> To be useful, there might need to be an initial annuity date (in >> absence of a fiscal year being defined all the way back to the >> activation start_date, that is for amortisations in progress in an >> accounting system migration) > > Indeed existing assets could be a problem. They are as I still have not found any way to get them dealt with. Please advise... The initial balance is typically entered with the depreciated amounts taken into consideration... Perhaps a means to create/edit the 'line's with appropriate values and some manner to indicate (or force) that the movement for these periods are in the initial balance. > > But IIRC, the amortization lines can be edited and you could put as > the first line the total amount of the previous line. This line should > be in the accounting period you use to import the accounting from the > other system (as I guess you're using a special period to import those > data). > >> 2. The company's account period can change, for example to align to a >> calendar year or to the contrary. This happens also quite >> frequently in connection with mergers and acquisitions. > > What happens then accounting wise for the assets? prorata temporis... (which is why always having the monthly schedule would be quite useful). > >> 3. Using only 'monthly' avoids a lot of mucking around in >> calculations seeing if the period is longer or shorter than a >> 'year', needing to verify for each fiscal year end_date that an >> annuity is corrected for an activated asset. >> >> All this is simplified keeping only a 'monthly' computation. >> >> 'Yearly' effects could still be done, for example, leaving it to the >> 'movement', that is, either split by period or grouping all and >> collapsing into a single movement at the end of the period... leaving >> the amortisation 'future' schedule monthly. > > If a company close its period frequently it might be a problem. I > don't know if they can use a temporary account and do the grouping > when closing the year, that might be OK. > Don't really see why a temporary account would be necessary, perhaps more a question to do a movement each month, or group them on the annuity date, potentially in an optimised entry. Seems Sage worked that way, if my memory isn't too fuzzy. But then again;b BTW, Grouping is also potentially useful if the entity closes by quarter instead of monthly. I guess I should have also mentioned that activation dates not falling on the first of the month can be problematic too, with 'linear' anyway. Typically the default is a fiscal year comprised of 360 days = 12 months * 30 days then there is also the method 'actual' (365 or 366 days per year with each month exact), or the method 360 days in the year, but with the actual number of days in the month, or finally the mothod 365 days (ignoring intercalary or bissextile years) with the actual number of days in the month. compute_depreciation does not seem use the typical default. It appears to use a mix of 30 days per month but actual days per year. (Otherwise the monthly amounts would differ under 'linear') This may be a source of difficulties. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/571772FE.7080600%40netbsd.org.
