Re: [tryton-dev] New release on Monday

[Sergi Almacellas Abellana]

El 22/04/16 a les 20:20, 'Udo Spallek' via tryton-dev ha escrit:

Hi,

Fri, 22 Apr 2016 18:10:24 +0200
Cédric Krier:

>I'm sad to say that I will not make the release on Monday because we
>don't have the news written:
>https://codereview.tryton.org/24161003/

its a pity, but I understand your decision.


Same here.

Haven't recognized the codereview of the release message, but
to be true, the whole week I was wondering when a draft version would
come to review … next time I'll ask.

I reviewed the news and added several paragraphs.

I have also added several comments and paragraph to the reviews, so it 
will be great if all of us can try to write some small paragraphs until 
all is writen.



It would be cool if some others could jump in and help out!
On Monday I'll review another time.

Regards,

Udo



--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

--
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/571A815B.7080107%40koolpi.com.

Re: [tryton-dev] New release on Monday

['Udo Spallek' via tryton-dev]

Hi,

Fri, 22 Apr 2016 18:10:24 +0200
Cédric Krier :
>I'm sad to say that I will not make the release on Monday because we
>don't have the news written:
>https://codereview.tryton.org/24161003/

its a pity, but I understand your decision.

Haven't recognized the codereview of the release message, but
to be true, the whole week I was wondering when a draft version would
come to review … next time I'll ask.

I reviewed the news and added several paragraphs.

It would be cool if some others could jump in and help out!
On Monday I'll review another time.

Regards,

Udo
-- 
_
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

i...@virtual-things.biz
http://www.virtual-things.biz

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20160422202023.421f4ef9%40bender.dsl.


pgpo0KoPGm3s4.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton] asset amortisation and 'yearly' frequency

[Richard PALO]

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.

Re: [tryton-fr] Utilisation d'un Binary Field pour stocker un fichier

[Cédric Krier]

On 2016-04-21 02:33, Maxime Richez wrote:
> Bonjour,
> 
> En considérant que je ne souhaite pas utiliser les attachements dans Tryton 
> et pouvoir ajouter un fichier dans un formulaire... 
> J'ai d'abord déclaré dans mon modèle un "field.Binary" et déclaré ce même 
> champ dans ma vue xml, mais pas moyen de charger mon fichier car cela est 
> grisé dans le client Tryton.
> Je suis allé voir le code de ir/attachment.py et la déclaration du champ 
> pour stocker le fichier est la suivante
> 
> data = fields.Function(fields.Binary('Data', filename='name', states={
> 'invisible': Eval('type') != 'data',
> }, depends=['type']), 'get_data', setter='set_data')
> 
> Dois je absolument utiliser un champ Function sur un champ Binary pour 
> pouvoir charger un fichier dans la DB ?

Non. Si le champs est grisé, c'est qu'il est "readonly" soit via un
"states" ou droit d'accès.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse 
https://groups.google.com/d/msgid/tryton-fr/20160422162545.GS3191%40tetsuo.

Re: [tryton-fr] Rapport invoice : full_address.split('-') ne fonctionne pas

[Cédric Krier]

On 2016-04-20 01:05, JMarc Legrand wrote:
> Avez-vous quelque suggestion ?


La seul solution est de surcharger get_full_address pour produire le
format désiré.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse 
https://groups.google.com/d/msgid/tryton-fr/20160422161911.GQ3191%40tetsuo.

[tryton-dev] New release on Monday

[Cédric Krier]

Hi,

I'm sad to say that I will not make the release on Monday because we
don't have the news written:
https://codereview.tryton.org/24161003/
And I will not spend my week-end to write it, I'm tired to do things
like that.

I'm also sad that I have to complaint over and over to get things
critical like this be done. Usually, I'm not this kind of guys. I don't
complain, I act instead. But it lasted 8 years, I have been doing that
without see any changes. So now I just let it go.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20160422161024.GO3191%40tetsuo.

Re: [tryton] asset amortisation and 'yearly' frequency

[Cédric Krier]

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: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: