Обработчики перебрасывают партию книг из CMPL в ЭК. Дата создания книг входит в период, но на момент рассылки (и не только последней, ведь партии бывают огромными) книг не было в эк, потом появляются, но период считается уже закрытым. Книги не попадут в рассылку?


Многих вопросов можно было избежать, если в протоколе будет указываться период поиска.

Количество результативных поисков (рассылок) за период с ддммгггг1 по ддммгггг2 NNN

Администратор хоть знал бы от чего отталкиваться в этом запутанном деле. Было бы легко проанализировать по файлам рассылки какие периоды дали какие результаты. А так есть файлы, которые привязаны только к дате рассылки, а ведь и период мог быть изменен.

У нас эта проблема решена так - в CMPL тот кто вводит работает с настройкой Этапа работы ОБРНЗ, а тот кто после переноса обрабатывает книгу уже в Каталогизаторе работает с этапом obrzv. Тогда при сохранении записи в Каталогизаторе поле 907 заменяется автоматически и дата получается уже не та, которую внесли в CMPL, а новая. И тогда в рассылку как раз попадают полностью обработанные книги.

Спасибо огромное, посоветуюсь с товарищами, вдруг у них на этот счет что-то не пойдет по вопросам, не связанным с ИРИ. Эти этапы мы тоже, конечно, меняем, но возможно не в той последовательности, и у нас 907 поле идет от даты создания в АРМ Комплектатор, а obrzv где-то в середине болтается, лишь бы снялся признак обрабтки)

Мы, кстати, этот порядок когда устанавливали, то ИРИ еще не запустили, так что нас это устроило и по другим вопросам. Там конечно есть 1 подводный камень. Если работать с obrzv, но на самом деле книга не доработана (перервали работу с ней на середине), то получается ложное сообщение об окончании обработки. И еще у нас книги передаются между отделами по партиям и получается, что книга уже числится готовой, а читателям она не доступна т.к. все еще лежит в отделе обработки. Но мы все-таки предпочли выбрать именно такой путь, тем более что с ИРИ только так и можно для нас не упустить ничего в рассылках (Вы то владеете языком и можете найти себе какой-то другой выход)

Первое, что приходит в голову это гордость за вас - вам важнее всего ваши читатели)), а я уже услышала ФИ по поводу изменения традиций статучета ввода в каталог, ну и про преждевременность снятия флага обработки (в общем будем посмотреть).
Второе - что ИРИ должна брать не первое повторение 907 поля, а повторение с этапом obrzv.
Третье - что если пункт 2 правильный или есть какое-то другое решение, то его нужно включать в поставку и инструкцию для всех пользователей. Сколько уже можно погибать в одиночку.

Спасибо за добрые слова (и заодно за помощь в ветке J тоже)!
Но с нашим подходом получается, что читателям тоже не вполне удобно - книга лежит в обработке, а числится обработанной полностью, читатель ее заказывает, а потом взять не может (идем навстречу выдаем в читальном зале, но на дом не даем). Правда, таких случаев за 4 года как у нас ИРБИС не так много было.
Поддерживаю полностью про пункт 2. В ИРИ нужно брать с obrzv! И пункт 3 про поставку тоже еще больше поддерживаю! Только вот есть такая тонкость - а если библиотеки не используют obrzv? Но тогда можно было бы все равно такой вариант просить сделать в типовой поставке, но при этом запараметрировать его использование в ини-файле.
Надеюсь может Александр Иосифович откликнется.

DEL



Редактировано 1 раз. Последний раз 20.03.2017 05:29 пользователем Novinka.

Вопрос все еще актуален, может мне кто-то помочь?

Еще немного подумала и пришла к выводу, что, работая с партиями КСУ, невозможно использовать ИРИ. Попадать в рассылку ВСЕ издания будут, только если рассылать из базы CMPL, но это вообще глупо...
М.б. привязываться не к периоду, а к номеру партии??? и апеллировать не к последней дате рассылки, а к последнему № КСУ...Или вообще к последнему mfn.



Редактировано 3 раз. Последний раз 14.03.2017 10:57 пользователем Novinka.

М.б. кто-то по своему опыту может мне помочь.
Пример из практики:
КСУ перекинуто 9 марта, дата поступления книг с 27 февраля по 9 марта. Последняя рассылка сделана 7 марта (большинства книг этого КСУ еще не было в каталоге, они обрабатывались в Комплектаторе).
Понятно, что в следующую рассылку попадут книги, созданные 7-9 марта (и то с 7 вопрос). А созданные с 27 февраля по 6 марта не попали Т.к. поиск ведется ПОСЛЕ даты последней рассылки, т.е. после 7 марта.



Редактировано 1 раз. Последний раз 20.03.2017 08:46 пользователем Novinka.

Галина, мне наши каталогизаторы вот что посоветовали. Если и комплектатор работает под ОБРНЗ и каталогизатор потом тоже работает под ОБРНЗ, то когда книги передаете в фонд, то можно сделать obrzv сразу и все повторения ОБРНЗ исчезнут и первым полем встанет как раз то, которое obrzv с датой передачи в фонд, таким образом всё попадет в ири что нужно.

Татьяна Ароновна, при смене статуса на obrzv первым повторением остается статус ПК...
вот наши повторения из отдельной записи

#907/1:_^CПК^A20170227^BГЛГ_ОБР
#907/2:_^CПК^A20170309^BГЛГ_ОБР
#907/3:_^CС^A20170314^BПТЯ_ОБР
#907/4:_^Cobrzv^A20170320^BУТВ_ОБР

В любом случае книга должна искаться с 20170227, но последняя рассылка была в марте.

Или м.б. я Вас не так понимаю? Или у вас настройки изменены, или у нас что-то не так.



Редактировано 1 раз. Последний раз 23.03.2017 12:10 пользователем Novinka.

У нас не изменены настройки, мы не умеем :)
Мы не используем статус ПК. У нас в АРМ Комплектатор наши комплектаторы работают со статусом ОБРНЗ. И тогда после передачи из cMPL в БД ЭК мы получаем запись в которой вот так:
907^CОБРНЗ^A20170322^Brta
если каталогизатор будет работать выбрав ту же настройку, то будет несколько записей с 907^CОБРНЗ^A20170322^Bимя каталогизатора
А потом, когда он передает книги в фонд, то если он каждую запись сохранит уже под статусом obrzv, то вместо ОБРНЗ будет так:
^Cobrzv^A20170323^Bleg
Или, как у нас, когда каталогизатор сразу работает с obrzv, то замена идет сразу, о чем я уже писала.
Конечно, для повторов так не будет (т.е. если книгу докомплектовывали и с ней уже работали, и в ней уже есть что-то кроме ОБРНЗ, то obrzv встанет не на первое место), но это и хорошо, они в ири и не должны попадать.
Получается, что obrzv заменяет только статус ОБРНЗ.



Редактировано 2 раз. Последний раз 23.03.2017 12:34 пользователем roit.

Молчание разработчиков красноречиво говорит о том, что проблема существует.