При проверке фонда в режиме "Отдельный штрихкод/Радиометка/Инвентарный номер" новый комплектатор в поле 910^C проставляет текущую дату проверки, так не должно быть - это ведь дата поступления, которая не должна меняться.

В режиме проверки по списку из файла "Штрих-коды/Инвентарные номера в файлк" и "Задание списка..." - проблем нет.

Это не проверка фонда проставляет дату. Даты, видимо, не было в поле 910^C и ее поставил автоввод. Если бы вы просто взяли на корректировку эту запись (до проверки) то тоже поставилась бы дата поступления как текущая.

Дата в поле 910^C была.

Вот что было:
#910/1:_^A0^B240025^C20140530^DНТБ^E144.89^U2014/396

Вот что стало:
#910/3:_^A0^B240025^C20181214^DНТБ^S20181214^U2014/396^E144.89

Исследуем

Объяснение такое. В этом режиме по умолчанию запускается глобальная в режиме пересчета цен. А если пересчет цен, то ставится новая цена и дата должна ей соответствовать, поэтому дата меняется.
На WEBinar я предупреждала, что за удобства режима чем-то надо расплачиваться. В обычном режиме у вас есть возможность выбирать - с пересчетом или без.
Наши возможные действия - 1.выполнять этот режим без пересчета цен. Но кто-то скажет - нет, с пересчетом. 2.проверять - если цена не изменилась, коэф=1, то и дату не менять.

Т.е. получается, что от поля 910^C зависит актуальность цены издания.

Как мне кажется, это не совсем верное решение, т.к. при этом теряется информация о сроке нахождения в фонде конкретного экземпляра издания. Или я не прав ?

Мне кажется, что правильнее было бы просто ввести еще одно поле, с датой переоценки.

В любом случае спасибо.
Буду признателен, если ещё поделитесь ссылкой на вышеупомянутый вебинар.

Просто в документации фигурировала "дата ввода":

Цитата:

Данные по проверке фонда вводятся автоматически в процессе выполнения режима проверки в АРМах Комплектатор или Каталогизатор: • дата проверки вводится всегда – и при «полной», и «текущей» проверке, при по-вторной проверке дата предыдущей проверки заменяется; • цена, дата ввода – только при «полной» проверке вводится «пересчитанная» цена, дата ввода заменяется на дату проверки, так что цена в поле экземпляра соответ-ствует дате ввода (с этой ценой)

То, что в данном контексте "датой ввода" обозначили "дату поступления" (семантически разные понятия), и сбило с толку. Ведь "Дата ввода" есть, в поле 907^A.

Результирующая: документация составлена с терминологическими неточностями и вводит в заблуждение.

А вы на заходите в раздел форума "Конференции..."? Там есть ссылка
[irbis.gpntb.ru]
Еще вводить поле - нет, это будет связано с очень множественными изменениям и ошибок будет больше чем пользы.
А в какой инструкции вы взяли эту цитату?

Хотелось бы знать мнения пользователей:
Проводить ли проверку в данном режиме без пересчета?
С пересчетом, но проверять - изменилась ли цена, и если не изменилась, то не менять дату поступления?



Редактировано 1 раз. Последний раз 14.12.2018 16:15 пользователем ochagova.

Добрый день. Ирбис 64+ 2019.1. Подниму тему. Может быть что-то изменилось.При проверке фонда в режиме "Отдельный штрихкод/Радиометка/Инвентарный номер" в поле 910^C проставляется текущая дата проверки вместо даты поступления и пересчитывается цена экземпляра. В нашей стране другой алгоритм пересчета цен. Можно ли убрать эту функцию? Проверку фонда решили проводить именно в этом режиме, чтобы дополнительно сверить электронный каталог с инвентарем.

Вы хотите убрать только пересчет цен? С изменением даты поступления вы согласны?
Пересчет цен можно убрать, если убрать файл IZC.mnu. К сожалению в этом режиме не опрашивается - с пересчетом да/нет. Пересчет - безусловно.

Добрый день, Ирбис 64+ 2019.1.
Для того, чтобы не пересчитывалась цена экземпляра при проверке фонда в режиме "Отдельный штрихкод/Радиометка/Инвентарный номер", убрали файл IZC.mnu.
Начали проверку, и только сейчас заметили, что стала исчезать цена за экземпляром в поле 910^Е. Её мы проставляли, если она отличалась от цены других экземпляров. В кодах поле 10^D цена остается.
Я так понимаю, что вернуть цену на проверенных экземлярах не получится, но, может быть есть возможность остановить процесс.Вернуть файл IZC.mnu не вариант, т.к в Беларуси не нужно пересчитывать цену. Помогите, пожалуйста

Исправила формат, в котором пропадала цена в случае отсутствия файла пересчета. Прикладываю.
Спасибо за сигнал. Этот вариант не был проверен.