Acquisitions/Resource Management implementers

It is standing orders not subscriptions that should default to false because they often have multiple invoices. for subscriptions more often there is one invoice for the year.

The default may not be as important than making clear what this toggle will do in documentation.

We will have some additional discussion after libraries have had a chance to review.

At Chicago, we're continuing to struggle with identifier matches when creating POs. We want to be creating new instances in Inventory, but instead matches are occurring and the new item is being attached to the wrong instance record in Inventory. This is on our test system (running Juniper). We are getting matches when the publisher provides an ISBN in the 024 or a publisher/distributor number in the 028. This is really common for Harrassowitz with music scores. So a short, non-unique publisher number, like "8021" matches multiple records already in Inventory, and then FOLIO picks the first one it finds and attached the new holdings/item. These aren't even the same title, different format - these are two very distinct publications. If you want to see this in action, here's a short video: https://drive.google.com/file/d/1MOnMnF7u-RKb0pmFy80wulCjIfBmnwJ8/view?usp=sharing. One interim solution is to remove any identifiers (which is kind of a bummer, since these can be useful to identifying the material). Lotus will bring the ability to turn off identifier matching.

Orders will use all "Product identifier types". These match up to "Resource identifier types" in instance records

• ASIN
• CODEN
• DOI
• ISBN
• ISSN
• Report Number
• Standard technical report number
• URN

It would be good to discuss how we might want matching to work since the current process is way too broad.

(edited)

Screenshot showing the PO Line details window after saving a new PO line with the receipt date populated and Receipt status showing "Awaiting Receipt" since the order hasn't been received yet through the Receiving app.

Clarify and discuss results of review with SIG.

Prompted by a question from Kimberly Pamplin at Texas A&M in slack on 1/12/22: "I notice that the "renewal date" and "subscription to" dates cannot be edited once an order is opened. Is it intended that these dates will update automatically? If so, what triggers them? I notice for example that filling in the subscription to and from fields will then populate them for invoice line creation, but I'm not sure how they are supposed to be updated once a subscription year is paid for." 

Also from Julie Brannon at Duke: The field labels are inconsistent between orders and invoices for these dates even though data flows from the order line to the invoice line.  Is there a reason they're different, because if not, we should probably keep them consistent between apps:

Order line: Subscription from, Subscription to


























































Invoice line: Subscription start date, Subscription end date.f

Prompted by Slack discussion on 1/15/22. Request to control default values in settings.  This relates to topics #24, #32, and #36 on this page.  The ability to control default values for key fields in the Orders and Invoices apps would enable libraries to align the UI with their needs and improve the user experience.

Eg. Checking the re-encumber checkbox. The library does a lot more orders that do not encumber and this was taking time and effort when creating orders. it can also be error-prone. Not using order templates for all orders. 

Eg. In invoices, we consistently have to remember to check "Lock Total" and uncheck "check subscription overlap" for different orders.

Eg. Also need to remember to adjust "Export to accounting" checkbox and new Invoice line > "Release encumbrance".

When a user creates a new organization record and wants to add a new contact person or interface, the user needs to save the organization record first. In a second step the user needs to edit the organization record again, click on "add contact"  to then create and link the new contact person (or interface).

For a more fluent workflow with less clicking it would be helpful to be able to create a new contact or interface without needing to save the organization record first. 

We would like to have a way of identifying Titles that represent material that will be sent for binding at a given point in the year–for example, in Receiving if there were a check box at the Receiving Title Record level for To be Bound or Bindery that one could then Filter on. We now include information in the Receiving Note that indicates that the title is a Bindery title, but one cannot search on the Receiving Note in the Receiving App. (I suppose we could use a Tag, but ...) It would be better if what indicates that the Title is a Bindery Title could be seen and filtered on from both the POL and Receiving Title record. ... Something more like the Rush or ??

I have a monthly magazine that I receive and at a certain point of the year when I have all issues for the year they will be sent to the bindery.

What we plan to bind is revisited over time as the budget fluctuates. Some titles may no longer be bound to say money. Understanding what is being bound in orders in helpful for making purchase decisions. The information may also change over time so ideally these are editable at any stage of the orders lifecycle.

Users that actually carry out the binding need this information in the receiving area to gather materials that need to be bound. Users need to access receiving to identify what needs to be bound. They also need information about how to bind and when (how long to retain issues before binding, how many issues to bind in a volume, whether to bind or discard etc.).

Need to know a little more about how the user finds what needs to be bound and what historical information they need about this activity in receiving.

The Finance > Fund displays a currency value which isn't editable during fund creation and is set to the primary currency set in Settings > Tenant > Language and localisation.  Do any institutions need to have some funds desingated as a different currency than the tenant?  I'm thinking through how to handle funds for Duke's campus in China and they would likely prefer to set up their funds with ¥/CNY/yuan as the basis rather than $USD.

Update 8/17/22: Duke's campus in China will operate using their own instance of FOLIO, so this question is no longer relevant for Duke.

In invoices when you access an invoice line to review or edit and close out of the invoice line, it will bounce you back to the top of the invoice.

PLEASE ADD MORE INFORMATION AND INCLUDE YOUR NAME SO WE KNOW WHO TO ASK FOR DETAILS. THX!

The only way to remove Receiving titles is to delete the POL. With Package POLs you may need to clean up the receiving titles but not want to remove the POL.

Titles can even be linked in error and there is no way to correct that without deleting the entire POL.

There are circumstances where we want to keep the receiving record and some when the user does not want to keep it.

May have originally ordered a specific version from Amazon as a rush. Circumstances change but user wants to keep the order history so it can be communicated to the requester. In this case the Receiving title would need to be removed and the more relevant instance connected.

Prior to the end of our fiscal year, we closed all paid POs, so that they wouldn't re-encumber on rollover. Now we are receiving the pieces. For our monographs, this is working fine. The POL Receiving workflow was set to "Synchronized order and receipt quantity" and when the item is received, the POL Receipt Status does get updated to "Fully Received" and the PO remains closed. But for some individual series volume orders (which are one-time orders), the orders staff coded them as "Independent order and receipt quantity." Now staff are creating the piece(s) to be received and receiving it (them). This is creating two problems: 1.--the Receipt Status becomes "Partially Received" but there is nothing else to be received. 2.--the PO reopens (ack, ack, ack)! We can go to the POL, edit and change the status to "Fully Received" and this will close the PO again, but we would prefer to have the PO remain in a closed state.

Dennis suggested on Slack: It’s the change in status that triggers the PO workflow status to change. Perhaps the receipt status should not be updated  when receiving pieces against a closed order. OR the only update made should be to “Fully received” which would close the order if it wasn’t already closed. We like the second. We are using the "Awaiting Receipt" Status to track items to be received, so we wouldn't want to leave the POL in an Awaiting Receipt status.

Requirement: The PO does not reopen when receipt continues against a closed PO. This was found in Lotus. We believe it is the Adding and receiving of a new piece after order was closed that confuses the system and changes the receipt status and opens the PO.

We love the new hidden fields options in Settings > Orders > Order templates.  We'd like to hide tags and wondered why the PO Tags and POL Tags and aren't "hideable"? Could we add that functionality in the future?

Note: The tags functionality can be hidden completely across all of FOLIO if it is not needed in any application.

Desire the ability to disable tags in the order and order line such that users are not able to apply them to orders. Tags are currently difficult to manage and we would like to prevent users from making a mess now that could be difficult to clean up in the future.

Question: Are other libraries interested in hiding tags from the orders interface but not other applications?

Create a feature for allowing users to hide tags from orders and order lines. It would be logical to incorporate this into the hidden fields functionality of the order template.

We're wondering why records display in the Receiving app for orders that are created with a Receipt status = "Receipt not required"?  We're not seeing anything in the receiving app record to indicate that the order is a "Receipt not required" order, so they wouldn't know from the Receiving app that this order was set to "Receipt not required."

Use cases for packages:

• We also use packages for some print "packages," but in those cases we do link the inventory records to the package.
• Regarding packages, Mich State has asked for the linked POLS to display within the package.  We don't create inventory records for most electronic resources.
• Our Package POLs are what we use for Print Approval plans and others in the 5C are for Gifts …. so not just for electronic resources

When approving invoices if the description is long I need to scroll right to view funds.  Far better would be to move the fund next to the POL number or allow for customization of displays.

The description is not something we want to completely remove. However, it can be unnecessarily long and could be truncated or wrapped at 30-50 characters. (group seems to favor truncation)

Allowing users to adjust the order of the columns would be another desirable solution if it persists at least for a session. Ie. it is persisted as you move from one invoice to the next.

Other Fields users are often scrolling to see: Total price, PO status.

To have a quick overview of frequently needed information and to avoid of "jumping" between multiple apps, it is desired to have additional acquisition data displayed in the "acquisition" accordion of the item record. Requested are:

• Cost
• Acquisition method
• Organization code (extension by supplier name and linking to the respective data record)
• Fund

Use case:

User looses item (Ie. a physical item) and needs to know how much they will need to pay for it. Ideally this cost data would be an accurate cost for the item from the invoice app
NDA's generally only apply to the cost of electronic packages so displaying this information would not be possible but for physical items it is not a problem
There are special funds that have restrictions that could complicate replacing the material. Helpful to show but not necessary to have it appear there.
Users in inventory may edit this cost field manually when an accurate cost is not available in acquisitions. (Talk to metadata)

• Cost could be used to communicate a replacement fee to the patron for a lost item
• In some cases there was a flat fee for replacing items. It was also possible to input a specific cost for replacement based on what was actually paid (invoice cost)
  • Not all things have related invoices. They might have been migrated in 100 years ago or they might be gifts and there is no invoice record.
  • Replacement fee does not necessarily directly related to the material type. There could be a large gap between saxophone and cowbell but they are both musical instruments.
  • When there is no cost and the item is Older staff will check value on amazon to verify the current price and determine the replacement fee.
• Circulation staff is not always able to spend time verifying prices, so it is helpful to have SOME KIND OF PRICE in the system, even if it is not exactly current or based on the estimated cost not the invoice cost
• When there are multiple items users in some systems will manually adjust the per item cost

Could there be a third option, Error or Failed, for when it truly failed; Uploaded for when it successfully uploaded to a server; and then something (Batched ??) for when a Batch file was created that is available for download/export but not also uploaded anywhere.

Seeing Error in Voucher export details on Invoices is especially confusing.

Are there any plans to make the HRID of the linked inventory entity searchable? The POL should be able to easily access this via the UUID link. If the POL is linked to an instance, the search for the instance HRID would be possible automatically. If you also link the Holdings with the POL, you can also search for Holdings-HRID.

Use selects index and executes a search for the POL based on either Instance HIRD or Holdings HRID. In the case of a package POL there might be multiple HRIDs that would return the POL.

Lehigh would be interested in a functionality that adds a Reporting Code (similar to Method of Acquisition) that helps track non-Acq. related data points

(eg. "DEIA Shelf Project")

This should be report-able via LDP. And uses vocabulary that we can edit.

There is an ask from the reporting group to identify things that are bough for specific projects. These projects span multiple projects. The amounts need to be as accurate as possible to satisfy auditing requirements.
It is the acquisitions staff that enter the code. Generally it is the ordering librarian that is responsible for attributing the reporting code.
For institutions that rely on this field, the field would ideally be a required field.

Questions:

1. Would these need to be applied to Orders AND Invoices? Any other acq records? Yes, this value should be added to the order and then carry over to the invoice(s)
2. Would this need to be a multi-select. Ie. have the ability to apply more than one Reporting code to a given record. Yes, there could be varying levels of specificity for codes.
3. Would codes potentially need to be deprecated over time? Should each code have a status and only allow users to apply active codes to records? Yes, there are one-time projects that last short periods of time. For auditing purposes we need to keep these values around but users would no longer be applying them to new orders/invoices.

Note: Even though this code is identified at point of order there could be reporting benefits to having it be inherited by invoice AND transactions (Encumbrance, payment, credit).

Aug.15, 2023

Aug.18, 2023

Organization interface types are currently hardcoded. Universita Degli Studi Di Modena E Reggio Emilia has suggested that we add a new type for "Holdings".

Are there other institutions that would like to see more values added to the list of interface types? Should this be enhanced such that users can added new types as controlled vocabularies in settings?

Initial discussion didn't reveal any additional type that would be desired. Could you provide a little more information about how you would use the "Holdings" type and why you would want to use any of the other types for this purpose. The simplest approach might be just adding this additional type.

VZG: We would like to add the type "metadata" or have the list a configurable list. Dennis Bridges

Create Inventory drop down does not have "Item" as a choice.  This is problematic when ordering replacements or intentional duplicates.  There is no way to only add an item to an existing Holding & Instance.  Also, we would like to discuss being able to add a temporary location in the order for an item that is created.  This would help us to differentiate items that need to be marked as non-requestable prior to receiving in a local workflow.  We are interested to know if this would be helpful to other libraries and if this would be added value to FOLIO.

Temporary location: Library has system where faculty recommend a purchase and as soon as that comes in the item can be requested (Or fill a title request). Ideally they are able to prevent this from happening.

At the moment there are just some fields from Holdings and Item level in the piece information.

1. It would be very useful to have more fields from Holdings and Item level in the piece information so that we do not have to go to the Inventory App to fill out the other fields during the receiving process. This would save us a lot of time.

  2. If the fields on Holdings and Item level in the Inventory App are populated afterwards, it should be also possible that these information are also shown in the fields in the piece information.

Some issues: how complicated do we want the UX to be?

What happens if there is conflict between the piece data and the item data?

What about when call number is managed in the holdings record? Some libraries do not want to have the call number controlled or entered at the piece level.

One-Time Orders of Multi-Volume Sets are problematic in FOLIO currently [Orchid]. Multi-Vol sets come in various flavors and with different scenarios:

(1) It is known at the outset that it is a multi-volume set. There is a single price, but 2+ items that are sold as a single (1) unit. In this case one can choose to either (a) use the Receiving Workflow option of Independent Order and Receipt Quantity and keep the Cost Quantity physical & Location Quantity physical as 1, OR, (b) divide the vendor's unit price by the number of expected items and enter it as the Physical Unit Price and set the Cost Quantity physical & Location Quantity physical to the expected items number so that the total for the Estimated price = the vendor's unit price. And then Open the Order. If one goes with option (a) then after receiving all pieces, one has to remember to return to the POL and change the Receipt Status to Fully Received otherwise the Order will not Close after also being Paid. In the case of option (b), the Order will Close automatically on its own after the last piece is received and the invoice paid, and all the items are created at the time of opening the order [so if needed one can place holds on all of them at that time] BUT the single unit cost is divided across them.

(2) It is NOT known at the outset that it is a multi-volume set, there is a single price, the vendor indicates a single unit for sale, but in fact there are 2+ items. Assuming it is undesirable to UNopen the Order again--otherwise one could could open it again & handle like described in (1)--but if unopening again is not desirable then one can either (a) use the Receiving App to receive one of the volumes so that it is linked up with the POL and Inventory–adding info in the Piece Comment field to show on the Holdings record and Notes variously–besides then in Inventory creating the additional Items directly, on the same Holdings record with the Comment, and adding Notes to the Item etc. ... OR (b) edit the POLs Physical Unit Price to X# so that when one then creates additional Expected Pieces in the Receiving App on the Receiving record, which then triggers the Cost Quantity physical & Location Quantity physical to increase one ends up with the orginal Estimated price = the vendor's unit price again. Basically implementing (1b) above after opening with the same +/- (- = the single unit cost is divided across the items). As to (2a) the issues are: additional Items are not linked to the POL via Receiving App Pieces and do not show in the Receiving Record, etc. & the Receiving Note may be missed, which may indicate that the Items are Requested, so that only the one initial Item has a hold and not the whole set.

(3) It is NOT known at the outset that it is a multi-volume set (there is a single price, the vendor indicates a single unit for sale, but in fact there are 2+ items) AND the POL has already been Fully Paid (as a single unit re: cost & quantity). At this point--as far as I can tell--while one is still able to edit the POLs Physical Unit Price, one is NO longer able to create additional Expected Pieces in the Receiving App on the Receiving record. So at this point then the options become (a) to handle like (2a), OR, (b) to Cancel the Invoice, then proceed according to (2b), and then re-entering etc the Invoice. Now however is not only the single unit cost divided across the items, but also (a) one has to tweak the invoice number to make it unique from its first-now cancelled version AND the manual entry of the invoice pulls in the now Cost Quantity physical which is greater than 1 [this may also happen for (1) and (2) depending on when the invoice is entered or EDIed into FOLIO and linked up to the POL].

What would be great [and I think take care of all of the above outlined scenarios] is re: One-Time Orders set to Receiving Workflow: Synchronized Order and Receipt Quantity [and actually generally too] if (a) the Cost Quantity physical and Location Quantity physical were not tied to each other. That is, that they did not have to match. And (b) for the Receiving Expected Piece quantity not to be tied back to the Cost Quantity physical but only tied to the Location Quantity physical. And (c) for POL Receiving Workflow: Synchronized Order and Receipt Quantity, it NOT be the creation/adding of Expected Pieces in Receiving that changes the quantity of the POL Location Quantity physical, but rather the other way around. That is, one would have to be able to edit the number of the POL Location Quantity physical and that then would change/add how many Expected Pieces there would be in Receiving. & The POL Receipt Status would have to be tied to the Location Quantity physical and not to the Cost Quantity physical.

Disassociate cost quantity from location quantity?  

How do others handle this?  

Skidmore: if the invoice as set, it is received as an item and cataloged individually.  

Continue conversation 

Kimberly Smith

MTSU

Dennis Bridges to create a feature for exposing a setting in the settings area that allows a user to change the rounding behavior of acquisitions applications from Banker's rounding to rounding to round up for values of half a penny and above and round down for values below half a penny.

UINV-560 - Getting issue details... STATUS

Linked Agreement line is currently showing package name. However users would like it to show agreement line description. AND if agreement line is linked to eResource ideally it would show the name of that resource (Which comes from eHoldings app).

In each row FOLIO could show Package name AND a separate column for agreement line description. the Agreement line description would then be hyperlinked to the agreement line. Currently the Agreement Name is hyperlinked to the agreement line.

Need Jira created for UI change. Could be a dependency on  UIEH-1401 - Getting issue details... STATUS  in showing the agreement line description

Currently prefix and suffix are Alphanumeric only so there is no way to add these manual if desired.

User don't actually want the characters added to the backend but rather ONLY displayed in the UI to help users read these numbers. Consistency would be helpful for readability as well. Meaning the same approach should be used in the view header and the POL number etc. so PO number looks consistent everywhere.

Need to create Jira for UI updates

Move holding/item data in Inventory should update POL-Instance connection accordingly

Move of holdings/items from one instance to another won't transfer the POL information from the origin to the target instance.

Exisiting JIRAs: 

• Data corruption. When holding/item data are moved in Inventory, then the connected Order lines are not updated accordingly (from 2021)
• Theme: Ability to maintain relationships between other apps when holdings/items are moved (from 2019)

Workaround: initiate the move from the order rather than the inventory record for any inventory records that have related acq data.

But:  Initiating the transfer in the Orders app won't work in all scenarios, e.g. when the move of holdings is triggered in an external source and not from within FOLIO.

That will most likely apply in other libraries as well, in case they let their Inventory be controlled from an external system like a union catalog.

Is it possible to set "Display on Holding" to always active somewhere in the app settings = make it configurable in settings?

Alternative: Would it be possible to check or uncheck the checkbox for "Display" in the process of receiving? Otherweise users need to edit the piece always as a separate step.

In the Orders app when creating a POL, a selector can be added in a free text field. 

For a user it would be helpful to choose one or mutliple selectors form a multi-select list. This select list should be configurable in settings.

Thereby, the input would be standardized which would enable precise searching and filtering for orders that are assigned to specific selectors.

Be able to define selectors in list in settings

Must be contributed to DI to keep field from breaking

Connect to User app, with added field for filtering selectors

link to users app for getting list

Aaron Neslin create Jira

As a user I am creating and editing an invoice line for a POL in invoices app. On the POL I have added a discount. On the invoice that I receive from my vendor the discount has increased and needs adjustment on the invoice line in FOLIO. Currently, there is no way to adjust the discount  amount on the invoice line, only the the total amount can be adjusted accordingly. For submission to a third party system the discount amount should be editable on the invoice line. 

Requirement: Display the discount amount that has been added on the POL on the invoice line. Make the discount amount editable on the invoice line.

Breaking up the discount and additional cost into adjustments would risk counting these twice unless the total cost is managed correctly when the values are parsed. 

When we withdraw items, we have been suppressing and marking instances for deletion, thinking that someday we will be able to delete instances.  When an instance has a linked order, we've been suppressing the instance only.  We'd like to ability to unlink the order from the instance, so that the instance can be deleted, but we'd like to retain the order details in the order record.  Is this possible??

Use case:

Cleaning up inventory to improve the search experience of the users there. However, wanting to retain the order and invoice information to understanding what was paid for that thing etc. At least for audit period (7 years) but possibly longer to inform decision making.

Lisa Smith

Michigan State

Sara Colglazier

MH/5C

Need to ensure that it is possible for the order application to display and manage orders if the instance they are linked to is no longer available. 

Create feature for maintaining order <> inventory references when deleting instances and related Holdings and Items.

NOTE: the authorities app allows users to delete authorities and covert data in MARC files to permanent data when link is removed. This might inform approach used here. 

We've needed to pull invoice information for reporting for our Special Collections, which uses multiple fund codes.  We had to do this fund by fund.  It would have been more efficient if we had the option to select multiple funds for filtering.  Also, the results limit to 1000 records.  Can this amount be raised?  It's not enough for larger reports, which we need to do from time to time.  Our workaround is to break up the exports by month (or sometime biweekly) instead of fiscal year.

Expected filter behavior: Allow user to select one or more Funds in filter dropdown. Show any invoices with one or more of the selected Funds. This will make the filter more consistent with Order line filter

Unclear what a more appropriate result limit would be.

Lisa Smith

Michigan State

We'd like the ability to create and use invoice templates, similar to order templates.

Use case:

• Speed the creation of invoices for specific vendors that are very commonly used for the purchase of material.
• Not need to clutter the open invoice list with "Template invoices" that can be duplicated
• Reduce the amount of user error in creating invoices for specific situations or Vendors

Lisa Smith

Michigan State

Mutirua, Katriena <kmmutirua@nust.na>

NUST

Kristin Martin

Chicago

In orders app, when linking a POL to an inventory instance, all product IDs should be transferred - exactly as it happens when a users changes the "Change instance connection" function.

Current behaviour: If you link a POL to an Inventory instance (via title look-up), only a few product IDs are transferred: usually ISBN, ISSN and ZDB-ID. Problem: It is difficult to search in the Orders and Inventory apps if you do not know 100% which IDs are searchable.

On the other hand, when a users changes the instance connection, all IDs seem to be transferred. Requirement: Functionality around the two actions should be aligned.

Question: If there are several ISBNs or ISSNs, which ones are transferred (random, last one ...)?

In the orders app, there is fairly strict ISBN validation. Vendors, when supplying preliminary order data (or even full cataloging) often don't meet the validation standards. This has become a problem for us in particular with multiple records rejected when loading a file of orders because the ISBNs don't meet validation. Some examples:

• Qualifiers placed in the 020 $a like (ebooks)
• Multiple ISBNs all palced in the same 020 $a
• Truly invalid ISBNs where the check digit is wrong

We'd rather get these records loaded, with the incorrectly formatted or invalid ISBNs - that's the data the vendor provided. Instead, we have to create routines to clean up the ISBNs or remove them altogether. Is there a reason for why ISBN validation is so strict in Orders? Inventory doesn't seem to care. Can we relax ISBN validation rules so that these types of issues can be accepted?

Sara Colglazier - additional identifiers can cause problems as well

According to MM, there is no validation in inventory

Order data is provisional-does not need to be source of truth

Susanne Gill - it's easier to get the correct order with the correct isbn

Receiving App:

Inconsistency in delete holdings behavior

Can the delete holdings behavior happen in both places?

Kimberly Smith

(MTSU)

Dennis Bridges in snapshot, it appears that the modal appears following the steps that Molly presented above. If instead you go to the Actions menu the Receive (next to Expected) while in the receiving app record, scroll to the right and change the location on the expected piece, the modal does not appear to ask if the user would like to keep or delete the empty holdings. The behavior is different in Quick Receive than in the receiving screen that appears navigating through the Actions menu.  I also left this note on the JIRA

Organisations app and modal:

always set "active" as default filter

When opening the Organization App, the checkbox for "Active" is not checked and the filter isn't applied. This also applies to the the search window, when selecting an organization for linking e.g. to an agreement. 

It would ease creation of reocrds if organization records could be duplicated or cloned. Similar functionality is available in Agreements/Licenses or other apps.

It would be very practical to be able to duplicate organizations e.g. in the event of takeovers or mergers. A current example would be De Gruyter and Brill, which will merge in the long term. In this case, users would probably create a new organization with a different identification code in order to keep the old orders from De Gruyter and Brill separate. 

For the organizations, it would probably be good if it were also possible to select which information should be transferred and which should not (just as with the agreements). However, it would be good if the data record could be opened first so that further information can be added and only created after saving again.  

In principle, it might also be practical if you could link/merge information from different entries in the organizations app, e.g. like it is possible for contact persons and interfaces.

The donor accordion appears above the fund distribution accordion in the POL when creating a new POL.  It would be better for the donor accordion to appear below the fund distribution so the user sees any donor linked to a fund on fund entry.

For ongoing and ongoing subscription orders, libraries want to be able to produce a report with titles, amount currently encumbered in a selected fiscal year, and amount paid during a selected fiscal year. This will help with future year projections and ensuring that all subscriptions are paid during a given fiscal year.

This type of report would need to encompass data from:

• Finance
  • Fiscal year
• Orders
  • Title
  • Order type
  • Encumbrance amount
• Invoices
  • Payment amount

Right now, this process is cumbersome because you have to go to a budget record to view unreleased encumbrances then click on POLs individually to access current information. The Orders and Invoices CSV exports can get some of the information, but not all filter criteria and data points can be included within a single app export. Libraries are seeking a more streamlined approach to subscription management.

Marie Meyer

TP-ERW BVB

We are in Nolana, but I have tested this in Quesnalia BugFest as well. 

Kimberly Pamplin & Heather McMillan (TAMU)

When there is an single match for an Orders and order lines, the order line or order record is opened.  This is a convince issue that saves clicks

When a new search is done in orders or order lines and a record is open, then close the currently open record before displaying new results 

In invoices, and Receiving as well

Many libraries use external sources to populate Inventory, e.g. via Union catalogues. In those cases, new instances, holdings and items will be generated in FOLIO Inventory as soon as a library adds an ietm to an instance in Union catalogue. For those resources, the usual PO and POL is created in FOLIO Orders, "Create Inventory" field is populated (via the drop-down) with "None", "Instance" or "Instance, Holdings". When the resource then is in receiving process, there is no way to add an accession number or barcode in FOLIO Receiving - neither via Number generator nor via manual input, as the relevant fields are deactivated when no item is created in Inventory.

Can we find a way to add a barcode, accession number and/or call number - either via using the number generator or via manual input - for ordering without item creation in Inventory? E.g. add a seeting to activate/deactivate the number fields in receiving depending on your workflows.

In this workflow the Receiving record is created first and the order does not generate the item. The items are created in the union catalog. 

Are there other use cases where libraries may want to link inventory records to an order but not have FOLIO generate those stub records in advance?

• The migration of records into FOLIO could also benefit from this. Currently it is difficult to migrate in orders and then migrate inventory data in and connect it to those orders.

We will have a demo of the process as the order of operation here will influence what approach would be possible form meeting this requirement.

Scott Stangroom

Aaron Neslin

3 Dec 2024

We would like to move all open purchase order lines from fund A to fund B with one simple function.

Background: During the year we have to do this really often, for example when the money of fund A is already expended but we still have lots of open orders on this fund A that then all need to be paid from fund B. In our current system this is possible with just a few clicks.

Marie Meyer

TP-ERW BVB

We are trying to verify a report that we have developed to report encumbrances

Lucas Moder

TP-ERW BVB

Lucas Moder

TP-ERW BVB