Для целей ведения статистики посещаемости библиотеки предлагается в записи читателя ввести новое поле: ДАТА ПОСЛЕДНЕГО ПОСЕЩЕНИЯ БИБЛИОТЕКИ. Предполагается, что поле будет НЕПОВТОРЯЮЩИМСЯ (!!!) и формироваться автоматически (при выполнении операций ВЫДАЧИ/ВОЗВРАТА/ПРОДЛЕНИЯ) и/или вручную (с помощью соотвествующего режима).
Инверсия этого поля (т.е. создание словаря по этому полю) позволит ОПЕРАТИВНО получать сведения о посещаемости библиотеки в любой день.
Жду комментариев и предложений от пользователей.

Кроме поля "последнее посещение" рекомендовал бы ввести поле счетчика, которое бы увеличивалось на 1 при изменении поля "последнее посещение", чтобы считать, сколько раз читатель посещал библиотеку в отчетный период. А в конце отчетного периода стирать эти данные в "0" глобальной корректировкой.

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

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

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

Это поле вроде чиститься иногда. Или я не прав? К тому же продление можно оформить и по телефону. Это же не посещение. Хотя... Мда, может, в таком случае, сначала определиться четко, что можно считать посещением?

Регистрация - посещение
Перерегистрация - посещение
Выдача/возврат - посещение
Если поиск, то посещение только если через АРМ Читатель (через веб - это посещение? или отдельная статистика)



г. Ярославль

> Если поиск, то посещение только если через АРМ Читатель (через веб - это посещение? или отдельная статистика)

Я считаю, что это ПОСЕЩЕНИЕ ресурсов библиотеки, и неважно, хоть на заборе этот каталог выгравировали :)

Хотя тут можно опуститься и до подсчета количества чтений пользователями библиотеки особо важных в жизни вывесок. Чем не ресурс внутри библиотеки? :)

Желающим провести эксперимент по ведению словаря (вида поиска) ПОСЕЩАЕМОСТЬ БИБЛИОТЕКИ предлагаю:
1. Внести в RDR.FST (с помощью PSETWS) нижеследующую строку

60 0 mhl,&uf('+1W1001,1000#',(if &uf('PV40^f') : '*' or &uf('PV40^f')='' then else 'VS=',&uf('PV40^f') fi/)),&uf('+1W2001,2000#',(if &uf('PV40^d')='' then else 'VS=',&uf('PV40^d') fi/)),&uf('+1A1001,',&uf('+1R1000'),'#2001,',&uf('+1R2000'))

после чего выполнить СОЗДАТЬ СЛОВАРЬ ЗАНОВО ПОЛНОСТЬЮ для БД RDR

2. В RDR.INI (с помощью PSETINI) создать новый вид поиска ПОСЕЩАЕМОСТЬ БИБЛИОТЕКИ, указав в качестве префикса VS=

Таким образом словарь ВИД ПОИСКА - ПОСЕЩАЕМОСТЬ БИБЛИОТЕКИ будет представлять собой оперативную статистику о кол-ве посещений по дням...

При этом следует иметь в виду, что под ПОСЕЩЕНИЕМ здесь понимается выполнение хотя бы одной операции ВЫДАЧИ или ВОЗВРАТА для данного читателя...

Караул!!! Что твориться? Я раньше в это поле не смотрел, а ща как глянул, даже ужаснулся. Дело вот в чем. В словаре, который Вы посоветовали создать, я нашел такие значения

020806GIUBNT - 1
020917GIUBNT - 1
030604GIUBNT - 1
200516GIUBNT - 27

Мне даже интересно стало, что это за фигня такая. Так вот. В некоторых повторениях поля 40 (вернее даже во всех) подполе F -дата фактического возврата стоит действительно такое значение!!! Я почесал репу и вот что понял.
Если смотреть на запись, в которой есть не возвращенные книги, то она выглядит так

...^E20050121^F******^GIUBNT^H00000...

И тогда меня прояснило, что на каком-то этапе выдачи книги данные заменяются не в подполе F, а берется все поле и в нем *****^ заменяется на текущую дату. При этом из записи пропадают сведения о исходной базе.
Но и это еще не все. Первые три значения еще как-то можно подвести под этот знаменатель (не хватает только первые 2-х цифр года), но вот последний термин под такое определение подвести нельзя. Хотя может и можно, только вот не хватает уже чего-то другого.
Александр Иосифович, гляньте, что может быть не так. Может у нас какие баги возникли при переходе с версии на версию. Но этот вопрос меня очень задел.

И еще заметил: запись читателя создана 2002100, книга должна возвратиться 20020213, а вот в ^F стоит 200516GIUBNT. Я вообще нефига не понимаю. Сегодня 17. Можно подумать, что если выпали сведения о месяце, то эта замена произошла вчера. А вчера я только экспорт каталога делал (в 64 заливал). Совпадение или закономерность?



Отправка отредактированного (17-01-05 19:46)

г. Ярославль

А как быть со статистикой посещений по местам автоматизированной книговыдачи?

Паневу - Таких значений в подполях ^D и ^F поля 40 БЫТЬ НЕ МОЖЕТ - это Ваши ошибки, разбор которых надо вести НЕ ЗДЕСЬ.

НБ СибГТУ - что это такое в ИРБИСе: МЕСТА АВТОМАТИЗИРОВАННОЙ КНИГОВЫДАЧИ?

В дополнение к предыдущему своему сообщению. Предложенный эксперимент (по ПОСЕШАКМОСТИ) требует использования FORMAT32.DLL версии 2004.2 - он находится на открытом [ftp.gpntb.ru]

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

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

Мы работаем реально: автоматизированная книговыдача осуществляется в двух отделах, и по каждому отделу требуется отдельная статистика посещений: выдача, возврат, регистрация, перерегистрация и т.д.!

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

Дополнение и уточнение:
Идея замечательная и может решить наболевшую проблему. Нам необходимо: фиксировать посещение, но при этом, чтобы в поле попадал номер подразделения из "Ответственное лицо" в АРМ "Книговыдача". И, соответственно, поскольку фиксирование производят разные подразделения, поле должно иметь повторение.
Тем не менее, ПРОДЛЕНИЕ - это не посещение по сути, а книговыдача. То есть в отчетности к статистике произведенных книговыдач продление плюсуется (пока точкуется по-старинке). Есть ли вероятность того, что при нажатии кнопки "Продление" 999 поле будет увеличиваться на 1?

Михаил Стрельцов

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