Bug 9775 - Unitprice should be hidden when creating an order
Hi all, There's a bit of contention going on over at bug 9775 and I wanted to ask the wider audience of librarians for their thoughts on acquisitions workflows in relation to this bug. Currently, the 'New order' page, whether it be via a suggestion, via an existing record or via another means, displays 'Actual cost' as an editable field. On further investigation, it appears that this field was intended to contain the final amount paid and not an estimation and as such the intention was for it to only be defined at the point of invoice/payments once it is fixed. Bug 9775 does exactly this, hides the field from display on the new order page. It also goes slightly further and prevents a prior paid price (for serial subscriptions) from carrying across when you are placing your next new order via a subscriptions search. My question to you is, is anyone using this field in a different way to my expectations/understanding? Would it cause anyone any issues to remove this field from the order screen so it is more clearly defined as to it's intended use only on the receipting pages? Are there any alternative improvements you would like to see instead of this change? Many thanks, *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com
Under our scenario and as developed under 16.05 (when we started working with Acquisitions because it was the first version that supported standing orders), UI "Actual Cost" (SQL aqorders.unitprice) is only filled in at the time of item receipt (invoice payment) for both firm and standing orders. I don't see how its removal during the Create Order process causes undue burden. I have always found the presence of Actual Cost extremely confusing when creating an order and have always been of the opinion that it should not display as part of the "Create order" process but should display at any other time. During the order creation process, a user should only be allowed to encumber funds, not expend them. Similarly, during receipt, a user should not be able to edit the estimated price entered at order creation and should only be able to enter the actual amount (with unencumbering happening automatically based on number of copies received times estimated price). Come to think of it, I'm not even sure how encumbering/unencumbering would work if both an estimated and actual price were entered at the same time (THEORY: no change to encumbered ("Ordered") amount and "Spent" increases by Actual Price). It might get messy, though, if someone were to alter the encumbered amount at a later point in time--I've never bothered to alter an estimated amount after an actual amount has been entered to see what might happen on the funds side). In my KohaCon 2018 presentation I have in my notes to remind users that "Actual cost will be set when the item is received and invoice processed". Whether I actually made that point or not I don't recall--there was a LOT to cover in 30 short minutes! We don't use subscriptions here so I cannot comment on that aspect (even though nearly 100% of our budget is spent via standing orders). Now if only I could get "Actual Price" to display as part of the broader basket display of orders, instead of having to go into an order to actually view it.... John On Thu, Oct 25, 2018 at 4:02 AM Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
Hi all,
There's a bit of contention going on over at bug 9775 and I wanted to ask the wider audience of librarians for their thoughts on acquisitions workflows in relation to this bug.
Currently, the 'New order' page, whether it be via a suggestion, via an existing record or via another means, displays 'Actual cost' as an editable field.
On further investigation, it appears that this field was intended to contain the final amount paid and not an estimation and as such the intention was for it to only be defined at the point of invoice/payments once it is fixed.
Bug 9775 does exactly this, hides the field from display on the new order page. It also goes slightly further and prevents a prior paid price (for serial subscriptions) from carrying across when you are placing your next new order via a subscriptions search.
My question to you is, is anyone using this field in a different way to my expectations/understanding? Would it cause anyone any issues to remove this field from the order screen so it is more clearly defined as to it's intended use only on the receipting pages? Are there any alternative improvements you would like to see instead of this change?
Many thanks,
*Martin Renvoize*
Development Team Manager
*Phone:* +44 (0) 1483 378728
*Mobile:* +44 (0) 7725 985 636
*Email:* martin.renvoize@ptfs-europe.com
*Fax:* +44 (0) 800 756 6384
www.ptfs-europe.com
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Senior Associate Librarian Manager, Technical Services, Collections, and Library Automation 700 East University Avenue Kresge Hall, 4th Floor East Suite K4511 Kresge Library Services The University of Michigan Ann Arbor, Michigan, USA 48109-1234 TEL: (734) 764-5746
I must update part of my response from yesterday: *"It might get messy, though, if someone were to alter the encumbered amount [after an "Actual cost" has been entered]--I've never bothered to alter an estimated amount after an actual amount has been entered to see what might happen on the funds side)."* I know exactly what happens--at least with standing orders because we do this to be able to see any given S.O.'s complete payment history when simply viewing the basket. If one updates the "Vendor price" field after the "Actual cost" has been entered, Replacement cost, Budgeted cost and Total are updated (like you would expect) but there is no change to "Ordered" for the order's fund because there is no additional encumbering/unencumbering of funds. Were this not true, my "Ordered" balances would be a disaster (much like they were with III and the way that system handled what were called c, d, and g order statuses)--but we've historically always ignored "Ordered" ("Encumbered" from back in the day) since it never actually represented "real money". John On Thu, Oct 25, 2018 at 1:52 PM John Sterbenz <jsterben@umich.edu> wrote:
Under our scenario and as developed under 16.05 (when we started working with Acquisitions because it was the first version that supported standing orders), UI "Actual Cost" (SQL aqorders.unitprice) is only filled in at the time of item receipt (invoice payment) for both firm and standing orders.
I don't see how its removal during the Create Order process causes undue burden.
I have always found the presence of Actual Cost extremely confusing when creating an order and have always been of the opinion that it should not display as part of the "Create order" process but should display at any other time. During the order creation process, a user should only be allowed to encumber funds, not expend them. Similarly, during receipt, a user should not be able to edit the estimated price entered at order creation and should only be able to enter the actual amount (with unencumbering happening automatically based on number of copies received times estimated price).
Come to think of it, I'm not even sure how encumbering/unencumbering would work if both an estimated and actual price were entered at the same time (THEORY: no change to encumbered ("Ordered") amount and "Spent" increases by Actual Price). It might get messy, though, if someone were to alter the encumbered amount at a later point in time--I've never bothered to alter an estimated amount after an actual amount has been entered to see what might happen on the funds side).
In my KohaCon 2018 presentation I have in my notes to remind users that "Actual cost will be set when the item is received and invoice processed". Whether I actually made that point or not I don't recall--there was a LOT to cover in 30 short minutes!
We don't use subscriptions here so I cannot comment on that aspect (even though nearly 100% of our budget is spent via standing orders).
Now if only I could get "Actual Price" to display as part of the broader basket display of orders, instead of having to go into an order to actually view it....
John
On Thu, Oct 25, 2018 at 4:02 AM Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
Hi all,
There's a bit of contention going on over at bug 9775 and I wanted to ask the wider audience of librarians for their thoughts on acquisitions workflows in relation to this bug.
Currently, the 'New order' page, whether it be via a suggestion, via an existing record or via another means, displays 'Actual cost' as an editable field.
On further investigation, it appears that this field was intended to contain the final amount paid and not an estimation and as such the intention was for it to only be defined at the point of invoice/payments once it is fixed.
Bug 9775 does exactly this, hides the field from display on the new order page. It also goes slightly further and prevents a prior paid price (for serial subscriptions) from carrying across when you are placing your next new order via a subscriptions search.
My question to you is, is anyone using this field in a different way to my expectations/understanding? Would it cause anyone any issues to remove this field from the order screen so it is more clearly defined as to it's intended use only on the receipting pages? Are there any alternative improvements you would like to see instead of this change?
Many thanks,
*Martin Renvoize*
Development Team Manager
*Phone:* +44 (0) 1483 378728
*Mobile:* +44 (0) 7725 985 636
*Email:* martin.renvoize@ptfs-europe.com
*Fax:* +44 (0) 800 756 6384
www.ptfs-europe.com
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Senior Associate Librarian Manager, Technical Services, Collections, and Library Automation 700 East University Avenue Kresge Hall, 4th Floor East Suite K4511 Kresge Library Services The University of Michigan Ann Arbor, Michigan, USA 48109-1234
TEL: (734) 764-5746
-- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Senior Associate Librarian Manager, Technical Services, Collections, and Library Automation 700 East University Avenue Kresge Hall, 4th Floor East Suite K4511 Kresge Library Services The University of Michigan Ann Arbor, Michigan, USA 48109-1234 TEL: (734) 764-5746
Thanks John, that's been really helpful feedback. *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com On Fri, 26 Oct 2018 at 17:39, John Sterbenz <jsterben@umich.edu> wrote:
I must update part of my response from yesterday:
*"It might get messy, though, if someone were to alter the encumbered amount [after an "Actual cost" has been entered]--I've never bothered to alter an estimated amount after an actual amount has been entered to see what might happen on the funds side)."*
I know exactly what happens--at least with standing orders because we do this to be able to see any given S.O.'s complete payment history when simply viewing the basket. If one updates the "Vendor price" field after the "Actual cost" has been entered, Replacement cost, Budgeted cost and Total are updated (like you would expect) but there is no change to "Ordered" for the order's fund because there is no additional encumbering/unencumbering of funds.
Were this not true, my "Ordered" balances would be a disaster (much like they were with III and the way that system handled what were called c, d, and g order statuses)--but we've historically always ignored "Ordered" ("Encumbered" from back in the day) since it never actually represented "real money".
John
On Thu, Oct 25, 2018 at 1:52 PM John Sterbenz <jsterben@umich.edu> wrote:
Under our scenario and as developed under 16.05 (when we started working with Acquisitions because it was the first version that supported standing orders), UI "Actual Cost" (SQL aqorders.unitprice) is only filled in at the time of item receipt (invoice payment) for both firm and standing orders.
I don't see how its removal during the Create Order process causes undue burden.
I have always found the presence of Actual Cost extremely confusing when creating an order and have always been of the opinion that it should not display as part of the "Create order" process but should display at any other time. During the order creation process, a user should only be allowed to encumber funds, not expend them. Similarly, during receipt, a user should not be able to edit the estimated price entered at order creation and should only be able to enter the actual amount (with unencumbering happening automatically based on number of copies received times estimated price).
Come to think of it, I'm not even sure how encumbering/unencumbering would work if both an estimated and actual price were entered at the same time (THEORY: no change to encumbered ("Ordered") amount and "Spent" increases by Actual Price). It might get messy, though, if someone were to alter the encumbered amount at a later point in time--I've never bothered to alter an estimated amount after an actual amount has been entered to see what might happen on the funds side).
In my KohaCon 2018 presentation I have in my notes to remind users that "Actual cost will be set when the item is received and invoice processed". Whether I actually made that point or not I don't recall--there was a LOT to cover in 30 short minutes!
We don't use subscriptions here so I cannot comment on that aspect (even though nearly 100% of our budget is spent via standing orders).
Now if only I could get "Actual Price" to display as part of the broader basket display of orders, instead of having to go into an order to actually view it....
John
On Thu, Oct 25, 2018 at 4:02 AM Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
Hi all,
There's a bit of contention going on over at bug 9775 and I wanted to ask the wider audience of librarians for their thoughts on acquisitions workflows in relation to this bug.
Currently, the 'New order' page, whether it be via a suggestion, via an existing record or via another means, displays 'Actual cost' as an editable field.
On further investigation, it appears that this field was intended to contain the final amount paid and not an estimation and as such the intention was for it to only be defined at the point of invoice/payments once it is fixed.
Bug 9775 does exactly this, hides the field from display on the new order page. It also goes slightly further and prevents a prior paid price (for serial subscriptions) from carrying across when you are placing your next new order via a subscriptions search.
My question to you is, is anyone using this field in a different way to my expectations/understanding? Would it cause anyone any issues to remove this field from the order screen so it is more clearly defined as to it's intended use only on the receipting pages? Are there any alternative improvements you would like to see instead of this change?
Many thanks,
*Martin Renvoize*
Development Team Manager
*Phone:* +44 (0) 1483 378728
*Mobile:* +44 (0) 7725 985 636
*Email:* martin.renvoize@ptfs-europe.com
*Fax:* +44 (0) 800 756 6384
www.ptfs-europe.com
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Senior Associate Librarian Manager, Technical Services, Collections, and Library Automation 700 East University Avenue Kresge Hall, 4th Floor East Suite K4511 Kresge Library Services The University of Michigan Ann Arbor, Michigan, USA 48109-1234
TEL: (734) 764-5746
-- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Senior Associate Librarian Manager, Technical Services, Collections, and Library Automation 700 East University Avenue Kresge Hall, 4th Floor East Suite K4511 Kresge Library Services The University of Michigan Ann Arbor, Michigan, USA 48109-1234
TEL: (734) 764-5746
participants (2)
-
John Sterbenz -
Renvoize, Martin