Сорокина Лариса написал(а):
-------------------------------------------------------
> New написал(а):
> --------------------------------------------------
> -----
> > Ирбис-64, 2012.
> >
> > Здравствуйте, возникла необходимость достаточно
> > большой части фонда поменять шифр. Но если хоть
> > один экземпляр выдан, то при изменении шифра в
> > поле 903 - не везде меняется информация
> корректно,
> > возникают проблемы и в АРМ Книговыдача и т.д.
> Как
> > поменять шифр автоматически везде, даже при
> > условии выданных экземплярах?
> >
> > Спасибо.
>
> "поменять шифр автоматически везде" можно
> глобальной корректировкой с отключенным ФЛК, но
> делать этого нельзя. Будет проблема с возвратом
> выданных экземпляров.


Возникла аналогичная необходимость. Изменить индекс УДК с одного на другой, а следовательно тогда и шифр документа в БД и систематический шифр нужно менять.

А если я глобально откорректирую поле 40^A в базе данных читателей, на новый шифр, чтобы совпадало с БД электронного каталога, тогда же не будет проблем с возвратом?

У нас такие ситуации когда индекс, а следовательно и шифр надо поменять у 1-2 книг бывают часто. Меняем глобальной в базе и обязательно в 40 поле у читателя. Проблем не может быть, если внимательно всё сделать т.к. тогда расхождения не будет. А вот если нужно менять большой объем, то больше вероятность что-то напутать, такого опыта у нас не было.



Редактировано 1 раз. Последний раз 20.11.2018 16:48 пользователем roit.

А еще часто по полю 903 формируется гиперссылка одной записи на другую (например, книга и рецензия на книгу), электронная версия и печатная публикация и др. Сейчас поле 903 формируется из ББК,УДК, а там присутствуют самые различные специальные символы, в частности {}+< > . И в некоторых выходных форматах на некоторых записях ссылки не работают. Например, обнаружила, что в файле opris488.pft неправильно работает &unifor('+I?2,,'v488^#',,I='v488^T'?'v488^1,if v488^#=&uf('+D') then else | (в БД |v488^#|) |fi ),
На вебинаре озвучила эту проблему, предложили использовать еще один unifor.

Это я могу исправить конкретно у себя и в этом конкретном файле. Но уверена, что такая подобная проблема всплывает и в других библиотеках и не только в этом выходном формате и как их всех выявить и исправить?
Может быть пора отвязать поле 903 от ББК и УДК и запретить его изменять?

А зачем менять 903-е? Оно должно быть уникально. Зачем соблюдать соответсвие индексов в нем текущим?

Затем меняем 903, что если мы в 906 поле меняем систематический шифр (нормальная рабочая ситуация перешифровки книг), но не меняем в 903, то в форматах просмотра получается вот такой бред в шифре (988 это то что я ввела в 906 поле, специально чтобы было нагляднее сделала там случайный набор цифр):
85.955/Б 30-408884856
988
Б 30
т.е. шифр полочный становится неправильным вместо правильного:
85.955
Б 30



Редактировано 1 раз. Последний раз 04.04.2019 12:29 пользователем roit.

Ну так надо разработчиков просить менять форматы просмотра. 903 вообще никак не должно на них (в моем понимании) влиять.

Там не только в этом проблема, как написала коллега выше в ББК и УДК могут входить символы, которые мешают в дальнейшем, а 903 поле автоматически когда формируется, то основа шифр, который может быть ББК или УДК

roit написал(а):
-------------------------------------------------------
> Затем меняем 903, что если мы в 906 поле меняем
> систематический шифр (нормальная рабочая ситуация
> перешифровки книг), но не меняем в 903, то в
> форматах просмотра получается вот такой бред в
> шифре (988 это то что я ввела в 906 поле,
> специально чтобы было нагляднее сделала там
> случайный набор цифр):
> 85.955/Б 30-408884856
> 988
> Б 30
> т.е. шифр полочный становится неправильным вместо
> правильного:
> 85.955
> Б 30

Пример непонятен. Зачем вводится в поле 906 "988", если правильным считается шифр без участия "988"?
Посмотрите, не поможет ли Вам в ситуации с изменением индексов настройка подполя "Шифр в просмотр выводить" поля 905, чтобы не менять поле 903

Пример был именно условный (не стала смотреть настоящие индексы ББК), наверное поэтому непонятно.
Ситуация с изменениями такая: в 906 поле у нас Систематический шифр. Он не всегда ББК, старый фонд и фонд художественного абонемента у нас по другой классификации стоит. Полочный шифр (который однозначно должен указывать на место книги на полке в фонде) таким образом формируется из 906 поля и авторского знака (908 поле). Теперь вернемся к моему примеру. Он показывал, что если я хочу переставить книгу из шифра 85.955 в условный 988, то я меняю это значение в 906 поле. Но при этом во всех форматах просмотра, если я еще и в 903 поле не поменяю 85.955/Б 30-408884856 на 988/Б 30-408884856, то у меня будет такой неправильный шифр, как я показываю.
Если я в 905 поле проставлю 1 т.е. выводить, формируя без учета 903 поля, то это отразится только на формате просмотра в АРМ каталогизатор. На каталожной карточке, в Web и J электронных каталогах будет такая же трехэтажная конструкция, как я показала выше. А, например, в Библиографическом указателе по автору и заглавию (другие не проверяла, но думаю что и везде где есть еще шифры) вообще в скобках за словом Шифр выводится содержимое 903 поля. Т.е. я книгу переставлю в этот условный 988 раздел, а она продолжит числится за старым отделом.
Все эти многочисленные проблемы и заставляют нас при перешифровке (изменении 906 поля) лучше уж менять содержимое 903 поля и глобальными корректировками корректировать 40 поле, если книга выдана.



Редактировано 1 раз. Последний раз 04.04.2019 15:56 пользователем roit.

Лариса Васильевна, очень много лет множество пользователей Ирбиса просит отказаться от вывода на экран поля 903! Но каждый раз нас или игнорируют вообще, или объявляют наши доводы несостоятельными. Перешифровка фонда - нормальная работа. При перешифровке книги приходится пересоздавать 903 поле, иначе на экран начинает выводиться бред. Но при этом это самое 903 поле используется в задачах Книговыдачи, Книгообеспеченности и установки связи между записями. Это кошмар!

roit написал(а):
-------------------------------------------------------
> Пример был именно условный (не стала смотреть
> настоящие индексы ББК), наверное поэтому
> непонятно.
> Ситуация с изменениями такая: в 906 поле у нас
> Систематический шифр. Он не всегда ББК, старый
> фонд и фонд художественного абонемента у нас по
> другой классификации стоит. Полочный шифр (который
> однозначно должен указывать на место книги на
> полке в фонде) таким образом формируется из 906
> поля и авторского знака (908 поле). Теперь
> вернемся к моему примеру. Он показывал, что если я
> хочу переставить книгу из шифра 85.955 в условный
> 988, то я меняю это значение в 906 поле. Но при
> этом во всех форматах просмотра, если я еще и в
> 903 поле не поменяю 85.955/Б 30-408884856 на
> 988/Б 30-408884856, то у меня будет такой
> неправильный шифр, как я показываю.
> Если я в 905 поле проставлю 1 т.е. выводить,
> формируя без учета 903 поля, то это отразится
> только на формате просмотра в АРМ каталогизатор.
> На каталожной карточке, в Web и J электронных
> каталогах будет такая же трехэтажная конструкция,
> как я показала выше. А, например, в
> Библиографическом указателе по автору и заглавию
> (другие не проверяла, но думаю что и везде где
> есть еще шифры) вообще в скобках за словом Шифр
> выводится содержимое 903 поля. Т.е. я книгу
> переставлю в этот условный 988 раздел, а она
> продолжит числится за старым отделом.
> Все эти многочисленные проблемы и заставляют нас
> при перешифровке (изменении 906 поля) лучше уж
> менять содержимое 903 поля и глобальными
> корректировками корректировать 40 поле, если книга
> выдана.

Если я правильно поняла, то условие вывода шифра,указанное в 905 поле помогает, но надо, чтобы оно работало также на WEBе и в печатных формах. Так?

Gena написал(а):
-------------------------------------------------------
> Лариса Васильевна, очень много лет множество
> пользователей Ирбиса просит отказаться от вывода
> на экран поля 903! Но каждый раз нас или
> игнорируют вообще, или объявляют наши доводы
> несостоятельными. Перешифровка фонда - нормальная
> работа. При перешифровке книги приходится
> пересоздавать 903 поле, иначе на экран начинает
> выводиться бред. Но при этом это самое 903 поле
> используется в задачах Книговыдачи,
> Книгообеспеченности и установки связи между
> записями. Это кошмар!

Указание в поле 905 "Шифр в просмотр выводить" и призвано избавить пользователей от перешифровки. Но забыли применить его на WEB и в печатных формах. Или это тоже не подходит?

Сорокина Лариса написал(а):
> Если я правильно поняла, то условие вывода
> шифра,указанное в 905 поле помогает, но надо,
> чтобы оно работало также на WEBе и в печатных
> формах. Так?
Это должно быть абсолютно везде - в Web не только том который новый +, но нужен и для старого, в J-ИРБИС и абсолютно во всех печатных формах (карточки, биб. указатели, ничего не должно быть забыто или пропущено).
Тот пример, что я приводила выше - выводим мы на результатах некого поиска Библиографический указатель по автору/заглавию и идем с ним к полке чтобы подобрать по этому списку книги, очень важно чтобы там в скобках был шифр настоящий полочный (906+908), а не из 903 поля. Но при этом я же не знаю, вдруг в другой библиотеке как-то иначе полочные делают.
На самом деле, нам бы нужно не 905 поле - его же для всей базы придется добавлять глобальной корректировкой (тоже возможно на крайний случай), а параметр в ини-файле.
Вообще то проблема шире. То что в 903 поле находится шифр систематический не очень хорошо в целом. Об этом выше писала Милана А.



Редактировано 4 раз. Последний раз 05.04.2019 09:47 пользователем roit.

Лариса Васильевна, получается нехорошая ситуация. Априори, при работе системы из коробки для НОРМАЛЬНОЙ работы нужно сразу же ограничивать и перенастраивать штатный функционал. И при этом каждый раз работаю с каждой записью в нее входить и вносить изменения в настройки? Где тут логика?! Почему изначально не сделали генерацию 903 поля по принципу хотя бы:

&uf('R5')'-'&uf('R5')'-'&uf('R5')'-'&uf('R5')'-'&uf('R5')

Данные в правом верхнем углу могут меняться по ряду причин в любой библиотеке. Это нормальная текущая работа. И при этом сразу же мы себя обрекаем на кучу лишних действий.

Добрый день.
Подскажите, пожалуйста, почему при занятых экземплярах, система позволяет изменить шифр документа в БД?
Если не ошибаюсь, в ранних версиях этого нельзя было сделать.
Ирбис64 2018.1 D6.

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Добрый день.
> Подскажите, пожалуйста, почему при занятых
> экземплярах, система позволяет изменить шифр
> документа в БД?
> Если не ошибаюсь, в ранних версиях этого нельзя
> было сделать.
> Ирбис64 2018.1 D6.

С прикреленным файлом контроля я такого не вижу. У вас какой?

По объему файл такой же, от 29.06.2016. Заменила Вашим файлом, все равно система изменяет шифр, при том что экземпляры числятся за читателями.
Система не должна же разрешать изменять шифр в таком случае.

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> По объему файл такой же, от 29.06.2016. Заменила
> Вашим файлом, все равно система изменяет шифр,

что значит "система изменяет шифр"? Вы корректируете поле 903 записи, у которой в 910 поле присутствуют экземпляры со статусом "1"? И система позволяет сохранить ваши изменения без всякого предупреждения?

Все верно. Либо статус 1, либо количество выданных экземпляров отлично от 0.
Удаляем поле 903, чтобы переформировать его при изменении УДК, и система присваивает новый шифр, не смотря на то, что экземпляры числятся выданными. Связь с БД Читателей теряется, т.к. уже шифры издания разные.
Конечно, стараются сотрудники перепроверять, чтобы не было выдач издания, но не всегда.

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Все верно. Либо статус 1, либо количество выданных
> экземпляров отлично от 0.
> Удаляем поле 903, чтобы переформировать его при
> изменении УДК, и система присваивает новый шифр,
> не смотря на то, что экземпляры числятся
> выданными. Связь с БД Читателей теряется, т.к. уже
> шифры издания разные.
> Конечно, стараются сотрудники перепроверять, чтобы
> не было выдач издания, но не всегда.

Прикрепите вашу запись и mhrvn.mnu.

Лариса Васильевна, прикрепила запись и справочник.

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Лариса Васильевна, прикрепила запись и справочник.

Да. Наконец увидела. Видимо в документах с выданными экземплярами со статусом "U" раньше никто шифр менять не пытался. Формат !903.pft не менялся с 2005 года. Прикрепляю новый

Сорокина Лариса написал(а):
-------------------------------------------------------
> LiLi написал(а):
> --------------------------------------------------
> -----
> > Лариса Васильевна, прикрепила запись и
> справочник.
>
> Да. Наконец увидела. Видимо в документах с
> выданными экземплярами со статусом "U" раньше
> никто шифр менять не пытался. Формат !903.pft не
> менялся с 2005 года. Прикрепляю новый


Лариса Васильевна, спасибо! Сейчас не дает изменить шифр при выданных изданиях.
Еще одна идея по этому поводу. А можно ли запретить изменять шифр документа, если издание было хоть раз выдано? Это важно нам для статистики, чтобы не терялась связь между читателями и эК.

Елена, КрЦНТИБ Красноярской ж.д.

Лариса Васильевна, уже много лет просим - отвяжите 903 поле от индексов! Ну это же не правильно, менять уникальные данные записи из-за того, что в библиотеке часть фонда переместилась с одной полки на другую, или сделали более дробное деление. Поле 903 используется в книговыдачи (переносится из ЭК во вторую базу), после архивирования данных о возвращенных книгах, это поле переносится в базу архива (третья база), а есть еще базы КЗД и Авторитетные файлы, в которые тоже копируются шифры из 903 поля. Из-за смены шифра в базе ЭК, дальше исчезает возможность работать с данными о старых выдачах/возвратах книг, привязывать книги в событиям или людям.

Gena написал(а):
-------------------------------------------------------
> Лариса Васильевна, уже много лет просим - отвяжите
> 903 поле от индексов! Ну это же не правильно,
> менять уникальные данные записи из-за того, что в
> библиотеке часть фонда переместилась с одной полки
> на другую, или сделали более дробное деление. Поле
> 903 используется в книговыдачи (переносится из ЭК
> во вторую базу), после архивирования данных о
> возвращенных книгах, это поле переносится в базу
> архива (третья база), а есть еще базы КЗД и
> Авторитетные файлы, в которые тоже копируются
> шифры из 903 поля. Из-за смены шифра в базе ЭК,
> дальше исчезает возможность работать с данными о
> старых выдачах/возвратах книг, привязывать книги в
> событиям или людям.

Попробую

Добрый день.
В самостоятельно созданной БД шифр документа формируется с использованием формата &uf('R'). Есть проверка на дублетность dbnflc.pft, шифр проверяется. Сейчас заметили, что в БД появились дублетные шифры, в БД около 50 тыс. записей, а дублетных шифров уже не один десяток. В БД записи создаются и крайне редко корректируются, поэтому и не замечали ранее, что появились дублетные шифры.
Могу изменить формат, например, на &uf('R9'), увеличить количество символов в шифре, но возник вопрос.
При создании записи автоматически сформированный шифр документа должен каким-то форматом еще проверяться на уникальность?

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Добрый день.
> В самостоятельно созданной БД шифр документа
> формируется с использованием формата &uf('R').
> Есть проверка на дублетность dbnflc.pft, шифр
> проверяется. Сейчас заметили, что в БД появились
> дублетные шифры, в БД около 50 тыс. записей, а
> дублетных шифров уже не один десяток. В БД записи
> создаются и крайне редко корректируются, поэтому и
> не замечали ранее, что появились дублетные шифры.
>
> Могу изменить формат, например, на &uf('R9'),
> увеличить количество символов в шифре, но возник
> вопрос.
> При создании записи автоматически сформированный
> шифр документа должен каким-то форматом еще
> проверяться на уникальность?

Рекомендую шифр создавать как-то так:

&uf('R4')'-'&uf('R4')'-'&uf('R4')'-'&uf('R4')'-'&uf('R4')

Будет создаваться шифр из 5 блоков по 4 случайные цифры. Это помогает несколько решить эту проблему.

По умолчанию проверки на созданный шифр нет, но ее можно ввести в автоввод.

Жаль, конечно, что нет такой проверки. Я уже на себя стала думать, что что-то упустила.
Геннадий, если можно, пожалуйста, поделитесь как можно ввести проверку в автоввод. Интересно как это можно реализовать.

Елена, КрЦНТИБ Красноярской ж.д.

Решила попробовать доработать autoin.gbl, добавив после формирования поля 903 проверку его на уникальность. Посмотрим как будет работать, будут ли появляться дублеты шифров.
Если кому интересно, оставляю свой фрагмент.
REPEAT
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
IF
if &uf('J,',"I="v903)<>'' then '1' fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
DEL
903
*
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
ADD
903
XXXXXXXXXXXXXXXXXXX
&uf('R9') *** или любой другой формат формирования поля 903
XXXXXXXXXXXXXXXXXXX
FI
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
UNTIL
if &uf('J,',"I="v903)<>'' then '1' fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX

Елена, КрЦНТИБ Красноярской ж.д.

Я бы в Автовводе для формирования 903 поля оставил вот такой формат:

&uf('+7w2#0'),
(if val(&uf('j,I='&uf('ag1#1')))>0 or &uf('ag1#1') = '' then 
   &uf('+7w1#'&uf('6create_903')),
   if val(&uf('ag2#1'))>10 then 
      'ERROR: Больше 10 попыток создания шифра'
      ,break,
   else 
      &uf('+7w2#'f(rsum(&uf('ag2#1')';1'),0,0)),
   fi,
else 
   &uf('ag1#1'),
   ,break,
fi)

А в файле create_903.pft прописал алгоритм формирования шифра.

Суть вот этого формата в том, что он вызывает формат create_903.pft до тех пор, пока не удается сформировать уникальный шифр, отсутствующий в текущей базе. На всякий случай я добавил заглушку, которая проверяет и после 10 неудачных попыток выдает сообщение