firts the table name is listed, then the data elements
for cost cluster: look at reports that deal with expenditure and costs
looking at: do we have all the data elements that we need for that report
i.e. invoive line numer total brings in total including adjustments
for many reports date ranges are needed
chat: Von Julie Brannon (Duke): Is it possible to add the material type (PO Line element)?
chat: Von Scott Stangroom similar at UMass (Five colleges) as Duke
answer: will be added
chat: Von Virginia Martin How about reporting on encumbrances?
it would be helpful to get use cases - will be provided by Virginia
at end of fiscal year there are questions like: how much man should we hold back?
with encumbrances you can run multiple years and then compare
answer questions about: what still needs to be paid for
Duke have such encumbrance reports as well
Scott: a list of reports would be helpful to get as oon as possible
Virginia and Angela will check whether those reports are already included in the existing ones
expense type should be added (acq small group is discussing this at the moment)
should be easy to report on
Dennis will ad the table this is in
encumbrances and expense type are still optional, libraries do not need to use those
Sara: reports on funds and groups would be needed
Michael: groups are still uner developed; so far you can just tag funds
at the moment Dennis is developing a hierarchy for the finance app and shared allocations, different layers of visibility
the development of a hierarchy is appreciated in the group
Kristin: what is the difference between an order line and POL
Dennis: they are the same thing
there is no description for acquisition method so far
"details" (subscription) data element on POL: information is missing; it just says details record
Dennis will follow up on that
there are still questions what data elements: "eresource" and "physical" on the POL mean
maybe this is a set of data (an array) that is associated with physical or electronic (if it is an ID)
Dennis will check
chat: Von Owen Stephens I think one of the things to remember is that this is about making sure the relevant fields are available to the LDP for reporting. Different implementations and uses of the system could result in different queries and different interpretations of fields in real-world reports
Virginia: I want to report not only on the total but on all related invoice lines
Sara: is the data itself not reflected or the invoice number, just the ID?
Sharon: there is an invoices cluster
but it could also be added to this cluster
Scott: will be considered; especially after looking at the use cases
Kristin: what is the timeframe for the information gathering phase?
Sharon: most of the reports are listed for Q2 2020
everybody who wants to share use cases or give feedback should get back to Sharon and Scott quite soon
soon they will reach out to RM SIG members for testing to see if it is working and to make adjustments if needed
as work moves forward they will touch base with RM SIG again
there are 2 important filters in ACQ JIRA concerning current discussions; actively analysed features
features to be reviewed with RM SIG
filter: needs-rmsigreview
the interface tables are moved into the ACQ wiki as well
maybe info organisation needs to be re-thought
there is an Acquisitions Wiki page as part of the RM SIG space
a lot of the technical information is in the development space which is a separate space from RM space
Tips and tricks space is separate again as well (because it applies to all functional areas)
if spreadsheet is updated, is the wiki space updated as well? yes, but is a manual process
Sara: "last modiefied date stamp" for the specific elemnt or at least row would be helpful
you can only see when the page has been changed
Owen: for agreements this is done in Google sheets
Kristin: advantage of wiki is you can search for it on the wiki
Ann-Marie: link from Tips and Tricks page would be good
lock down the editing is agreed on so that nothing can unintentionally be changed
features that need further discussion:
UXPROD-1581: Receiving material without an order
problem: an order is required to receive a piece at the moment
in case of exchange or gifts: you would not need an order, but they need to be received
Dennis asks for comments to the feature
the workaround would be fake records and fake records never make sense
Sara: what does receiving mean in this scenario? Waht for?
to indicate where it came from
to create an order for this information would mean recording a lot of extra dummy information
chat:
Von Scott Stangroom The order type would be “gift” Von Owen Stephens But it’s not an order?
Von Scott Stangroom Not in the traditional sense, but in current systems, including Aleph, this is the way some handle such things
I’m not advocating it - I’d not want to use order records for recording gift receipts
in current systems statistical codes are used to indicate resources are gifts
donor information can be added to the catalogue record
Sara: receiving is different from just adding an item
there is a statistical codes area in the item record
this discussion will be continued
Chat
Von Julie Brannon (Duke) an alle: 02:52 PM Is it possible to add the material type (PO Line element)? Von Virginia Martin an alle: 02:55 PM How about reporting on encumbrances? Von Scott Stangroom an alle: 02:56 PM similar at UMass (Five colleges) as Duke
Von Owen Stephens an alle: 03:13 PM Agreement Lines are attached to Purchase Order Lines
There is a separate report cluster for reports pulling on Agreement & Agreement Line data, but we’ve discussed the links to this report cluster as there is obv. a big overlap
Von Owen Stephens an alle: 03:19 PM I think one of the things to remember is that this is about making sure the relevant fields are available to the LDP for reporting. Different implementations and uses of the system could result in different queries and different interpretations of fields in real-world reports
What Scott said :) - if the POL is attached to an Agreement Line you may want to derive the resource description from there, but the resources are described via Inventory, you can go that way instead Or both if you are using a mixture
Von Scott Stangroom an alle: 03:53 PM The order type would be “gift” Von Owen Stephens an alle: 03:53 PM But it’s not an order?
Von Scott Stangroom an alle: 03:54 PM Not in the traditional sense, but in current systems, including Aleph, this is the way some handle such things
I’m not advocating it - I’d not want to use order records for recording gift receipts
Von Scott Perry an alle: 03:56 PM Chicago handles this currently via a donor code in the eholding or item which also drives public display.
For gifts, that is
Von Ann-Marie Breaux an alle: 03:59 PM This is a super-interesting topic to me, but I'm going to need to jump to another mtg