Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7130 ).
Bug 7130 should be 7131.
Created attachment 20994 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Created attachment 21006 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Applying: Bug 10877 - Add "Order Record" processing Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 10877 - Add "Order Record" processing The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Depend on 7180.
Created attachment 21429 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Patch applied cleanly, go forth and signoff
Applying: Bug 7180: Add UT for C4::Budgets::GetBudgetByCode Using index info to reconstruct a base tree... M t/db_dependent/Budgets.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Budgets.t CONFLICT (content): Merge conflict in t/db_dependent/Budgets.t Patch failed at 0001 Bug 7180: Add UT for C4::Budgets::GetBudgetByCode The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
This bug depends on bug7180 which is in status Needs Signoff but the patches for it do not apply cleanly
Created attachment 24466 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Created attachment 24467 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Created attachment 24468 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
I test against master 3.15.00.052 Applying: Bug 10877 - Add "Order Record" processing fatal: sha1 information is lacking or useless (acqui/addorderiso2709.pl). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 10877 - Add "Order Record" processing So I pass the patch to "Patch doesn't apply" status
Created attachment 29405 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Created attachment 29406 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
We've tested this extensively and have seen no problems with the upload and automatic order generation.
Comment on attachment 29406 [details] [review] Bug 10877 - Add "Order Record" processing Review of attachment 29406 [details] [review]: ----------------------------------------------------------------- ::: C4/ImportBatch.pm @@ +967,3 @@ > =cut > > sub GetImportBatchRangeDesc { You should provide unit test here, but it seems to be quite difficult here (no test exists for this module). ::: acqui/addorderiso2709.pl @@ +270,5 @@ > my @serials = $input->param('serial'); > my @ind_tag = $input->param('ind_tag'); > my @indicator = $input->param('indicator'); > + > + if ($is_order) { Could you detail why you process these 4 fields? @@ +295,5 @@ > + GetMarcFromKohaField('items.itype'); > + push( @tags, $itype_field ); > + push( @subfields, $itype_subfield ); > + push( @field_values, $infos->{itype} ); > + warn "ITYPE: " . $infos->{itype}; useless warn @@ +359,1 @@ > hum, good candidate for an hashref param. @@ +450,5 @@ > item_action => $item_action > ); > batch_info($template, $batch); > + > + return \@list; Why did you change this return? ::: installer/data/mysql/updatedatabase.pl @@ +8565,5 @@ > + $dbh->do("ALTER TABLE import_batches ADD is_order BOOLEAN NOT NULL DEFAULT '0' AFTER comments"); > + print "Upgrade to $DBversion done (Bug 10877 - Add 'Order Record' processing)\n"; > + SetVersion ($DBversion); > + > +} FAIL pod *** WARNING: =head2 without preceding higher level in file installer/data/mysql/updatedatabase.pl Just add an blank line before =head1 ::: koha-tmpl/intranet-tmpl/prog/en/includes/acquisitions-add-to-basket.inc @@ +18,4 @@ > <li><a href="/cgi-bin/koha/acqui/z3950_search.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]">From an external source</a></li> > <li><a href="/cgi-bin/koha/acqui/addorderiso2709.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]"> From a staged file</a></li> > [% IF ( CAN_user_circulate ) %]<li><a href="/cgi-bin/koha/circ/reserveratios.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]">From titles with highest hold ratios</a></li>[% END %] > + <li><a href="/cgi-bin/koha/acqui/addorderiso2709.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]&is_order=1"> From a staged order file</a></li> Maybe should be put just after "from a staged file"? ::: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/addorderiso2709.tt @@ +145,5 @@ > + $("#checkAll").click(); > + > + $("#all_budget_id").hide(); > + $('label[for="all_budget_id"]').hide(); > + [% END %] I don't understand the trick here. Please check because the behavior is buggy (try to check/uncheck "Show all fund", the fund list will become empty).
Comment on attachment 29406 [details] [review] Bug 10877 - Add "Order Record" processing Review of attachment 29406 [details] [review]: ----------------------------------------------------------------- ::: C4/ImportBatch.pm @@ +967,3 @@ > =cut > > sub GetImportBatchRangeDesc { Agreed. There are no unit tests for this. I think it would be extremely difficult to unit test. However, the additions I've made to it are close to trivial. ::: acqui/addorderiso2709.pl @@ +270,5 @@ > my @serials = $input->param('serial'); > my @ind_tag = $input->param('ind_tag'); > my @indicator = $input->param('indicator'); > + > + if ($is_order) { This is so we can pre-set the items to a notforloan value of 'ordered', and to preset the home and holding fields to the current branch, as well as pre-set the itemtype. @@ +295,5 @@ > + GetMarcFromKohaField('items.itype'); > + push( @tags, $itype_field ); > + push( @subfields, $itype_subfield ); > + push( @field_values, $infos->{itype} ); > + warn "ITYPE: " . $infos->{itype}; Will fix! @@ +359,1 @@ > While I agree, I wanted to make as few changes as possible to that subroutine. @@ +450,5 @@ > item_action => $item_action > ); > batch_info($template, $batch); > + > + return \@list; I just thought it sensible to have the sub return something. Considering no caller of the sub takes in the return value, I expect it will be compiled away. I can remove this if you think it prudent. ::: installer/data/mysql/updatedatabase.pl @@ +8565,5 @@ > + $dbh->do("ALTER TABLE import_batches ADD is_order BOOLEAN NOT NULL DEFAULT '0' AFTER comments"); > + print "Upgrade to $DBversion done (Bug 10877 - Add 'Order Record' processing)\n"; > + SetVersion ($DBversion); > + > +} Will fix! ::: koha-tmpl/intranet-tmpl/prog/en/includes/acquisitions-add-to-basket.inc @@ +18,4 @@ > <li><a href="/cgi-bin/koha/acqui/z3950_search.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]">From an external source</a></li> > <li><a href="/cgi-bin/koha/acqui/addorderiso2709.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]"> From a staged file</a></li> > [% IF ( CAN_user_circulate ) %]<li><a href="/cgi-bin/koha/circ/reserveratios.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]">From titles with highest hold ratios</a></li>[% END %] > + <li><a href="/cgi-bin/koha/acqui/addorderiso2709.pl?booksellerid=[% booksellerid %]&basketno=[% basketno %]&is_order=1"> From a staged order file</a></li> Will fix! ::: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/addorderiso2709.tt @@ +145,5 @@ > + $("#checkAll").click(); > + > + $("#all_budget_id").hide(); > + $('label[for="all_budget_id"]').hide(); > + [% END %] I believe this is causing issues do to the fact that this patch targeted an earlier version of bug 7180. I will update the patch.
Created attachment 29759 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ).
Created attachment 29760 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ). Signed-off-by: Aaron Sakovich <asakovich@hmcpl.org>
(In reply to Kyle M Hall from comment #18) > Comment on attachment 29406 [details] [review] [review] > ::: acqui/addorderiso2709.pl > @@ +270,5 @@ > > my @serials = $input->param('serial'); > > my @ind_tag = $input->param('ind_tag'); > > my @indicator = $input->param('indicator'); > > + > > + if ($is_order) { > > This is so we can pre-set the items to a notforloan value of 'ordered', and > to preset the home and holding fields to the current branch, as well as > pre-set the itemtype. Yes but you hard-code arbitrarily these values. Why these 4 values and not others? I would like to get another QA point of view here. Katrin maybe?
-1 is the standard value for 'ordered' in Koha. This feature is to process order records so the items are by definition ordered and not any other status. Additionally we grab the itemtype from the system preference, and we set the branch selects to the logged in branch. I wouldn't say it's arbitrary. If you have any suggestions on how to better handle this, I'd be open to making changes. As the author of the feature this builds on, I think you are probably in the best position to qa this patch. Kyle (In reply to Jonathan Druart from comment #21) > (In reply to Kyle M Hall from comment #18) > > Comment on attachment 29406 [details] [review] [review] [review] > > ::: acqui/addorderiso2709.pl > > @@ +270,5 @@ > > > my @serials = $input->param('serial'); > > > my @ind_tag = $input->param('ind_tag'); > > > my @indicator = $input->param('indicator'); > > > + > > > + if ($is_order) { > > > > This is so we can pre-set the items to a notforloan value of 'ordered', and > > to preset the home and holding fields to the current branch, as well as > > pre-set the itemtype. > > Yes but you hard-code arbitrarily these values. > Why these 4 values and not others? > I would like to get another QA point of view here. > Katrin maybe?
Will have a look at this one, unless another QAer is faster :)
Created attachment 31338 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ). Signed-off-by: Aaron Sakovich <asakovich@hmcpl.org>
Trivial rebase.
QA Comment: Looks quite good to me. Some small details still need attention (see also earlier remark of Jonathan): my $infos = get_infos_syspref($marcrecord, ['itype']); This does not seem to make sense. According to the description of the pref itype is not contained in the pref. (So you create/use an undocumented feature here?) Note that if I just comment those lines, the items will fall back to the item type that I had in 942c of the biblio record somehow? Any idea where that comes from? On the other hand, we could add this to the syspref description and keep it. Although I do not mind to set the home and holding branch of the item as you do now in the same code region, it is not really necessary. They could be null as well. If I comment the lines, the items will be created too. (Note that I do not specifically understand the concerns of Jonathan for this field.) Your argument on the notforloan to -1 makes sense to me. I would suggest to keep that one at least. Changing status to reflect need for small adjustments.
Hi Kyle and Marcel, I know I am late to this, but what is the difference between the 2 options 'order from a staged file' and 'order from a staged order file'? Why do those need to be kept separate?
Katrin, they need to be kept separate because order files behave differently than traditional marc files. (In reply to Katrin Fischer from comment #27) > Hi Kyle and Marcel, > I know I am late to this, but what is the difference between the 2 options > 'order from a staged file' and 'order from a staged order file'? Why do > those need to be kept separate?
So now I know as much as before ;) Can you please explain the direction this goes? What makes them behave differently and how?
(In reply to Katrin Fischer from comment #29) > So now I know as much as before ;) Can you please explain the direction this > goes? What makes them behave differently and how? What you stage a record file, you have the option of saying "this is an order record". This is how Koha knows if file is an order file and not a standard marc record file. The difference is how an order file is set up. In a traditional marc record, you have items in 952, one for each item. In an order file, you have simply have a field for quantity, a field for budget code, etc. These are defined in MarcFieldsToOrder. This pref can also be used for regular marc files. The difference is that order records have not for loan, home and holding branch, and itemtype preset as well. So basically, order records have more data preset and are less "editable" compared to regular marc records. The workflow goes something like this: 1) You place an order with your vendor from their website 2) You download the order record and stage in in Koha 3) You create a basket and import the order records, which automatically have the data pre-set to match the order you placed on the vendor's website.
Hm, if the only difference is the prepopulating of the item fields (which we shoudl document :) ), then I'd suggest to not use a different order link, but maybe use the existing 'from staged file' and add a column to the list of files that clearly indicates, that the file was marked as 'order record'. Then from there it would just go the normal way, with the difference of prepopulating the fields. I am not sure if there are more features planned for this, but maybe we need to think about some kind of import template on vendor level at some point - so we don't need to hardcode things, but can have some more flexibility and granularity.
*** Bug 9171 has been marked as a duplicate of this bug. ***
I feel like I don't understand this feature well - at least not the differences to the existing staged MARC records workflow. Marcel noted some concerns in comment #26 and earlier Jonathan worked some on this - comment #17. Can we try to restart the discussion together?
Created attachment 35677 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ). Signed-off-by: Aaron Sakovich <asakovich@hmcpl.org>
(In reply to Katrin Fischer from comment #33) > I feel like I don't understand this feature well - at least not the > differences to the existing staged MARC records workflow. I'll see what I can do to make this happen!
Created attachment 38849 [details] [review] Bug 10877 - Add "Order Record" processing Order Record Processing will allow a library to stage an "order record" file which is a standard marc file with some additional information in it about how to create items automatically ( quantity, itemtype, etc ). The location of these fields is defined in the system preference MarcFieldsToOrder from bug 7180. The workflow is thus: 1) A librarian uploads an "order record" file, and marks the batch as an order file during the staging process. 2) The librarian selects an acquisitions basket and chooses "from a staged order file" 3) From here, the librarian can view all the records that will be created, along with quantity and other data ( from bug 7180 ). The librarian will *not* see the item fields, as those are automatically created using the minimum data needed ( branches, itype ). 4) The librarian hits "save" and the items are automatically generated on order. Later ( using features not directly tied to this feature ), the librarian will receive a new marc batch file with items attached ( including itemnumbers ). The vendor will have this information because it was sent via EDI ( bug 7736 ). The librarian will then use the marc record staging feature to overlay those bare bones item records with the full data ( via bug 7131 ). Signed-off-by: Aaron Sakovich <asakovich@hmcpl.org>
Created attachment 38850 [details] [review] Bug 10877 [QA Followup]
(In reply to Kyle M Hall from comment #35) > (In reply to Katrin Fischer from comment #33) > > I feel like I don't understand this feature well - at least not the > > differences to the existing staged MARC records workflow. > > I'll see what I can do to make this happen! Did you do something since this comment? Is it related to the second patch [QA Followup]?
Waiting for an answer.
Order records, at an item level, work much differently than traditional marc records. A standard marc record for Koha would have a 952 field for each item with the appropriate subfields. An order record, on the other hand, has *no* 952 field. Instead it has data that tells us how to create the items ourselves, with fields/subfields for the itemtype, collectioncode, acquisitions fund, etc defined in the record in a non 952-field ( it seems that 947 is often used for this ). Most importantly, that is a field that defines the quantity of items to create. (In reply to Jonathan Druart from comment #38) > (In reply to Kyle M Hall from comment #35) > > (In reply to Katrin Fischer from comment #33) > > > I feel like I don't understand this feature well - at least not the > > > differences to the existing staged MARC records workflow. > > > > I'll see what I can do to make this happen! > > Did you do something since this comment? > Is it related to the second patch [QA Followup]?
I forgot to mention the items on an order record are automatically marked as being not for loan ( since they are on order ) and have home and holding branch automatically set to the logged in library.
Kyle, Sorry about that but I am switching the status back to Needs Signoff. The idea is not to try and block this enhancement but, on the contrary, to get feedbacks from someone else. I have CCed some people which might be interested in this feature. Hope to get it back in the QA queue soon!
fatal: previous rebase directory .git/rebase-apply still exists but mbox given. at ./getter.pl line 196.
I believe we are pursuing an alternative solution and will continue to get this patch into Koha.