Номер операции уже использован на дату

[_guestl_]

Добрый день.

По складу возникла проблема. При разноске складских журналов возникает сообщение об ошибке "Номер операции уже использован на дату .." В настройках журналов "Присвоение номера" стоит как "разноска", так и "ввод" - пробовали оба эти варианта в попытках борьбы с ошибкой.
Номерная серия как непрерывная, так и прерывная. Тоже пробовали оба варианта.

Пока боремся тем, что создаем новый журнал и копируем туда старый. И иногда создаем новые номерные серии. Но это не выход.

Может быть кто-нибудь сталкивался с подобной проблемой и поборол её на практике?

Версия Ax в подписи.

[pedrozzz]

Попробуйте через обозреватель таблиц найти записи с проблемным номером и понять для какой операции уже был использован данный номер из номерной серии. Возможно журналы создавались программно и зарезервированные номера не были помечены, как использованные. Попробуйте почистить зарезервированные номера вручную "Основное / Номерные серии / Номерные серии" кнопка "Список"

[_guestl_]

Чистили через кнопку "Список" - не помогало.

[Peter Savintsev]

Если для вас не критично наличие разрывов в номерах ваучеров (документов ГК), то просто можно вручную увеличить значение поля "Следующий" в номерной серии ваучеров.

[Rezervforall]

можно еще после открытия строк журнала нажать - Сохранить. Дальше все нормально. Почему там и как - не в курсе.

[_guestl_]

Переформулирую вопрос.

Как оперативно бороться с ошибкой - понятно.

Хотелось бы узнать, что нужно покрутить и где, чтобы эта ошибка не повторялась.

У нас, примерно, 70-80 пользователей на складе и формируется, примерно, 300-400 складских журналов в день. Если по каждому править - саппорт с ума сойдет. Хотелось бы более радикального решения.

зы: Ошибка возникает не постоянно, а несколько раз в неделю. При этом только в определенных названиях складских журналов. Мы уже для каждого наименования свою номерную серию сделали - не помогло. Разрывы в номерах ваучеров не страшны.

[madm]

Цитата:

Сообщение от _guestl_

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

Есть модификации создающие журналы/строки программно?

[_guestl_]

Цитата:

Сообщение от madm

Есть модификации создающие журналы/строки программно?

Есть самописные функции для строк: создать на основании и сторно на основании. Но журналы, где возникают ошибки с операциями кладовщики создают вручную.
Вспомнили, есть еще "создать списания". Кстати, возможно, в ней собака могла порыться. Пошукаем.

зы: сейчас перетестировали - дело не в них. тем более, что они не на одном проекте уже использовались - проверены временем.

[madm]

Просто недавно сталкивался с похожей ошибкой в 3.0 "Документ '%1' уже использован для даты %2." дело было в неверном выделении ваучера.

[_guestl_]

Цитата:

Сообщение от madm

Просто недавно сталкивался с похожей ошибкой в 3.0 "Документ '%1' уже использован для даты %2." дело было в неверном выделении ваучера.

Ваучер выделялся в самописной функции?

[madm]

Цитата:

Сообщение от _guestl_

Ваучер выделялся в самописной функции?

Да. Причем что интересно. На двух приложениях этот функционал был запущен и там даже после его исправления (до перезапуска АОСов) наблюдалось заполнение NumberSequenceList записями со статусом "Свободно", что и приводило в дальнейшем к этому сообщению. На третьем приложении сбоев не было, т.к. там неверное выделение было исправлено до первого запуска.
К этой ситуации привел вызов

ledgerJournal.newVoucher(ledgerJournalTable.voucherSeries, [B]true[/B]);

Вам удалось воспроизвести последовательность в результате которой происходит ошибка?

[Ivanhoe]

Не понятно, вы пробовали искать операции ГК с номером из журнала, на который ругается Система?

Ситуация повторения номера вообще критична? Может просто изменить параметр проверки в настройке модуля ГК?

вроде при беглом просмотре RU5 видел там фикс для такой ошибки, но могу ошибаться

[Logger]

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

Больше проблемы не должно появиться.

[Wamr]

Сталкивался с такой проблемой на функционале GMCS (ax3) при импорте платежей.
Сдвиги и прыжки с непрерывностью помагали временно. Бороться было как-то некогда, просто разрешили задвоение

[CDR]

Цитата:

Сообщение от _guestl_

По складу возникла проблема. При разноске складских журналов возникает сообщение об ошибке "Номер операции уже использован на дату .." В настройках журналов "Присвоение номера" стоит как "разноска", так и "ввод" - пробовали оба эти варианта в попытках борьбы с ошибкой.
Номерная серия как непрерывная, так и прерывная. Тоже пробовали оба варианта.

Данная ошибка частенько возникает либо в складских журналах, либо в журналах ГК.

В 90% случаев ошибка связана с наличием самописного функционала, который создает новые строки журналов, при этом не обрабатывает соответствующим образом номерную серию, используемую для нумерации Ваучера.

Механизм возникновения ошибки в этом случае приблизительно следующий. При создании строки журнала руками в форме, система выделяет следующий номер и резервирует его под нумерацию будущих проводок. При этом на самой форме написано куча кода по управлению номерной серией. Если строка журнала сохраняется и разноситься, выделенный номер система помечает как использованный и больше его не выделяет.
При написании самописных функций для создания строк программисты как правило копируют код выделения номерной серии, написанный для использования на форме. Если не вдаваться в технические подробности, то система при исполнении этого кода выделяет следующий номер, но не помечает его, как использованный. В итоге этот номер спустя какое-то время будет выделен снова, не смотря на то, что проводки с этим номером уже существуют. И при соответствующей настройке параметров ГК, получим вышеприведенную ошибку.

В 9% случаев ошибка является следствием неправильной настройки системы. Т.е. для нумерации документов ГК в строках используются номерные серии, имеющие пересекающиеся номера.

Оставшийся 1% случаев - формы новых типов журналов, на которых программисты "забывают" обрабатывать номерную серию. Но это очень редкий случай

Цитата:

Сообщение от _guestl_

Есть самописные функции для строк: создать на основании и сторно на основании. Но журналы, где возникают ошибки с операциями кладовщики создают вручную.

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

Алгоритм возможного решения вашей проблемы:

Проверьте, копируется ли номер документа ГК из старой строки в новую с помощью самописных функций.
Если номер скопировался - это не правильно.
Если поле пустое, то для соответствующих названий журналов необходимо указать в поле "Присвоение номера" значение "Разноска".
Если выделился новый номер, то для соответствующего названия журнала необходимо указать в настройке "Присвоение номера" значение "Ввод". А затем пойти в номерную серию и проверить корректное выделение номеров (кнопка "список").

ИМХО, наилучший вариант - это позволить системе самой работать с номерами документов ГК. При этом в создаваемых строках журнала поле Ваучер должно быть пустым, а в названиях журналов указать выделение номера при разноске. И я бы не рекомендовал отключать контроль документов ГК, т.к. все-таки связь Ваучер-Дата - одна из основных связей в системе для различных документов/проводок.

[_guestl_]

Цитата:

Сообщение от madm

Вам удалось воспроизвести последовательность в результате которой происходит ошибка?

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

[CDR]

Цитата:

Сообщение от _guestl_

При создании строки в поле "номер операции" пишется номер операции, который был свободен на момент создания строки.

А если сразу после создания строки зайти в номерную серию и посмотреть значения по кнопке "Список"? В списке присутствует только что выделившийся номер? Если да, то с каким статусом?

[_guestl_]

Цитата:

Сообщение от CDR

А если сразу после создания строки зайти в номерную серию и посмотреть значения по кнопке "Список"? В списке присутствует только что выделившийся номер? Если да, то с каким статусом?

Статус "активный", действие "нерешенный".

После разноски номер остается в списке с теми же статусом и действием.

Более того, все номера строк, что создаются через доп.функционал, остаются в списке после разноски. Если создавать строки руками, то они в список не попадают.

[CDR]

Цитата:

Сообщение от _guestl_

Статус "активный", действие "нерешенный".

После разноски номер остается в списке с теми же статусом и действием.

Более того, все номера строк, что создаются через доп.функционал, остаются в списке после разноски. Если создавать строки руками, то они в список не попадают.

Ну вот, теперь со 100% уверенностью можно говорить о том, что самописные функции написаны криво. .

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

Более правильное решение - исправить алгоритм самописных функций таким образом, чтобы они учитывали настройку для соответствующего журнала и в зависимости от нее либо правильно выделяли номер (параметр _makeDecisionLater должен быть false), либо не выделяли его вообще.

И ваша ошибка пропадет навсегда...