← Back to team overview

openerp-expert-accounting team mailing list archive

Re: Secondary Currency for Liquidity Journals

 

Hello Frédéric

in a liquidity journal associated with a currency it is mandatory that you can only write accounting entries with the same currency as the one associated with the journal it sems to me that this check is now made using an account with a secondary currency and not by just checking the currency attached to the journal which is a more open solution in my mind The NEW behaviour also implies that you must create an account for each currency while several of our big customers using multi currency transactions just want one account for each journal type.

By the way this NEW behaviour will prevent any "automatic" update, since you will have to create accounts for each currency and each type of liquidity journal, which is not a very good news for us and for automatic scriptable updates from OpenERP S.A.

Regards

Maurice MORETTI
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



  <mailto:frederic.clementi@xxxxxxxxxxxxxx>



2012/2/10 TeMPO Consulting <info@xxxxxxxxxxxxxxxxxxx <mailto: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
    <mailto: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 <mailto:mm@xxxxxxxxxxxxxxxxxxx>

        Tel      : 33 (0)3 88 56 82 <tel:33%20%280%293%2088%2056%2082> 10
        Fax      : 33 (0)3 88 56 46
        <tel:33%20%280%293%2088%2056%2046> 64
        Mobile   : 33 (0)6 08 61 85 <tel:33%20%280%296%2008%2061%2085> 02




        _______________________________________________
        Mailing list:
        https://launchpad.net/~openerp-expert-accounting
        <https://launchpad.net/%7Eopenerp-expert-accounting>
        Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
        <mailto:openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx>
        Unsubscribe :
        https://launchpad.net/~openerp-expert-accounting
        <https://launchpad.net/%7Eopenerp-expert-accounting>
        More help   : https://help.launchpad.net/ListHelp




-- --------------------
    Saludos Cordiales

    Nhomar G. Hernandez M.
    +58-414-4110269 <tel:%2B58-414-4110269>
    Skype: nhomar00
    Web-Blog: http://geronimo.com.ve
    Servicios IT: http://openerp.com.ve
    Linux-Counter: 467724
    Correos:
    nhomar@xxxxxxxxxxxxxx <mailto:nhomar@xxxxxxxxxxxxxx>
    nhomar@xxxxxxxxxxxxxxx <mailto: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  <mailto:mm@xxxxxxxxxxxxxxxxxxx>	
    			
    Tel      :33 (0)3 88 56 82  <tel:33%20%280%293%2088%2056%2082>  10
    Fax      :33 (0)3 88 56 46  <tel:33%20%280%293%2088%2056%2046>  64				
    Mobile   :33 (0)6 08 61 85  <tel:33%20%280%296%2008%2061%2085>  02
    			



    _______________________________________________
    Mailing list: https://launchpad.net/~openerp-expert-accounting
    <https://launchpad.net/%7Eopenerp-expert-accounting>
    Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
    <mailto:openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~openerp-expert-accounting
    <https://launchpad.net/%7Eopenerp-expert-accounting>
    More help   : https://help.launchpad.net/ListHelp



_______________________________________________
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


--
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
			



References