Версия 9.1 + D1

Прошу дать пояснения по алгритму. Логика переноса поменялась?

1. В CMPL перенесли запись из ЭК похожую на поступившую книгу.
2. Внесли изменения в БО, удалили поля 910 и 66
3. При переносе партии в ЭК все инвентари приписались к книге в ЭК. Я так понимаю в результате поиска по шифру (903)
4. Кроме того в таких записях CMPL появилось количество повторений поля 66 соответствующее (кажется) числу повторений 910 поля (видимо по чилу корректировок)

Судя по сообщениям протокола типа

Цитата:

MFN=16372: не переносилась, не найдена запись в каталоге по запросу "I=-750775"+("IN=158730"*"NKSU=2009/184"), новая в БД каталога

программа теперь игнорирует отсутствие отметки о переносе и пытается все таки найти запись для докомплектования и проверки того, все ли инвентари перенеслись в ЭК. Но зачем по шифру...

Раньше что-то такого я не помню, и вообще в чем смысл? Если бы еще хоть шифр у нас в системе (о чем я не устаю повторять с какого-то лохматого года) не нагружался при формировании смыслом (исключительно для печати выходных форм), а четко выполнял роль ТОЛЬКО идентификатора записи, а значит было бы 99% уверенности в том что он будет неизменен. Так ведь нет - каталогизаторы могут, а зачастую просто вынуждены удалять шифр сформированный в комплектовании, потому что систематизируют именно они и карточки печатают они.


PS: вообще же, хочется ругаться. Пара партий. Больше 100 наименований и больше 1000 экз. Пока заметили, пока исправили, потом перенесли повторно и разобрались, опять исправили - до кровопускания слава богу не дошло :)

PPS: в общем не надо искать по шифру запись для докомплектования. А если уж и искать то хотя бы минимально (на уровне сверток) проверять БО обеих записей перед корректировкой

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP



Редактировано 1 раз. Последний раз 25.11.2009 12:15 пользователем Куделя.

Да, в последних версиях я добавила поиск по шифру. Это было связано с хроническим ненахождением записи каталога на докомплектование и сл-но образование новых записей. Когда удаляли экземпляры в записи CMPL - по чему еще искать? А почему вы, если запись другая, не изменили/удалили в ней шифр? Он же д.б. уникален.

Почему комплектаторы не удалили шифр? Потому что им никто этого не говорил :) А не говорил, потому что не знал и это было несущественно, теперь знаю и сказал.

Мне все-таки кажется неправильным игнорировать наличие\отсутствиее отметки о переносе. Одно дело, когда запись с дублетным (по каким-то причинам) шифром перенесется в ЭК и автоматически удалиться по ФЛК и это будет отражено в протоколе с прямым указанием на причину удаления, и совсем другое, когда в ни в чем не повинную запись ЭК допишется пара сотен "левых" инвентарей. А шанс появления дублетного шифра даже без "вины" в этом оператора, хоть и исчезающе мал, но тем не менее не исключен - базы-то разные, а структура и алгоритм формирования шифра одинаковые.

А что насчет размножения поля 66?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

"неправильным игнорировать наличие\отсутствиее отметки о переносе" - когда я опиралась на эту пометку, выходило так: из каталогизатора копировали описание НЕ ПО KPMK.FST, и при переносе запись создавалась как новая.
А что такое "размножение 66"?

ochagova написал(а):
-------------------------------------------------------
> пометку, выходило так: из каталогизатора
> копировали описание НЕ ПО KPMK.FST, и при переносе
> запись создавалась как новая.
Но ведь это противоречит технологии. И поиск соответствия по шифру, как раз уступка тем, кто делает неправильно и не по документации.
В этом мне видится сущностная разность между Вами и АИ :)


> А что такое "размножение 66"?
Это значит, что после выполнения операции переноса в тех записях CMPL, которые "не новые", появилось количество повторений поля 66 с данными '^AIBIS^B20091125' равное количеству повторений 910 содержащих инвентари перенисимой партии. Т.е. 70 инвентарей для докомплектования - 70 повторений 66 поля.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP