С 2016 версии создан объединенный рабочий лист. Т.е. новые записи читателей в БД RDR создаются по умолчанию с 920 полем не RDRU, а RDR.
Соответственно в БД RDR у нас все старые записи на студентов 920RDRU, а новые (их пока немного, но скоро будет записан 1 курс и будет много) 920RDR.
Переводила студентов на следующий семестр и обнаружила, что в АРМ Книгообеспеченность похоже этот параметр учитывается.
Я выбирала студентов по семестрам и переводила их последовательно. И студентка, у которой 920RDR не перевелась. Она даже в словаре не отображается по семестрам (ее запись прикрепляю).
Проверила еще так - поменяла у одной из старых записей RDRU на RDR и сразу же в словаре по семестрам эта запись пропала. Как только поменяла обратно - появилась.
В поиске по идентификатору студентку с RDR нашла и перевела. В словаре по семестрам ее по-прежнему не видно.
Прикрепляю картинку и запись.
Версия у нас 2016 (D3)
Если для Книгообеспеченности важно чтобы было RDRU и это еще где-то учитывается, то что нам делать? Отказаться от нововведения в этой и последующей версиях? Но это же наверное не совсем правильно? Придется вносить изменения при переходе на каждую следующую версию.



Редактировано 2 раз. Последний раз 31.07.2017 15:53 пользователем roit.

Татьяна Ароновна, по всей видимости действительно в ряде технологий (форматов, сценариев ГК и т.п.) не были произведены изменения связанные с рекомендацией разработчиков использовать объединенный РЛ RDR.

Т.к. в ПГУПС мы используем ИРБИС128, который как раз наоборот, требует наличия в 920 поле RDRU у студентов, то применять предложенные по умолчанию РЛ при переходе на ИРБИС 2016.1 мы не стали, сравнив их с имеющимися РЛ и не найдя существенных отличий. Значение поля 920 по умолчанию для РЛ RDR - RDR для RDRU - RDRU.

Перевод студентов на новый семестр осуществляем не пакетным заданием, а при импорте записей студентов из csv файла (в том же АРМе Книгообеспеченность), предоставляемого из АИС вуза (с обновлением имеющихся записей новой информацией).

Поэтому, я бы рекомендовал оставить два РЛ - RDR и RDRU, в которых (в соответствии с реальными потребностями библиотеки и с учетом 152-ФЗ) оставить только необходимые поля и при обновлениях/переходах на новые версии сравнивая эти файлы с вновь предлагаемыми включать в свои файлы только нужное.
А по БД RDR - на записях, содержащих 90 поле провести глобальную корректировку, заменив RDR на RDRU.

Можно конечно и так, но хотелось бы, чтобы раз уж разработчики теперь предлагают 1 объединенный рабочий лист RDR, то все бы работало корректно. Хотя уже думаю сделать опять, как у нас было ранее RDRU для всех типов записей, как у нас и было ранее. Можно даже этот объединенный рабочий лист переименовать в RDRU. Поля лишние нас не особо тревожат, то что не надо просто не заполняем.
А зачем Вам тогда просто RDR? Для тех кто не студент? Но можно же тогда не заполнять 90 поле просто, в РЛ RDRU.

Татьяна Ароновна, вы правы. Проверка на RDRU осталась в таблице создания словарей, поэтому вы не видите записи в словарях. Исправления будут в D4, но я прикладываю исправленную таблицу, нужно заменить и создать словарь RDR заново. Спасибо.

Спасибо, Людмила Николаевна! Получилось. Все-таки так лучше. Раз уж разработчики решили, что будет объединенный рабочий лист RDR, то пусть уж дальше он у нас и будет. Лишь бы все работало с любым РЛ и старым, и новым

Людмила Николаевна! Загружаю в базу студентов 1 курса пользуясь любимым режимом (снова и снова спасибо за него!) Импорт с преобразованием. Они все после импорта получились в 920 RDRU.
Наверное мне стоит это поменять? И наверное это нужно исправить?
Ведь когда до нас потом дойдут студенты уже не массово, а индивидуально, которых нет в базе (кто-то переведется из другого вуза и т.п.), то при записи они получат автоматом RDR в 920. Или не надо ничего менять, пусть будет как будет? Ведь старые то у нас все равно RDRU.
Роман Сергеевич вот советует тут вообще наоборот RDRU делать. А мне неохота в каждой следующей версии делать изменение по сравнению с дистрибутивом. Придумали разработчики объединенный, пусть и будет. Только бы понять пока как будет и что конкретно в каждом случае делать :)



Редактировано 2 раз. Последний раз 08.08.2017 10:46 пользователем roit.

Вопрос в том, каковы причины перехода к единому рабочему листу?

Ведь ряд технологий до этого был ориентирован на разные РЛ (RDR, RDRU).
Может все-таки стоит сохранить в дистрибутиве два РЛ ввода и не менять ничего в форматах под единственное значение 920 поля?

Наверняка у продвинутых пользователей (и у нас тоже) для БД RDR создавались какие-то собственные выходные формы или возможно сценарии ГК или автоввода, опирающиеся на значение в 920 поле.

Как раз продвинутые пользователи и могут при переходе к новой версии сохранять любые отличия от дистрибутива. А раз в дистрибутиве сделан таки этот один рабочий лист, то в дистрибутивной же версии это должно быть учтено везде. Также должно быть учтено, что в базах пользователя есть записи по технологии предыдущих версий как с RDR, так и с RDRU. А сейчас ничего непонятно. То где-то учтено, то нет.
И на сегодняшний день мне неясно что делать. Вот есть эти первокурсники, которые загрузились как RDRU и что с ними сделать? Поменять на RDR, чтобы было одинаково, хотя бы для всех новых читателей. Не менять. Где еще всплывет и в какой месте будет завязано на это отличие что-то у самих разработчиков?
Мне не хочется каждый раз при переходе на новую версию сохранять отличие от дистрибутива, как будет если последовать совету Романа Сергеевича.



Редактировано 2 раз. Последний раз 08.08.2017 13:18 пользователем roit.

Могут-то они могут, но вот переписывать все форматы под новые условия - тоже не очень-то веселое занятие. Поэтому надо понимать, ради чего все это.

Очень бы хотелось действительно получить разъяснения от разработчиков. И не потому что у меня какие-то претензии. А просто мне действительно неясно что делать и как дальше быть!

Что касается модуля Книгообеспеченность. В нем все улажено.
1. С обновленным файлом rdr.fst (в D4) словари не зависят от поля 920
2. Формат просмотра - С.М. вставила в единый формат для всех значений 920 возможность и книг на руках, и книг из архива. Прикладываю форматы для RDR, будут в D4. Для регулировки показа архивных данных можно использовать параметр LimPftFull_arh=число



Редактировано 1 раз. Последний раз 09.08.2017 14:53 пользователем ochagova.

Спасибо Вам и Светлане Михайловне!
1) Только вот тут [irbis.gpntb.ru]
Светлана Михайловна мне писала про название парамтра:
"В этом формате изменено имя параметра настройки (уточнено для дистрибутива)
было LimPftFull_arh=10
стало LimPftFull_rdrarh=10"
2) И я правильно поняла rdrw_arh_html это тоже для RDR? Или для RDR_ARH?



Редактировано 1 раз. Последний раз 10.08.2017 08:43 пользователем roit.

С.М. еще раз исправила формат т.о., что параметра не нужно. Прикладываю. rdrw_arh_html - для RDR

Простите, не понимаю.
1!) Как это параметра не нужно? о LimPftFull_rdrarh не нужно? А как тогда регулировать сколько мы хотим чтобы показывалось по ссылке в архивных (т.е. с какого количества "убиралось под ссылку")? Я вот сейчас установила о LimPftFull_rdrarh=1.
2) И вообще непонятно ранее для всех этих дел мне С.М. присылала в той ветке форума (Книнговыдача) rdrw_html.pft
3) А rdrw_arh_html.pft у меня почему-то в Deposit. Оттуда убрать?



Редактировано 2 раз. Последний раз 10.08.2017 09:41 пользователем roit.

rdrw_arh_html.pft - в Deposit, здесь я не права.
По поводу параметров - мы обсудим и сделаем одинаково в Книгообеспеченности и Каталогизаторе.