Только приступаем к автоматизации обслуживания и не знаем как правильно настроить клиентов для доступа к серверу, исходя из интересов именно этого АРМа. Должны ли мы для каждого сотрудника отдела обслуживания (несколько разных абонементов, читальный зал) сделать личного клиента с его личным ini файлом, или мы должны создавать общие клиенты для каждого места выдачи. Т.е., например, клиент uchab - для учебного абонемента, nauch - для научного абонемента, cz - для читального зала и т.п. Вопрос связн с тем, что, как мы поняли, настройки количества книг и количества дней на которые эти книги можно выдать находятся в ini файлах. Если будут личные файлы сотрудников, а сотрудники эти у нас не закреплены жестко за абонементами, они постоянно подменяют друг друга, то как тогда настраивать эти параметры, которые различаются у разных абонементов между собой и еще свои у читального зала, неясно.

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

Вот тут то и получается непонятная ситуация: настройки максимального количества выдаваемых книг и максимального количества дней в ини-файле клиента. Задаю я макисмальное количество книг, которое выдает библиотекарь на художественном абонементе = 5 и кол-во дней = 30. Приходит этот библиотекарь на учебный абонемент, заходит под своим паролем, а там он должен выдать читателю книги на весь учебный год в гораздо больших (несколько десятков) количествах. И как это сделать? Еще и читальный зал есть.Там книги выдают на 1 день. Приходит оттуда поработать библиотекарь на абонемент и как? Я только осваиваю ИРБИС и может я чего-то не понимаю, может эти настройки в каком-то еще месте, а я не сумела правильно прочесть инструкцию?
Пожалуйста, помогите разобраться! Клиентов и ини-файлы настраивать надо, а как поступить, чтобы книговыдача шла правильно неясно



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

Присоединяюсь к вопрошающему!!! Отзовитесь, горнисты! Ждем ответа!

Если Маша, работает в отделе обслуживания, сектор художественного абонемента, и ИМЕЕТ право заменять подругу в секторе студенческого абонемента, то Маше надо сделать ДВА (три-четыре, в зависимости от количества мест, на которые ее могут "подвинуть") профиля, с базовым именем Маша и с теми настройками, которые являются ВЕРНЫМИ для данного места выдачи, а Маше объяснить, на своем ОСНОВНОМ рабочем месте заходишь под таким профилем, а если тебя передвинули на студенческий абонемент, то под таким и т.д. Может быть так?

Вопрос с количеством книг еще +- понятен. Более того, логично было бы вы вынести в ини файл соответствие абонемент - количесвто книг, дабы вообще не привязывать этот момент к ини-файлам. Так же можно было бы поступить и с датой выдачи. Сейчас срок выдачи регулируется файлом return.mnu, который указан у всех ини файлов по умолчанию. Логично предположить, что для разных ини-файлов могут быть заданы разные сроки выдачи. Но морочить голову из-за одного единственного абонемента, на котором срок отличается от других - это как-то расточительно по трудоемкости доработок. Скажите пожалуста, реально ли у вас, кроме как в читальном зале, много отличающихся сроков выдачи на разных абонементах? Я в разных библиотеках встречал только ситуации, в которых книги с одного абонемента выдаются на разные сроки, это было связанно с количесвтом экземпляров: много книг - бери хоть на месяц, одна-две - только на несколько дней. Но это правило одинаковое для всех абонементов в рамках одной библиотеки и регулируется при выдачи выставлением даты возврата.

Это как бы в рамках обсуждения проблемы...

Вот наш пример. В читальном зале и справочном отделе книги выдаются на 1 рабочий день, ограничений в количестве нет; в отделе нотной литературы студенту на 1 день, преподавателю могут - на больший срок (сейчас не помню какой); на учебном абонементе книги выдаются на весь учебный год (с сентября по июнь) в неограниченном количестве; на художественном - на месяц в количестве 5 книг; на научном абонементе - в зависимости от количества книг на полке (как Вы и описывали) от 5 дней до месяца и тоже только 5 книг, при этом преподавателям там же может быть выдано и более 5 книг. Заводить, как тут предлагали, "для одной Маши" разные профили не кажется рациональным. Работа сотрудников отдела обслуживания на разных абонементах, взаимные подмены, не какая-то разовая ситуация, а, увы, довольно таки постоянная (не хватает сотрудников + еще много студентов работает, а у них сессии в период которых совсем острая нехватка сотрудников).

Здравствуйте, уважаемые коллеги!

Ни в коем случае не претендую на истину в последней инстанции, но все же...

Мой личный опыт (работаю в вузовских библиотеках с 1999г.) не дает мне возможности говорить, что указанная ситуация с подменами работы сотрудников - общая практика. Я лично встречал такие ситуации 1-2 раза, за все время, хотя знаком с парой-тройкой десятков библиотек. Наоборот, в большинстве случаев сотрудники очень жестко привязаны к конкретным пунктам (отделам) выдачи. Но тем не менее, описанные выше ситуации никто не отвергает.

Логика, проверки соответствия параметров книговыдачи для конкретного пользователя довольно-таки сложная и разветвленная, чтобы говорить о ее модернизации или не дай Бог - замене. Тут и фильтры (по месту выдачи) отображения информации о выдачах, и сведения о предварительных заказах и права пользователя на те или иные действия (кнопочки интерфейса АРМ) и т.д. и т.п.

Как наиболее простой и понятный (в рамках действующих правил и настроек) мне видится следующее решение. Т.к. АРМ допускают работу с вложенными (по крайней мере одним уровнем) ini-файлами (читай профилями), то:
1. Для каждого пункта обслуживания создаются ini с общими для всех сотрудников параметрами характерными для данного места выдачи.

2. Выделяются категории сотрудников - по правам и привилегиям и создаются ini с правами групп для каждого из отделов (напр. один профиль - только для выдачи/возврата, другой - для оформления утери и работы с платными услугами и т.п.) для каждого мета выдачи.

3. для конкретных сотрудников создаются ini (как конструктор) набором соотв. общих и категорийных ini файлов отдельно ДЛЯ КАЖДОГО ПУНКТА ВЫДАЧИ. например: Маша-ЧЗ, Маша-ОУЛ, Маша-НБ и т.п. При этом пароль у Маши вполне м.б. единым для всех пунктов обслуживания.

Порядок должен быть. Его гарантирует проработка структуры ini (профилей) иначе - может получиться бардак. Очень советую (а согласно закону о защите персональных данных - эти меры просто неизбежно должны быть приняты - разделение ответственности за действия с ПД и возможность протоколировать эти действия и при необходимости установить ответственное за них лицо) потратить время и организовать структурированные профили.

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



Редактировано 1 раз. Последний раз 16.01.2013 08:44 пользователем А. Роман.