[OPEN-ILS-DEV] Changes to funds and allocating money in Acquisitions (LP800478)

[Bill Erickson]

Question to Evergreen[st]ers in general... Does anyone out there use the
currency conversion capabilities of Evergreen for Acquisitions, as opposed
to converting money externally and simply entering the amounts?  If so,
what's your work flow?  At what stage in the process do you convert the
real money and what do you do when the converted amounts don't match the
provisionally converted amounts within Evergreen?

-b



On Wed, Mar 5, 2014 at 11:19 AM, Liam Whalen
<liam.whalen at bc.libraries.coop>wrote:

> 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
>



-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: berick at esilibrary.com
| web: http://esilibrary.com
| Equinox Software, Inc. / The Open Source Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140306/5fc24ee4/attachment.htm>