Добрый день. Переносим запись поступивших экземпляров из базы CMPL в базу электронного каталога, возникло пару вопросов:
1) если оставить контроль при переносе, то ничего не получается перенести. Приходится отключать контроль;
2) перенесли в базу каталога, там в каталогизаторе написано - "издание в обработке. не выдается" (см. фото)
Видимо, какие-то действия по обработке поступившей литературы мы не выполнили, в инструкции ничего не нашли по этому вопросу.

1.Как вы переносите записи из БД CMPL?
2.В настройке, в этапе работы надо выбрать Obrzv - Обработка записи завершена

переносим так: находим запись по любому ключевому полю, в данном случае по №КСУ смотрели, во втором списке (справа) наша запись отображается (Шувариков), её отметили галочкой, нажали кнопку "Перенос в ЭК", в новом окне в первом поле выбрали наш электронный каталог, во втором поле контроль отключили и всё. Попробуем теперь еще этам работы выбрать (у нас стояло "исполнение заказа".

Рекомендуется переносить по номеру КСУ.По заданному номеру, во-первых, отбираются записи на перенос. Во-вторых, происходит доукомплектование записей каталога новыми экземплярами этой партии

т.е. получается групповой перенос с коррекцией уже существующих записей? Большое спасибо, завтра опробуем!

Подскажите пожалуйста как быть в таком случае: - АРМ "Комплектатор"- формирование очередной подписки и последующий ее перенос БД ЭК.

1. Какая у Вас версия системы?
2. Покажите несколько записей, которые Вы переносите в формате iso или txt

У нас ИРБИС64 2007.1

У Вас все эти записи переносились,смотрите 66 поле в БД CMPL в этих записях. Поэтому они не переносятся,а корректируются. При переносе в БД ЭК в соответствующую запись добавляется повторение 938 поля с новым периодом заказа

Смотрела, действительно поле 66 прописано, и 938 тоже, но поля заполняются автоматически!!!

У Вас не заполнено в БД CMPL в РЛ OJK поле Заказ по подразделениям

Lenka_X777 написал(а):
-------------------------------------------------------
> Смотрела, действительно поле 66 прописано, и 938
> тоже, но поля заполняются автоматически!!!

Новые записи на журналы при переносе создаются в следующих случаях:
1.Запись еще НЕ переносилась в заданную БД каталога (значение поля 66) и по шифру журнала запись в БД каталога НЕ найдена.
2.Запись переносилась в заданную БД каталога (значение поя 66), по имеющимся экземплярам запись в БД каталога НЕ найдена и признак контроля переноса отключен.

Добавление/Изменение данных о заказанных экземплярах.
Поиск журнала на дописывание выполняется по его шифру. Это значит, что НЕ следует изменять значение поля ШИФР после первой передачи описания журнала в БД каталога!
Если по шифру журнала в БД каталога находится запись, то выполняется докомплектование, т.е. дописывание данными о новом периоде подписки.

Спасибо большое за помощь!!! Еще разбираемся.Просто с АРМом "Комплектатор " мы работаем всего 2 год, в том году такой проблемы не возникало.

Так что конкретно нужно сделать, для того что бы пошло докомплектование? Какие шаги?

Уж если не хотите читать инструкцию, то прочитайте: раздел форума "Часто задаваемые вопросы", обзоры - перенос журналов в ЭК, перенос книг в ЭК.

Раньше все далали по инструкции и все получалось!!!



Редактировано 1 раз. Последний раз 18.01.2013 16:13 пользователем Lenka_X777.

Спасибо за помощь!!!Просто слетел клиент, переустановив ИРБИС обнаружили что все в норме))

Здравствуйте. Ирбис 64 (2012)
Обработка говорит, что раньше в 32 в заимствованных записях просто выбирали в списке РЛ ZK. Сейчас сделали КСУ в 64 также, но в 920 поле сохранился PAZK. Так и скинули в ЭК, и зашифровали уже, и тут обнаружилось, что у части впервые экспортированных записей нет ОБРНЗ.

Получается, что РЛ нужно менять в двух местах - в области меню и в поле 920? Повторюсь, что сотрудники клянутся, что 920 поле в 32 Ирбисе никогда не корректировали.

Для общего развития интересно зачем имя РЛ для текущей записи можно независимо корректировать в двух полях - в обл. кнопок и в поле 920, причем именно независимо: внизу поставили ZK, а в 920 поле осталось PAZK? Для каких задач такая вариантность?

И еще подскажите, пожалуйста, какие еще могли быть последствия неправильного переноса (в PAZK)? КСУ большое и хотелось бы на первый раз простить себя)) и ничего не переделывать.



Редактировано 10 раз. Последний раз 11.04.2013 11:52 пользователем Novinka.

Не совсем понятен Ваш вопрос. Надо уточнить
1.Вы говоря о заимствовании имеете ввиду перенос из БД CMPL в БД ЭК?
2.В 920 поле код ZK есть только в РЛ ZK и ZK31 БД СMPL, в БД ЭК РЛ с таким кодом нет,есть РЛ с кодом PAZK и другие РЛ с другими кодами

Яковлева Татьяна написал(а):
-------------------------------------------------------
> Не совсем понятен Ваш вопрос. Надо уточнить
> 1.Вы говоря о заимствовании имеете ввиду перенос
> из БД CMPL в БД ЭК?

Нет, заимствование в CMPL из корпорации (в Каталогизаторе бд CMPL нажали кота, импортировали запись).
записи приходят в PAZK, я так понимаю, что нужно для дальнейшего экспорта в ЭК исправить 920 поле на ZK.
Но наши сотрудники говорят, что никогда 920 поле в 32 не правили, а меняли РЛ внизу формы.
В 64 они тоже не исправили 920 поле, а выбирали ZK вверху окна.
В итоге РЛ PAZK так и сохранился в CMPL на момент передачи КСУ в каталог.
Короче говоря, в 32 ирбисе 920 поле не правили и все было ок, в 64 не исправили, и записи передались неправильно.

И какие могут быть ошибки с записями уже переданными в PAZK кроме отсутствия ОБРНЗ?



Редактировано 4 раз. Последний раз 12.04.2013 11:59 пользователем Novinka.

Нет,дело не в РЛ. ОБРНЗ формируется если выполняется условие: if &unifor('Ketr.mnu|ОБРНЗ')<>''then'^CОБРНЗ'fi

Яковлева Татьяна написал(а):
-------------------------------------------------------
> Нет,дело не в РЛ. ОБРНЗ формируется если
> выполняется условие: if
> &unifor('Ketr.mnu|ОБРНЗ')<>''then'^CОБРНЗ'fi

Вот я привожу строку из общего описания:

"При переносе проверяется вид записей. Переносимая запись должна со-держать в поле 920 код “ZK”... "

Все наши проблемные записи в CMPL имеют код PAZK, а правильные - ZK.
Ага! До меня дошло, фраза "должна содержать" равнозначна коду ":", а я ее восприняла, как "=". И все докапываюсь и докапываюсь)))

Значит, можно переносить записи в PAZK из комплектатора в каталог? И проблема в чем-то другом?



Редактировано 3 раз. Последний раз 15.04.2013 09:06 пользователем Novinka.

Вам надо перед переносом в БД ЭК установить в настройке в Этапе работы - обработка не завершена

Яковлева Татьяна написал(а):
-------------------------------------------------------
> Вам надо перед переносом в БД ЭК установить в
> настройке в Этапе работы - обработка не завершена

Так и есть. Я же говорю, что часть записей (ZK) перенеслась правильно (с ОБРНЗ), проблема только в PAZK- записях, именно поэтому я думаю, что дело в РЛ.

Нет, переносить в PAZK нельзя(( Я скопировала КСУ в 32 Ирбис, провела перенос в ЭК там. В протоколе сплошные строки типа:

MFN=15146: ... вид записи книги не ZK (PAZK), ...
Не перенесена MFN=15145
провела глобальную на всех PAZK - записях, изменила их на ZK и книги перенеслись правильно!

И вообще в 32 Ирбисе у нас нет НИ ОДНОЙ! записи в CMPL с PAZK.

Я очень прошу ответить по пунктам:

1. Нужно ли до переноса в ЭК менять в записях КСУ РЛ PAZK на ZK?

2. Почему в 32 Ирбисе в протоколе сообщается, что запись не перенесена, т.к. РЛ не ZK, а в 64 просто переносятся, но некорректно.

Для переноса книг в ИРБИС32 и в ИРБИС64 используется таблица TRANSN.fst.
Из нее следует
1. Если у Вас в 920 стоит код PAZK, то он при переносе в ЭК не изменится, это Вам и сообщается в протоколе. А если у Вас в 920 стоит код ZK, то при переносе в ЭК он в зависимости от вида документа,который стоит в 900^B изменится на PAZK или PVK или SPEC.Это делается потому что РЛ ЭК, нет кода ZK
2.Если запись содержит 66 поле(перенос записи в другую БД),то она у Вас не перенесется как новая.

Не надо сравнивать перенос в версии 32 (наверное древней) и в версии 64. Мы всегда говорим, что версия 64 является приоритетной, а версия 32 может отставать.
В версии 64 не надо менять код РЛ! PAZK - это приемлемо. В чем, по вашему, ошибка переноса (еще раз)? Только что не сформировался код ОБРЗВ? Татьяна Васильевна объяснила, что он берется из настройки. Его, видимо, не было.
Может я что-то не поняла, но в чем еще ошибка?

ochagova написал(а):
-------------------------------------------------------
> Не надо сравнивать перенос в версии 32 (наверное
> древней) и в версии 64. Мы всегда говорим, что
> версия 64 является приоритетной, а версия 32 может
> отставать.
> В версии 64 не надо менять код РЛ! PAZK - это
> приемлемо. В чем, по вашему, ошибка переноса (еще
> раз)? Только что не сформировался код ОБРЗВ?
> Татьяна Васильевна объяснила, что он берется из
> настройки. Его, видимо, не было.
> Может я что-то не поняла, но в чем еще ошибка?
Мы с 2011 ирбис32 перешли на 2012 64.
Часть записей (ZK) перенеслась с сообщением о ОБРНЗ, а часть(заимствованные в PAZK) без него, т.е. это было звоночком, что что-то не так.

В TRANSN.fst ведь автоматически формируется ОБРНЗ, получается это не работает для PAZK?

Итак, значит перед пополнением КСУ (или перед экспортом в ЭК???) нужно поставить этап работы ОБРНЗ, пополнить и экспортировать в каталог, а перед созданием нового КСУ вернуть ПК?

Дело в том, что в БД комплектования записи с кодами РЛ PAZK, PVK и SPEC могут появиться ТОЛЬКО при переносе их из БД каталога для докомплектования либо БЕЗ переформатирования, либо по KPK.FST (что не соответствует технологии), и поэтому считается, что они уже прошли обработку и не требуют ввода ОБРНЗ.
При заимствовании записей и их импорте в БД комплектования формируется код РЛ ZK, в то время как при таком же заимствовании и импорте в БД ЭК - соответствующие коды PAZK/PVK/SPEC.
Непосредственный ввод записи в БД CMPL тоже ведется в РЛ с кодом ZK.

Каким путем у Вас в БД комплектования появились записи PAZK?

Дунаевская написал(а):
-------------------------------------------------------
> Дело в том, что в БД комплектования записи с
> кодами РЛ PAZK, PVK и SPEC могут появиться ТОЛЬКО
> при переносе их из БД каталога для
> докомплектования либо БЕЗ переформатирования, либо
> по KPK.FST (что не соответствует технологии), и
> поэтому считается, что они уже прошли обработку и
> не требуют ввода ОБРНЗ.

А...если мы ставим ОБРНЗ в этап работы, сообщение не появится в т.ч. и для докомплектованных записей?
> При заимствовании записей и их импорте в БД
> комплектования формируется код РЛ ZK,
Светлана Михайловна, а какой формат за импорт отвечает при заимствовании? Как Каталогизатор понимает, что заимствование ведется в бд комплектования? В IrbisC.ini нет параметра имя бд комплектования.
>в то время
> как при таком же заимствовании и импорте в БД ЭК -
> соответствующие коды PAZK/PVK/SPEC.
> Непосредственный ввод записи в БД CMPL тоже
> ведется в РЛ с кодом ZK.

> Каким путем у Вас в БД комплектования появились
> записи PAZK?

Это записи, заимствованные из web-ресурсов в АРМ Каталогизатор в бд CMPL. Мы месяц как перешли на 64. Может быть, я что-то не настроила?

Если книги нет в наших каталогах мы независимо (т.е. не по кнопке "Ввод описания без заказа") открываем АРМ Каталогизатор и по кнопке Ирбис-корпорации в CMPL заимствуем. РЛ PAZK.
Сегодня попробовала скачать запись из Ирбис-корпорации по кнопке "Ввод описания без заказа" в бд CMPL. Снова получился PAZK(



Редактировано 11 раз. Последний раз 18.04.2013 09:33 пользователем Novinka.

Да, так и получилось, если ставим ОБРНЗ в этап работы перед экспортом ксу в ЭК, запись, что издания не выдаются появляется для ВСЕХ книг, в т.ч. дописанных. В общем, МЫ пришли к выводу, что нужно просто менять 920 поле на ZK. ТОгда все правильно.
НЕ ПОНИМАЮ, ПОЧЕМУ НЕТ ОТВЕТОВ, ЭТО ЧТО, КАКАЯ-ТО ЭКСКЛЮЗИВНАЯ ПРОБЛЕМА? вОПРОС В ТОМ, ГДЕ МЫ НАРУШАЕМ ТЕХНОЛОГИЮ, ПОЧЕМУ pazk ПОПАДАЮТ В БАЗУ КОМПЛЕКТОВАНИЯ ПРИ ИМПОРТЕ ИЗ WEB. я ГОТОВА ОТВЕТИТЬ НА ЛЮБЫЕ НАВОДЯЩИЕ ВОПРОСЫ, ЧТОБЫ ВЫЯСНИТЬ, КАК НУЖНО РАБОТАТЬ.