Ошибка при учете финжурнала

[soleu_imported]

Привет всем!

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

[attachment=545:attachment]

Проблема похоже в кодюните 12
что-то неправильное с изменением переменной NextEntryNo (она подставляется в поле "Entry No" и при инициализации считывается максимальный "Entry No" из таблицы + 1 )
или ( идея #2) - при одновременном учете от нескольких пользователей не срабатывает блокировка таблицы, и в таблицу заносятся записи от другого пользователя с номером, который планирует использовать текущий сеанс в качестве "Entry No" для записи в таблицу

Может кто сталкивался с таким или может подсказать идеи, где копать?

[Scorpie]

Круто!

Копать в следах "кастомизации".

[Sitizen]

Возможные причины:
1. копались в 12 КЮ;
2. неправильно что-то исправили в базе - поясню: насколько я помню, номер операции вычисляется следующим образом - фильтруется 17-я таблица по номеру транзакции, берется последняя запись и к номеру операции прибавляется один. Т.е. номер транзакции последний, а номер записи при этом не последний.
3. то, что в базе остаются проводки указывает на то, что явно правили 12 КЮ, и в результате правок появились дополнительные коммиты, я бы начал от туда.

[Fordewind]

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

[Scorpie]

Fordewind, как нет если такую ошибку дает именно INSERT?!

[Fordewind]

Quote:

Originally Posted by Scorpie

Fordewind, как нет если такую ошибку дает именно INSERT?!

Помню была похожая ситуация. Такая же ошибка. В чем там именно дело было не помню
Но четко помню, что когда смотрел в базу, то такой операции там не было! Нумерация до него еще не дошла операций эдак на 100. (Версия была 3.6)

Кстати, как версия: Возможно, где-то баг при вставке во временную таблицу. в КЮ 12 инетерсным образом гоняются
NextEntryNo +/- 1. Может где-то налажали

аналогичная фишка была. учет операций клиента с применением рублей к другой валюте.

есть подозрение, что глюк может проявляться и в других ситуациях.
попытайтесь отловить ситуацию.

[zm]

Если речь идет о какой-то тестовой базе, то возможно удаляли "руками" G/L Entry и не почитстили G/L Register.

[Dzemon]

Какая версия Навижина?
Эта ошибка была в 2.60 и связана, если память не изменяет, с учетом НДС...
Лечилась добавлением 1-й строчки в 12 кодеюнит.

[soleu_imported]

Спасибо всем за идеи!

>> Копать в следах "кастомизации".
еще раз просмотрели кастомизацию,ничего особо криминального не видно

>>> 2. неправильно что-то исправили в базе - поясню: насколько я >>> помню, номер операции вычисляется следующим образом - >>> фильтруется 17-я таблица по номеру транзакции, берется
>>> последняя запись и к номеру операции прибавляется один. >>> Т.е. номер транзакции последний, а номер записи при этом не >>> последний.
там явно ведется поиск по фильтру по Entry No и ищется последняя запись

>> Fordewind, как нет если такую ошибку дает именно INSERT?!
точно, это же именно в INSERT из-за наличия записи с таким же значением первичного ключа

>> Какая версия Навижина?
>> Лечилась добавлением 1-й строчки в 12 кодеюнит
3.70,
и какой строчки?

[Dzemon]

В 3.70 этой ошибки уже не было, так что ищи дебагером.
В 2.60 не присваивался номер новой операции при вставке суммированного НДС.

[Scorpie]

Quote:

Originally Posted by soleu

еще раз просмотрели кастомизацию,ничего особо криминального не видно

Там криминала уже на 58ю по сталинскому кодексу.
Всмысле что журнал частично учитывается (COMMIT).

[grif]

Quote:

Originally Posted by Fordewind

Помню была похожая ситуация. Такая же ошибка. В чем там именно дело было не помню
Но четко помню, что когда смотрел в базу, то такой операции там не было! Нумерация до него еще не дошла операций эдак на 100. (Версия была 3.6)

Ну так значит оно в рамках одной транзакции писало в один и тот же номер операции или и правда во временную. Вобще я склоняюсь к варианту, что если ничего криминального в коде нет, там что-то криво поудаляли из таблиц.

[Fordewind]

Quote:

Originally Posted by grif

Quote:

Originally Posted by Fordewind

Помню была похожая ситуация. Такая же ошибка. В чем там именно дело было не помню
Но четко помню, что когда смотрел в базу, то такой операции там не было! Нумерация до него еще не дошла операций эдак на 100. (Версия была 3.6)

Ну так значит оно в рамках одной транзакции писало в один и тот же номер операции или и правда во временную. Вобще я склоняюсь к варианту, что если ничего криминального в коде нет, там что-то криво поудаляли из таблиц.

У нас вариант кривого удаления отпадал. Ничего руками не удаляли.

[grif]

Значит попахивает криминалом

[rov_imported]

Quote:

Originally Posted by Scorpie

Quote:

Originally Posted by soleu

еще раз просмотрели кастомизацию,ничего особо криминального не видно

Там криминала уже на 58ю по сталинскому кодексу.
Всмысле что журнал частично учитывается (COMMIT).

Scorpie прав на 100% - смотрите тщательнее кастомизацию. Других причин быть
не может.

[Urgen]

Quote:

Originally Posted by Scorpie

Quote:

Originally Posted by soleu

еще раз просмотрели кастомизацию,ничего особо криминального не видно

Там криминала уже на 58ю по сталинскому кодексу.
Всмысле что журнал частично учитывается (COMMIT).

То, что журнал учитывается частично, как раз ничего криминального нет. Это COMMITы из 13 кодеюнита срабатывают, если несколько документов сразу учитываются, с разными номерами или датами.

[Urgen]

Дополнение к предыдущему. (что-то сообщение не редактируется)

Переменная NextEntryNo инкрементируется только в одном месте, в функции InsertGLEntry. соотвественно и ошибка может возникнуть, только если при кастомизации строку пытаются вставить в tab17 без помощи этой функции. Ручная правка в принципе не может привести к такой ошибке. Параллельный учет тоже - в функции InitCodeunit сразу идет LOCKTABLE на tab17.