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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 > [email protected] > http://www.elico-corp.com > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > 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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
