Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0006912Openbravo ERPZ. Otherspublic2009-01-15 14:032009-05-22 16:39
networkb 
gorkaion 
immediateminoralways
closedfixed 
5
2.40 
 
Core
No
0006912: It is not possible to deactivate a product which has an ordered quantity of zero.
If we have a product which is related to a certain sales
order or purchase order it is not possible to deactivate it.

When we change the ordered quantity field to zero in the lines of a sales order or purchase order, the QTYRESERVED column should be automatically updated to zero in order to update the M_STORAGE_PENDING table.

This is not done, so, it is not possible to DEACTIVATE this product.
The steps to reproduce this issue are:

*Sales Management or Procurement Managenet/Sales Order:
- Create a new SO/PO and in its' lines select a product and an Ordered Quantity, save and complete. You will see the new value in QTYRESERVED column of the M_STORAGE_PENDING table.
- Reactivate the order and in the lines change the Ordered Quantity to zero, save and complete. The QTYRESERVED column of the M_STORAGE_PENDING table must change to zero, it isn't changed. The previous value remain.

*Master Data Management/Product
- Try to deactivate the product, it is not possible (red message: cannot deactivate the product because it has inventory).
comsup_sprint4
depends on backport 0006941 closed gorkaion It is not possible to deactivate a product which has an ordered quantity of zero. 
depends on backport 0009119 closed gorkaion It is not possible to deactivate a product which has an ordered quantity of zero 
has duplicate defect 0006910 closed gorkaion Shadow reservations for products after re-activating the sales order 
Issue History
2009-01-15 14:03networkbNew Issue
2009-01-15 14:03networkbAssigned To => rafaroda
2009-01-15 14:03networkbsf_bug_id0 => 2509846
2009-01-15 14:03networkbRegression testing => No
2009-01-15 17:51networkbversion => 2.40
2009-01-16 11:14rafarodaStatusnew => scheduled
2009-01-16 11:14rafarodaAssigned Torafaroda => gorkaion
2009-01-16 11:14rafarodafix_in_branch => trunk
2009-01-20 10:46rafarodaRelationship addedrelated to 0006910
2009-01-20 11:15svnbotCheckin
2009-01-20 11:15svnbotNote Added: 0012381
2009-01-20 11:15svnbotStatusscheduled => resolved
2009-01-20 11:15svnbotResolutionopen => fixed
2009-01-20 11:15svnbotsvn_revision => 12052
2009-01-20 11:27gorkaionRelationship replacedhas duplicate 0006910
2009-01-23 11:33gorkaionTag Attached: comsup_sprint4
2009-01-30 10:46networkbNote Added: 0012871
2009-02-06 01:17gorkaionTag Attached: comsup_sprint5
2009-02-06 01:18gorkaionTag Detached: comsup_sprint5
2009-04-21 12:39psarobeStatusresolved => closed
2009-05-21 10:56rafarodaRelationship addedrelated to 0009119
2009-05-21 10:57rafarodaRelationship replaceddepends on 0009119
2009-05-22 16:39hgbotCheckin
2009-05-22 16:39hgbotNote Added: 0016590
2009-05-22 16:39hgbotFixed in SCM revision12052 => http://code.openbravo.com/erp/stable/2.3x/rev/2e1e60273c9a03bcbd4d1adb1656886056ff67f5 [^]

Notes
(0012381)
svnbot   
2009-01-20 11:15   
Repository: openbravo
Revision: 12052
Author: gorkaion
Date: 2009-01-20 11:15:11 +0100 (Tue, 20 Jan 2009)

Fixed bug 6912. Fixed the C_ORDER_POST1 procedure to properly manage the reserved quantity in the M_Storage_Pending table.

---
U trunk/src-db/database/model/functions/C_ORDER_POST1.xml
---

https://dev.openbravo.com/websvn/openbravo/?rev=12052&sc=1 [^]
(0012871)
networkb   
2009-01-30 10:46   
Gorkaion,

It happens the same in Purchase orders. It should be fixed as well
(0016590)
hgbot   
2009-05-22 16:39   
Repository: erp/stable/2.3x
Changeset: 2e1e60273c9a03bcbd4d1adb1656886056ff67f5
Author: Gorka Ion Damián <gorkaion.damian <at> openbravo.com>
Date: Fri May 22 16:39:08 2009 +0200
URL: http://code.openbravo.com/erp/stable/2.3x/rev/2e1e60273c9a03bcbd4d1adb1656886056ff67f5 [^]

Fixed bug 9119.Applied patch of issue 6912.

---
M database/model/functions/C_ORDER_POST1.xml
---