help text for income and expense accounts

trunk
experts please review
IMHO at product level only Income (value of product sold) and Expense (value of product purchased) account can be defined -
for stock locations we need for incoming goods (value of product purchased/produced) and for outgoing products cost of goods sold
for this we will have move_value_cost (for valuating the stock) and move_value_sale (for invoices) in stock_move

I don't agree with the proposed patch, as outgoing and incoming stock are NOT ONLY related to invoices.
Incoming and outgoing stock is also used when moving stock between locations (internal and external), thus also in production and in this case not related to any invoice.

Side note;
Also in case of mentioned invoices (invoices itself do not create a stock move!! At least an order or picking should be made to create that invoice!!!) the stock is moved between locations e.g. from supplier to internal location or in case of purchase from internal to customer location.

Knowing this OpenERP stock moving principle the current helptext is correct for me.

@Jan - this is an issue for the upcoming trunk
I had massive troubles to get the correct account moves in 5.0 IMHO because of this confusing issue

Prodcut accounts must be configured to be usable for physical prodcucs and services (which have not stock input/output but only Expense and Sales accounts)

OK Invoices do not /and should create stock_move but
Invoice lines - these must have the same value as stock moves
* Supplier invoices
** move_value_cost == subtotal of invoice line
* Customer invoices
** move_value_sale == subtotal of invoice line
** move_value_cost == avg price at the time of sale

For evaluating the stock moves these accounts should be used
definend in stock/product.py

class product_category(osv.osv):
    _inherit = 'product.category'
    _columns = {
        'property_stock_journal': fields.property('account.journal',
            relation='account.journal', type='many2one',
            string='Stock journal', method=True, view_load=True,
            help="This journal will be used for the accounting move generated by stock move"),
        'property_stock_account_input_categ': fields.property('account.account',
            type='many2one', relation='account.account',
            string='Stock Input Account', method=True, view_load=True,
            help='This account will be used to value the input stock'),
        'property_stock_account_output_categ': fields.property('account.account',
            type='many2one', relation='account.account',
            string='Stock Output Account', method=True, view_load=True,
            help='This account will be used to value the output stock'),
    }

product_category()

BTW if only modul account is installed - a help text referring to "value incoming/outgoing stock" makes no sense

(or my English is not good ...)

just want to inform you that I have a correctly working setup of all accounts and account_move_line creation in the chricar_price_unit branch which is about to be merged into trunk.

I agree with help texts changing.

But I don't agree to remove stock account settings.

In PL we use the same account in Stock Income Account field and in Expense Account field for proper account moves so for this case stock account could be removed.
BUT
we use different accounts for Stock Output Account and Sales Account.
I see in docs that it is an option to use the same account but practically all account guides indicate using different accounts. So maybe for various national purposes it is better to leave these fields.

Will you add (in your improvement) Price Difference Account as in account_anglo_saxon module? In Poland we need this settings but we don't need other anglo_saxon functionality.

Hi,

Well I agree with Jan Verlaan (Veritos) #2. And I totally desagree with Ferdinand @ ChriCar #3 when he write "OK Invoices do not /and should create stock_move but Invoice lines - these must have the same value as stock moves" ! From my point of view, it's false because the invoice will post the sale value & the stock movement will post the stock value change.

It should be normal that you stock value price (Moving average value defined on purchase value) is lower than you sales price. So the values of the 2 accounting movements are logically different and must clearly be posted separetly.

To complete the idea of Grzegorz Grzelak (Cirrus.pl) #6

We need a module to complete the current solution. When we produce, the best way is to valuate the stock at a planned standard price (calculated on bom & routing), but when you do the real production, you often have price variance with the standard price. So it's should be very useful & powerfull if OpenERP was able to post the different variance on different accounts. I identy the following possibilities : price variance (of the components or labor), currency variances, loss/win on the final product, loss/win on raw material consumption, lot size variation (if you have setup or cleaning time of the production chain before to be able to produce, and that you produce a different lot size, it will of course impact you production price), production maintenance cost variation, indirect cost reposting variances, ... And I'm far sure it's not complete !

Second problem, in some countries (France for example) it's not allowed to valuate stock at standard price. It means we need 2 separated fields for standard price & moving average price.

Regards

Alain

@Alain -
I wrote in comment 3 - we need 2 additional fields in stock_move for customer invoices
 ** move_value_sale == subtotal of invoice line
 ** move_value_cost == avg price at the time of sale

move_value_sale is used for the move value of the sale account - IMHO it's advantageuos to have this value stored in stock_move
move_value_cost is used to reduce the stock value and IMHO must be the average price so if all stock is used the value should be zero too.

adding up the
* move_value_cost == stock (location) value
* move_value_sale == income account

Sorry Ferdinand, I totally missunderstood your intention. Thanks for your precision
It ok so.
Regards
Alain

Alain: As in France, in Spain the stock must be valuated with a "moving
average price" or "FIFO" methods, "standard price" is not available as a
general case (there are a few, not common, exceptions)

Alain Rivet wrote:
> Second problem, in some countries (France for example) it's not allowed
> to valuate stock at standard price. It means we need 2 separated fields
> for standard price & moving average price.
>

By the way people, on other ERPs the stock moves are valuated (you can
even set the products value when making an inventory). Why? Just think
about this example: Your company has a warehouse in China (where it
boughts the products) and a warehouse in France (where it sells them).
The products on the China warehouse would be valuated at moving average
cost price. Moving products from China to France has a cost, this cost
must be reflected on the value of the stock: the same products have more
value for you in France (where you can sell them) than in China. So you
should be able to specify on the stock moves the new 'unit cost' value
(and this may or may not be reflected on the accounting) so the cost of
the products in the French warehouse is propertly updated (moving
average price of the 'unit cost' of the incoming stock moves).

--
Borja López Soilán
<email address hidden>

Pexego Sistemas Informáticos S.L.
Avenida de Magoi 66 - 27002 Lugo (España)
Tel./Fax 982801517
http://www.pexego.es

@Borja - stock evaluation

string the move_value_cost (for in and out moves) in each moves allows to calculate the stock value and average price in every stock location.

this - and hence using average price for evaluation of the out moves I have already in my branch and it's working.

I am going to propose this for merging into trunk during the next weeks.

what I do not have is FIFO (because I do not need it) but obviously having all the necessary data stored it's just setting a flag and a some hours of coding.

But there is another (unsolved) problem
Shall we calculate the average price
* per location (what I do)
* per warehouse

or do we need both options ?

Example
a company has to distinct tanks for the same product (petrol) and has to document the quantity in/out for some certification reasons using lots.

Ferdinand @ ChriCar escribió:
> But there is another (unsolved) problem
> Shall we calculate the average price
> * per location (what I do)
> * per warehouse
>
> or do we need both options ?
>
I would say "per location".
> Example
> a company has to distinct tanks for the same product (petrol) and has to document the quantity in/out for some certification reasons using lots.
>
Something similar happens here with spirited drinks. As each tank may
have a different alcohol percent (and there are taxes based on the
quantity of alcohol), they have to be registered individually.

--
Borja López Soilán
<email address hidden>

Pexego Sistemas Informáticos S.L.
Avenida de Magoi 66 - 27002 Lugo (España)
Tel./Fax 982801517
http://www.pexego.es

Hello,

the original suggestion is commited for version 6.0.

Thanks