АРМ Каталогизатор. Новые сервисные возможности:
1. Обеспечены ОПЕРАТИВНЫЕ РЕЖИМЫ для сборников с расписанным содержанием, т.е обеспечена оперативная связь и переходы между сборником и аналитическими описаниями - аналогично периодическим изданиям.
2. Для ИРБИС64 введен новый параметр INI-файла (серверного) в разделе [MAIN]
AutoMerge, определяющий факт автоматического слияния несовпадающих версий записи при корректировке - подробнее см. [irbis.gpntb.ru]
3. Обеспечено клавиатурное управление словарями, меню, навигаторами через соотвествующую редактируемую строку КЛЮЧ - подробнее см. [irbis.gpntb.ru]

АРМ Каталогизатор. Новая опция-режим АВТОСЕРВИС.
Суть опции - если она включена - состоит в том, что при установке курсора ввода на ПУСТОЕ поле/подполе автоматически открываются предусмотренные для соотвествующего элемента ПРОСТЫЕ сервисные средства ввода. Под простыми понимаются инструменты ввода через справочники и словарь (НЕ в режиме МУЛЬТИ). Средства ввода открываются автоматически в ПЛАВАЮЩЕМ окне, т.е. фокус ввода остается на текущем элементе ввода. Автоматическое открытие средств ввода происходит, если курсор задерживается в окне ввода более определенного времени (полсекунды).
Данная опция-режим может быть полезна для обучающихся каталогизаторов...



Редактировано 1 раз. Последний раз 15.03.2007 11:36 пользователем Alio.

АРМ Каталогизатор.

В интерфейсе для работы с буферной записью введен режим СРАВНИТЬ, который заключается в том, что сравниваются буферная запись и текущая запись в РЛ ввода и ОТЛИЧАЮЩИЕСЯ поля и там и там отмечаются.
При сравнении повторяющихся полей их номер повторения НЕ учитывается.
При сравнении значений полей регистр учитывается.
Данный режим имеет отношение к проблеме, которая обсуждалась в [irbis.gpntb.ru]



Редактировано 1 раз. Последний раз 15.03.2007 11:37 пользователем Alio.

АРМ Книговыдача.

Обеспечена возможнось ИСПОЛЬЗОВАТЬ в режиме печати (ОКНО ЧИТАТЕЛЬ - КНОПКА ПЕЧАТЬ) ОТМЕЧЕННЫЕ (птичками) сведения о выданной литературе.
Сведения об отметках - т.е. НОМЕРА отмеченных повторений поля 40 - передаются в формат печати через повторения модельного поля 1001. В дистрибутиве предлагается пример такого формата печати (rdr_html_marked.pft)

АРМ Книговыдача ИРБИС64

Обеспечена возможность непосредственного перехода к КОРРЕКТИРОВКЕ записи текущего читателя, т.е в окне ЧИТАТЕЛЬ АРМа Книговыдача появилась КНОПКА, по которой осуществляется переход к АРМу Каталогизатор и корректировке соотвествующей записи БД RDR.

Также обеспечена возможность непосредственного перехода к ПРОСМОТРУ/КОРРЕКТИРОВКЕ записи ЭК, соответствующей текущим сведениям о выдаче, т.е. по правой кнопке мыши в таблице сведений о выдаче/возврате (ОКНО Читателя) возникает меню, в котором можно выбрать режим перехода к АРМу Каталогизатор для ПРОСМОТРА/КОРРЕКТИРОВКИ соотвествующей записи ЭК. В этом всплывающем меню также предлагаются режимы:
- ПОЛНОСТЬЮ (позволяет компактно, в одном окне, просмотреть текущие сведения о выдаче/возврате, в т.ч. краткие сведения о ВОЗВРАЩЕННОЙ литературе, которые не показываются по умолчанию)
- УДАЛИТЬ
- ВОЗВРАТ
- ПРОДЛИТЬ

ИРБИС64

Предлагается технология ВЛОЖЕННОСТИ для СЕРВЕРНЫХ ini-файлов - которая позволяет существенно упростить ведение профилей пользователя (особенно в случае их большого количества)
Идея состоит в том, что конкретный личный INI-файл (профиль) может ссылаться на стандартный (общий, групповой) и непосредственно в себе содержать ТОЛЬКО те параметры, которые отличают конкретный профиль от стандартного.
Например:

[@irbisс]

[MAIN]
DBNNAMECAT=dbnam_rdr.mnu
DefaultDB=RDR


такой профиль каталогизатора будет отличаться от стандартного (irbisc.ini) только двумя параметрами.

В этом случае - изменение общих параметров в стандартном ini-файле приведет автоматически к изменению соотвествующих параметров в личных профилях, которые ссылаются на стандартный.

Теперь подробнее.

Вложенный ini-файл указывается в исходном ini-файле в виде ПУСТОЙ секции

[@<имя_ini_файла>]

Местоположение вложенного ini-файла внутри исходного НЕ ИМЕЕТ значения.

В случае ОДНОИМЕННЫХ параметров в ОДНОИМЕННЫХ секциях приоритет за ИСХОДНЫМ INI-файлом.

Вложенный ini-файл берется по тому же пути, что и исходный.

Обновление параметров - например, по настройке - осуществляется в ИСХОДНОМ (самом верхнем) ini-файле

АРМ Читатель (ИРБИС64)

Обеспечен контроль на дублетность заказов на книговыдачу. Т.е. если читатель пытается повторно заказать на книговыдачу издание и при этом в очереди заказов от этого читателя есть НЕВЫПОЛНЕННЫЙ заказ на это иэдание, выдается соответствующее сообщение и заказ не создается. (Обеспечено за счет дополнительной инверсии в БД RQST связки ИДЕНТТИФИКАТОР ЧИТАТЕЛЯ/ШИФР ИЗДАНИЯ)

АРМ Книговыдача (ИРБИС64)

Введен новый режим ОФОРМЛЕНИЕ (возврат) УТЕРЯННЫХ экземпляров.
Для выполнения данного режима служит соответствующая инструментальная кнопка в окне ЧИТАТЕЛЯ и пункт главного меню в разделе ЧИТАТЕЛИ.
Для оформления утерянных экземпляров необходимо ОТМЕТИТЬ соотвествующе сведения о выданной литературе в окне ЧИТАТЕЛЬ.
В результате выполнения режима производится следующая корректировка:
- в БД RDR в записи соответствующего читателя оформляется возврат для соответствующих изданий и дополнительно делается отметка в специальном подполе (ставится 1 в подполе U в соответствующем повторении поля 40)
- в БД ЭК:
- для экземпляров индивидуального учета устанавливается статус УТЕРЯН (4)
- для экземпляров группового учета оформляется возврат (т.е. уменьшается на единицу кол-во выданных экземпляров - подполе 2), изменяется (уменьшается на единицу) общее количество экземпляров (подполе 1) и дополнительно создается описание нового экземпляра (т.е. создается новое повторение поля 910) со статусом УТЕРЯН (4) и остальными подполями, совпадающими с описанием экземпляра группового учета (исключая подполя 1 и 2)

В БД RDR создается дополнительная инверсия (словарь) - УТЕРЯННЫЕ
ЭКЗЕМПЛЯРЫ.

(Также реализовано в ИРБИС32)



Редактировано 1 раз. Последний раз 22.05.2007 11:36 пользователем Alio.

АРМ Читатель

Обеспечена возможность пересылки результата поиска на E-mail - за счет того, что в режиме ПЕЧАТЬ появилась дополнительная опция при выборе выходного носителя.
ВЫХОДНОЙ НОСИТЕЛЬ:
ФАЙЛ - БУМАГА - E-mail

При этом используются два новых параметра INI-файла (секция [MAIN], для ИРБис64 - серверный INI)
MAILHOST= адрес хоста
MAILFROM= отправитель

Разработан HTML-формат для печати штрих-кодов в несколько колонок с размножением для экземпляров со статусом U
Для изменения кол-ва и размера колонок в формате отмечены соответствующие места.
Если кому-то уже сейчас необходим такой формат, обращайтесь...

Alio написал(а):
-------------------------------------------------------
> Разработан HTML-формат для печати штрих-кодов в
> несколько колонок с размножением для экземпляров
> со статусом U
> Для изменения кол-ва и размера колонок в формате
> отмечены соответствующие места.
> Если кому-то уже сейчас необходим такой формат,
> обращайтесь...

Великолепно! И указание на то, что форматы могут быть использованы со старыми версиями исполняемых файлов, звучит просто интригующе. Я был убеждён, что единственный режим вывода в HTML – режим печати простых списков никак не позволяет этого сделать(http://irbis.gpntb.ru/read.php?10,21661,22124)

Или я всё-таки ошибаюсь, речь идёт о комплексной доработке системы, включающей изменение исполняемых файлов?

Это обычные форматы, которые будут работать в любых версиях системы (начиная с тех, где появились глобальные переменные и HTML-форматы)

Уважаемые коллеги, предлагаю к рассмотрению следующую технологию:

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


Смысл предложения заключается в следующем - по существующей технологии штрих-код книги должен быть уникальным (как и инвенарный номер), т. е. не допускается наличие двух и более повторений 910 поля, содержащих одинаковые значения штрих-кода, хотя одно значение штрих-кода на партии идентичных книг - обычное явление.
Эта ситуация крайне неудобна в случае передачи части экземпляров между разными пунктами выдачи, а также и в случае передачи части книг в библиотеки филиалов.
Пример: Имеется 500 (идентичных) экз. учебника, скажем - по истории отечества. Которые распределены поровну между двумя корпусами вуза. Со временем изменилось соотношение студентов, которым требуется данный учебник, скажем 2/3:1/3. При этом, необходимо оперативно (это в нашей жизни обычный термин) передать 50 экз. учебника в один или два филиала.

Так вот, в таком случае в записи БД будет 2 повторения 910 поля:
#910: ^AU^H00001^1250^DАБ1...
#910: ^AU^H00002^1250^DАБ2...


В результате необходимо:
1. Из общего числа отобрать 50 экз. для филиалов.
2. Из оставшихся 225 экз. АБ2 75 отобрать для передачи на АБ1
(возможны варианты с закупкой доп. партии учебников, но это в условиях тендеров и котировок процесс крайне неоперативный)
3. На 50 экз. для филиала(ов) переклеить этикетки со ш.-к. (кол-во значений ш.-к. - по количеству филиалов)
4. Допечатать 75 экз. этикеток для экз., передаваемых в фонд АБ1 и естественно опять-таки переклеить этикетки.

В итоге в БД должно получиться:

#910: ^AU^H00001^1300^DАБ1...
#910: ^AU^H00002^1150^DАБ2...
#910: ^AС^H00003^120^DФИЛ1...
#910: ^AС^H00004^130^DФИЛ2...


Согласитесь - не очень-то удобная процедура.

Все было бы гораздо проще, в случае, если бы изначально была картина:

#910: ^AU^H00001^1250^DАБ1...
#910: ^AU^H00001^1250^DАБ2...

тогда действия бы заключались в следующем:

1. Отобрать 50 экз. для библиотек филиалов.
2. Из фонда АБ2 отобрать 75 экз. для АБ1.
Переклеивать и допечатывать этикетки - НЕ ТРЕБУЕТСЯ!

В записи получим:

#910: ^AU^H00001^1300^DАБ1...
#910: ^AU^H00001^1150^DАБ2...
#910: ^AС^H00001^120^DФИЛ1...
#910: ^AС^H00001^130^DФИЛ2...


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



Редактировано 4 раз. Последний раз 04.07.2007 15:30 пользователем А. Роман.

АРМ Книговыдача

Обеспечена возможность пересылки результата печати (окно/режим ЧИТАТЕЛЬ - ПЕЧАТЬ) на E-mail - за счет того, что появилась дополнительная опция при выборе выходного носителя.
ВЫХОДНОЙ НОСИТЕЛЬ:
ФАЙЛ - БУМАГА - E-mail

Если в записи читателя указан E-mail, то он предлашается по умолчанию.


При этом используются два новых параметра INI-файла (секция [MAIN], для ИРБис64 - серверный INI)
MAILHOST= адрес хоста
MAILFROM= отправитель

Alio написал(а):
-------------------------------------------------------
> Разработан HTML-формат для печати штрих-кодов в
> несколько колонок с размножением для экземпляров
> со статусом U
> Для изменения кол-ва и размера колонок в формате
> отмечены соответствующие места.
> Если кому-то уже сейчас необходим такой формат,
> обращайтесь...

Пришлите, пожалуйста(sokolinsky[sobak]@de.nwpi.ru). Очень интересно посмотреть, как работает этот формат.

Alio написал(а):
-------------------------------------------------------
> Разработан HTML-формат для печати штрих-кодов в
> несколько колонок с размножением для экземпляров
> со статусом U
> Для изменения кол-ва и размера колонок в формате
> отмечены соответствующие места.
> Если кому-то уже сейчас необходим такой формат,
> обращайтесь...

Больше спасибо за формат. Несомненно, он является ещё одним шагом к разработке новой методики печати штрихкодов. Тем не менее, в описываемом решении заложен целый ряд ограничений, которые делают его недостаточно эффективным.
1.Из-за проблемы переполнения один штрихкод может быть распечатан только в 351 экземпляре. Поэтому в ВУЗовских библиотеках, где количество экземпляров может доходить до 3000, использование этого формата невозможно. (Именно по этой причине я в своё время отказался от использования режима печати списков.)
2.При печати штрихкодов колонками(на листах А4) много этикеток оказывается пропущено. Штрихкоды для каждой записи выводятся с новой строки, и, при использовании листа с четырьмя колонками, в ходе печати одного штрихкода для одной книги три этикетки теряются.
На первый взгляд какая-нибудь небольшая доработка может легко устранить этот недостаток, но при более внимательном рассмотрении оказывается, что ограничения режима печати списков не могут быть преодолены.
Штрихкоды не удастся печатать в одной большой таблице(<table> ) змейкой, поскольку в режиме печати списков нельзя определить какая запись является последней и в какой момент нужно поставить закрывающий тег(</table> ). Для каждой записи приходится создавать свою таблицу.
3.Невозможна сортировка штрихкодов. Это неудобно если партия распечатки достаточно велика.
4.В этом режиме не может быть реализовано деление на страницы. При печати на листах А4 это неизбежно приведёт к постепенному «сползанию» штрихкодов.
Вставить разрыв страницы очень просто, но фиксировать количество выведенных штрихкодов потребуется в глобальной переменной. Если не очищать глобальную переменную после завершения формирования списка, то при печати следующего списка она станет причиной некорректной установки разрыва.

Таким образом, вопрос о печати штрихкодов в режиме ТАБЛИЧНЫХ форм не утратил свою актуальность.



Редактировано 1 раз. Последний раз 05.07.2007 21:13 пользователем Кирилл Соколинский (СЗТУ).

АРМы Каталогизатор и Читатель

Введен дополнительный сервис при управлении словарем с помощью редактируемой строки КЛЮЧ - при вводе ключа осуществляется "подсказка" его возможного продолжения в соответствии с текущим словарем.
Сервис можно отключить с помощью параметра INI-файла (секция [MAIN])

KEYSERVICE=0

По умолчанию сервис включен.