Re: [Koha] report generation-Till Reconciliation for each branchlibraries
Salvete!
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At present, the branch where the transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch? I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist. I know that many people were turned off by Nomarc getting removed without warning from the code. I would submit that it ought to be an option again in the next release, much as I hate the thought of folks not cataloguing in MARC. I think it's quite possible to poll folks and figure out which reports are used most frequently and just have those included out of the box. There is some of this done already, I realise, and I also know that folks are working on improving reports. Is it possible in future to send out a note that the developers are going to comment a feature out or remove it entirely when that code isn't going to be reworked or included? Code changes and bugs need fixing, but one of the most attractive things about Koha to me was that the product was tailored to match the community's needs, and that generally once a feature was added, it wouldn't go away until just about everyone agreed that it was deprecated. It was an ILS that wasn't like other ILSs. I'm really starting to feel like the usability and innovation present in 2.x is taking a back seat to an interface that is increasingly resembling Horizon. Y Gwir yn Erbyn y Byd, Brooke
Salvete!
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At present, the branch where the transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch? I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist. I know that many people were turned off by Nomarc getting removed without warning from the code. I would submit that it ought to be an option again in the next release, much as I hate the thought of folks not cataloguing in MARC. I think it's quite possible to poll folks and figure out which reports are used most frequently and just have those included out of the box. There is some of this done already, I realise, and I also know that folks are working on improving reports. I'm curious if you also propose that the people responding to that
On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org> wrote: poll fund the development in line with what their requirements are. One of the challenges we have in this community is that us developers have to develop things in line with what the libraries that are paying us ask us to do.
Is it possible in future to send out a note that the developers are going to comment a feature out or remove it entirely when that code isn't going to be reworked or included? Code changes and bugs need fixing, but one of the most attractive things about Koha to me was that the product was tailored to match the community's needs, and that generally once a feature was added, it wouldn't go away until just about everyone agreed that it was deprecated. It was an ILS that wasn't like other ILSs. I'm really starting to feel like the usability and innovation present in 2.x is taking a back seat to an interface that is increasingly resembling Horizon. Well, there's nothing preventing you from continuing to use 2.x if you feel that way.
The reasons behind taking out that report WERE WIDELY DISCUSSED on koha-devel, and ultimately the decision to remove it was made by me, the RM for 3.0, primarily because it represented a serious security and load vulnerability in 3.0, and because it didn't accurately represent things for most of the libraries running Koha. Based on usability testing and feedback from the users that I've seen upgrade from 2.2 to 3.0, I'm hearing nothing but praise for the improvements in interface and workflow, so I'm puzzled to hear that you aren't happy with it. Could you provide some specific examples of interface paradigms that you liked in 2.2 that aren't present or have changed in a bad way in 3.0? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi, BWS Johnson a écrit :
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch? I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist. I know that many people were turned off by Nomarc getting removed without warning from the code. Please, if anyone here is in this case, step forward and say so. I would submit that it ought to be an option again in the next release, much as I hate the thought of folks not cataloguing in MARC. I think it's quite possible to poll folks and figure out which reports are used most frequently and just have those included out of the box. There is some of this done already, I realise, and I also know that folks are working on improving reports. Is it possible in future to send out a note that the developers are going to comment a feature out or remove it entirely when that code isn't going to be reworked or included? For what it's worth,RFCs are there in that aim. They are public, they are on the wiki.koha.org And anyone can comment on those (just need a user/password.). Is that not what your ask for ? Code changes and bugs need fixing, but one of the most attractive things about Koha to me was that the product was tailored to match the community's needs, and that generally once a feature was added, it wouldn't go away until just about everyone agreed that it was deprecated. It was an ILS that wasn't like other ILSs. I'm really starting to feel like the usability and innovation present in 2.x is taking a back seat to an interface that is increasingly resembling Horizon. mmm neverending discussion. But I donot agree in many aspects. Is there nothing yet to improve ? I donot think so. Is there some features gaps ? yes.
But this is the main reason why I am involved. -- Henri-Damien LAURENT
On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org>wrote:
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At
Salvete! present, the branch where the
transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch?
Yes, in particular since the current implementation is neither. A Koha user with a single branch still doesn't want their system to become unreliable just because they add a second branch. But fines in Koha has enough problematic design flaws that it requires overhaul even for single branch setups. The current model is not reliable, atomic, maintainable, extensible, documented, secure or auditable. The overhaul offers most if not all those characteristics.
I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist.
I'd rather not provide institutions of *any* size with functions that are erroneous, unreliable or fundamentally unsound. I am against preserving features that happen to work only in small or single branch setups (unless they are wrapped in the SingleBranch syspref). As a different example, inefficient queries that "work fine" on 4,000 records and crash systems on 100,000 are not the kind of well-designed features worth preserving. Leaving those kinds of landmines for users to step on makes Koha (or Unicorn, or any product) look amateurish. --Joe Atzberger
On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org> wrote:
Salvete!
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At present, the branch where the transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch?
Yes, in particular since the current implementation is neither. A Koha user with a single branch still doesn't want their system to become unreliable just because they add a second branch.
But fines in Koha has enough problematic design flaws that it requires overhaul even for single branch setups. The current model is not reliable, atomic, maintainable, extensible, documented, secure or auditable. The overhaul offers most if not all those characteristics.
I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist.
I'd rather not provide institutions of any size with functions that are erroneous, unreliable or fundamentally unsound. I am against preserving features that happen to work only in small or single branch setups (unless they are wrapped in the SingleBranch syspref). As a different example, inefficient queries that "work fine" on 4,000 records and crash systems on 100,000 are not the kind of well-designed features worth preserving. Leaving those kinds of landmines for users to step on makes Koha (or Unicorn, or any product) look amateurish.
Wow, how defensive we developers are. I think its worth acknowledging that Brooke has made some valid points. That we do need to be careful that we make Koha usable for as many people as possible. And while Joshua is right we mostly have to code what the libraries are asking for we should be careful we don't undo what other libraries have already paid for also. If something is broke, lets fix it. Lets not just throw features out. Chris
On Wed, Dec 10, 2008 at 2:32 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
Wow, how defensive we developers are. I don't think this is defensive, it's pragmatic. Brooke is making valid points to be sure--this project isn't perfect--but it's very important to understand that there are reasons for the problems we face. In particular, we have a real dearth of development resources relative to the number of Koha users.
I think its worth acknowledging that Brooke has made some valid points. That we do need to be careful that we make Koha usable for as many people as possible. And while Joshua is right we mostly have to code what the libraries are asking for we should be careful we don't undo what other libraries have already paid for also.
If something is broke, lets fix it. Lets not just throw features out. I completely agree, we should strive to fix broken code, but sometimes we're forced to throw out completely broken stuff and start over. Just to be clear, if a report or feature causes the whole of Koha to lock up if you've got more than 10,000 records, any RM worth their salt will need to either fix it or remove it. If we had a swell of volunteer developers doing free work on Koha in their spare time I'd expect this kind of thing would get worked out on its own, but the fact is, more than 90% of Koha development is done by developers who work for specific customers and we're very strapped for resources, and we have to focus on coding stuff that customers that are paying our bills.
I don't think any developer who's looked at the code will argue that the NOMARC stuff could have been preserved in 3.0 without a serious investment in development time (hundreds of hours). As the RM, I certainly did my best to make 3.0 as backwards compatible as possible, but the fact is, I had to draw the line somewhere. As it is, I was heavily criticized for how long it took for 3.0 to get out the door. I'd be very interested in hearing any suggestions from users like Brooke for how we could address this resource problem and make sure that we have enough resources in the community to make sure that the needs of libraries that can't afford to pay for development are still met. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Thu, Dec 11, 2008 at 10:00 AM, Joshua Ferraro <jmf@liblime.com> wrote:
On Wed, Dec 10, 2008 at 2:32 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
Wow, how defensive we developers are. I don't think this is defensive, it's pragmatic. Brooke is making valid points to be sure--this project isn't perfect--but it's very important to understand that there are reasons for the problems we face. In particular, we have a real dearth of development resources relative to the number of Koha users.
Valid point. I meant the tone not the content, I should have been more explicit. Anyway, Ive said my bit on this. So I'm going to leave it alone now Chris
I don't know if there's a current official "head count" for Koha libraries, but according to librarytechnology.org, the number is just shy of 500, including 399 LibLime libraries (surely not!) In the past, I've suggested privately to LibLime that they take a page from several models that already exist for facilitating cooperative sponsorship of projects. Why not use http://www.fundable.com, http://www.dropcash.com, or http://www.chipin.com? Or develop a comparable utility in-house? Given the number of Koha libraries out there, wouldn't such an approach have the potential to accelerate the evolution of the software? With a transparent price tag for any particular enhancement, it would soon become very clear which projects are most highly desired as they would be funded the quickest. Cheers, Cab Vinton, Director Sanbornton Public Library Sanbornton, NH On Wed, Dec 10, 2008 at 4:00 PM, Joshua Ferraro <jmf@liblime.com> wrote:
I'd be very interested in hearing any suggestions from users like Brooke for how we could address this resource problem and make sure that we have enough resources in the community to make sure that the needs of libraries that can't afford to pay for development are still met.
Cheers,
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
I should clarify that the librarytechnology.org figures for the # of Koha libraries include a large number of branch libraries within larger systems, so the true figure is no doubt much lower. Cab Vinton, Director Sanbornton Public Library Sanbornton, NH
I don't know if there's a current official "head count" for Koha libraries, but according to librarytechnology.org, the number is just shy of 500, including 399 LibLime libraries (surely not!) I guess it depends on how you run the query, the way I did it I get 572 total, of which, 399 are LibLime customers. the 399 number is accurate in the sense that all of our customers that have publicly selected LibLime or gone live on Koha are in Marshall's database. We make a diligent effort to keep his database up to date, but I know for certain that many many Koha libraries 'in the wild' aren't represented
In the past, I've suggested privately to LibLime that they take a page from several models that already exist for facilitating cooperative sponsorship of projects.
Why not use http://www.fundable.com, http://www.dropcash.com, or http://www.chipin.com? Or develop a comparable utility in-house?
Given the number of Koha libraries out there, wouldn't such an approach have the potential to accelerate the evolution of the software? With a transparent price tag for any particular enhancement, it would soon become very clear which projects are most highly desired as they would be funded the quickest. In general I like this idea, and LibLime has implemented a small-scale experiment we call the LibLime Development Exchange that attempts to
On Wed, Dec 10, 2008 at 4:38 PM, Cab Vinton <bibliwho@gmail.com> wrote: there. So hint hint, if you're a Koha library, and you haven't registered in libwebcats, please do so: http://librarytechnology.org/libwebcats/ provide this kind of transparency to our customers. However, one problem with doing this as the Koha project, is that price tags for enhancements aren't generally considered transparent by the companies providing support on Koha. I think most of the Koha companies (correct me if I'm wrong folks) would consider unfinished specifications and quotes for those specifications to be private. If you don't understand why that tends to be the case, you likely haven't ever managed a services company :-). Another problem, and we've seen this happen on the LibLime Development Exchange, is that there is really very little overlap between what one library wants and another library wants. It's really surprising, but unfortunately true. So there is less opportunity for co-sponsorship than you might think. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
If the Development Exchange has not worked as well as hoped, perhaps it's because a critical mass was lacking? I think we would have been very interested to learn more about the project. The transparency of price quotes is above my pay grade unfortunately. But seeing as there's a ton of transparency in at least certain areas of the software development world -- guru.com, rentacoder.com, scriptlance.com, etc. -- perhaps it's not all that out of the question. Certainly, it would seem to be gibe well w/ the whole open source ethos. Just my 2c. Cab Vinton, Director Sanbornton Public Library Sanbornton, NH On Wed, Dec 10, 2008 at 4:48 PM, Joshua Ferraro <jmf@liblime.com> wrote:
In general I like this idea, and LibLime has implemented a small-scale experiment we call the LibLime Development Exchange that attempts to provide this kind of transparency to our customers.
However, one problem with doing this as the Koha project, is that price tags for enhancements aren't generally considered transparent by the companies providing support on Koha. I think most of the Koha companies (correct me if I'm wrong folks) would consider unfinished specifications and quotes for those specifications to be private. If you don't understand why that tends to be the case, you likely haven't ever managed a services company :-).
Another problem, and we've seen this happen on the LibLime Development Exchange, is that there is really very little overlap between what one library wants and another library wants. It's really surprising, but unfortunately true. So there is less opportunity for co-sponsorship than you might think.
Cheers,
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi there, We use the daily reports in our existing 2.9 install - over 3 branches and while it has a few tiny quirks we know what they are and we work around and I believe the daily til reconciliation is accurate. Chris or Mason can probably extract the code and make it available as a starting point - and I am happy to pass on the bug descriptions. cheers Jo. Chris Cormack wrote:
On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org> wrote:
Salvete!
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At present, the branch where the transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch?
Yes, in particular since the current implementation is neither. A Koha user with a single branch still doesn't want their system to become unreliable just because they add a second branch.
But fines in Koha has enough problematic design flaws that it requires overhaul even for single branch setups. The current model is not reliable, atomic, maintainable, extensible, documented, secure or auditable. The overhaul offers most if not all those characteristics.
I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist.
I'd rather not provide institutions of any size with functions that are erroneous, unreliable or fundamentally unsound. I am against preserving features that happen to work only in small or single branch setups (unless they are wrapped in the SingleBranch syspref). As a different example, inefficient queries that "work fine" on 4,000 records and crash systems on 100,000 are not the kind of well-designed features worth preserving. Leaving those kinds of landmines for users to step on makes Koha (or Unicorn, or any product) look amateurish.
Wow, how defensive we developers are.
I think its worth acknowledging that Brooke has made some valid points. That we do need to be careful that we make Koha usable for as many people as possible. And while Joshua is right we mostly have to code what the libraries are asking for we should be careful we don't undo what other libraries have already paid for also.
If something is broke, lets fix it. Lets not just throw features out.
Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Joann -- Chris and Mason are still active developers here in the community and their code is certainly the basis of fines operation, for example in C4/Accounts.pm and members/pay.pl. I don't think Chris, who has already commented in this thread, would withhold mentioning or contributing better code if he had written it for any version. That being said, I think both of them would also agree that the existing implementation is inadequate. For example pay.pl dates all the way back to 2000! Transaction types are hardcoded, so the user cannot create new ones. Unlike the issues table, the accountlines table is never purged or rotated, so performance will inevitably degrade if used over time. The accountlines data structure lacks capacity to record the operator (who received the money) and the branch (where the money is). All that (and more) needs to change. You are welcome to file bugs against any version of koha at http://bugs.koha.org. But I think we are talking about essentially the same code. --Joe Atzberger On Wed, Dec 10, 2008 at 5:23 PM, Joann Ransom <jransom@library.org.nz>wrote:
Hi there,
We use the daily reports in our existing 2.9 install - over 3 branches and while it has a few tiny quirks we know what they are and we work around and I believe the daily til reconciliation is accurate. Chris or Mason can probably extract the code and make it available as a starting point - and I am happy to pass on the bug descriptions.
cheers Jo.
Chris Cormack wrote:
On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson < mhelman@illinoisalumni.org> wrote:
Salvete!
That report has been discussed before and was purposefully commented out in 3.0 (I argue should have been deleted) becuase it is not reliable in a multi-branch situation. At present, the branch where the transaction took place is not logged, so you cannot possibly create a report to extract that information.
Developers are fairly aware of this problem and are working to totally overhaul fines data structure.
I don't mean to be abrasive here, but will that overhaul include a solution that is palatable to both single branch Libraries and multi branch?
Yes, in particular since the current implementation is neither. A Koha user with a single branch still doesn't want their system to become unreliable just because they add a second branch.
But fines in Koha has enough problematic design flaws that it requires overhaul even for single branch setups. The current model is not reliable, atomic, maintainable, extensible, documented, secure or auditable. The overhaul offers most if not all those characteristics.
I'd rather not see things tilt towards larger institutions in terms of deleting functions that used to exist.
I'd rather not provide institutions of any size with functions that are erroneous, unreliable or fundamentally unsound. I am against preserving features that happen to work only in small or single branch setups (unless they are wrapped in the SingleBranch syspref). As a different example, inefficient queries that "work fine" on 4,000 records and crash systems on 100,000 are not the kind of well-designed features worth preserving. Leaving those kinds of landmines for users to step on makes Koha (or Unicorn, or any product) look amateurish.
Wow, how defensive we developers are.
I think its worth acknowledging that Brooke has made some valid points. That we do need to be careful that we make Koha usable for as many people as possible. And while Joshua is right we mostly have to code what the libraries are asking for we should be careful we don't undo what other libraries have already paid for also.
If something is broke, lets fix it. Lets not just throw features out.
Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Thanks Joe, I am in the process of configuring a Koha 3.0 install and hadn't realised that we would lose the ability to run till reconciliation reports each day. It is a matter core to our operations and I will have to consider that if upgrading to 3.0 will mean losing functionality - hence my input. cheers Jo. Joe Atzberger wrote:
Joann --
Chris and Mason are still active developers here in the community and their code is certainly the basis of fines operation, for example in C4/Accounts.pm and members/pay.pl. I don't think Chris, who has already commented in this thread, would withhold mentioning or contributing better code if he had written it for any version.
That being said, I think both of them would also agree that the existing implementation is inadequate. For example pay.pl dates all the way back to 2000! Transaction types are hardcoded, so the user cannot create new ones. Unlike the issues table, the accountlines table is never purged or rotated, so performance will inevitably degrade if used over time. The accountlines data structure lacks capacity to record the operator (who received the money) and the branch (where the money is). All that (and more) needs to change.
You are welcome to file bugs against any version of koha at http://bugs.koha.org. But I think we are talking about essentially the same code.
--Joe Atzberger
On Wed, Dec 10, 2008 at 5:23 PM, Joann Ransom <jransom@library.org.nz <mailto:jransom@library.org.nz>> wrote:
Hi there,
We use the daily reports in our existing 2.9 install - over 3 branches and while it has a few tiny quirks we know what they are and we work around and I believe the daily til reconciliation is accurate. Chris or Mason can probably extract the code and make it available as a starting point - and I am happy to pass on the bug descriptions.
cheers Jo.
Chris Cormack wrote: > On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger <ohiocore@gmail.com <mailto:ohiocore@gmail.com>> wrote: > >> On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org <mailto:mhelman@illinoisalumni.org>> >> wrote: >> >>> Salvete! >>> >>>> That report has been discussed before and was purposefully commented out >>>> in 3.0 (I argue should have >>>> been deleted) becuase it is not reliable in a multi-branch situation. At >>>> present, the branch where the >>>> transaction took place is not logged, so you cannot possibly create a >>>> report to extract that information. >>>> >>>> Developers are fairly aware of this problem and are working to totally >>>> overhaul fines data structure. >>>> >>> I don't mean to be abrasive here, but will that overhaul include a >>> solution that is palatable to both single branch Libraries and multi branch? >>> >> Yes, in particular since the current implementation is neither. A Koha user >> with a single branch still doesn't want their system to become unreliable >> just because they add a second branch. >> >> But fines in Koha has enough problematic design flaws that it requires >> overhaul even for single branch setups. The current model is not reliable, >> atomic, maintainable, extensible, documented, secure or auditable. The >> overhaul offers most if not all those characteristics. >> >> >>> I'd rather not see things tilt towards larger institutions in terms of >>> deleting functions that used to exist. >>> >> I'd rather not provide institutions of any size with functions that are >> erroneous, unreliable or fundamentally unsound. I am against preserving >> features that happen to work only in small or single branch setups (unless >> they are wrapped in the SingleBranch syspref). As a different example, >> inefficient queries that "work fine" on 4,000 records and crash systems on >> 100,000 are not the kind of well-designed features worth preserving. >> Leaving those kinds of landmines for users to step on makes Koha (or >> Unicorn, or any product) look amateurish. >> >> > Wow, how defensive we developers are. > > I think its worth acknowledging that Brooke has made some valid > points. That we do need to be careful that we make Koha usable for as > many people as possible. And while Joshua is right we mostly have to > code what the libraries are asking for we should be careful we don't > undo what other libraries have already paid for also. > > If something is broke, lets fix it. Lets not just throw features out. > > Chris > _______________________________________________ > Koha mailing list > Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> > http://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
The only thing you will "lose" is the *current form* of the report complete with the many flaws enumerated and unenumerated. There will be a "Cash Reconciliation" report after revision... the kind that might actually survive an audit. Nobody is suggesting that the purpose of the report is useless or that it isn't important to track payments. The point is that it needs to be implemented correctly to be reliable for anyone. I've advanced the argument (and the RFC's and surrounding discussions contend) that there are technical problems with the existing implementation of fines and payment accounting. I appreciate that the *purpose* of the report is important. That's actually part of my argument, or I'd just let it go. But unless you want to argue that it is technically and logically sound, we don't really have any point of disagreement. Your impressions of its accuracy are based on limited admittedly buggy use in an older version and have not engaged the question of how it works in your case, or how it will work for any other users. --Joe On Wed, Dec 10, 2008 at 8:22 PM, Joann Ransom <jransom@library.org.nz>wrote:
Thanks Joe,
I am in the process of configuring a Koha 3.0 install and hadn't realised that we would lose the ability to run till reconciliation reports each day. It is a matter core to our operations and I will have to consider that if upgrading to 3.0 will mean losing functionality - hence my input.
cheers Jo.
Joe Atzberger wrote:
Joann --
Chris and Mason are still active developers here in the community and their code is certainly the basis of fines operation, for example in C4/Accounts.pm and members/pay.pl. I don't think Chris, who has already commented in this thread, would withhold mentioning or contributing better code if he had written it for any version.
That being said, I think both of them would also agree that the existing implementation is inadequate. For example pay.pl dates all the way back to 2000! Transaction types are hardcoded, so the user cannot create new ones. Unlike the issues table, the accountlines table is never purged or rotated, so performance will inevitably degrade if used over time. The accountlines data structure lacks capacity to record the operator (who received the money) and the branch (where the money is). All that (and more) needs to change.
You are welcome to file bugs against any version of koha at http://bugs.koha.org. But I think we are talking about essentially the same code.
--Joe Atzberger
On Wed, Dec 10, 2008 at 5:23 PM, Joann Ransom <jransom@library.org.nz <mailto:jransom@library.org.nz>> wrote:
Hi there,
We use the daily reports in our existing 2.9 install - over 3 branches and while it has a few tiny quirks we know what they are and we work around and I believe the daily til reconciliation is accurate. Chris or Mason can probably extract the code and make it available as a starting point - and I am happy to pass on the bug descriptions.
cheers Jo.
Chris Cormack wrote: > On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger <ohiocore@gmail.com <mailto:ohiocore@gmail.com>> wrote: > >> On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <mhelman@illinoisalumni.org <mailto:mhelman@illinoisalumni.org>> >> wrote: >> >>> Salvete! >>> >>>> That report has been discussed before and was purposefully commented out >>>> in 3.0 (I argue should have >>>> been deleted) becuase it is not reliable in a multi-branch situation. At >>>> present, the branch where the >>>> transaction took place is not logged, so you cannot possibly create a >>>> report to extract that information. >>>> >>>> Developers are fairly aware of this problem and are working to totally >>>> overhaul fines data structure. >>>> >>> I don't mean to be abrasive here, but will that overhaul include a >>> solution that is palatable to both single branch Libraries and multi branch? >>> >> Yes, in particular since the current implementation is neither. A Koha user >> with a single branch still doesn't want their system to become unreliable >> just because they add a second branch. >> >> But fines in Koha has enough problematic design flaws that it requires >> overhaul even for single branch setups. The current model is not reliable, >> atomic, maintainable, extensible, documented, secure or auditable. The >> overhaul offers most if not all those characteristics. >> >> >>> I'd rather not see things tilt towards larger institutions in terms of >>> deleting functions that used to exist. >>> >> I'd rather not provide institutions of any size with functions that are >> erroneous, unreliable or fundamentally unsound. I am against preserving >> features that happen to work only in small or single branch setups (unless >> they are wrapped in the SingleBranch syspref). As a different example, >> inefficient queries that "work fine" on 4,000 records and crash systems on >> 100,000 are not the kind of well-designed features worth preserving. >> Leaving those kinds of landmines for users to step on makes Koha (or >> Unicorn, or any product) look amateurish. >> >> > Wow, how defensive we developers are. > > I think its worth acknowledging that Brooke has made some valid > points. That we do need to be careful that we make Koha usable for as > many people as possible. And while Joshua is right we mostly have to > code what the libraries are asking for we should be careful we don't > undo what other libraries have already paid for also. > > If something is broke, lets fix it. Lets not just throw features out. > > Chris
participants (7)
-
BWS Johnson -
Cab Vinton -
Chris Cormack -
Henri-Damien LAURENT -
Joann Ransom -
Joe Atzberger -
Joshua Ferraro