openerp-community team mailing list archive

[Goran Kliska <gkliska@xxxxxxxxx>]

    def _check_contra_minus(self, cr, uid, ids, context=None):
        """ This is to restore credit_debit2 check functionality, for
contra journals
        """
        for l in self.browse(cr, uid, ids, context=context):
            if l.journal_id.posting_policy == 'contra':
                if not (l.debit + l.credit) >= 0.0:
                    return False
        return True


 lp
Goran Kliska
*Slobodni programi d.o.o.*
*Gorjanska 23, Zagreb*
*tel. +385 (1) 3095 113*
*fax. +385 (1) 3095 148 *
*mob. +385 91 2722 676*


2013/4/8 Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>

>  Storno setup should be at company and journal level. Regarding SQL
> constraint removal, I am not sure about the impact but they will need to be
> replaced in the code since storno and non-storno companies could be
> coexisting in the same database.
>
>
>  Eric Caudal*CEO*
> --*Elico Corporation, Shanghai branchOpenERP Premium Certified Training Partner *
> Cell: + 86 186 2136 1670
> Office: + 86 21 6211 8017/27/37
> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>
> [image: Elico Corp]
> On 04/08/2013 07:58 PM, Goran Kliska wrote:
>
> Hello,
>
>  This is mostly about "peaceful co-existence" of localizations:
>   - common ancestor(s) for localizations in "storno accounting" part of
> the world
>   - ability to have one company "storno", another "contra" in same database
>
>  I am willing to invest my time maintaining a branch, best I can.
>
>  History of account_storno module:
>   - patching account module -> having private fork, worst possible idea
>   - l10n_hr_account_storno -> ok for local installations, but it
> will collide with other localizations
>   - account_storno -> common ancestor for l10n_hr..., l10n_ro..., don't
> know for others,
>      but I am sure that is needed in current form for Bosnia, Serbia,
> Montenegro, Macedonia.
>
>  @Nhomar
>  Some years ago I learned about "contra accounting" and I
> was surprised just as you are now with "storno".
> It is in every accounting book, high school class, law in this region.
> Recent example is "Fiscal Invoice Law"(SOAP) where we MUST have negative
> amounts.
> Contra accounting is forbidden by law in some countries, in some is
> optional, in some storno is forbidden.
>
>  "I am totally disagree about this approach."
>   Every accountant in the region totally disagree with contra approach.
>   Implementing ERP without accountant blessing == mission impossible
>
>  Let's say my example is from analytic accounting.
>  What is the meaning of sum(debit) & sum(credit) for A)Contra?
>  Just being curious and NOT pushing this analytic idea as community one -
> I'll do it in some other branch.
>
>  "I dont know how we can be affected with Storno"
> It is like account_anglo_saxon. Don't install if you don't need it.
>  For mixed installations
>    - replacement of SQL constraint is provided
>    - storno/contra is selectable on the Journal level
>
>  I don't' know about origin, is not that important.
> Maybe it is from Soviet USSR, maybe from Benedikt Kotruljević
> (Dubrovnik,Croatia) regarded as inventor of double-entry accounting
> and his work *Libro de l'Arte de la Mercatura* (*Book on the Art of Trade*)
> from 1458
>
>
>  BRGDS
> Goran Kliska
> *Slobodni programi d.o.o.*
>  *Gorjanska 23, Zagreb, Croatia*
>
>   2013/4/8 Nhomar Hernández <nhomar@xxxxxxxxx>
>
>> Hello/
>>
>>  From my point of view, the global approach must be cosidered, but i
>> have one strong point in your example, comment in lines.
>>
>>
>>   2013/4/8 Goran Kliska <gkliska@xxxxxxxxx>
>>
>>>  Please support the idea.
>>>
>>>  We can't ignore Russia, China and whole East Europe and claim we have
>>> global ERP.
>>> Storno and red-storno are mandatory by the low in some countries.
>>> Imagine multi-company/multi-country implementation.
>>> As Croatia is entering EU we are getting more&more leads requiring
>>> multi-country.
>>> It is implemented in all ERPs pretending to be global or multi-country.
>>>
>>>  Another goal is to raise awareness in developer community because
>>> we are suffering when in the middle of a 200 lines method we have to
>>> deal with contra accounting assumption.
>>>
>>>  As Eric said, it really is in a category of anglo-saxon accounting.
>>> Let's start with community effort and hope it will lend in official
>>> addons some day.
>>>
>>>  There are some advantages in storno principle.
>>> One example (it could be for analytic accounting):
>>> 1. Cost 100€ Debit
>>> 2. Cost   50€ Debit
>>>  3. Cost  -50€ A) (+)Credit or B) (-)Debit  (late correction)
>>> 4. Revenue 200€ Credit
>>>
>>>  Balance is the same 100€, but
>>> A) with Contra approach  sum(Debit) = 150€ , sum(Credit) = 250€
>>>      - useless
>>> B) with Storno approach
>>>        sum(Debit) = 100€ = Total Costs
>>>        sum(Credit)= 200€ = Total Revenues
>>>
>>>  For Contra only one field is enough to express Debit&Credit with
>>> (+)&(-) sign.
>>> IMHO much better approach is to always have debit and credit fields that
>>> can be negative.
>>>
>>
>>   I am totally disagree about this approach.
>>
>>  We use in Vauxoo as reference this book:
>>
>>  www.principlesof*accounting*.com/
>>
>>  It is REALLY good, our utopic dream is that OpenERP support 100% over
>> it.
>>
>>  Do you have some text book where the storno approach is documented and
>> where they say explicitly that you can have (-) Negative values in your
>> Journal Entries.
>>
>>  For me is difficult to believe, in my opinion, It is more a thing
>> regarding the old system are done in times where validate this were so
>> difficult .... Now with actual technilogies, i can not see reason to brake
>> intentionally _basic_ accounting principles.
>>
>>  A LOT of thing are more easy in accounting because we have very weel
>> controlled this issue, brake it can represent A LOT of more problem (we
>> solved them in V5.0 when this feature was allowed, and it represent to us
>> fix 1 year of accounting information) this is the reason because i need
>> introduce this comment here.
>>
>>  I dont know how we can be affected with Storno, but the First Step is
>> at least introduce where is the origin of the concept, it must be our
>> starting point.
>>
>>
>>
>>>  Let's just start with legal requirements that in some countries
>>> refunds must be done
>>> with NEGATIVE quantities and amount.
>>>
>>>  http://forum.openerp.com/forum/topic27740.html
>>> https://answers.launchpad.net/openobject-addons/+question/123322
>>>
>>>
>>>
>>  Best regards.
>>
>>>   lp
>>> Goran Kliska
>>> *Slobodni programi d.o.o.*
>>>  *Gorjanska 23, Zagreb*
>>> *tel. +385 (1) 3095 113*
>>> *fax. +385 (1) 3095 148 *
>>> *mob. +385 91 2722 676*
>>>
>>>
>>> 2013/4/8 Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>
>>>
>>>>  China is using Storno accounting so we are interested in
>>>> participating.
>>>> This is a localization but so widely used that I would rather be in
>>>> favor of general feature (to be activated in the setting/accounting menu
>>>> like anglo-saxon accounting)
>>>>
>>>>  Eric Caudal*CEO*
>>>> --*Elico Corporation, Shanghai branchOpenERP Premium Certified Training Partner *
>>>> Cell: + 86 186 2136 1670
>>>> Office: + 86 21 6211 8017/27/37
>>>> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>>>>
>>>> [image: Elico Corp]
>>>>  On 04/08/2013 03:22 PM, Joël Grand-Guillaume wrote:
>>>>
>>>>  Dear Community,
>>>>
>>>>
>>>>  Goran suggested to me that we should add a new project for "Storno"
>>>> accounting under the community reviewer responsibility. It seems to be
>>>> "best practice" accounting mostly used on eastern european country.
>>>>
>>>>  The branch of his work is currently here:
>>>>
>>>>  http://bazaar.launchpad.net/~gkliska/addons-
>>>> sp/slobodni_addons_61/files/head:/account_storno/
>>>>
>>>>  It seems more related to a localization problematic from my point of
>>>> view. Since now, we mainly try to avoid that in our community branch,
>>>> focusing more on "general" feature. Localization are more handled by each
>>>> of us in our respective country. However, this seems to be used by quite
>>>> lots of country and may justify to land in our community branch...
>>>>
>>>>  What is your opinion ? Who is in favor of including this as a new
>>>> project of the team "Account Core Editors" in the community branches ?
>>>>
>>>>  Thanks for your feed-back,
>>>>
>>>>
>>>>  Joël
>>>>
>>>>
>>>>
>>>> Début du message réexpédié :
>>>>
>>>>  *De : *Goran Kliska <gkliska@xxxxxxxxx>
>>>>  *Objet : **Storno accounting branch*
>>>>  *Date : *5 avril 2013 03:14:36 UTC+02:00
>>>>  *À : *Joël Grand-Guillaume @ camptocamp <
>>>> joel.grandguillaume@xxxxxxxxxxxxxx>
>>>>  *Répondre à : *Goran Kliska <gkliska@xxxxxxxxx>
>>>>
>>>> Dear Account Core Editors team admins,
>>>>
>>>> Please consider creating a new branch for storno accounting modules.
>>>>
>>>> Storno Accounting is  a business practice commonly used in Eastern
>>>> European countries.
>>>> Countries where Storno accounting is mandatory or considered as best
>>>> practice:
>>>>     Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine,
>>>> Croatia, Bosnia and Herzegovina, Serbia, Romania, ...
>>>>
>>>> Latest 6.1 version is here:
>>>> http://bazaar.launchpad.net/~gkliska/addons-
>>>> sp/slobodni_addons_61/files/head:/account_storno/
>>>>
>>>> Best regards,
>>>> Goran Kliska
>>>> Slobodni programi d.o.o.
>>>> --
>>>> This message was sent from Launchpad by
>>>> Goran Kliska (https://launchpad.net/~gkliska)
>>>> using the "Contact this team's admins" link on the Account Core Editors
>>>> team
>>>> page (https://launchpad.net/~account-core-editors).
>>>> For more information see
>>>> https://help.launchpad.net/YourAccount/ContactingPeople
>>>>
>>>>
>>>>       --
>>>>
>>>>
>>>>   *camptocamp*
>>>> INNOVATIVE SOLUTIONS
>>>> BY OPEN SOURCE EXPERTS
>>>>
>>>>  *Joël Grand-Guillaume*
>>>> Division Manager
>>>> Business Solutions
>>>>
>>>>  +41 21 619 10 28
>>>> *
>>>> *
>>>> www.camptocamp.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> Mailing list: https://launchpad.net/~openerp-community
>>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openerp-community
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openerp-community
>>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openerp-community
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-community
>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-community
>>> 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://vauxoo.com
>> Linux-Counter: 467724
>> Correos:
>> nhomar@xxxxxxxxxxxxxx
>> nhomar@xxxxxxxxxx
>> twitter @nhomar
>>
>
>
>