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. Какой вы оцениваете временную сложность?