On 2016-04-20 14:15, Richard PALO wrote: > 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.
Probably the current design is wrong. It should not be based on monthly or yearly but instead base on period or fiscal year. But then we can not create forecast as it is highly improbable that fiscal years and periods will be create years in advance. But if the user has the flexibility to define the date at which the frequency starts than he can adapt to match its configuration. > >> 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. I guess you can just put as value the value already depreciated at the start date. > >> 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). In such case, I think a new accounting will be started where all existing assets will be re-encoded. > >> 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. The methods are customizable so you can add the one you want easily. > 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') Patch is welcome. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- 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/20160422142316.GM3191%40tetsuo.
