On acqui-home.pl, the amounts for Ordered and Spent for parent funds to no reflect orders charged to their child funds, only orders charged to the parent fund directly. I can see some room for argument here if libraries are are sometimes charging a parent fund directly, but overall it may be more clear if ordered and spent for a parent fund showed totals for all orders charged to the parents AND its children. Total Available for the parent is also based only on orders charged to the parent directly and this is definitely misleading. Total available for a parent fund should display as total allocated to parent minus (total ordered/spent for parent plus total ordered spent for all children). These changes would bring acqui-home.pl in line with the numbers shown on aqbudgets.pl.
This is the first year we are using parent and child fund. It is a really helpful tool for us to help reconcile with the city. The problem we discovered is it don't work properly. Please take a look at the problem Andrew described. Rhonda K.
Is this perhaps a duplicate of bug 23767 ?
*** This bug has been marked as a duplicate of bug 23767 ***
Hi folks! I'm reopening this one. It was not actually a duplicate of bug 23767. 23767 was about the total at the bottom of the table on Acq Home. This is about the amount shown in each parent fund's line directly.
Following through (In reply to Andrew Fuerste-Henry from comment #4) > Hi folks! I'm reopening this one. It was not actually a duplicate of bug > 23767. > 23767 was about the total at the bottom of the table on Acq Home. This is > about the amount shown in each parent fund's line directly. Which means really this is an enhancement rather than a bug.
We set up the parent/child fund structure a couple of budget cycles ago. But when we discovered we could not depend on the parent totals accurately reflecting expenditures made to the child funds we had to abandon it. If this functionality existed it would save me from having to export data to a spreadsheet or use a calculator to make sure all my figures are correct. We would love to see this fixed.
I believe this is a duplicate of 29287 *** This bug has been marked as a duplicate of bug 29287 ***