[stock] product.product method get_product_accounts just check the first level category_id in stock_valuation

[hbto [Vauxoo] http://www.vauxoo.com]

[stock] product.product method get_product_accounts just check the first level category_id

When trying to get the accounting account for stock_[in/out] variation_account and journal_id
from a category_id this method just go up to the first level and does not check upper levels
which would avoid a lot of problems because those upper level could provide the missing parameters
lacking to accomplish stock valuation

the patch provide could avoid that, is simple is easy to use and quite possible would not break any
backward compatibility.

[Amit Parik (amit-parik)]

Hello,

I have checked your issue as well as your patch but I did not understand why you want this.

You mean if we don't assign a stock valuation account in product category then it will check the account of it's parent category.
I think this does not make sense.

SO would you please provide more information or proper use-case for it.

Thank you!

[Nhomar - Vauxoo (nhomar)]

Hello Amit.

>>You mean if we don't assign a stock valuation account in product category then it will check the account of it's parent category.
Yes this is exactly what Hbto is trying to say.

I think:

If we have:
Category A
--Category A.1

Category A Properties: ACC1 - ACC2 - ACC3 .....
Category A.1 Properties: ACC3 - "False" - "False" - .....

If we have some operation wit a product correspondint to Category A.1 it will take for operations: ACC3 - ACC2 - ACC3.

Righ now Categories on products are JUST usable for Accounting porpose nothing more, if we don't have this feature in this way, in implementations with a lot of products, will be almost imposible detect the leak of an account, but if you functionally clasified well your product you can work without problem from an accounting POV.

In Order to explain better:

Now search account properties is in this way:

Account on product > Accounts on Category > Message of Error:

We propose:

Account on product > Accounts on Category > Accounts on Parent Category [Recursivally] > MEssage of Error:

Do You get our point?

Thanks a lot for your time.

REgards.

[Amit Parik (amit-parik)]

Hello Nhomar,

Thanks for your reply as well as nice explanation:).

Now I exactly got the point. As per you said, currently we have checked account properties in following manner.
Account on product > Accounts on Category > Message of Error:

Here hbto and Nhomar, specified about the stock valuation account, so there is also one possibility which is account comes from the stock location for stock accounting.

Anyways you have provide a nice feature and I think we have to implement this but before implementing this we need to more discussion about it because If we applied a this on stock accounting purpose then also we will apply this same thing for income account and expanse account. There is also possibility for the location parent->child hierarchy.

Finally such as a improvement, currently we are considering this as a wishlist but also we need to more discussion on same.
SO I am subscribing Accounting experts to look in to this issue.

@Accounting Experts : Would you please share your views on this.

Thanks and more suggestions are welcomed also thanks for the savvy.!

[Kevin McMenamin (kevin-mcmenamin)]

Conceptually I like this - would simplify category maintenance as could hold accounting rules at top level then only as required for differences at lower levels. Would help when setting up lots of pricing categories in a multi-company situation (eg 40 categories x 12 companies).

Will this work for anglo-saxon or extra code required?

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

Hello, Kevin,

this module is addressing this problem right now,
will a solution is reached

http://bazaar.launchpad.net/~inddiana/sisb/sisb/files/head:/product_category_account

Regards,

Hbto [VAUXOO]

[Graeme Gellatly (gdgellatly)]

I don't know. It sounds great in theory, and for a long time I wanted that
as the default behaviour. But I kind of like it now in that it is explicit
that the values in the product category are the values. Because they are
all property fields I can just see it being a mess from a user perspective.
 Is the field blank because a different company created the category,
moreoever - now that it is blank it will still pull an account from
somewhere is it even taking the right accounts? What if I change its
parent, etc etc (of course the reverse is true, if I change its parent I
might be doing so to change the accounts)

Scenario - new category by Company A for some new products (by default
shared company wide). To be measured in separate account say Product A
Revenue instead of General Sales. All works well for Company A as they set
up the category. Now smart salesperson from Company B sells it and instead
of throwing an error and alerting accounts it just flows through.

In the current scenario, one sale, error thrown, problem corrected by
accounts.
In the proposed scenario, many sales, maybe even to end of a fiscal or
longer.

I know its a pain to setup product categories properties when you have a
lot of them (we use 78 shared over 6 companies) and you can't just SQL
them, but csv import works, and KOO supports updating multiple objects so
I'd rather see this as a seperate module.

Also get_product_accounts is from memory only used by 1 other function as a
helper function. There are many many other modules that access product
accounts information. I'm not saying thats right, but just reality.
 Anglosaxon is just one that will break.

On Sat, Feb 18, 2012 at 1:39 PM, hbto [Vauxoo] http://www.vauxoo.com <
<email address hidden>> wrote:

> Hello, Kevin,
>
> this module is addressing this problem right now,
> will a solution is reached
>
>
> http://bazaar.launchpad.net/~inddiana/sisb/sisb/files/head:/product_category_account
>
> Regards,
>
> Hbto [VAUXOO]
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/912631
>
> Title:
> [stock] product.product method get_product_accounts just check the
> first level category_id in stock_valuation
>
> Status in OpenERP Addons (modules):
> Confirmed
>
> Bug description:
> [stock] product.product method get_product_accounts just check the
> first level category_id
>
> When trying to get the accounting account for stock_[in/out]
> variation_account and journal_id
> from a category_id this method just go up to the first level and does not
> check upper levels
> which would avoid a lot of problems because those upper level could
> provide the missing parameters
> lacking to accomplish stock valuation
>
> the patch provide could avoid that, is simple is easy to use and quite
> possible would not break any
> backward compatibility.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/912631/+subscriptions
>