← Back to team overview

openerp-expert-accounting team mailing list archive

Re: Cost and sales price fields in multi-company

 

IMHO Lots should be used for Lot traceability. Maybe as a workaround in
some implementations.
Not suitable for or FIFO or serial numbers mgmt.
For "Specific identification" costing method I only have experience
with Car dealership scenario where cost for a new/used car is calculated
for specific chassis no. - more serial no. than lot no..
I wouldn't use "stock" modules for car sale, don't know about other
Specific identification costing scenarios.


 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/4 Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>

>  Absolutely in favor. We had to implement a average cost calculation on
> MO (simple calculation of the cost of Raw material actually used in an MO)
> and without this feature we can only half implement it.
> Besides, if we have proper cost at stock move level, we could batch
> process a lot of calculations.
> What about having the cost at production lot level? Isnot it necessary if
> we want to achieve some FIFO/LIFO cost management?
>
>
>  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/04/2013 07:59 AM, Goran Kliska wrote:
>
> 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
>>
>>
>>
>>
>
>

JPEG image


References