День добрый!
Ирбис 64 2014.1
Прошу помощи с мастером списания. Есть ли возможность списывать через мастер списания отдельные экземпляры (под одним инв.№) одновременно во внутренних отделах ЦБ и у филиалов? Т.е., для примера, корректно списывать 2 экз. из 3-х у читального зала и 1 экз. из 5-ти у выбранного филиала?

ame написал(а):
-------------------------------------------------------
> День добрый!
> Ирбис 64 2014.1
> Прошу помощи с мастером списания. Есть ли
> возможность списывать через мастер списания
> отдельные экземпляры (под одним инв.№)
> одновременно во внутренних отделах ЦБ и у
> филиалов? Т.е., для примера, корректно списывать 2
> экз. из 3-х у читального зала и 1 экз. из 5-ти у
> выбранного филиала?


Все экземпляры описаны в одном ЭК? Какой статус у экземпляров ЧЗ и экземпляров филиала? Дайте примеры записей

Не могу добиться воспроизведения ситуации, ФЛК не даёт, поэтому этот вопрос снимаю, а на обычной записи всё ок.

Подниму ещё раз тему о мастере списания. Возник вопрос: почему при списании книг по ИН/ШК через txt-файл НЕ возникает проверка на дублетные ИН? Когда со словаря идёт списание, то проверка присутствует, и мастер предлагает нажать "вперёд" и выбрать в следующей таблице, какие где экз. списать. А при подаче ИН из файла списываются все экземпляры, невзирая на статус и МХР. Как быть, что делать, где подправить, если сильно хочется списывать с помощью файла и с выбором?

Версия 2014 - см. Doc2. При списании по файлу предлагается пойти вперед и выполнить дальнейшие действия. Но вовсе не выбор МХР, а передачу в другой фонд.
Откуда вы взяли выбор МХР? Это вы заранее обеспечиваете, когда готовите файл для списания.

ochagova написал(а):
-------------------------------------------------------
> Откуда вы взяли выбор МХР? Это вы заранее
> обеспечиваете, когда готовите файл для списания.
Выбор МХР я взял из таблицы мастера списания. См. прикреплённый файл. В нём показана типичная для нашей ЦБС ситуация, когда:
а) экземпляры со статусом "0" есть в одном отделе
б) экземпляры со статусом "0" есть и в других отделах тоже.
У нас задача - списать конкретный экземпляр в конкретном отделе. В ИРБИСе, насколько мне удалось понять, невозможно списать один из многих экземпляров со статусом "0" с одного МХР. В этому случае, т.е. если есть больше одного экз. со статусом "0" в одном МХР, ИРБИС списывает все возможные экземпляры со статусом "0" (с выбранным ИН, разумеется) везде, где найдёт. У нас в ЦБС такая практика списания (как в прикреплённом файле) и ведение учёта не считается нарушением, и в ИРБИСе ФЛК даёт сохранить запись, где есть идентичные друг другу повторения 910 поля. Вы считаете это преодолимой ошибкой, и поэтому нам хотелось бы списывать экземпляры со статусом "0" по ИН с выбором МХР (или зная из выводимой таблицы, откуда мы списываем) через мастер списания, а не вручную. Что и где нам подправить (если это возможно), чтобы выполнить описанную выше задачу?

P.S. Повторю свой первый вопрос ещё раз: почему при списании книг по ИН/ШК через txt-файл НЕ возникает проверка на дублетные ИН?

В приложенной картинке - списание не по TXT-файлу. Это новый режим, как раз, когда по файлу списывать нельзя, т.к. имеются дублетные ИН. В этой таблице придлагается выбрать нужную строку, поставить 1 и списать именно этот экземпляр.
Вы не указали версию и обновления.

Версия 2014.1. Подскажите, пожалуйста, где посмотреть установленные обновления в вашей программе? Может быть, я плохо искал, и информация об обновлениях есть в сопроводительной документации к вашему программному продукту?

Цитата:

ochagova
В приложенной картинке - списание не по TXT-файлу.

Разумеется, нет, не по файлу. В приложенной картинке - списание по словарю при дублетности ИН. Вы спрашивали, откуда я взял выбор МХР, и я привёл скрин из мастера списания. И спрашивал вас о том, как тот же выбор получить при списании из файла. И на это вы ответили:

Цитата:

ochagova
Это новый режим, как раз, когда по файлу списывать нельзя, т.к. имеются дублетные ИН.

То, что нельзя, это было ясно с самого начала. Это предыстория вопроса, а сам мой вопрос был о том, почему так, и что и как изменить, чтобы МОЖНО было списывать из файла с проверкой на дублетность. На первую часть "почему так?" вы ответили, что это - новый крутой режим. Ок, пусть будет так. Прошу вас ответить на другую часть вопроса: что и как изменить, чтобы была возможность списать из файла с проверкой на дублетность, т.е. выполнить задачу по списанию конкретных экземпляр(-а,ов) из конкретного отдела/филиала?

Так вы сначала объясните, что такое, на ваш взгляд, проверка на дублетность в случае списания инвентарей их файла? Как должна поступать программа?
Если вы считаете, что сами можете что-то изменить, то я назову вам имя пакетного задания, которое запускается при списании по инвентарным номерам - spisgblBinv.gbl

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

Но я сначала объясню: на мой взгляд, проверка на дублетность в случае списания из файла - это "обработка ситуации, когда на списание отмечены инвентарные номера с количеством ссылок больше чем 1" (из вашего руководства по ИРБИСу). Как же эта обработка должна происходить? Так же, как она происходит при режиме списания при выборе ИН из словаря инвентарных номеров, т.е. в обычном режиме БЕЗ подтягивания инвентарных номеров из файла. Есть дублетные номера - таблица выводится, из которой можно выбрать нужный экземпляр. Нет - нет. Хочется увидеть такую же таблицу при работе с файлом, потому что у ИН из файла тоже часто бывает "количество ссылок больше чем 1".

Теперь понятно ваше пожелание.
Действительно, предполагалось, что списание по файлу возможно только в случае уникалности ИН при индивидуальном учете. Это, действительно, не было акцентировано в инструкции. Но также там ничего нет и о Кол-ве ссылок больше 1 и о ФЛК.
Для этого (неуникальность) и был предложен вариант с таблицей.
Списани через файл рассматривается как пакетный процесс, в файл, конечно, помещаются ШК (уникальные). А какая м.б. таблица в пакетном процессе? Предположим в файле 1000 ИН, из них 50 неуникальных. И что делать пакетному заданию? В притокол - да, можно выдать сообщение и не выполнять списание.

Цитата:

ochagova
Это, действительно, не было акцентировано в инструкции. Но также там ничего нет и о Кол-ве ссылок больше 1 и о ФЛК.

См. прикреплённый файл. Если эта ситуация не есть проверка на дублетность в случае списания инвентарей из файла, то что это?

Про ФЛК ничего скажу, присутствует именно он или у вас задействованы какие-то внутренние процедуры контроля уникальности ИН/ШХ исключительно из CIRBISP_UNICODE.exe. Для рядового пользователя, типа меня, особой разницы нет, что это - непреодолимый формально-логический контроль или просто какой-то процедурный контроль из исполнительного файла. Главное, что в результате всех этих действий/обработок формируется таблица, где можно выбрать нужные экземпляры и только потом отправить эти данные в пакетное задание.

Цитата:

ochagova
в файл, конечно, помещаются ШК (уникальные).

Где об этой уникальности написано в документации хотя бы пол-слова? Упоминается только текстовый файл, который бывает и .doc, и .rtf, и, да, .txt. Со всеми этими форматами ИРБИС работает. Наши работники начинали обкатывать ваш новый режим с .doc. И это не их вина, если разобраться. У вас в документации на картинке стоит тип файла *.*, попробуйте догадаться сами, с каким расширением он должен быть.

Цитата:

ochagova
А какая м.б. таблица в пакетном процессе?

Никакая.

Цитата:

ochagova
Предположим в файле 1000 ИН, из них 50 неуникальных. И что делать пакетному заданию?

У вас есть предварительный контроль (ФЛК или какой-то другой), что формирует таблицу. Только то, что отмечено пользователем в таблице, попадает в пакетное задание. (У меня правильные представления о том, как мастер списания работает?) У нас файл создают одни работники (сотрудники филиалов), а проверяют другие (сотрудники ОКиО ЦБ), и этот элемент проверки, т.е. таблица на экране ПЕРЕД выполнением задания, уже сам по себе очень важен при списании. Мало ли, какие ИН будут в файле; мало ли, какие всплывут ошибки учёта, статус, количество - все они будут на визуальном контроле.
Пакетному же заданию делать то, что отмечено и указано в таблице. Если нельзя пересобрать CIRBISP_UNICODE.exe с проверкой ИН из файла, нет возможности или вы откажетесь, то для меня только один путь просматривается - добавлять либо "0" в StatusSpisGroup в ини-файл, либо "С" в StatusSpisInd, и переписывать SpisGblBInv.gbl. Не знаю, что "лучше".

1. Про обновления см. [irbis.gpntb.ru]. Т.е. в разделе "Часто задаваемые вопросы"
2. На вашей картинке - Списание ОТМЕЧЕННЫХ ИН, т.е. НЕ по файлу, а ручками ставили отметки в словаре ИН
3. Согласна, что режиму списания по файлу уделено мало внимания. Его надо как-то улучшать. Но как?
4. Во-первых, в общем случае невозможно положить все ИН, все таблицы имеют ограничения на размер. Возможно, надо ввести промежуточный шаг работы с файлом. Положить его в буферизированную таблицу, по каждому инвертарю проверять ситуации - наличие ИН, статус ИН, что делать если на руках? что делать если дублеты, если уже списаны и т.д. Предлагайте ситуации
5. Учтите - это затратно по времени на большом файле
6. Для версии 2014 этот режим м.б. предложен некоторым для обкатки

1. У вас по ссылке находится тема, как и где обновления взять. Где же в ИРБИСе посмотреть, какое обновление уже стоит?
2. Конечно. На картинке отмеченные вручную ИН. Вопрос же был про дублетность, что это, на мой взгляд, такое, применительно к режиму списания из файла. То же самое, те же основные механизмы, те же определения, что и для списания по словарю.
3. Первое, что приходит на ум: доработка документации. Хотя бы добавить имя формата, и как ИН должны размещаться в файле. У нас некоторые вообще не пользуются механизмом, когда записи в ИРБИСе неспешно отмечаются и собираются в файл на списание. Сотрудники не знают, в каком виде файл должен быть - в столбик ИН идут или в строчку? Они всё делают в экселе, из которого у нас в ЦБ уже собирают ещё один файл с ИН. Второе: возможно, после ИН в ту же строку полезно было бы добавить данные из 200 поля через какой-нибудь разделитель. С другой стороны, это улучшение может превратить всё в обычное списание через выбытие, для которого мастер вовсе не нужен. В принципе, кроме списания из файла нас всё устраивает.
4. Тут мне кое-что неясно. В общем случае я могу отметить чек-боксы на ВСЕХ ИН при списании со словаря. Каждый раз при новой отметке в чек-боксе будет запускаться проверка на дублетность по выбранному ИН. Я так понимаю, сама проверка, её алгоритм, вас не устраивает, если эти ИН получать из файла. Если дело в кол-ве ИН и высоком среднем повторении поля 910, то можно узнать об оценке границы? 100 ИН, включая 50 неуникальных при, в среднем, 5 повторениях на запись или 1000, 500 при 10-20?
Обобщённый алгоритм формирования предварительной таблицы видится таким:
а) проверка на наличие ИН
б) проверка на статус, совпадает ли со списком из ини-файла. Если статус не совпал, то в таблицу данные из повторения поля не заносить. По статусу 4 у вас существует отдельный режим. Если кто-то ведёт учёт в разрезе ветхих экземпляров (для обновления фондов и т.д.), то всегда можно дописать справочник и внести новый статус в ини-файл. А если кто не хочет связываться с перемещением непрофильных изданий, а хочет их списать, то тоже самое. Единственное, что вызовет проблемы, - это если кто-то пропишет "U" в StatusSpisInd.
Если статус совпал - заносить в предварительную таблицу нужные подполя из 910 повторения (МХР, кол-во, цена, ИН, КСУ), плюс 200, 700 поля. Хотелось бы, конечно, чтобы таблица была широкой, и колонки в ней настраивались/убирались, но это уже функционал мастера отчётов.
в) сохранить порядковый/последовательный номер повторения поля и MFN
г) повторять, пока есть повторения 910 поля текущей записи
д) загрузить следующий ИН из файла, определить по нему MFN, загрузить на обработку запись и п. а)
Когда предварительная таблица (или массив) сформирована, то данные выводятся на экран пользователю. Сейчас в текущем виде всё выглядит вполне хорошо. Пользователь отмечает в ячейках кол-во на списание или просто ставит "1". Дальше происходит изменение в нужной записи в нужном повторении 910 поля, номера которых были заранее сохранёны, заносятся данные в 940 поле и т.д. Ситуаций, когда записи с разными MFN имеют одинаковые ИН, быть не может, потому что ФЛК не пропустит их сохранение. Кол-во экземпляров при статусе "0" тоже под ФЛК. Не знаю, что ещё может возникнуть? Какие-то ньюансы при работе с КСУ, актами?

Цитата:

ochagova
по каждому инвертарю проверять ситуации... что делать если дублеты

Я правильно понимаю, что вы имеете в виду точное повторение 910 поля? Мне кажется, надо сохранить номер повторения, и пусть пользователь сам решает, как поступить - списать ли по первой строчке или по второй, третьей...
5. Какой вы оцениваете временную сложность?

Говорим только о режиме списания по файлу!

1. Документация - согласна.
"...Хотя бы добавить имя формата..." - я не пойму - вы со знанием используете термин "формат"? В данной точке технологии нет никакого формата. Что вы имеете в виду - не поняла

2. Предложение о заглавии ... - отвергается. На то он и режим по файлу, что ничего более не требуется, кроме заранее заготовленных списков. По заглавию, по месту хранения и т.д. - идите в другие режимы.
Сотрудники не понимают в каком виде файл - но администратор им должен объяснить, не так ли?

3. Вы заметили, что в ИРБИСе есть словари - они как бы "бесконечны" и поэтому помещаются в специализированные таблицы-списки, которые буферизируются. То что можно "отметить все" - это условность, не создается никакой список отмеченных, просто используется определенный поисковый запрос. Список из файла - это не словарь и он м.б. помещен во вполне конечную таблицу с заданными размерами.

4."... будет запускаться проверка на дублетность по выбранному ИН. " - что вы имеете в виду? Вам бы этого хотелось? Или вы уверены, что так и есть? Но так не есть. Не заложена проверка на дублетность в процесс выбытия.

5. Далее по вашим словам - краткий режим списания по файлу превращается в широкое полотно с показом всего-всего. Т.е. новый интерфейс вместо существующего.

Нет, я не готова делать такой режим. Попробуйте использовать другие режимы списания (не по файлу).
Но проверку на "неуникальность" ИН можно добавить в пакетное задание и выводить информацию в протокол.

1.

Цитата:

ochagova
В данной точке технологии нет никакого формата. Что вы имеете в виду - не поняла

Расширение у текстового файла, ".txt".
2. Где бы ещё администратор мог в документации почитать помимо сакраментального "текстовый файл", в каком формате этот текстовый файл, т.е. как в нём должны располагаться данные, в каком виде, какое у файла должно быть расширение? Впрочем, это всё лирика и вопросы риторические в свете вашего внимания к полноте документации.
3. Ясно. Про ограничения этой "конечной таблицы" вы так и не рассказали. Опять-таки, всё будет познаваться эмпирически.
4. Ясно.
5. Ясно, что нового интерфейса не будет. Про временную сложность ни слова, ни пол-слова.
Вопросов больше нет. Большое спасибо, что всё объяснили.

Давайте слово "формат" использовать в значении ИРБИСа. Это файл pft, или написанная строка, который(ая) извлекает из записи некоторые данные.
Режим списания по файлу - с технологами будем обсуждать.