Le 22/04/16 16:23, Cédric Krier a écrit : > 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.
At the very least there needs to be some impedence matching provided between month/year and period/fiscal year. There are numerous means and reasons behind the depreciation decided upon in a business. If the mechanisms around generating schedules and managing actual moves are simple but rich enough, the it should be able to cater to most needs. That is, as long as the methods to generate the moves allows for: - initial load of an accounting - for fiscal year end (even if changed) - as well as for interim accounting situations (many company elect or have obligation to prepare one) then KISS should probably apply. If there were a requirements needs analysis done, I would wager that the all that is really needed is the 'true' past, and future simulation. A certified accountant or auditor may potentially invoke more specific details, though. The past (prior to tryton-managed depreciation) should be possible to "fix", perhaps as mentioned earlier by updating the first generated move with the date, value, depreciation, and accumulated depreciation where date is the end_date of the period prior to the first tryton managed one...(which may not be necessarily the first tryton fiscal account year). This would allow folks to migrate to tryton managed assets when it suits them. >>>> 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. > I believe to be generally acceptable, perhaps other data still needs to be taken into consideration.. For example, the degressive method coefficient (in France, at least) depends upon such things as the date of activation and the duration... and the coefficient magnitude has influence naturally upon when the linear optimisation kicks in. I still sort of favour, currently at least, special first 'line' entry (or entries) for 'in progress' depreciations. > >> 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. > Well, I'd like to get 'degressive' polished first, I think linear can be 'fixed' and both methods optimised in a future pass. Walk before run? Teething can be painful:-P Nicolas has a copy of the work in progress. Once I get the GUI part reacting better, to me at least, I'll prepare the issue for comments. cheers, -- 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/571A566A.601%40netbsd.org.
