openerp-expert-accounting team mailing list archive

[Frédéric Clementi <frederic.clementi@xxxxxxxxxxxxxx>]

Hi,

On our side we are very happy that now account secondary currency must
match the journal secondary currency and I would be curious to know the
scenarii where you could have to have this mismatch.
Please keep also in mind that this set up is mandatory for account_voucher
(the multicurrency version in 6.1)

Regarding revaluation module, we have recently developped a module for a
international company :
account_unrealized_currency_gain_loss<http://bazaar.launchpad.net/%7Ec2c/c2c-financial-addons/6.1/files/head:/account_unrealized_currency_gain_loss/>in
~c2c/c2c-financial-addons/6..<https://code.launchpad.net/%7Ec2c/c2c-financial-addons/6.1>

It can generate different kind of reevaluation journal entries (which can
be different in UK, FR or CH for example...so you can choose), at account /
currency/ partner level. these entries can be reversed easily with
account_reversal (dependancy). Of course this works on any account (see
check box 'allow revaluation' in account form...still to be as generic as
possible) with or without secondary currency.

We will maybe improve this module soon with a webkit report for audit
purpose.

Any contributions are welcome.

Regards

Frederic




Frédéric CLEMENTI
Business Solutions
Camptocamp SA
Tel : + 41 (0)21 619 1041
http://www.camptocamp.com

 <frederic.clementi@xxxxxxxxxxxxxx>




2012/2/10 TeMPO Consulting <info@xxxxxxxxxxxxxxxxxxx>

> **
> Dear Vadim and Claude
>
> I don't know what you mean exactly by revaluations (fx rate changes ?) but
> I still dont' see why this is related to the account
> Since everything is stored in the account item entry (booking amounts both
> in booking currency and functional currency) you can
> revaluate what you want.
> We are actually developing a project where we make huge use of foreign
> currencies and handle perfectly the revaluation without
> the need to have a dedicated account for each currency.
>
> To be clear, it is not that I don't want it to be configured the way you
> guys think it should do, I just want to avoid that this is the ONLY way
> The way it was in 6.0 leave the configuration open and both methods (yours
> and mine work)
>
> Then I agree with Nhomar about portablility and that is my biggest
> concern;
> 6.1 is changing the behaviour of the software and this is simply not
> suitable for an industrial product (no matter what the product is)
>
> Lastly, if this should be the designed behaviour then I don't understand
> why the user have to configure two times the same currency
> (in the journal and in the associated account)
>
> Regards
>
> Maurice
>
> Tempo.
>
> Im totally agreed with you.
>
> We have several accounting case where you need to have a journal with
> different currency on account.
>
> BTW.
>
> This new feature WILL generate a lot of backward incompatibility, and
> mathematically is probable a lot of mistakes, because even you can change
> from time to time currency on journal and or account and the calculation is
> doing a lazzy sum for ammount_currency.
>
> We right now are working an a patch for improve __compute method, but we
> think this behaviour will bring A LOT of inconsistencies.
>
> IMHO.
>
> Currency in journal, needs to be done for one thing and on account for
> other ne, if we mix both fields this will try a lot of problem in
> configuration and migrations.
>
> @odony or qdp what do you think?
>
>
> 2012/2/9 TeMPO Consulting <info@xxxxxxxxxxxxxxxxxxx>
>
>> Dear all
>>
>> it seems that in 6.1 a change has been introduced in the way the
>> liquidity journals are handled
>> When you setup such a journal the system is requesting to enter the same
>> currency both in the journal
>> and in the secondary currency field of the associated accounts
>>
>> As a side effect you must have as many accounts as currencies used
>>
>> In 6.0 this behaviour was optional and fine to me
>> I don't understand nor agree to that change
>>
>> Your inputs are welcome
>>
>> --
>> Très cordialement
>>
>> Maurice MORETTI
>>
>> _________________________________________________________________________
>> TeMPO CONSULTING Valparc 9, rue du Parc  67205 Oberhausbergen FRANCE
>>
>> Web   : http://www.tempo-consulting.fr
>> email : mm@xxxxxxxxxxxxxxxxxxx
>>
>> Tel      : 33 (0)3 88 56 82 10
>> Fax      : 33 (0)3 88 56 46 64
>> Mobile   : 33 (0)6 08 61 85 02
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-accounting
>> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> --------------------
> Saludos Cordiales
>
> Nhomar G. Hernandez M.
> +58-414-4110269
> Skype: nhomar00
> Web-Blog: http://geronimo.com.ve
> Servicios IT: http://openerp.com.ve
> Linux-Counter: 467724
> Correos:
> nhomar@xxxxxxxxxxxxxx
> nhomar@xxxxxxxxxxxxxxx
> twitter @nhomar
>
>
>
> --
> Très cordialement
>
> Maurice MORETTI
>
> _________________________________________________________________________
> TeMPO CONSULTING Valparc 9, rue du Parc  67205 Oberhausbergen FRANCE
> 			
> Web   : http://www.tempo-consulting.fr
> email : mm@xxxxxxxxxxxxxxxxxxx	
> 			
> Tel      : 33 (0)3 88 56 82 10
> Fax      : 33 (0)3 88 56 46 64				
> Mobile   : 33 (0)6 08 61 85 02
> 			
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>
>