According to schemaspy, unitprice is supposed to be used for the actual price of an item, known by librarians when they are receiving the document. That is how we use it in Rennes 2. So it should be displayed only in receipt page, and not when we are creating an order M. Saby
We also recommend to use it like that and only fill in list price.
Created attachment 79211 [details] [review] Bug 9775: Unitprice should be hidden when creating an order
Is unitprice "Actual cost"? When I change the amount in Actual cost, it doesn't take into account the decimal (I tried with a comma and a period). So 19,99 becomes 1999,00 and 19.99 also becomes 1999,00.
Slightly confused by your comment Caroline. This patch should just remove the 'actual cost' on the new order forms. The reasoning behind this is that this actual cost is intended to only be set at the point of invoice when it is definitive. Where are you entering numbers and finding decimal issues creeping in.. that may well be another bug.. in. The orderrecieve form perhaps?
Hi Martin, Sorry for the confusion. There were two points to my comment. 1) is unitprince and Actual Cost the same thing? I only see Actual Cost on my system, so I'm assuming it's the same 2) On the orderreceive.pl page, if I try to change the actual cost (which is set by default to the vendor price), no matter what decimal symbol I use, it is not taken into account. 20.99 becomes 2099.00 So if your patch is only to remove actual cost from the order form, it works. But the decimal problem is very serious, imo. Should I file another bug?
So, 'unitprice' is the database column name, 'actual cost' is the phrase used in the UI with default en language out of the box. Sorry for the confusion there, I should have added a clear testplan. As for decimal issues, I agree that is a terrible issue. I think there are a few bugs around it already though.. perhaps you could comment on bug 17098, 12310 or 18723..?
Created attachment 79777 [details] [review] Bug 9775: Unitprice should be hidden when creating an order The actual cost box is effectively hidden from the order page. Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
CCing Sévérine on this one, I talked with her yesterday and I think she told me they are using it as a workaround for subscriptions.
Created attachment 80704 [details] [review] Bug 9775: Unitprice should be hidden when creating an order The actual cost box is effectively hidden from the order page. Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
We adjust the 'actual price' only on reception page, especially for subscription when we've got several invoices for only one subscription order, so I agree with hiding the 'actual cost' in the order form. This patch seems to work as expected :)
Do not we want to keep the value from the "last order received" for subscription? - $data->{unitprice} = $lastOrderReceived->{unitprice}; You do not hide it, you removed it. Is it really what we want?
My understanding of it was that it should only get set at invoicing time as that's when you know the final accurate price. At least, that's where my logic to remove it entirely came from.
We have the option to view an already received order. I think it still makes sense to display the value there to have complete information. I agree that entering it at ordering time doesn't make sense with the current workflow.
Hm, checking the GUI it looks like I imagined the option to view? *scratches head* So the change makes sense.
(In reply to Jonathan Druart from comment #11) > Do not we want to keep the value from the "last order received" for > subscription? > > - $data->{unitprice} = $lastOrderReceived->{unitprice}; > > > You do not hide it, you removed it. Is it really what we want? Martin, can you check this specific line? I agree with you on the workflow - actual cost is supposed to be set on receiving/processing the invoice.
Created attachment 80966 [details] [review] Bug 9775: Unitprice should be hidden when creating an order The actual cost box is effectively hidden from the order page. Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Sorry for all the comments, I am just getting warmed up today it seems. I've decided to pass QA since the behaviour makes sense to me. I've tested an acquisition order. When it's not yet received the amounts show in Ordered and when you receive, the actual cost is shown in Spent.
(In reply to Katrin Fischer from comment #17) > Sorry for all the comments, I am just getting warmed up today it seems. > > I've decided to pass QA since the behaviour makes sense to me. I've tested > an acquisition order. When it's not yet received the amounts show in Ordered > and when you receive, the actual cost is shown in Spent. Can you send this one out to the mailing list Martin? While I agree with the change I believe there are libraries out there entering items retroactively, and sometimes entering them upon the ordering phase, this would add work for them as they would have to make new edits in the receiving phase. I am not against it, just want to make sure users are warned.
The general feedback from the mailing list post was positive but not extensive.. I'm still keen to get this one through to clarify the intended use.
Awesome work all! Pushed to master for 18.11
Could cause an unexpected change for a stable release at this point in the cycle.. deferring to 18.11 series.