- Koha - lists.katipo.co.nz

29 Apr '04

Hi, This is my 1st attempt at installing Koha, and I'm having some problems w/r/t the virtual servers it requires. I went thru the installation with the installer.pl, and it wrote the directives for the virtual servers in /etc/koha-httpd.conf. When I try to access the url, I get a seg fault. I've wrestled with this most of the day, and was going to post to an apache group, but thought I'd try here 1st,since anyone who's running Koha prolly has their directives written correctly. Here's my setup: Fedora Core 1-Yarrow 2.4.22-1.2179 smp kernel httpd-2.0.48 Koha-2.0.0 installed in /usr/local/ Here's the relevant lines in httpd.conf: > # Ports to listen to for Koha > # uncomment these if they aren't already in main httpd.conf > Listen 80 > Listen 8080 > > # NameVirtualHost is used by one of the optional configurations detailed > below > > NameVirtualHost *:80 > # KOHA's OPAC Configuration > <VirtualHost wccs.homelinux.org:80> > ServerAdmin tom(a)wccs.homelinux.org > DocumentRoot /usr/local/koha/opac/htdocs/ > ServerName wccs.homelinux.org > ScriptAlias /cgi-bin/koha /usr/local/koha/opac/cgi-bin/ > ErrorLog /usr/local/koha/log/opac-error_log > TransferLog /usr/local/koha/log/opac-access_log > SetEnv PERL5LIB "/usr/local/koha/intranet/modules" > SetEnv KOHA_CONF "/etc/koha.conf" > > </VirtualHost> > > NameVirtualHost *:8080 > # KOHA's INTRANET Configuration > <VirtualHost wccs.homelinux.org:8080> > ServerAdmin tom(a)wccs.homelinux.org > DocumentRoot /usr/local/koha/intranet/htdocs/ > ServerName wccs.homelinux.org > ScriptAlias /cgi-bin/koha "/usr/local/koha/intranet/cgi-bin/" > ErrorLog /usr/local/koha/log/koha-error_log > TransferLog /usr/local/koha/log/koha-access_log > SetEnv PERL5LIB "/usr/local/koha/intranet/modules" > SetEnv KOHA_CONF "/etc/koha.conf" > > </VirtualHost> > -- Tom

3 5

Re: [Koha] LC number : solution in 2.2
by COURYHOUSE＠aol.com 29 Apr '04

29 Apr '04

Paul, does this mean that when you add MARC records it automatically knows the LC number is to be there? thanks ! Ed Hi everybody, Here is the solution I propose for LC and any other callnumber : * a field has already been added in items table. It's called itemcallnumber. * this field will be "connected" to : biblio dewey OR LoC number OR manual & local classification. if connected to dewey or LoC, it will automatically be filled. So every library can have it's own callnumber system. Sounds this good ?

1 0

RE: [Koha] LC number : solution in 2.2
by Bigwood, David 28 Apr '04

28 Apr '04

It is not really so odd to have 2 different call numbers for different copies of the same item. We often have circulating and reference copies. The class and cutter numbers would stay the same but the prefix or suffix would vary. In other cases we have a map or other accoampying material that goes with a book but is housed in a seperate location. Once again the class and cutters would be the same but the pre or suffix would be different. I have also heard of cases when a work covers two topics for a library to give each copy a different class number so that folks browsing will find it in either place. I think that is less common, but it does happen. Sincerly, David Bigwood bigwood(a)lpi.usra.edu Lunar & Planetary Institute http://www.lpi.usra.edu/library/whats_new.shtml Catalgoing News http://www.catalogablog.blogspot.com -----Original Message----- From: koha-admin(a)lists.katipo.co.nz [mailto:koha-admin@lists.katipo.co.nz]On Behalf Of paul POULAIN Sent: Tuesday, April 27, 2004 3:37 PM To: koha(a)lists.katipo.co.nz Subject: [Koha] LC number : solution in 2.2 Hi everybody, .... NOTE : why put the callnumber in items & not in biblio you may ask ? it's because some libraries may have 2 differents callnumbers for 2 items of the same biblio. Sounds silly (& quite old), but exists. And you can't ask a 100 000 items library to reorganize it's shelves ;-) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org) _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

ongoing data conversion to MARC format without LCCN's
by Anthony S. 28 Apr '04

28 Apr '04

Hi, My programmatic method as well as a test (with one filled field per MARC record) allows all records to be imported unsuccessfully. Each record gives the following error message. "Error: Problem with " There must be some validating logic that I am missing out on. It would be nice if I could get some quick education about what is completely required for minimum Koha validation of record(s). Ottawa, Can. ... My notes... MarcEdit Usage instructions... Using the wizard and getting to the "mapping" dialog, please remember to use the format as described below, for example. 245$a After MarcEdit's text wizard generates files, those files need to be re-processed using the MarcMaker feature of the main MarcEdit program, which will in turn produce a newer version of files. those files look to me (i.e. Tony) to be readable by Koha directly. I haven't tried generating a valid record, though using these tools yet. The above instructions are what I learnt from the MarcEdit wizard dialogues which are only available if you have the program installed locally on Windows successfully. Regards, Tony

1 0

RE: Re: [Koha] Export MARC from Koha
by Stephen Hedges 27 Apr '04

27 Apr '04

Don't forget that Koha let's you store item data anywhere you want to -- so long as you tell Koha where to find it by setting up your MARC to Koha links. At Nelsonville, we use a 9xx tag for all this data, but you could just as easily use 876 or 37, or any other (repeatable) tag. The choice belongs to the user, and is not controlled by Koha. Stephen Hedges Nelsonville Public Library > Sunday, April 25, 2004 16:11 CDT > > Hi, Dave, > > I can see what you mean about tags 876-878. > > Most of the records I've seen here don't do > anything towards keeping acquisitions data (which > is a shame), but when they do they invariably > avoid using the holdings data tags you recommend > (from what I see, I wonder if NLC had a policy of > using them only for serials) and instead have > opted for the tag 37 (which is flexible enough to > handle the important information and the limits > of which encourage one to remember not to collude > 2 or more different editions of works) or more > frequently use a 5xx number (sometimes one not > specifically allowed) to keep the information > they want. > > As library manager for a highschool library, I > had to insist with my 'assistant' that such info > not be encoded as a general public note (in 500) > which is what someone had recommended to her > prior to my appointment (not the kind of > information we wanted highschool students to > have: 'oh, this only cost $2.50, I can afford to > lose it' problem). > > The Athena system we were using already encoded > data to an 852 (with unauthorised uses of various > subfields, including a creative $w - we couldn't > find any way to change these peculiarities) and > so we used 37 (repeating for each copy as > necessary, $n beginning with barcode to ID > specific copy) for the additional data we > wanted. > > It would perhaps be good to recommend to users to > adopt use of the 876-878 fields but still leave > open the option of 37 for others. Smaller > libraries, especially school ones, often don't > have more than one copy of many works. > > Could someone from development tell us where/how > Koha is storing that more detailed acquisitions > information and if it could be integrated into > the MARC tag structure that Dave suggests in one > of the near future releases? > > Cheers, > Steven F. Baljkas > library tech at large > Koha neophyte > Winnipeg, Manitoba, Canada > > > From: "Bigwood, David" <bigwood(a)lpi.usra.edu> > > Date: 2004/04/25 Sun PM 03:23:40 CDT > > To: <koha(a)lists.katipo.co.nz> > > Subject: RE: Re: [Koha] Export MARC from Koha > > > > Fields 876-878 are a better choice to include > acquisitions data. It includes the cost for each > copy, different copies can have been purchased at > different prices, or one could be a gift. It also > includes where it was purchased, date acquired, > item status and other subfields available for > each copy. > > > > Field 037 is repeatable but not linked to each > copy in the same manner. > > > > Sincerely, > > David Bigwood > > bigwood(a)lpi.usra.edu > > Lunar & Planetary Institute > > > http://www.lpi.usra.edu/library/whats_new.shtml > > Cataloging News > > http://www.catalogablog.blogspot.com > > > > > > -----Original Message----- > > From: koha-admin(a)lists.katipo.co.nz > > [mailto:koha-admin@lists.katipo.co.nz]On Behalf > Of Steve/Ollie/Steven F. > > Baljkas > > Sent: Friday, April 23, 2004 5:39 PM > > To: Chris Cormack; MJ Ray > > Cc: koha(a)lists.katipo.co.nz > > Subject: Re: Re: [Koha] Export MARC from Koha > > > > > > Friday, April 23, 2004 17:30 CDT > > > > Hi, Chris et al., > > > > > Hi Guys > > > > > > Theres also the budget data if using full > acquisitions. This might be > > > useful to export also. > > > > Regarding the budget information kept in full > acquisitions mode, I have to confess I haven't > looked at that function, but there is a MARC tag > available for item cost: tag 37. > > > > I agree that budgetary info would be useful to > transfer, for a whole host of reasons (not the > least of which is providing a base for > determining replacement cost should an item be > lost). > > > > As for fines, maybe I am just (too) grateful > when things have been returned: rather than > fussing about transferring fines, I'd suggest > using the occasion of migration to offer an > 'amnesty', something my local public library > system does at irregular intervals (not dependent > on system upgrades) and it seems to have a > positive effect. > > > > > > >I don't know what is meant exactly by > 'financial records' but I am assuming > > > > >that that is a euphemism for fines. Same > as paragraph above. > > > > > > > > I doubt that these can be exported in a > useful way, but I could be wrong. > > > > Adding the ability to trigger code on fines > to notify another accounting system > > > > may be interesting to someone. > > > > Maybe if one adopted one of the neat ideas Dave > Bigwood suggested (thanks Dave, I think what you > suggested would be super) there would be some way > of transferring the fine information (if > substantial at least) to the patron file format? > Anyway, just another two cents worth. > > > > Cheers, > > Steven F. Baljkas > > library tech at large > > Koha neophyte > > Winnipeg, Manitoba, Canada > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Re: [Koha] authority records
by Stephen Hedges 27 Apr '04

27 Apr '04

Tomasz, that is exactly correct. Koha does not refer to an "authority file" similar to what librarians think of when they see that term. (For the non- librarians, a library "authority file" contains things like the "authorized" spelling of an author's name, his/her "authorized" birth and death dates, etc. By refering to such an authority file, records are kept consistent and you avoid having "Smith, Joe" and "Smith, Joseph" records for books by the same author.) Stephen Hedges Nelsonville Public Library > Hi, > do I understand correctly that the "authority > records" support in Koha is > limited to prompting values for a given field, > but the bibliographic > records do not actually contain references to > authority records and hence a > change in authority records is not reflected in > how the bibliographic > record will be presented? > > Tomasz > > > -- > Tomasz M. Wolniewicz > Tomasz.Wolniewicz(a)uni.torun.pl > http://www.uni.torun.pl/~twoln > > Uczelniane Centrum Informatyczne > Information&Communication Technology Centre > Uniwersytet Mikolaja Kopernika Nicolaus > Copernicus University, > pl. Rapackiego 1, Torun pl. > Rapackiego 1, Torun, Poland > tel: +48-56-611-2750 fax: +48-56-622-1850 > tel kom.: +48-693-032-576 > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Re: [Koha] Library System - good system, LC problem
by COURYHOUSE＠aol.com 27 Apr '04

27 Apr '04

Hopefully this one drawback will soon be seamless.... It is the finishing touch it needs... Ed Sharpe archivist for SMECC > Subj:RE: [Koha] Library System - good system, LC problem > Date:4/26/2004 4:25:09 PM US Mountain Standard Time > From:BernadetteC@burwood.org.nz > To:baljkas@mb.sympatico.ca, pgichiri(a)strathmore.edu, koha(a)lists.katipo.co.nz > CC:baljkas@mts.net > Sent from the Internet > > > > Greetings all, > > > > I would concur with much of what Steven has said re Koha. As for LC > classification, at our library we’ve come up with a temporary solution of including > LC numbers in the biblio in the notes section!! Seriously once the developers > come up with a solution to LC numbers will be great. > > > > ___________________________________________ > > Bernadette Cassidy > > Library & Learning Coordinator > > > Allan Bean Centre for Research and Learning in Rehabilitation > > > Private Bag 4708 > > > Burwood Hospital > > Christchurch > > New Zealand > > Tel: (03) 383 9492 > > Fax: (03) 383 7500 > > > > -----Original Message----- > From: Steven F. Baljkas [mailto:baljkas@mb.sympatico.ca] > Sent: Thursday, 22 April 2004 8:21 a.m. > To: Peter Gichiri; koha(a)lists.katipo.co.nz > Cc: baljkas(a)mts.net > Subject: Re: [Koha] Library System - good system, LC problem > > > > Wednesday, April 21, 2004 15:05 CDT > > > > > > Greetings, Peter, > > > > > > Just a 'quick' reply to your message inquiring about Koha, that others on > the listserv will hopefully augment with their wisdom. > > > > > > First, I (and many others) think Koha is a great system. It is extremely > versatile and compared to other ILS that one would have to purchase at > significant cost, it is astoundingly good. > > > > > > In terms of technical support and further development, the prospects are at > least as good. Most questions to the listserv receive a response within 24 > hours, usually less. The community is very good at lending a hand with advice. > > > > > > Development is continual and the nice thing there is that, being an open > source product, your library could direct further development along lines that > would give you features you wanted simply by financing the programming and/or > appealing to the Koha community to see if some nice volunteer could effect > the change you wanted. > > > > > > As people write in to the listserv with different questions and requests for > features, many are added to the programmer's 'bug' lists for future work. If > you look back at the archive of message, you can see how much has been > accomplished in just one year (something we should all be applauding and thanking > the developpers for)!!. > > > > > > There are only 2 significant issues that I can see in terms of your library > adopting Koha. > > > > > > The first is that it would be preferable if there were a member of the > systems administration team who were familiar or willing to familarise him- or > herself with the program so that you would have technical support closer to home > . > > > > > > The second -- and this is really the major one -- is that Koha is NOT at > present compatible viz. LC classification numbers. I am not sure what the > progress has been in the last several months towards that. I know that the > understandable focus of the developpers has been on achieving a stable 2.0 release, > which is now done. > > > > In the meantime, perhaps somebody on the development side could reply with a > guesstimation on how long it might be until LC-numbers are usable within > Koha. Also, if there is a library that uses LC classification that has found a > way around this issue, it would be helpful to let the community know. > > > > > > Hope this lengthy response helps a bit, Peter. I think your library would > ultimately benefit greatly by adopting Koha. > > > > > > Best wishes in your automation/migration project, > > > > > > Steven F. Baljkas > > > library tech at large > > > Koha neophyte (and cheerleader!) > > > Winnipeg, Manitoba, Canada > > > > >> ----- Original Message ----- >> >> >> From: Peter Gichiri >> >> >> To: koha(a)lists.katipo.co.nz >> >> >> Sent: Wednesday, April 21, 2004 4:09 AM >> >> >> Subject: [Koha] Library System >> >> >> >> >> >> I am an assistant librarian working at Strathmore university, an up-coming >> university in Kenya, Africa. We are scouting for a library system that will >> address all the aspects of the library. We are using the Library of Congress >> systems of cataloging books. We hope to have a system that is compatible >> with other departments of the university for we share enough information with >> other department. The university has a well laid computer network. >> >> >> >> >> >> Is Koha a suitable system and what are is the best way ahead. >> >> >> >> >> >> Peter Wanyoike Gichiri >> >> >> Ass. Librarian >> >> >> Strathmore University >> >> >> >> >> >> >> --- >> Outgoing mail is certified Virus Free. >> Checked by AVG anti-virus system (http://www.grisoft.com) >> Version: 6.0.663 / Virus Database: 426 - Release Date: 20/04/2004 >> >> >> > > Thanks Ed Sharpe, Archivist for SMECC - - See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library - please advise if you have anything we can use. Coury House / SMECC 5802 W. Palmaire Ave. Phone 623-435-1522 Glendale Az 85301 USA CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono confidenziali e riservati. Se vi è stato recapitato per errore e non siete fra i destinatari elencati, siete pregati di darne immediatamente avviso al mittente. Le informazioni contenute non devono essere mostrate ad altri, né utilizzate, memorizzate o copiate in qualsiasi forma. CONFIDENTIAL: This e-mail and any attachments are confidential and may contain reserved information. If you are not one of the named recipients, please notify the sender immediately. Moreover, you should not disclose the contents to any other persons, nor should the information contained be used for any purpose or stored or copied in any form.

1 0

RE: [Koha] Library System - good system, LC problem
by Bernadette Cassidy 27 Apr '04

27 Apr '04

Greetings all, I would concur with much of what Steven has said re Koha. As for LC classification, at our library we've come up with a temporary solution of including LC numbers in the biblio in the notes section!! Seriously once the developers come up with a solution to LC numbers will be great. ___________________________________________ Bernadette Cassidy Library & Learning Coordinator Allan Bean Centre for Research and Learning in Rehabilitation Private Bag 4708 Burwood Hospital Christchurch New Zealand Tel: (03) 383 9492 Fax: (03) 383 7500 -----Original Message----- From: Steven F. Baljkas [mailto:baljkas@mb.sympatico.ca] Sent: Thursday, 22 April 2004 8:21 a.m. To: Peter Gichiri; koha(a)lists.katipo.co.nz Cc: baljkas(a)mts.net Subject: Re: [Koha] Library System - good system, LC problem Wednesday, April 21, 2004 15:05 CDT Greetings, Peter, Just a 'quick' reply to your message inquiring about Koha, that others on the listserv will hopefully augment with their wisdom. First, I (and many others) think Koha is a great system. It is extremely versatile and compared to other ILS that one would have to purchase at significant cost, it is astoundingly good. In terms of technical support and further development, the prospects are at least as good. Most questions to the listserv receive a response within 24 hours, usually less. The community is very good at lending a hand with advice. Development is continual and the nice thing there is that, being an open source product, your library could direct further development along lines that would give you features you wanted simply by financing the programming and/or appealing to the Koha community to see if some nice volunteer could effect the change you wanted. As people write in to the listserv with different questions and requests for features, many are added to the programmer's 'bug' lists for future work. If you look back at the archive of message, you can see how much has been accomplished in just one year (something we should all be applauding and thanking the developpers for)!!. There are only 2 significant issues that I can see in terms of your library adopting Koha. The first is that it would be preferable if there were a member of the systems administration team who were familiar or willing to familarise him- or herself with the program so that you would have technical support closer to home. The second -- and this is really the major one -- is that Koha is NOT at present compatible viz. LC classification numbers. I am not sure what the progress has been in the last several months towards that. I know that the understandable focus of the developpers has been on achieving a stable 2.0 release, which is now done. In the meantime, perhaps somebody on the development side could reply with a guesstimation on how long it might be until LC-numbers are usable within Koha. Also, if there is a library that uses LC classification that has found a way around this issue, it would be helpful to let the community know. Hope this lengthy response helps a bit, Peter. I think your library would ultimately benefit greatly by adopting Koha. Best wishes in your automation/migration project, Steven F. Baljkas library tech at large Koha neophyte (and cheerleader!) Winnipeg, Manitoba, Canada ----- Original Message ----- From: Peter Gichiri <mailto:pgichiri@strathmore.edu> To: koha(a)lists.katipo.co.nz Sent: Wednesday, April 21, 2004 4:09 AM Subject: [Koha] Library System I am an assistant librarian working at Strathmore university, an up-coming university in Kenya, Africa. We are scouting for a library system that will address all the aspects of the library. We are using the Library of Congress systems of cataloging books. We hope to have a system that is compatible with other departments of the university for we share enough information with other department. The university has a well laid computer network. Is Koha a suitable system and what are is the best way ahead. Peter Wanyoike Gichiri Ass. Librarian Strathmore University --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.663 / Virus Database: 426 - Release Date: 20/04/2004

1 0

Re: Re: [Koha] Export MARC from Koha
by Steve/Ollie/Steven F. Baljkas 27 Apr '04

27 Apr '04

Monday, April 26, 2004 17:07 CDT Hi, Chris, Just a quick response 'cause you were bang on in what you said, to wit: > In Full acquisitions mode, Koha stores lots of financial data, much more > than the replacement price of an item > (which is stored in the replacement price column on the item table btw) I think the only other things we would really want accessible in MARC might be the donor/fund that provided/purchased the item in question, the initial cost, the replacement cost (an estimate, and it can be omitted in favour of the original cost), and, if possible, the date of accessioning (theoretically this could be the same as the date it is catalogued but those of who've worked in tech services KNOW that ain't nothin' but a fairy tale). I have encountered librarians and lib techs who also like to have separate PO numbers noted, but I think that could be safely part of the donor/fund information without causing too much confusion. Are there other desiderata in this vein? Pipe in, folks. > In the aqorders, aqbudgets, aqbookfunds it stores a lot more information. > Such as the allocated budgets for each bookfund (ie for 2003-07-01 to > 2004-06-30 the Non Fiction bookfund may have $20k allocated) > It also tracks how much is committed to each fund (orders placed but not > received) and how much is spent from each fund (received orders) > It handles supplier profiles, exchange rates, discounts, sales taxes etc. > > All of this sounds to me like it wouldnt belong in MARC at all. > The replacement price would, but all the budgetary data would need to be > exported in some other format. So, yes, your are definitely right, Chris. I don't even think we need to try to export that information as such, certainly not for cataloguing purposes. Are there fields that would be able to handle that information I suggested in Acquisitions that could synch the data for cataloguing? (If not, that's still not a huge problem as it is not much information and could be looked up if desired in cataloguing.) Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, Manitoba, Canada

1 0

RE: Re: [Koha] Export MARC from Koha
by Steve/Ollie/Steven F. Baljkas 27 Apr '04

27 Apr '04

Sunday, April 25, 2004 16:11 CDT Hi, Dave, I can see what you mean about tags 876-878. Most of the records I've seen here don't do anything towards keeping acquisitions data (which is a shame), but when they do they invariably avoid using the holdings data tags you recommend (from what I see, I wonder if NLC had a policy of using them only for serials) and instead have opted for the tag 37 (which is flexible enough to handle the important information and the limits of which encourage one to remember not to collude 2 or more different editions of works) or more frequently use a 5xx number (sometimes one not specifically allowed) to keep the information they want. As library manager for a highschool library, I had to insist with my 'assistant' that such info not be encoded as a general public note (in 500) which is what someone had recommended to her prior to my appointment (not the kind of information we wanted highschool students to have: 'oh, this only cost $2.50, I can afford to lose it' problem). The Athena system we were using already encoded data to an 852 (with unauthorised uses of various subfields, including a creative $w - we couldn't find any way to change these peculiarities) and so we used 37 (repeating for each copy as necessary, $n beginning with barcode to ID specific copy) for the additional data we wanted. It would perhaps be good to recommend to users to adopt use of the 876-878 fields but still leave open the option of 37 for others. Smaller libraries, especially school ones, often don't have more than one copy of many works. Could someone from development tell us where/how Koha is storing that more detailed acquisitions information and if it could be integrated into the MARC tag structure that Dave suggests in one of the near future releases? Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, Manitoba, Canada > From: "Bigwood, David" <bigwood(a)lpi.usra.edu> > Date: 2004/04/25 Sun PM 03:23:40 CDT > To: <koha(a)lists.katipo.co.nz> > Subject: RE: Re: [Koha] Export MARC from Koha > > Fields 876-878 are a better choice to include acquisitions data. It includes the cost for each copy, different copies can have been purchased at different prices, or one could be a gift. It also includes where it was purchased, date acquired, item status and other subfields available for each copy. > > Field 037 is repeatable but not linked to each copy in the same manner. > > Sincerely, > David Bigwood > bigwood(a)lpi.usra.edu > Lunar & Planetary Institute > http://www.lpi.usra.edu/library/whats_new.shtml > Cataloging News > http://www.catalogablog.blogspot.com > > > -----Original Message----- > From: koha-admin(a)lists.katipo.co.nz > [mailto:koha-admin@lists.katipo.co.nz]On Behalf Of Steve/Ollie/Steven F. > Baljkas > Sent: Friday, April 23, 2004 5:39 PM > To: Chris Cormack; MJ Ray > Cc: koha(a)lists.katipo.co.nz > Subject: Re: Re: [Koha] Export MARC from Koha > > > Friday, April 23, 2004 17:30 CDT > > Hi, Chris et al., > > > Hi Guys > > > > Theres also the budget data if using full acquisitions. This might be > > useful to export also. > > Regarding the budget information kept in full acquisitions mode, I have to confess I haven't looked at that function, but there is a MARC tag available for item cost: tag 37. > > I agree that budgetary info would be useful to transfer, for a whole host of reasons (not the least of which is providing a base for determining replacement cost should an item be lost). > > As for fines, maybe I am just (too) grateful when things have been returned: rather than fussing about transferring fines, I'd suggest using the occasion of migration to offer an 'amnesty', something my local public library system does at irregular intervals (not dependent on system upgrades) and it seems to have a positive effect. > > > > >I don't know what is meant exactly by 'financial records' but I am assuming > > > >that that is a euphemism for fines. Same as paragraph above. > > > > > > I doubt that these can be exported in a useful way, but I could be wrong. > > > Adding the ability to trigger code on fines to notify another accounting system > > > may be interesting to someone. > > Maybe if one adopted one of the neat ideas Dave Bigwood suggested (thanks Dave, I think what you suggested would be super) there would be some way of transferring the fine information (if substantial at least) to the patron file format? Anyway, just another two cents worth. > > Cheers, > Steven F. Baljkas > library tech at large > Koha neophyte > Winnipeg, Manitoba, Canada

2 1