Уважаемые коллеги!
Просим откликнуться всех, кто работает с программой "Книгообеспеченность". Пожалуйста, выскажите свое мнение о программе. Возникают ли у вас проблемы и какие?
Заранее благодарны за ваш ответ.

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

Уважаемые коллеги!

Неужели никто, кроме Тюмени и АмГУ, не работает с модулем Книгообеспеченность????

НБ СибГТУ
lib@sibstu.kts.ru

Здравствуйте!

Мы работает по технологии УНД, но пока по 1му неинтегрированному варианту. Создан БД VUZ и ввод в поле 691 осуществляем из него. Данные по КО пока получаем практически вручную, так как при автоматическом их получении они получаются очень некорректными из-за того что не учитывается предназначенность одного учебника для студентов разных специальностей.

Проблемы :

1) первая известна: из-за отсуствия автоматической корректировки по всем БД приходится одни и те же данные исправлят вручную по всем БД, глобальную ещё не использовали ,потому что исправлялись единичные данные или ошибки, но много. Очень муторно.

2) при установленном параметре MaxCont=40, в словаре поля 691^D при просмотре "Полностью" подаются не более 20ти связок. У нас версия 2002.2 .

БД "Читатели" только начали создавать.

С уважением.

Формат koravr.pft лишний раз делит коэффициент К.О. на два (2003.2)!

А вообще правильно ли, что при расчётах коэффициента К.О. (в том числе и в koravr.pft) используется реальное значение коэф., каково бы оно ни было. Особенно при получении сводного (среднеарифметического) коэф-та.
То есть, не учитывается условие: когда коэф. К.О. оказывается > 1 то принимать его равным 1, в остальных случаях выводить реальное значение.
Конечно, чем выше коэф. К.О., тем лучше для отчёта, но хуже для читателей, поскольку сводный коэф. в таком случае скрывает качественное состояние проблемы.
Насколько справедлив по Вашему мнению Ерахторин М.В. в статье:
Расчёт и использование коэф. К.О. учебной литературой. (Библиотеки учебных заведений, №1, 2002г.).

Формат koravr.pft лишний раз делит коэффициент К.О. на два (2003.2)!

У меня это ни разу не проявлялось. Если у Вас обаружился такой эффект, пришлите, пожалуйста, на мой адрес запись ЭК и соответствующие записи читателей

Посмотрела присланные Романом БД IBIS, RDR и VUZ (работа по технологии УПЛ).
Хочу дать некоторые пояснения всем, работающим с задачей КО в версии 2003.2.
1. Если БД VUZ и RDR вводятся независимо одна от другой (не в общей сети), то может быть эффект, с которым встретился Роман : словарь "UPS=" (№ учебного плана-семестр) - пустой. Дело в том, что в связи с решением проблемы дисциплин-иностранных языков, этот словарь формируется по полю 69 (кафедра-дисциплина), и если оно отсутствует, словарь оказывается пустым (напомню, что формирование этого поля производится автоматически или при вводе поля 90 в записи RDR, или при создании/пополнении записи UPL в БД VUZ). Выход из этой ситуации простой - выполнить глобальной корректурой формальную замену поля 90 в записях RDR (REP 90 1 v90), в результате которой запись обновится, в нее будут введены поля 69 из БД VUZ и сформируется словарь.
Я, со своей стороны, могу внести изменения в таблицу формирования словаря "UPS=" в БД RDR, с тем, чтобы этот словарь формировался и при отсутствии поля 69. Но в этом случае работа с иностранными языками (точнее, привязка их к языку, изучаемому студентом) будет не определена. Нужно ли это делать?
2. По вопросу "Формат koravr.pft лишний раз делит коэффициент К.О. на два (2003.2)!" - это принципиальная проблема, и я прошу всех заинтересованных Пользователей высказать свое мнение.
Каким должен быть алгоритм счета среднего (за год) коэффициента КО при отсутствии данных в одном из полугодий в итоговых таблицах.
При просмотре отдельных записей и в выходных формах для отобранного списка "КО средний" в этом случае не определяется. А как быть с итоговыми таблицами (по циклам, новизне ...), где даются только средние данные (а не отдельно для осенних и весенних семестров). То есть нужно ли считать средним единственное значение (в реализованном варианте формат koravr.pft, считая второе значение равным 0, "уполовинивает" среднее)