openerp-expert-accounting team mailing list archive

[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?
> 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 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
> 
> 
> 
> _______________________________________________
> 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