openerp-community team mailing list archive

[Goran Kliska <gkliska@xxxxxxxxx>]

Dear all,

Accounting approach on company basis is really needed.
Something like 5 - 6 options, some can be on the country level.
We are using company wide defaults and the posting_policy on the journal
level,
so account_storno can be installed and if all your journals are 'contra'
policy it will work as contra only.
account_anglo_saxon needs something like that too.

@Huberto
Thanks for wonderful explanation about Multi-Country/Company problem.
IMO price_cost or any price field in Product relation is sign of "far from
optimal" design even for one company/multi-wh level.
Showing something like last_xy_price with function field is OK for
usability. OT and long story.

@Joel
 First, I must say, "..that we tend to avoid." is the most polite critique
I ever saw. Have to work on my posts/english.
 In pre OpenERP era i wrote hundreds of triggers. Each beeing fix for bad
design decisions, legacy or proprietary code.
 Triggers are BAD practice and there is no need for them in open source
software.
 It is much better to improve design/model/code.
 I removed comment with trigger def. (Paranoia after 2 day of fixing my
first OE live db.)
  Did MP best I can. Hope it will not take much of Account Core Editors
precious time.

@Fabrice
    huge framework change/challenge
    is not necessarily needed, or at least it is not stopping us to write
better code towards multi-country.
    Just follow usual rants from community (Raphael mostly)
    1.Framework improvements:
      - on_change()
      - control visible/readonly/mandatory/selection_choices from related
entities on forms
      ...
    2. Refactoring  - long methods doing more than 1-2 tasks
    3. Refactoring  - fields.selection(_get_fieldname,) function as a rule/
best practice
    4. Refactoring  - naming conventions, (_get_fieldname or
_fieldname_get, ids or lines...)
    5. Refactoring  - create() method for multiple ids, optionally get Ids
in advance from pg sequence
    6. ...uffff
    7. Public roadmaps so we can spot problems early
   Long list, but after great web client and other improvements in 7.0 we
should focus on maturity and community involvement IMO.


 PS.
   Leading Slovenian OpenERP partner called me saying they prefer storno
for sum(debit), sum(credit) reason.
   I added Slovenia in a list of countries.


 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/10 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>

> Dear all,
>
>
> I created the project here :
>
> https://launchpad.net/storno-accounting
>
> It belong to account-core-editor team and his purpose is to provide a base
> module that support the STORNO accounting in OpenERP. It should serve as a
> base module for all localization of country that need this behavior in
> accounting.
>
> I pushed an empty branch for series 6.1 (ask if you want to starts with
> 7.0), I now let the involved people push their own and request a merge on
> Launchpad. Remember that to be able to do that, you'll need to branch this
> empty branch first and start from here (otherwise, Bazaar will tell you
> there is no common ancestor).
>
> @Goran, I think you're the most advanced here, you should probably take
> that part
>
> Now, it's clear that an OpenERP instance with that module installed will
> have to deal with it in every company he owned.. But as Humberto and
> Fabrice said, currently there is no way to change that now. It's the same
> for Anglo-Saxon accounting...
>
> Keep contributing,
>
> Regards,
>
>
> Joël
>
>
>
> Le 10 avr. 2013 à 06:31, Humberto Arocha <humbertoarocha@xxxxxxxxx> a
> écrit :
>
> And that is something that should be addressed if we want to keep Openerp
> claiming on Multicompany complaince,
>
> Just like price_cost as a property_field, and not as a plain float field,
>
> Trying to not admit that we are wrong just because we want to be known
> as the best and  being arrogant at it will not avoid that awful things
> smash
> at our faces,
>
> I just want this issues to be acknowledge and that there is an clear
> agenda to
> address it, be it for 8.x o 9.x, but there should be an agenda for that
> framework
> you just has propose Fabrice, It is really great.
>
> I just don't want Apple Maps.
>
> I love Openerp as a Framework, I love Openerp as Business Suite but it
> wont avoid from keeping me to tell what I just see as wrong. And something
> is wrong.
>
> Regards.
>
> Hbto [Vauxoo]
> El 09/04/2013 23:47, "Fabrice Henrion" <fhe@xxxxxxxxxxx> escribió:
>
>> Hello,****
>>
>> Same for mrp_jit, sale_crm...****
>>
>> If you want to have the capability to install a module and apply it only
>> to certain companies, it would be really cool but it sounds like a huge
>> framework change/challenge.****
>>
>> __
>> Fabrice Henrion****
>>
>> ** **
>>
>> *From:* openerp-community-bounces+fhe=openerp.com@xxxxxxxxxxxxxxxxxxx[mailto:
>> openerp-community-bounces+fhe=openerp.com@xxxxxxxxxxxxxxxxxxx] *On
>> Behalf Of *Humberto Arocha
>> *Sent:* Tuesday, April 09, 2013 4:40 PM
>> *To:* Joël Grand-Guillaume
>> *Cc:* openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx; OpenERP Community
>> *Subject:* Re: [Openerp-community] Storno accounting branch****
>>
>> ** **
>>
>> Hello, community people,****
>>
>> ** **
>>
>> Wonderful that community is aware of this accounting approach,****
>>
>> ** **
>>
>> everybody seems to solve the problem about accounting approach, as a
>> matter of localization,****
>>
>> And I think it is not just like that, Lets just point out this, ****
>>
>> ** **
>>
>> Let us think there is a multinational company across all continents, ****
>>
>> and that multinational company decides to use OpenERP as a first class ERP
>> ****
>>
>> Solution for there Enterprises operations.****
>>
>> ** **
>>
>> Their accounting people has come to realize that there are at three
>> different ****
>>
>> accounting approaches, that are mandatory for them to use on each country
>> ****
>>
>> where they have operations. ****
>>
>> ** **
>>
>> Each national company decides to create a new company for each country,**
>> **
>>
>> ** **
>>
>> In Febrary Openerp Technical deploys Openerp, in France, French National
>> Company,****
>>
>> they were all happy, first company deploying Openerp and everything works
>> great,****
>>
>> ** **
>>
>> In March 1st, GoLive, in Venezuela, Venezuelan National Company,****
>>
>> They are all happy, second company using Openerp in a Multicompany
>> environment,****
>>
>> ** **
>>
>> French guys begins to rise their eyebrows somethings is going wrong,****
>>
>> accounting is begining to release mismatching numbers.****
>>
>> ** **
>>
>> Long story short.****
>>
>> ** **
>>
>> French guys are using, native accounting in openerp, Continental, Rhine,
>> Normand Accounting.****
>>
>> Venezuelan guys are using, anglo-saxon-accounting and that approach is
>> colliding with****
>>
>> the French Accounting approach,****
>>
>> ** **
>>
>> What I want to point out, and please, make corrections to my words, ****
>>
>> nobody has the intelligence monopoly, is that openerp is __not__ aware***
>> *
>>
>> of the accounting approach on company basis, just on module installed
>> basis.****
>>
>> ** **
>>
>> And that one is to my believes the biggest bug on Openerp Accounting
>> Approach****
>>
>> ** **
>>
>> So if we are going to support a new accounting approach And OpenERP is **
>> **
>>
>> going to keep claiming on the multicompany Compliance. ****
>>
>> ** **
>>
>> This will end in just a big accounting mess!!!****
>>
>> ** **
>>
>> Thanks in advance****
>>
>> ** **
>>
>> 2013/4/8 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>****
>>
>> Hi,****
>>
>> ** **
>>
>> After reading you guys, I suggest to create a project called:****
>>
>> ** **
>>
>> storno-accounting****
>>
>> ** **
>>
>> That belong to the Account Core Editors team as suggested by Goran. This
>> project under the community responsibility will be in charge of
>> implementing this accounting concept in OpenERP in a common way for all
>> concerned localization.****
>>
>> ** **
>>
>> As all other projects, code will have to be review before landing there
>> for the good of all.****
>>
>> ** **
>>
>> Anybody is against that ?****
>>
>> ** **
>>
>> ** **
>>
>> Regards,****
>>
>> ** **
>>
>> ** **
>>
>> Joël****
>>
>> ** **
>>
>> ** **
>>
>> @Nhomar : I agree with you on the basis, but like anglo-saxon accounting,
>> those principles are specific to certain law/country.. Even if not approved
>> here, OpenERP should provide a good support of those principles IMO. As
>> various country are concerned, making a community project for them seems a
>> good idea.****
>>
>> ** **
>>
>> @Goran : After looking at your code, the only main blocker I saw is the
>> postgres trigger that we tend to avoid in the OpenERP's module. Other stuff
>> are details and in any case, it'll be reviewed by the community reviewer.
>> Moreover, making it at company level is a good idea as several company may
>> belong to several country.****
>>
>> ** **
>>
>> ** **
>>
>> Le 8 avr. 2013 à 15:10, Goran Kliska <gkliska@xxxxxxxxx> a écrit :****
>>
>>
>>
>> ****
>>
>> Storno setup at company level is good idea. ****
>>
>> That can control default setup/visibility at journal level.****
>>
>> Thanks Eric.****
>>
>>
>> ****
>>
>>  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 branch*
>>
>> *OpenERP Premium Certified Training Partner** *****
>>
>> Cell: + 86 186 2136 1670****
>>
>> Office: + 86 21 6211 8017/27/37****
>>
>> Skype: elico.corp****
>>
>> eric.caudal@xxxxxxxxxxxxxx****
>>
>> http://www.elico-corp.com****
>>
>> ** **
>>
>> <elico_signature.jpg> ****
>>
>> 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 branch*
>>
>> *OpenERP Premium Certified Training Partner** *****
>>
>> Cell: + 86 186 2136 1670****
>>
>> Office: + 86 21 6211 8017/27/37****
>>
>> Skype: elico.corp****
>>
>> eric.caudal@xxxxxxxxxxxxxx****
>>
>> http://www.elico-corp.com****
>>
>> ** **
>>
>> ****
>>
>> 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****
>>
>> ** **
>>
>> -- ****
>>
>> ** **
>>
>> *camp**to**camp*****
>>
>> 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 ****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> _______________________________________________
>> 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****
>>
>> ** **
>>
>> --****
>>
>> ** **
>>
>> Camptocamp****
>>
>> Innovative Solutions by Open Source Experts****
>>
>> ** **
>>
>> Joël Grand-Guillaume****
>>
>> Division Manager - Business Solutions****
>>
>> ** **
>>
>> 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****
>>
>> ** **
>>
>
>      --
>
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Joël Grand-Guillaume*
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> *
> *
> www.camptocamp.com
>
>
>
>
>