Richard Ellis
My feedback
8 results found
-
7 votesRichard Ellis
shared this idea
·
-
103 votesRichard Ellis
supported this idea
·
An error occurred while saving the comment -
12 votes
An error occurred while saving the comment Richard Ellis
commented
Additional context to the above:
The current finance system integrations in Alma are severely limited for institutions that rely on Real Time Ordering (RTO) APIs with vendors and intend to integrate with an external finance system using API but not using 'burn down' POs. All vendors default to the 'Purchase at Vendor System' acquisition method as this doesn't trigger emails from Alma etc on approval.As it stands Alma exempts the POs containing POLs other than Purchase/Purchase no Letter from being flagged for approval. However for those institutions that intend to push PO's to a finance system over API they encounter problems of financial oversight. A number of institutions like us historically would raise PO's for the year as a lump sum with a particular vendor and supply these to the vendor, updating them throughout the year as the money is spent and run down. Based on discussions with others who have implemented a finance integration this requires additional work to provide the vendor with this PO information, match it to Alma as associated with the incoming order/invoice and allocate associated orders with the top level PO in the finance system.
The current configuration proves to be inflexible for those who wish to move away from this 'burn down' PO structure and will be required to generate a PO per received order for approval based on finance regulations at their institution. If the API trigger to push an Alma PO to the finance system is set to be the approval of the PO in Alma, the current rules will cause issues as these orders will not be checked before being pushed to the integrated finance system just automatically delivered skipping the oversight needed by finance teams.
Could we please be provided with an option to configure order approval rules POs if needed to improve these workflows for those who rely heavily on API in our workflows and to give customers alternative solutions other than the out of the box finance system integration reliant on file exports and SFTP servers. The alternative is to request API changes from vendors so every order is listed as Purchase No Letter to trigger the approval rules and to stop order notifications going to the vendor on approval of the PO. This comes with risks as institutions aren't aware of vendor API issues when they occur until a problem becomes apparent in the received data, meaning giving us control via an Alma configuration change is a more sensible approach.
Richard Ellis
shared this idea
·
-
3 votes
An error occurred while saving the comment Richard Ellis
commented
Hi Stacey,
We have disabled it in the user facing forms in Primo but there is still the problem of non-fulfilled requests in Alma. If a request is raised and the book never returned say, the request remains open forever and staff have to trudge through the list of open, non-system expired requests to manually close them. It just produces additional burden on staff. We migrated to Alma from Symphony which did have a feature where requests could be set to auto-close after a set period of time so we have noticed the absence of such functionality since going live.Richard Ellis
shared this idea
·
-
35 votesRichard Ellis
supported this idea
·
-
59 votes
An error occurred while saving the comment Richard Ellis
commented
This would be a really useful addition. At the moment staff cannot easily identify when items have been requested for renewal. Could items with this status be added to the Borrowing Requests area of the Tasks widget to highlight these items need attention? Otherwise they are easily overlooked.
Richard Ellis
supported this idea
·
-
3 votesRichard Ellis
shared this idea
·
-
110 votesRichard Ellis
supported this idea
·
This feature should really be added as an option to the User Registration Terms of Use options. Although we have been provided with the option to apply a User Renewal Period in this configuration area, providing an option for User Purge period that works in a similar way would solve this issue?
Say you have set the TOUs to add an additional 12 months to the expiration date at renewal for a user group , you could set a similar rule for Purge Date to be x number of months from renewal date in accordance with your retention policies. This allows flexibility of applying different rules based on user group or other criteria in the terms of use being applied rather than one single logically calculated rule being applied to all user groups.