Settings and activity
93 results found
-
10 votes
Jeremy Goldstein
supported this idea
·
-
3 votesJeremy Goldstein
supported this idea
·
-
10 votesJeremy Goldstein
supported this idea
·
-
7 votesJeremy Goldstein
supported this idea
·
-
27 votesJeremy Goldstein
supported this idea
·
-
50 votes
An error occurred while saving the comment Jeremy Goldstein
supported this idea
·
-
11 votesJeremy Goldstein
supported this idea
·
-
9 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Yes these are the individual entries that make up the posting registers and payment history files such as encumbrances and expenditures being applied to particular funds.
Jeremy Goldstein
shared this idea
·
-
9 votesJeremy Goldstein
supported this idea
·
-
31 votes
An error occurred while saving the comment Jeremy Goldstein
commented
This is quite important information that we would love to see in item records for all sorts of statistical purposes. Just calculating cost per circ by fund alone would be a game changer.
My one big concern with it however, which would need to be addressed, is to make sure that items wouldn't have to become bound to accounting units, similar to orders and checkin records. Items must remain accessible to libraries beyond the accounting unit owner.
Jeremy Goldstein
supported this idea
·
An error occurred while saving the comment Jeremy Goldstein
commented
Besides the record count report mentioned in the idea we've had many requests over the years for cost per circ reports, which we've only ever been able to estimate given that our items generally contain list prices (for billing purposes) and not the library's cost (residing in the order record paid field).
I have reservations about establishing a direct link between an order and an item given the need at many libraries to routinely delete old order records, but just having the fund code available as an item field could be a decent compromise and enough to provide some additional reporting options.
-
19 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Having an actual id value and not just a row number feels like basic database design and would go a long ways towards preventing determiner related errors from occurring when rules may be deleted.
Jeremy Goldstein
supported this idea
·
-
16 votes
An error occurred while saving the comment Jeremy Goldstein
commented
As a consortia with a few hundred rules, this would be incredibly helpful to assist in managing the whole table.
Jeremy Goldstein
supported this idea
·
-
39 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Jeremy Goldstein
commented
@Jennifer I'm almost certain the default setting would allow the current scenario to work as is. Presently holds are allowed on bibs with only orders attached, because it doesn't take orders into consideration at all...this is the identical scenario to having a bib with nothing attached.
It's only when items are attached that the loan rule determiner comes into play at present.
An error occurred while saving the comment Jeremy Goldstein
commented
We encounter this quite a bit in our system as well and it is a cause of problems for patrons and confusion for staff.
Jeremy Goldstein
supported this idea
·
-
14 votesJeremy Goldstein
supported this idea
·
-
3 votesJeremy Goldstein
supported this idea
·
-
7 votesJeremy Goldstein
supported this idea
·
-
17 votesJeremy Goldstein
supported this idea
·
-
8 votesJeremy Goldstein
supported this idea
·
-
22 votesJeremy Goldstein
supported this idea
·
-
14 votesJeremy Goldstein
supported this idea
·
Idea is pretty closely related to https://ideas.iii.com/forums/951745-ils-sierra/suggestions/47428049, which made it to the IUG ballot for 6.7 before expiring. Definitely worth another shot, particularly given the Vega implecations.