[Stock valuation] Stock journal entry for real-time product which have unit and sale price are 0.0

[gde (OpenERP)]

On the SaaS, when I make an inventory directly from the product form for a Consumable product with sales and cost price equal to 0, I get an accounting line with an amount equal to 1 which is not correct.

It should generate a move with an amount equal to 0 or no move at all.

Steps to reproduce:
- Create a consumable product with sales and cost price equal to 0
- Set the Stock valuation to real time
- Make an inventory for 10000 units
- Check the accounting move
- Make an inventory for 5 units for the same product
- Check the accounting move

--> Problem: accounting move with amount different of 0

[Amit Parik (amit-parik)]

Hello,

I have checked your issue but this is not a bug rather than it's functional behavior for accounting entires.

Let me explain whole thing here:

First of all that doesn't matter that we have using a "Consumable " or "Stackable" both have behavior same for this scenario.

You have created a product with cost and sale both price 0.0.
Yes, you are right. Whenever we creates stock journal's entires for this product it will take the credit and debit value 1.0.

This is not a bug, but we have set this thing for better functional behavior for real time scenario. Because If we creates entires for 0.0 it's doesn't make sanes and it's meaning less also we won't allow entires for 0.0.

Finlay that's behavior is set an intensionally and this 's not a bug, So I am converting this to questions.

Correct me If I am wrong .

Thanks for understanding!

[Numérigraphe (numerigraphe)]

Confirming back as a bug according to gde (OpenERP)'s comment:

"Ok. So it is more correct to have several wrong lines instead of having some correct lines with an amount of 0 or no lines at all?

 A better solution is to have no line if the debit/credit amount is equal to 0."
Lionel Sausin.

[Amit Parik (amit-parik)]

Hello Lionel,

I don't agree, we should not allow the entry for credit and debit with amount 0 for stock accounting because If we have to calculate our stock valuation there should be some entry . That's we have create entry for (less amount 1.0) please see the comment#1.

If we update some stock for realtime product then there should be some entry for this product's valuation. If we creates entry with 0.0 amount then it's don't have any meaning that's why we have put this behavior.

So this is not a generalize issue and for more discussion I am setting this as an "Opinion".
After a discussion over here we will decide the better solution for this and then we will set the appropriate status for it.

Correct me If I am wrong.

 @Stock and Accounting experts: Would you please share your views on this!

Thanks and more suggestions are welcomed!

[Vadim - Enapps LTD (vadim-enapps)]

although this doesnt affect me, I agree that this is a bug. dont create an accounting entry if its zero then.

[Antoine(OpenERP) (ahu-openerp)]

I completely agree with Gde & people supporting the idea this is a bug.

[Kyle Waid (midwest)]

I also agree this is a bug. It does not make any sense to create a value from nothing.

[Amit Parik (amit-parik)]

Hello Folks,

Thanks for replied on this.

Would you please describe here which behaviour is good for this.
- Entry should be created with 0.0 value.
- Journal entry should not be created (because may be it's good, If we should not create this entry rather than create a entry for nothing)

Would you please provide your suggestion for the better solution. That is very efficient, If someone provide a proper real use case.

Thank you!

[Graeme Gellatly (gdgellatly)]

Well for me the answer is that an entry for 0.00 should be created.

For a few reasons:
1 - Other modules expect invoices to have account move lines e.g
account_anglo_saxon and to not have a move line could cause breakage.
2 - it is probably easier - there is a default somewhere causing 1, just
removing the default probably fixes it.
3 - its probably cleaner - same reason as above - rather than a special
test and not create moves - uses same code.
4 - it provides better traceability in case of returns, refund invoices etc.
5 - accountants (and tax departments) like to see everything especially in
audits (most fraud is perpetuated and caught at the journal level)
6 - not creating the zero move makes amending it harder.

On Mon, Feb 20, 2012 at 6:30 PM, Amit Parik (OpenERP) <email address hidden>wrote:

> Hello Folks,
>
> Thanks for replied on this.
>
> Would you please describe here which behaviour is good for this.
> - Entry should be created with 0.0 value.
> - Journal entry should not be created (because may be it's good, If we
> should not create this entry rather than create a entry for nothing)
>
> Would you please provide your suggestion for the better solution. That
> is very efficient, If someone provide a proper real use case.
>
> Thank you!
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/921680
>
> Title:
> [Stock valuation] Stock journal entry for real-time product which have
> unit and sale price are 0.0
>
> Status in OpenERP Addons (modules):
> Opinion
>
> Bug description:
> On the SaaS, when I make an inventory directly from the product form
> for a Consumable product with sales and cost price equal to 0, I get
> an accounting line with an amount equal to 1 which is not correct.
>
> It should generate a move with an amount equal to 0 or no move at all.
>
>
> Steps to reproduce:
> - Create a consumable product with sales and cost price equal to 0
> - Set the Stock valuation to real time
> - Make an inventory for 10000 units
> - Check the accounting move
> - Make an inventory for 5 units for the same product
> - Check the accounting move
>
> --> Problem: accounting move with amount different of 0
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/921680/+subscriptions
>

[Amit Dodiya (OpenERP) (ado-openerp)]

Hello,

This issue if fixed with following branch:
Branch: lp:~openerp-dev/openobject-addons/6.0-opw-381937-ado with
Revision-id: <email address hidden> and
Revision-no: 5013

Thanks,
Amit

[gde (OpenERP) (gde-openerp)]

It is solved in 6.0.3 but the bug is still present in 6.1

The patch should be done for the 6.1 also.

[Xavier ALT (dex-phx)]

Hi Gregory,

The forward-port of the patch to v6.1 is on the following branch:
(awaiting approval of the R&D Team)

Branch: lp:~openerp-dev/openobject-addons/6.1-opw-381937-xal
Revision-id: <email address hidden>
Revision-no: 6642

Thanks,
Xavier

[gde (OpenERP) (gde-openerp)]

Thanks. Waiting for the merge in the 6.1.

[Numérigraphe (numerigraphe)]

Was this fixed in trunk?
Lionel.

[Naresh(OpenERP) (nch-openerp)]

Hello OpenERP Lovers ,

This bug was fixed in 6.0,6.1, and forward 7.0 also trunk a long back but the status of the bug was not updated !

6.0: @ 5103 : <email address hidden>

6.1: @ 6677 : <email address hidden>

and was forward ported to 7.0 and so on with trunk @6680 : <email address hidden>

Thanks,
Naresh Soni
OpenERP Enterprise Services