Bug 5473 - 952 fields should be filled in by Acquisitions
Summary: 952 fields should be filled in by Acquisitions
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: 3.6
Hardware: All All
: P2 normal (vote)
Assignee: Srdjan Jankovic
QA Contact: Bugs List
URL:
Keywords:
: 4968 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-05 13:42 UTC by Nicole C. Engard
Modified: 2013-12-05 19:59 UTC (History)
5 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (2.68 KB, patch)
2011-09-07 08:35 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (2.94 KB, patch)
2011-09-08 04:15 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (2.94 KB, patch)
2011-09-09 01:43 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (3.03 KB, patch)
2011-09-13 00:29 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (2.51 KB, patch)
2011-12-07 21:26 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (3.00 KB, patch)
2011-12-19 05:01 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (4.73 KB, patch)
2011-12-20 01:59 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
[SIGNED-OFF] bug_5473: Update items when receiving shipments (5.02 KB, patch)
2011-12-20 14:35 UTC, Nicole C. Engard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2010-12-05 13:42:07 UTC
From an email:

"In Koha 2.2.9 when you used the Acquisitions module and acquired an item, in the item record it would put in 952$e the number Koha assigned to that vendor when it is created in the Acquisitions module. - I really liked this feature in v2.2.9 and find it is strange why it was taken out of v3."

It makes perfect sense that if you're adding an item from acquisitions that it should fill in not only the 952e but also all other acquisitions related fields: 952d, 952g, 952v, and 952w.
Comment 1 Katrin Fischer 2010-12-06 15:36:31 UTC
I totally agree with Nicole, these fields should be filled by acquisition.

952 $e Source of acquisition
952 $d Date acquired
952 $g Cost, normal purchase price 
952 $v Cost, replacement price 
952 $w Price effective from 

Note: I have the plugin dateaccessioned.pl linked to $d in my ACQ framework - but the ... do not show up in acquisition.
Comment 2 Nicole C. Engard 2011-02-24 12:31:33 UTC
*** Bug 4968 has been marked as a duplicate of this bug. ***
Comment 3 Srdjan Jankovic 2011-09-07 08:35:03 UTC Comment hidden (obsolete)
Comment 4 Nicole C. Engard 2011-09-07 13:21:48 UTC
Srdjan,

I guess the received date would work.  

I have tested this and it's not doing anything differently so I'm wondering if you could give me a test plan.  I ordered two titles and added items at the time I placed the order.  When I received the items they were not updated with the pricing information.

Nicole
Comment 5 Nicole C. Engard 2011-09-07 15:40:36 UTC
Via the mailing list :


On Wed, Sep 7, 2011 at 4:52 AM, LAURENT Henri-Damien <henridamien.laurent@biblibre.com> wrote:
> Hi
> In my opinion, append_fields should not be used that much.
> use insert_fields_ordered or insert_fields_before
> rather than append_fields...
> Why ?
> Because usually, what you want is tags to be grouped and not dispatched
> in the biblio. And append_fields will append them at the end of the
> record. If the record is too long, then it will simply fail to index
> that part. (when 999 tag/subfields which stores the biblionumber, you
> would certainly have indexing problems on big records.)
Comment 6 Srdjan Jankovic 2011-09-08 04:15:39 UTC Comment hidden (obsolete)
Comment 7 Ian Walls 2011-09-08 11:45:05 UTC
Srdjan,


No, subfields should NOT be alphabetized; their order is meaningful (repeated subfields can take on different semantics depending on the subfield they follow).  MARC must die.

Thank you for the test details.  We'll need to be sure that 'external source' and 'staged file' both work, too, before we can move this fix through QA, for completeness and consistency.  Testers, please note.
Comment 8 Srdjan Jankovic 2011-09-08 23:24:30 UTC
If the order of subfields is meaningful then I'll have to correct my patch slightly
Comment 9 Srdjan Jankovic 2011-09-09 01:43:00 UTC Comment hidden (obsolete)
Comment 10 Srdjan Jankovic 2011-09-09 01:43:34 UTC
Ready for testing
Comment 11 Paul Poulain 2011-09-12 14:01:30 UTC
frenchy/UNIMARC guy comment:
Looking at this patch I heavily suspect some MARC things are hardcoded and it would heavily break non MARC21 instances...
A if (marcflavour eq "marc21") would be a bare minimum

PS : are you sure *everybody* using marc21 will have field 952 with those subfields & content ?
Comment 12 Srdjan Jankovic 2011-09-13 00:29:44 UTC Comment hidden (obsolete)
Comment 13 Paul Poulain 2011-09-13 08:37:19 UTC
mmm... the more I see it, the more I dislike it... hardcoding values that can be set differently 

In C4/Biblio, there is GetMarcFromKohaField, that you could call with items.itemnumber to retrieve the MARC field for items.
That could be safer for the 0.01% of libraries that don't use 952 for items and will be very disappointed to loose some data or think they've found a bug.
Comment 14 Katrin Fischer 2011-09-18 20:43:50 UTC
I would love to see this functionality in Koha, but I think Paul is right that it should be redone to check for the mapping of the fields instead of using the marc fields. So add the value into the field that is mapped to the right database column. Or it needs to be possible to be turned off/on, because it might not be useful bordering to annoying for libraries not using this combination of fields.
Comment 15 Nicole C. Engard 2011-12-06 17:39:49 UTC
What if it doesn't go in the 952 but in the items table - which is basically the table that holds item info from the 952 and/or other item fields.  Or is that what you're asking for?
Comment 16 Srdjan Jankovic 2011-12-07 21:26:50 UTC Comment hidden (obsolete)
Comment 17 Nicole C. Engard 2011-12-14 15:05:48 UTC
This works awesome if you have your AcqCreateItem preference is set to 'placing an order' but if it's set to 'receiving an order' then it looks like the pricing info is not populating the item record at all. I think that it needs to work for both of these options for AcqCreateItem. I don't think it's possible to have it work for the third option on the preference of 'cataloging the record' but am up to being corrected if I'm wrong.

Nicole
Comment 18 Srdjan Jankovic 2011-12-19 05:01:32 UTC Comment hidden (obsolete)
Comment 19 Nicole C. Engard 2011-12-19 15:48:38 UTC
I'm still seeing the same thing - see here: http://screencast.com/t/sQUZIHbszbL
Comment 20 Srdjan Jankovic 2011-12-20 01:59:06 UTC Comment hidden (obsolete)
Comment 21 Nicole C. Engard 2011-12-20 14:35:21 UTC
Created attachment 6888 [details] [review]
[SIGNED-OFF] bug_5473: Update items when receiving shipments

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>

Tested by recieving multiple items with the AcqCreateItem
preference set to 'placing and order' and 'receiving an item'
In both cases the pricing and vendor is brought over to the
item record so I'm signing off.
Comment 22 Paul Poulain 2012-01-20 15:32:40 UTC
QA comment:
* a warn must be removed:
+    warn "AAA $itemnumber";
* the patch also updated some PODDOC and removed some commented code

I made a follow-up:
* removing the warn
* updating some indentation (s/tab/4 spaces/, that where not in the patch, but where here since years)

I made tests with UNIMARC, everything is OK (as I suspected, as there is no more hardcoded values, and using ModItem is the way to go)

Just about:
> Interface to ModItem() is just insane...

This is a little bit short man. What is insane, and which alternative do you propose ? Just saying it's insane won't help fixing the insanity ;-)
Comment 23 Jared Camins-Esakov 2012-05-23 12:55:57 UTC
This fix was included in the 3.6.x branch prior to 3.6.4.