Поехали!

1. После регистрации выдачи экземпляров читателю при осуществлении в последующем другими операторами любых процедур (продление, возврат) система НЕ МЕНЯЕТ данные в подполе "Ответственное лицо", т.е. кто осуществлял продление/возврат не установить, т.о. НИ О КАКОЙ ОТВЕТСТВЕННОСТИ ОПЕРАТОРОВ говорить нельзя - любой сотрудник может списать книгу с читателя и при этом никто никаким образом не установит этого...


2. Также, при осуществлении любых действий как с записями читателей, так и документов, система вносит в 907 поле только дату, не внося данные ответственного лица (пользователя, при работе которого с АРМ Книговыдача были осуществлены соответствующие действия). Пример: при продлении срока пользования в записи появилось: ^A20111023^B
Почему подполе "B" пустое?

Как предложение - Не плохо было бы заполнять подполе "этап работы" - Выдача/Возврат/Продление/Корректура, т.к. для сбора и анализа статистики работы сотрудников это было бы полезно.

3. Не запоминаются параметры таблицы "Издания на руках у читателя"
Т.е. при каждом запуске АРМ необходимо заново настраивать состав, последовательность и ширину столбцов. Настройка должна быть индивидуальной и осуществляться из АРМ Книговыдача пользователем, а не PHP-программистом.

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

5. Невозможно проставить отметку о возврате экземпляров в записи читателя при отсутствии или изменении сведений об этих экземплярах либо шифра документа в БД ЭК. Конечно, это не норма жизни, но к сожалению, вполне допустимая ситуация. В 64-м система предупреждает об отсутствии сведений об экземпляре и при этом снимает отметку о выдаче данного экземпляра с читателя.

6. Система не поддерживает работу одного места выдачи объединяющего в себе нескольких мест хранения, например: в параметре настройки указано несколько мест хранения и одно место выдачи, в файле справочнике указаны соответствия мест выдачи и мест хранения.
У пользователя:
MaskMRG = БМ
MaskStore = ФО|СО|ЧЗФО|ЧЗСО



Редактировано 2 раз. Последний раз 24.10.2011 01:27 пользователем А. Роман.

Адвансед юзер пишет девелоперу о его ошибках. Если они не общеинтересны - пока не въехал, ибо нет демо 128 - может лучше по мылу?

Lavrinovich написал(а):
-------------------------------------------------------
> Адвансед юзер пишет девелоперу о его ошибках. Если
> они не общеинтересны - пока не въехал, ибо нет
> демо 128 - может лучше по мылу?

Мыло - штука скользкая, может затеряться.
(в качестве ответа получаю лишь подтверждение прочтения письма)

Пункты 1, 4-6 -КРАЙНЕ КРИТИЧНЫ для работы библиотеки с АРМ, поэтому очень нужна реакция разработчикА.



Редактировано 2 раз. Последний раз 11.01.2012 11:03 пользователем А. Роман.

При печати контрольного талона штрих-коды читателя и выданного экземпляра имеют одинаковое отображение и при считывании их сканерами имеют значение Code128 вместо положенных значений идентификаторов читателя и экземпляра.

п. 1-2. Список желаемых кодов операций и их расшифровок можете набросать?

3. PHP-программист для этого не нужен.

Цитата:

п. 8.3.4.2 документации:
Порядок колонок (элементов) и порядок сортировки строк табличной формы является настраиваемым в зависимости от потребностей пользователя (см. п.8.3 Общая характеристика пользовательского интерфейса). Установленный порядок колонок и сортировки сохраняется только в текущем сеансе работы пользователя.
Выбор какие столбцы в списке изданий на руках у читателя видны, а какие по умолчанию не видны, можно настроить через серверный INI-файл (irbisb.ini). Параметры, отвечающие за это (и их значения по умолчанию):
[MAIN]
//Шифр
BLSHIFRHIDE=0
// brief
BLDESCHIDE=0
// Дата выдачи
BLDATEVIDHIDE=0
// Дата предполагаемого возврата
BLDATEVOZHIDE=0
// Инв. номер
BLEKZHIDE=0
// Штрих код
BLSHKHIDE=0
// БД ЭК
BLBDEKHIDE=1
// Ответственное лицо
BLOTVFACEHIDE=0
// Место хранения
BLMHRHIDE=1
// Место выдачи
BLMVIDHIDE=0

4. Может. Если запретить пользователю менять параметры. ([MAIN] OPTIONABLE установить в 0). Собственно, а что именно хочется запретить пользователю в той форме кроме даты предполагаемого возврата?

5. Это не норма жизни и ситуация НЕ допустимая. По крайней мере, на рабочем месте выдачи это точно разрешать нельзя. Решение такой проблемы задача не для оператора выдачи - это задача для администратора.

6. На сегодняшний день это так. Для осуществления такого режима работы придется или постоянно переключаться между местами хранения в фильтре или отключить контроль места храниния через *. В ближайшем после Libcom'а релизе постараюсь возможность такой работы ввести.

Про контрольный талон: Поправлено.

Михайленко Илья написал(а):
-------------------------------------------------------
> п. 1-2. Список желаемых кодов операций и их
> расшифровок можете набросать?

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


> 3. PHP-программист для этого не нужен.
>

С PHP-программистом - погорячился, признаю. Но почему нельзя сохранять последовательность и отображение столбцов (т.е. соотв. параметров) в пользовательском ini, как впрочем, и их ширину (в относительном выражении)?



> 4. Может. Если запретить пользователю менять
> параметры. ( OPTIONABLE установить в 0).
> Собственно, а что именно хочется запретить
> пользователю в той форме кроме даты
> предполагаемого возврата?

Поверьте, это не мне "Хочется", это требование технологии.
Сроки пользования менять необходимо однозначно, а вот место выдачи и прочие маски по ситуации.
При этом желательно привязывать к некоторым полям файлы меню, с конкретными наборами разрешений. Например, для одной группы пользователей, места выдачи из <пункт выдачи 1>.mnu для другой - <пункт выдачи 2>.mnu, т.е. чтобы нельзя было в произвольной форме с клавиатуры ввести любое значение маски.
Т.е. главная задача - ограничить действия оператора зоной ответственности по пункту обслуживания, при этом оставив возможность регистрировать операции с разными обозначениями места выдачи и места хранения (опять же - в пределах зоны ответственности).


> 5. Это не норма жизни и ситуация НЕ допустимая. По
> крайней мере, на рабочем месте выдачи это точно
> разрешать нельзя. Решение такой проблемы задача не
> для оператора выдачи - это задача для
> администратора.

С тем, что это не нормально, согласен. Но в иногда такое все-же происходит. На сколько я понял, А.И. ввел такую возможность в 64-м именно потому, что она в принципе возможна. Обращаться к администратору (или ответственному по отделу обслуживания) в таких случаях конечно же необходимо, но прежде надо иметь оператору возможность снять отметку с читателя, т.к. он вернул экземпляр с указанными параметрами - ш-к, инв. номер, наименование.


> 6. На сегодняшний день это так. Для осуществления
> такого режима работы придется или постоянно
> переключаться между местами хранения в фильтре или
> отключить контроль места храниния через *. В
> ближайшем после Libcom'а релизе постараюсь
> возможность такой работы ввести.
>
> Про контрольный талон: Поправлено.

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

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

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

Если предложите - реализую. Может, сделать в виде параметров ини?
Например:
[BOOKLAND]
ETR_LANDIN=ВЫД
ETR_LANDOUT=ВОЗВР
ETR_LANDPRODL=ПРОДЛ
ETR_LANDVISIT=ПОСЕЩ
ETR_LANDREREG=ПЕРЕРЕГ

и так далее.

> > 3. PHP-программист для этого не нужен.
> С PHP-программистом - погорячился, признаю. Но
> почему нельзя сохранять последовательность и
> отображение столбцов (т.е. соотв. параметров) в
> пользовательском ini, как впрочем, и их ширину (в
> относительном выражении)?

Подумаю, как это можно реализовать. Препятствие - различные разрешения и размеры окон, различия браузеров.

> > 4. Может. Если запретить пользователю менять
> > параметры. ( OPTIONABLE установить в 0).
> > Собственно, а что именно хочется запретить
> > пользователю в той форме кроме даты
> > предполагаемого возврата?
> Поверьте, это не мне "Хочется", это требование
> технологии.
> Сроки пользования менять необходимо однозначно, а
> вот место выдачи и прочие маски по ситуации.
> При этом желательно привязывать к некоторым полям
> файлы меню, с конкретными наборами разрешений.
> Например, для одной группы пользователей, места
> выдачи из <пункт выдачи 1>.mnu для другой - <пункт
> выдачи 2>.mnu, т.е. чтобы нельзя было в
> произвольной форме с клавиатуры ввести любое
> значение маски.
> Т.е. главная задача - ограничить действия
> оператора зоной ответственности по пункту
> обслуживания, при этом оставив возможность
> регистрировать операции с разными обозначениями
> места выдачи и места хранения (опять же - в
> пределах зоны ответственности).

Сделаю возможность прятать кнопку фильтра и выбор места выдачи. Имя справочника так же запараметрирую

> > 5. Это не норма жизни и ситуация НЕ допустимая.
> По
> > крайней мере, на рабочем месте выдачи это точно
> > разрешать нельзя. Решение такой проблемы задача
> не
> > для оператора выдачи - это задача для
> > администратора.
> С тем, что это не нормально, согласен. Но в иногда
> такое все-же происходит. На сколько я понял, А.И.
> ввел такую возможность в 64-м именно потому, что
> она в принципе возможна. Обращаться к
> администратору (или ответственному по отделу
> обслуживания) в таких случаях конечно же
> необходимо, но прежде надо иметь оператору
> возможность снять отметку с читателя, т.к. он
> вернул экземпляр с указанными параметрами - ш-к,
> инв. номер, наименование.

И как потом искать проблему? Описание из 40^A стирается при возврате, инв№/шк/шифр изменились, т.е. возникшая проблема в 99% просто теряется. Почему нельзя просто отложить книгу и вложить в нее листок с фио или идентификатором читателя? Ну не правильно это - решать одну проблему, сознательно создавая другую еще более тяжело разрешаемую. Задержка выплывет не на этапе возврата, так на этапе выдачи (экземпляр уже числится выданным). А если статус не 0/1 а U - тогда совсем караул: какие экземпляры, сколько их и кому выданы - уже не понять вовсе.
Нет. Пока не убедили.

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

Видел это в живую. Посочувствовал.

> Маску * ставить нельзя, т.к. в этом случае можно
> будет выдать (вручную введя значение инвентаря или
> ш.к.) экземпляр из любого другого отдела.
> пожалуйста, реализуйте возможность работы с
> разными сиглами хранения для одного места выдачи.
> Без этого - никак нельзя.

Через * можно, но, как Вы правильно заметили, не есть хорошо. Сделаю.


PS: Спасибо большое за обсуждение. Очень "напрягает" молчание - не понятно, все ли устраивает, какие проблемы есть.

То, что взял в работу смогу реализовать только после либкома и Новосибирска т.е. после 28-го

Михайленко Илья написал(а):
-------------------------------------------------------
> То, что взял в работу смогу реализовать только
> после либкома и Новосибирска т.е. после 28-го

После 28-го числа какого месяца? Через 3 дня исполнится ровно 2 месяца с момента открытия темы...
Пожалуйста, обозначьте сроки выпуска обновлений. До сих пор нет возможности использовать АРМ (не учитывая отсутствие системы заказов).
Письма по эл. почте отправлял 2-го и 16-го декабря. Ответа пока не получил.

Р.S. На счет молчания - согласен, напрягает.

Очень много неожиданных для меня поездок. Успеваю меньше чем хотелось бы. :( Имелось ввиду после 28 ноября. Не ожидал, что после Либкома и Новосиба будет еще несколько незапланированных командировок.

Обещанные маски и параметры будут к концу новогодних праздников в постновогодней версии.

PS: Хочется все же услышать предложения по этапам работы.

Михайленко Илья написал(а):
-------------------------------------------------------

> PS: Хочется все же услышать предложения по этапам
> работы.

;) Как только увижу на своем сервере рабочую версию системы, с удовольствием обозначу предложения.