On Wed, Dec 17, 2008 at 1:31 AM, Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
Joshua Ferraro wrote:
On Mon, Dec 15, 2008 at 10:16 PM, Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
This is the specific step that's gone - along with all of simple acquisistions
That step is still in 3.0, but the shipping costs code was very buggy so that specific field was removed ... If I recall the specific error, you could add a shipping cost, but it wouldn't be calculated in the totals on the invoice page. I believe part of the problem had to do with how the shipping costs were stored in the database, they were indistinguishable from an actual item cost IIRC.> Cheers
I think it got lost in the last version of Koha (another bit of acquisitions got removed all together).
You used to put in freight as the first thing when receiving an order, so that the amount was split amongst all the items in the order, but you don't appear to be able to do that now.
This is how acquisitions used to work...
http://katipo.co.nz/gallery/album15
I haven't seen plans to put it back, but perhaps Liblime might have a view on that.
I've yet to see a contributed version of Acquisitions that had all of these features working at the same time. 3.0 Acquisitions represents the only Acquisitions in a released version that I've seen where all the functionality is actually usable. I suspect that it works for Katipo and others because they run custom code, and/or custom templates, rather than the mainline Koha releases.
I don't recall that we did that specifically, although we did usually do custom templates for clients. We still should have some systems running simple acquisitions - however they don't work with the MARC stuff - my recollection is that once the MARC stuff came at 2.x acquisitions started to come unstuck because it had no "native" awareness of MARC. So it would work as long as you had MARC off - but not with MARC on. I don't mean to imply that Katipo or anyone else is intentionally withholding code from the community to be mean or something, but the fact remains that for whatever reason, Acquisitions works for Katipo clients like HLT ... yet I've never seen a working Katipo-written acquisitions system in any of the public releases prior to 3.0. My impression is that Katipo staff never took the time to contribute all of their code in a way that it would work for the whole community ... and some functionality remains un-contributed as code on local installations, or locked up in custom templates that we can't see.
It's really easy to figure out where the differences are if you're interested. For instance, you could run the Linux utility 'diff' recursively to compare all of the files in your Koha source tree on one of these installations ... against, say, a fresh 2.2.9 install. I suppose that at the end of the day, you can't cry over spilt milk ... all you can hope to do is learn and move forward ...
I'm guessing that with later versions it got dropped as that was too hard to reconcile as most people moved to MARC.
We have some non MARC systems still running and they use simple (and possibly even some original "normal") acquisisitions. That's a distinction I'm not familiar with, what's the difference between 'simple', 'normal' and whatever other type there is?
In any event, moving forward, I'd recommend anticipating this problem and looking for ways to ensure that everyone can run from a public release, rather than having custom code siloed on local systems. I suspect it's not only frustrating, but expensive, to have to keep playing hopscotch to get in sync with the community code every couple versions. I also suspect that's where Joann's frustration is coming from (in the other acq thread). My main point in both of threads is that: 1. Acquisitions never worked the way the documentation in that link says it did -- at least not in code in our releases or source repositories. It may have worked for HLT and other Katipo customers, but that's because the code or templates were different than publicly available ones. 2. It's not fair to say 'This is the way it used to work' and then point the finger at others, when in fact, we all know it didn't work in publicly available code in the first place. The last few RMs have done our best to fix what was there to be something that is functional. 3. A successful community process is not to write something and then walk away, code requires constant maintenance. It's not the case that one Koha shop wrote a working acquisitions system and another shop came along and broke it. Really! RMs have to make hard decisions, and they rely on what available resources the community provides them with, and if you want your stuff to continue working as is, you have to 1. Contribute it in a fully-working version, and 2. Maintain it. Cheers, Josh
Cheers R
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