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.
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.
*** Bug 4968 has been marked as a duplicate of this bug. ***
Created attachment 5335 [details] [review]
I did not know where to source Price effective from, the only date available is Date received
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.
Via the mailing list :
On Wed, Sep 7, 2011 at 4:52 AM, LAURENT Henri-Damien <firstname.lastname@example.org> wrote:
> 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.)
Created attachment 5348 [details] [review]
I have replaced append_fields() with insert_fields_ordered(). Also using $field->update when appropriate.
Anote on subfields: they are not ordered within fields. My impression is that it is like that anyway. I can order them if required
When testing I used "Add Order To Basket"
- From an existing record
- From a Suggestion
- From a new (empty) record
Not tried From an external source and From a staged file
After receiving all orders and looking MARC lightbox popup all 952 subfields showed as expected
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.
If the order of subfields is meaningful then I'll have to correct my patch slightly
Created attachment 5369 [details] [review]
Ready for testing
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 ?
Created attachment 5410 [details] [review]
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.
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.
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?
Created attachment 6646 [details] [review]
The last comment is absolutely valid, I made a wrong assumption. This patch should apply correct update.
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.
Created attachment 6855 [details] [review]
Interface to ModItem() is just insane...
I'm still seeing the same thing - see here: http://screencast.com/t/sQUZIHbszbL
Created attachment 6877 [details] [review]
Created attachment 6888 [details] [review]
[SIGNED-OFF] bug_5473: Update items when receiving shipments
Signed-off-by: Nicole C. Engard <email@example.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.
* 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)
> 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 ;-)
This fix was included in the 3.6.x branch prior to 3.6.4.