openerp-expert-accounting team mailing list archive

[Goran Kliska <gkliska@xxxxxxxxx>]

Dear Joël,

My top 3 bad things in open source world:
 1. Posting videos, tutorials about modules you can't find on LP (and SA
not doing enough about it IMO)
 2. Duplicate effort - just learned today about "vat on payment"
 3. Being silent/ not contributing on expert forums
Now, I am guilty on all 3 points.
Sorry. It takes time and knowledge.

Code is still in very bad shape - early development/ POC
phase. Embarrassed.
It is not compatible with OpenERP stock philosophy, community addons,
looking more like a fork.
But it is impossible to make it right without radical changes.
You will see lot of ideas from your R&D work, some Vauxoo modules, and
others.
They should take credit and notion in module description.
At first I tried to be compatible with others work.

I was wrong saying:
  "I invested 2+ months developing "warehouse_base" module for 6.1 that
implements described functionality."
Much better version:
  "... that implements *parts* *of* described functionality *that my
customers needed most.*"
My intention was to answer Eric question, but got carried away about what
is wrong with stock accounting in OE.

I'am sending you code in next private mail as best I can do in a reasonable
time.
Please help with publishing and finishing.


About:

 Ideally costs should be calculated from account_move_line (like fixed
assets)
to avoid "stock accounting" and "real accounting" discrepancies. I am not
100% sure.

I'm sure Nhomar can testify how hard it is to get financial stock_card
right from current state.
I'am *strongly *against duplicate data,
    but there are exceptions like Joe Celco aux tables,
performance/compatibility reasons.
In any case there must be very,very strong reason for duplication of data
or business logic.
   (Having one less field (contact_id/partner_id) on forms not being a
reason at all.)

      Where I would prefer recording the cost price in every stock moves
and compute it from here.

Having cost *value *field displayed in every stock move is a must, but what
it is?
  - for IN(put) picking
      - it is almost right value that will be corrected by supplier/cost
invoice
      - in case of import and different currency there will be difference
      - some invoices for LC are month or 3 months late
      - we don't want to wait for invoice and block whole process so we
post best we know
      - it is not a job of warehouse employee to enter invoices
      - origin can be from PO, manually(must!), physical inventory, inter
wh. output
      - it would be wrong to change it later on stock move according to
late supplier invoice
      - real, correct value with history must end in accounting anyway on
warehouse value account
  - for OUT(put) picking
      - it can represent current cost value of the move
      - after processing preceding IN documents it will be wrong
      - again, true value in time can be extracted from accounting
         value in the moment of picking,

*Using account_move_line to calculate costs*
  PROS:
        - it is in one place => stock value == accounting value ==
happy accountant anytime
        - in line with how OE handles invoices, reconciliations, taxes,
assets ->I like that!
        - it is easy to extend logic
        - you can do whatever you want with additional modules (avanzosc
for example)
           without worrying about cost calculation
        - cost can be adjusted by manual account move (there are cases...)
        - account_move_line.id is a perfect sequence for FIFO
  CONS:
         - it is verbose.
           Picking with 100 move lines can be posted with 2
account_move_lines (without product_id, stock_move_line_id)
           but that is what we have now + hard time explaining to
accountants what account_move for each stock move really is?

In other words:
    If stock cost *value* is recorded *for *every stock_move in
account_move_line in the moment of confirmation of picking
    we can compute price, value, margin, historical margin or anything I
can think of in any legally allowed scenario.


Recording cost price and using it for calculation can be good fix for not
so radical

I would challenge anyone to prove me wrong, but can't promise timely
response - I am nowhere near rvalyi's eloquence :).

Best regards,

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

> Dear Goran,
>
>
> I'm really in favor of your approach, expect may be for that little part:
>
>  Ideally costs should be calculated from account_move_line (like fixed
> assets)
> to avoid "stock accounting" and "real accounting" discrepancies. I am not
> 100% sure.
>
>
> Where I would prefer recording the cost price in every stock moves and
> compute it from here.
>
> I really invite you to publish your work ASAP ine the communities branches
> so that others can contribute, the risk is otherwise that another option
> would be taken... I heard that FIFO is may be under devs... Don't know more
> about.
>
> In every case, I would be interested in having a look at your work !
>
> Regards,
>
>
> Joël
>
>
>
> Le 25 mars 2013 à 09:27, Goran Kliska <gkliska@xxxxxxxxx> a écrit :
>
> Hi Eric,
>
> Costing in OpenERP is oversimplified IMHO.
> It can be good enough for one Company with one Warehouse without Landed
> Costs scenario.
>
> For services property field could solve part of the multi-company problem.
>
> Cost price, stock valuation method, cost price calculation,
> accounts for posting, (in some cases Sale price also), Sequences for
> Picking (I found 7)
> are all related to a* Warehouse* NOT Product/Company.
> As Warehouses are defined for a specific Company, multi-company
> is automatically solved.
>
> More :
>  - Posting should be bound to a picking, not individual move - same as
> Invoice (1 Document== 1 account_move)
>  - Picking is a document (legal), not arbitrary collection of stock moves
> from somewhere to somewhere
>  - Whole Picking must be related to one warehouse. 2 new fields on
> Picking: warehouse_id, and contra_location_id.
>
> All Picking stock_moves must go from/to warehouse main location (or
> childs)  to/from "contra_location" (or child of contra_loc)
>  For posting one account is defined on warehose, other on contra location.
> I don't use Product stock_input... Doesn't make sense.
>
> - Between two warehouses there should be picking OUT from 1. Wh
> to inter-company virtual "transport" location, and strongly related picking
> IN 2. warehouse(with LC).
> - Technically we could support only one picking between 2 warehouses
> inside one company, but I found it too complicated to implement
>  - There is a need for a strong (many2...) link between stock_move(s) and
> invoice line(s)
>  - For each "In" picking company could have Landed Costs (planed,
> internal, awaiting supplier invoice for a months)
>
> - Production(virtual) -> Prod.Plant(internal in) add direct LC same way as
> In picking
> - Prod.Plant(internal) -> Finished Goods(internal) add Costs
>
>  - Supplier Invoices for goods and landed costs should create "corrective"
> additional posting
>    adjusting stock value for the goods still in warehouse, and COGS for
> sold goods
> - Program needs to track all that using FIFO method by warehouse even if
> costing method for a Warehouse is Average
> - Look at http://t.co/ghPmB2wHxn  where Fabien explains it.
>
> I think that FIFO with Landed Costs by warehouse should be done first.
> Then Average is trivial.
> I wouldn't  support LIFO, but there is Specific Identification method -
> can be based it on Lots,
> and Plan Costing - can be based on special Price lists
> (multi-company/currency)
>
> - Margin calculation is now based on current cost price from product :(
>  ouch
> - Physical Inventories should produce:
>
> - Inside picking for quantities diff inside one warehouse (without
> accounting posting)
> - Surplus picking (new price and comment)
> - Loss picking
> - Tax allowed Scrap
> - Scrap that is not Tax allowed
> - Internal Picking between warehouses in same company
>
> - There is a need for special documents for initial state and price
> nivelation
>  - In some(all?/most?) countries selling below cost price is tricky (VAT!)
> - Stock can be valued by cost, sale, retail price
> - In some countries "Storno" is mandatory (negative qty and posting)
> - COGS can be taken at Picking Out or Invoice
> - Ideally costs should be calculated from account_move_line (like fixed
> assets)
> to avoid "stock accounting" and "real accounting" discrepancies. I am not
> 100% sure.
>   Right now I am using:
>     create or replace view account_warehouse_product_sum as (
>                 SELECT  min(aml.id) as id  ,sw.id as warehouse_id,
> aml.product_id
>                         ...
>                        ,CASE WHEN abs(sum(aml.debit_qty - aml.credit_qty))
> > 0
>                              THEN sum(aml.debit - aml.credit) /
> sum(aml.debit_qty - aml.credit_qty)
>                              ELSE 0.000 END  as *avg_price*
>                         ...
>                   FROM account_move_line aml
>                   JOIN stock_warehouse sw  ON (sw.account_id =
> aml.account_id)
>                  WHERE am.state='posted'
>                  --AND sw.id = %s  AND aml.product_id = %s
>                  GROUP BY sw.id , aml.product_id
>
> I am from "storno accounting" country and there are more special issues
> about retail store accounting, returns,
> unnecessary margin and VAT posting ...
>
> All over Launchpad/Git you can find attempts to deal with parts of a
> Warehouse costing problem.
> Fabian diagnose is absolutely correct:
>  Some community members started basic implementations of FIFO/LIFO but, as
> they don't rely on strong costing foundations, this will not work in all
> situations (lots of side effects).
>
> How important is it?
>    https://twitter.com/davidecorio/status/314278440067031040
> How relevant is feedback.openerp.com<http://feedback.openerp.com/forums/87921-accounting/suggestions/1492529-landed-costs-purchase-price-freight-insurance-#comments>
> ?
> Top 3 idea:
>
> http://feedback.openerp.com/forums/77459-general-improvements/suggestions/1426907-fifo-and-lifo-costing
> Top accounting idea:
>
> http://feedback.openerp.com/forums/87921-accounting/suggestions/1492529-landed-costs-purchase-price-freight-insurance-#comments
>
> I invested 2+ months developing "warehouse_base" module for 6.1 that
> implements described functionality.
> Plan is to clean/refactor the code and break it to series of modules
> before publishing on LP.
>
> Is there anyone interested in "Costing by Warehouse" aproach?
>
> Goran Kliska
> *Slobodni programi d.o.o., Croatia*
>
>
>
> 2013/3/23 Nhomar Hernández <nhomar@xxxxxxxxx>
>
>> Look for this in launchpad.
>>
>> A lot of discusions about this.
>>
>> Reason? Leak of functionality thats all.
>>
>> Yo have in extra-addons product_multicompany
>>
>> Comment: all sql view will be broken if it use cost or price.
>>
>> Written from my android
>> On Mar 23, 2013 12:11 AM, "Eric Caudal" <eric.caudal@xxxxxxxxxxxxxx>
>> wrote:
>>
>>>  Hi,
>>> Currently in product form, Cost price, sales price, stock valuation
>>> method and cost price calculation method are not multi-company property
>>> fields when clearly they should be (at least as far as I understand
>>> multi-company).
>>>
>>> Is there any reason for that or anything that I am overlooking?
>>>
>>>
>>> --
>>>
>>> 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]
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> 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
>
>
>      --
>
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Joël Grand-Guillaume*
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> *
> *
> www.camptocamp.com
>
>
>
>
>