In light of the recent conversation about development discussions happening on LP, I am going to move a conversation happening there to this list.
Currently, we are working on the functionality to transfer funds between accounts on both an individual fund basis and an Org Unit basis during a year end rollover. In this process, a few questions have come up. Here is my last response with some content cut and some clarification for context. It is possible for a library to move funds around the Acq system without making the transfers at banks where the accounts reside. In most cases, where there are no currency differences, this is not important. However, if there are differences between the currencies of two funds or the currencies of funds and funding sources, then extra precautions must be taken because exchange rates could change before the funds are transferred at the bank. In this section, I am referring to a comment Bill Erickson made about being able to finalize a transaction with Acq to indicate that the funds have been moved. If anyone has any thoughts or knowledge about how libraries work with their acquisitions funds (especially when there are currency differences) please let us know how the library expects Acq to reflect the state of money within bank accounts. https://bugs.launchpad.net/evergreen/+bug/800478 ***** Here is a part of the conversation from the LP discussion: In the case where a transfer is not finalized, how should the staff indicate that it is final once the funds have been changed? Should there be new interface for unfinalized transfers. When a transfer is finalized, should the user be prompted to enter the amount in the receiving fund for each finalization, should it default to acq.exchange_rate, or should a library setting determine the default? Should the user be given the choice to use the acq.exchange_rate table? What should be done when a rollover is performed and unfinalized accounts exist? In the case of a rollover, the system should probably prompt for each unfinalized transfer to be adjusted or verified as correct. What do you think? I think the less confusing thing for a library to do, is make the transfers at the bank then update the system to match. But, if they need the freedom to explore with the funds before actually moving them around accounts, we do need a way to indicate this. I think this should be a new table. acq.potential_fund_allocation id INT funding_source INT potential_fund INT amount NUMERIC allocator INT note TEXT create_time TIMESTAMP coversion_ratio NUMERIC This will require an update to the ACQ interface. There needs to be a total value of funds allocated and a total number of potential allocations as well a combination total of these two values. This keeps actual money in the bank separate from money that may get transferred or needs to be transferred at some point. This separate table would allow for easy generation of a list of potential transfers to be finalized through whatever UI process is necessary to do that. We could use fund_amount as a NULL value to indicate that a acq.fund_allocation is in fact a potential allocation, but I do not like side effects such as that. If at a later point the functionality between potential allocations and allocations needs to diverge then tying the tables together makes it harder to provide new and separate functionality. As well, the fact that fund_amount is NULL is not easily communicated in pgpsql code when dealing with acq.fund_allocation as oppsoed to acq.potential_fund_allocation (similarly for acq.fund_allocation.fund and acq.potential_fund_allocation.potential_fund) the use of different names makes their use within the same pgpsql function distinct, and they do represent distinct things. In the end though, having a potential amount in a fund that can be spent seems dangerous because the library could spend money that no longer exists once the actual conversion is done if the currency of the fund loses value in comparison to the funding source currency. Perhaps a warning that potential funds will need to be used once they are accessed by a debiting action? That way the library can visit the bank and finalize the potential allocations into allocations. Liam
