Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007954Openbravo ERP03. Procurement managementpublic2009-03-05 07:462011-08-01 13:03
Reportersureshbabu 
Assigned Tojonalegriaesarte 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformOS5OS Version
Product Version3.0RC3 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0007954: Requisition status not changing from completed to locked, when requisition adds to the bottom list in Requisition To Order page
DescriptionRequisition document status not moved from completed to locked status when the user adds the requisition to the bottom list in the 'Requisition To Order' screen.

Refer:0007229
Steps To Reproduce* Login is as userA
* Go to Procurement Management || Transactions || Requisition
[Header]
* Create a new record
* Business partner = Vendor A(VA)
* Save record

[Lines]
*Create a new record
* Need by date: two weeks from today
* product = RMA (Raw material A)
* Quantity =10
Save record
[Header]
click complete button and confirm with OK.

Go to Procurement Management || Transactions || Requisition To Order
* Check the check box of the above created Requisition and click ok.

Go To Procurement Management || Transactions || Requisition || Header >> Lines

Expected: Requisition line item status should be locked.

Actual result: Requisition line item not in locked status.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Filesjpg 190609LockedRequisition.jpg (25,860) 2009-06-19 14:16
https://issues.openbravo.com/file_download.php?file_id=1443&type=bug
jpg
Issue History
Date ModifiedUsernameFieldChange
2009-03-05 07:46sureshbabuNew Issue
2009-03-05 07:46sureshbabuAssigned To => rafaroda
2009-03-05 07:46sureshbabuRegression testing => No
2009-03-12 11:52rafarodaNote Added: 0014602
2009-03-12 11:52rafarodaStatusnew => feedback
2009-03-17 06:07sureshbabuNote Added: 0014706
2009-03-17 10:03rafarodaStatusfeedback => new
2009-03-17 10:03rafarodaAssigned Torafaroda => pjuvara
2009-06-19 13:52RenateNieuwkoopNote Added: 0017482
2009-06-19 13:55RenateNieuwkoopNote Added: 0017483
2009-06-19 14:12sureshbabuNote Added: 0017484
2009-06-19 14:15RenateNieuwkoopNote Added: 0017485
2009-06-19 14:16RenateNieuwkoopFile Added: 190609LockedRequisition.jpg
2009-10-21 15:46RenateNieuwkoopNote Added: 0021274
2011-02-03 15:49RenateNieuwkoopNote Added: 0034041
2011-02-03 15:50RenateNieuwkoopIssue Monitored: RenateNieuwkoop
2011-02-03 15:52RenateNieuwkoopAssigned Topjuvara => adrianromero
2011-02-03 15:52RenateNieuwkoopPrioritynormal => high
2011-02-03 15:52RenateNieuwkoopSeverityminor => major
2011-02-03 15:52RenateNieuwkoopTypefeature request => defect
2011-02-03 15:52RenateNieuwkoopversionpi => 3.0RC3
2011-06-03 10:58dalsasuaAssigned Toadrianromero => dalsasua
2011-07-20 18:16dalsasuaAssigned Todalsasua => jonalegriaesarte
2011-08-01 13:03psarobeStatusnew => closed
2011-08-01 13:03psarobeResolutionopen => unable to reproduce

Notes
(0014602)
rafaroda   
2009-03-12 11:52   
Suresh,

Is this a feature request or a defect?

Thanks.
(0014706)
sureshbabu   
2009-03-17 06:07   
Hi Rafa,

This one needs to be a future request.
(0017482)
RenateNieuwkoop   
2009-06-19 13:52   
Sorry Suresh, but this scenario is a standard exercise in the BFT and I never had any issues with it.

The expected result is that the line is locked and also the actual result is that the line is locked. So that's correct.

When you report a difference between an expected and an actual result, that is by definition a bug, so I'm not sure what you mean by saying that it is a future request.

Just my 2 cents!
(0017483)
RenateNieuwkoop   
2009-06-19 13:55   
By the way, I would vote against changing current functionality.
What I explain to the students is that lines get locked while the purchaser is reviewing the requisitions, possibly having contact/negotiations with the vendor. During that time you do not want the user to change the requisitions without notifying the purchaser.
(0017484)
sureshbabu   
2009-06-19 14:12   
Hi Renate,

Generally i would prefer the status of the requisition should move from complete to Locked (and should not allow the requester to change the details), since the Purchaser is already considered the requisition details for negotiation purpose and about to create the Purchase order based on the details.
(0017485)
RenateNieuwkoop   
2009-06-19 14:15   
Hi Suresh,

Exactly and that is how it works. Have you tested it recently? I just tested it and it works fine in 2.50MP1. Like I said, I have never experienced any problems with this. Maybe you can retest and see if it works?

cheers
Renate
(0021274)
RenateNieuwkoop   
2009-10-21 15:46   
Hi Suresh,

Can this issue be closed? It still works fine, there are no issues with this functionality.

regards
Renate
(0034041)
RenateNieuwkoop   
2011-02-03 15:49   
This issue should be considered a bug. I am testing in the live builds for 3.0 and even though the status on the line changes to 'locked', the requisition can be put back to draft and the requisition line can be updated, for example the quantity.

To test it:
User Openbravo/openbravo, but also create a separate user with password and assign the F&B Admin role to it. Create a requisition with the created user and complete it. Log out and Log in with Openbravo/openbravo and in the Requistion to Order form add the requisition line to the bottom half of the screen, which causes a lock.
Log out and log in with Openbravo/openbravo again and go to the requisiton line. It is showing as being locked. Yet, when you go to the header and reverse the status to draft, you can go down to the lines and change the quantity on the line, so there is no lock.