Проблема постоянная (была во всех версиях), но хотелось бы помощи в ее решении:
При переносе партии из CMPL в БД ЭК в протоколе вот такие сообщения:
MFN=1393: не переносилась, поиск записи каталога по шифру , - найдена по шифру, не совпала свертка записи каталога
Не перенесена MFN=1393
Причина очень простая - в БД CMPL не заполняются поля классификаций (комплектаторы не имеют квалификации систематизировать издания) и в итоге шифр в 903 поле имеет вид -291739. А в БД ЭК у нас в записях статей (Имя рабочего листа ASP) шифры такого же вида. Вот и получается, что шифры время от времени совпадают и запись не перенести. И видим мы это уже только в протоколе. Вот сейчас у нас была большая партия на 1057 записей и 62 таких случая при переносе.
Потом приходится довольно трудоемко возвращаться к редактированию записи: в протоколе только MFN, а в списке записей в Мастере поступления в партии авторы и заглавия. Нужно провести в базе поиск по MFN, выявить автора-заглавие, потом отметить запись на корректировку, потом отдельно переносить.
Для того чтобы перенос выполнить таких записей и уже гарантированно шифр не совпал, мы им временно добавляем авторский знак в 908 и 903 поле, но это делать при вводе всех записей в CMPL неудобно т.к. тогда чтобы был правильный шифр уже с индексами каталогизатору приходится делать лишнюю работу уже в БД ЭК - стирать шифр.
Может быть можно сделать так: при сохранении записи в CMPL все равно выполняется проверка на дублетность по БД ЭК. Нельзя ли в флк добавить контроль на совпадение шифров? Чтобы запись, у которой совпал шифр с БД ЭК не давало сохранить и мы это совпадение устраняли сразу, еще при вводе. А может вы найдете еще более удачное решение, до которого мы не додумались.
Записи для примера прикладываю.
Про Крым и отъезд разработчиков все понимаю :) Проблема давняя и можно еще жить с ней. Просто хотелось бы в принципе найти решение.



Редактировано 6 раз. Последний раз 02.06.2017 15:24 пользователем roit.

Возьмите измененный файл dbnflc.pft, в нем внесена проверка шифра и с БД ЭК

Спасибо за оперативность!



Редактировано 2 раз. Последний раз 02.06.2017 15:24 пользователем roit.

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



Редактировано 1 раз. Последний раз 02.06.2017 15:44 пользователем roit.

Я не уверена, что все поняла. Но может вы, Т.А., меня лучше поймете.

1. Когда берется запись из БД каталога для последующего докомплектования, то сообщения и дублетных шифрах выдаваться не будет, т.к. при переносе из каталога формируется поле 66 и запись имеет признак "переносилась", поиск записи в каталоге будет по инв. номерам, штрих-кодам.
2. Вариант запись "не переносилась" и должна перенестись как новая. Могут быть два неверных варианта
- в каталоге есть другая запись, но с этим же шифром. Здесь помогает двойная проверка, которая есть
- в каталоге есть такая же запись, но шифры разные. Будет выполнен неверный перенос записи как новой (хотя она уже есть). Для этого случая имеется режим "Таблица дублетных описаний в БД каталога". Она выявляет такие случаи, если сделать эту проверку ДО переноса. Может в этот режим добавить другую прповерку - выявлять записи в БД каталога, которые совпадают по шифру, но отличаются по свертке, т.е. они другие?

Изначально проблема была (см. мое первое сообщение тут), в том, что практически в каждой партии у нас бывают случаи совпадения шифра новой записи в cmpl со старой записью на статью в БД ЭК. Суть проблемы - мы узнаем об этом из протокола при переносе партии и затрачиваем довольно много усилий, чтобы вызвать записи на редактирование, откорректировать шифры и отдельно перенести такие записи.
Теперь тут Татьяна Васильевна Яковлева прислала файл dbnflc.pft, в нем внесена проверка шифра и с БД ЭК. Это очень удобно для нашей проблемы т.к. при сохранении записи мы сразу видим, что шифр образовался дублетный с БД ЭК и сразу исправляем - просто стираем шифр и сохраняем заново.
Но теперь, с этим новым файлом, сообщение про дублетность шифра появляется и для записей, взятых нами из БД ЭК.
Чтобы было понятно прикрепляю картинки - на Дублет_новая очень полезное новое сообщение о дублетности шифра, а на Дублет_докомплектование 2 не полезных сообщения о дублетности записи и шифра.
Вообще то, раз есть 66 поле с информацией, что запись взята из БД ЭК, то может быть было бы правильно, чтобы о таких записях не прявлялось не только предупреждение о дублетном шифре, но и сообщение о дублетной записи в БД ЭК в целом?



Редактировано 4 раз. Последний раз 05.06.2017 08:33 пользователем roit.

Возьмите измененный файл dbhflc.pft,сообщение о дублетности шифра будет только для записей введенных в БД СMPL, а не перенесенных из БД ЭК

Я бы взяла, но его нет :(

Извините, прикрепляю

Спасибо! Попробовала, все пока хорошо. Посмотрим теперь, надеюсь при промышленной эксплуатации тоже все будет хорошо

При промышленной эксплуатации выявилась проблема. У нас версия 2016 D4 и файл этот уже из этой версии, а не тот что получен тут, он был в этом обновлении.
Похоже, что проверка шифра на дублетность с БД ЭК происходит только при редактировании записи.
Механизм похоже такой: запись создана, мы нажимаем на "сохранить", в этот момент в 903 поле записи образуется шифр, но проверка на дублетность после этого не происходит. Похоже проверка идет до создания 903 поля. Если зайти в запись для редактирования и отредактировать любое поле, то там на момент нажатия на "сохранить" происходит проверка и т.к. шифр уже в 903 поле есть, то сообщение о дублетности с БД ЭК появляется.
Обнаружили так - заметили, что несколько раз записи, у которых при сохранении не появлялось сообщение о дублетности, но которые мы затем редактировали ругаются на дублетность при сохранении после редактирования.
Записи я прикладываю, но как воспроизвести ситуацию искусственно не знаю. Когда я проверяла до этого, то как раз делала запись с дублетным шифром сама. Но тут весь фокус, что похоже на момент проверки никакого шифра в записи нет вообще, потом он образуется и уже никто не предупреждает о его дублетности.



Редактировано 2 раз. Последний раз 13.09.2017 15:54 пользователем roit.

roit написал(а):
-------------------------------------------------------
> При промышленной эксплуатации выявилась проблема.
> У нас версия 2016 D4 и файл этот уже из этой
> версии, а не тот что получен тут, он был в этом
> обновлении.
> Похоже, что проверка шифра на дублетность с БД ЭК
> происходит только при редактировании записи.
> Механизм похоже такой: запись создана, мы нажимаем
> на "сохранить", в этот момент в 903 поле записи
> образуется шифр, но проверка на дублетность после
> этого не происходит. Похоже проверка идет до
> создания 903 поля. Если зайти в запись для
> редактирования и отредактировать любое поле, то
> там на момент нажатия на "сохранить" происходит
> проверка и т.к. шифр уже в 903 поле есть, то
> сообщение о дублетности с БД ЭК появляется.
> Обнаружили так - заметили, что несколько раз
> записи, у которых при сохранении не появлялось
> сообщение о дублетности, но которые мы затем
> редактировали ругаются на дублетность при
> сохранении после редактирования.
> Записи я прикладываю, но как воспроизвести
> ситуацию искусственно не знаю. Когда я проверяла
> до этого, то как раз делала запись с дублетным
> шифром сама. Но тут весь фокус, что похоже на
> момент проверки никакого шифра в записи нет
> вообще, потом он образуется и уже никто не
> предупреждает о его дублетности.


Вы правильно поняли, что проверка дублетности происходит, когда шифра еще нет. Пока можно предложить только увеличить разрядность случайного числа в шифре. Autoin.gbl прикрепляю.

Простите, а что значит разрядность случайного числа?
И что значит "пока можно предложить", вы все-таки найдете другое решение?
Получается, что в существующем варианте проверка почти ничего не дает - она работает только при редактировании записи. И даже в этом случае если стереть дублетный шифр и создать его заново, то нет гарантии, что он опять не дублетный.

roit написал(а):
-------------------------------------------------------
> Простите, а что значит разрядность случайного
> числа?

Вместо 6-значного будет формироваться 9-значное. Вероятность формирования дублетного уменьшится.


> И что значит "пока можно предложить", вы все-таки
> найдете другое решение?

Мы будем искать другое решение