При суммарной обработке закупок аксапта удаляет строки разноски счета и накладной

[maxkov]

Какой-то очередной странный глюк.

Настроил параметрах поставщиков суммарную обработку "счет на".

Теперь при обработке счета одного заказа под некоторыми пользователями после нажатия кнопкп ОК в диалоге разноски, строки для разноски система удаляет.

Под другими пользователями все работает.

Разработчик не может понять причину, посокльку глюк в ядре. Система вызывает какой-то метод делит, котрый должен выполняться при определенных условиях. Набор этих условий ложный, но ядро все равно удаляет записи ПОД НЕКОТОРЫМИ ПОЛЬЗОВАТЕЛЯМИ.

Кто нибудь сталкивался с подобным бредом?

[Ivanhoe]

Хотя бы версию системы укажите..

[lev]

сброс пользовательских настроек делали?
кэшевские файлы АОС удаляли на машине пользователя?

[Poleax]

Цитата:

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

Какой-то очередной странный глюк.
.... но ядро все равно удаляет записи ПОД НЕКОТОРЫМИ ПОЛЬЗОВАТЕЛЯМИ.
Кто нибудь сталкивался с подобным бредом?

Пользователи в разных группах? Права пользователей одинаковы?
В коде не дописан код который в зависимости от группы, что то чистит?

почему вы решили, что проблема с ядром?
Данный глюк воспроизводится на разработческой и тестовой аксапте?

[maxkov]

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

[lev]

если я правильно понял проблему, то у Вас удаляется таблица SalesParmLine.
что бы понять в какой момент и по какой причине она удаляется поставьте в методе delete() этой таблицы точку останова (если этого метода нет, перекройте его) и запустите процесс обработки. Если удаление происходит не через doDelete(), то у вас откроется отладчик и в нем вы сможете посмотреть стек вызова. Думаю что просмотр стека расставит все по своим местам.

[S.Kuskov]

Цитата:

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

Разработчик не может понять причину, посокльку глюк в ядре. Система вызывает какой-то метод делит, котрый должен выполняться при определенных условиях. Набор этих условий ложный, но ядро все равно удаляет записи ПОД НЕКОТОРЫМИ ПОЛЬЗОВАТЕЛЯМИ.

Вариантов два: либо запись удаляется ещё из какого-то места (выяснить просто - необходимо поставить точку останова внутрь метода delete и проанализировать стек вызовов), либо в момент выполнения условие всё-таки не ложно. Как бы не абсурдно это выглядело, но отображаемый код и исполняемый могут отличаться из-за сбоев кэша. И опять же из отладчика всё это можно увидеть.

[lev]

кстати, что то подумалось, а АОСы перезапускали?

[maxkov]

в делите нет ничего, там по релэйшену удаляется
и аос перезапускали

Короче при попытке удалить в SalesParmTable система удаляет в SalesParmSubTable, несмотря на то что условие релэйшена по полю TableRefId не выполняется

Причем сгенерили даже не путем запуска процедура а тупо на таблице сделали удаление и все равно система удалила не смотря на условие релэйшена (НО ТОЛЬКО ПОД ОПРЕДЕЛННЫМИ ПОЛЬЗОВАПТЕЛЯМИ - у этих пользователей нет ограничей по правам - они в группе админ)

[lev]

Цитата:

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

в делите нет ничего, там по релэйшену удаляется
и аос перезапускали

Короче при попытке удалить в SalesParmTable система удаляет в SalesParmSubTable, несмотря на то что условие релэйшена по полю TableRefId не выполняется

Причем сгенерили даже не путем запуска процедура а тупо на таблице сделали удаление и все равно система удалила не смотря на условие релэйшена (НО ТОЛЬКО ПОД ОПРЕДЕЛННЫМИ ПОЛЬЗОВАПТЕЛЯМИ - у этих пользователей нет ограничей по правам - они в группе админ)

эээ, у меня Relation на таблице SalesParmSubTable с таблицей SalesParmTable сделан через поля ParmId и SalesId. Таблица эта у нас стандартная (правда у нас третья аксапта, возможно в четвертой переделали).

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

[maxkov]

Доступ совсем нипричем. если бы условие выполняось то под всеми бы оно отрабатывало

[maxkov]

Разобрались
Действительно глюк с правами.
Несколько групп прав пришлось убить и настроить новые аналогичные - тогда все заработало.

[Wamr]

На мой взгляд, это ошибка, что deleteAction зависит от настройки прав.
Ладно бы оно полностью работало или не работало, а то ведь удаляет не то что надо.

[mayk]

Цитата:

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

в делите нет ничего, там по релэйшену удаляется
и аос перезапускали

Короче при попытке удалить в SalesParmTable система удаляет в SalesParmSubTable, несмотря на то что условие релэйшена по полю TableRefId не выполняется

Причем сгенерили даже не путем запуска процедура а тупо на таблице сделали удаление и все равно система удалила не смотря на условие релэйшена (НО ТОЛЬКО ПОД ОПРЕДЕЛННЫМИ ПОЛЬЗОВАПТЕЛЯМИ - у этих пользователей нет ограничей по правам - они в группе админ)

Бамп старинному треду. Может ещё кто столкнется. Я вот столкнулся, а на форуме решения не нашлось.

Оказывается, в четверке при удалении relation'ы по невидимым полям не используются, поэтому когда reArrange удаляет parm таблицы, он иногда грохает все parmLine с такими же parmId не смотря на то то tableRefId в них отличается от TableRefId в ParmTable. Axapta делает это не всегда, а только для пользователей которые ей особенно не нравятся. И права тут не причем.

Для обхода надо выставить visible=yes в tableRefId, тогда AX нормально воспринимает table relation и не удаляет что попало.

(узнал в http://www.archivum.info/microsoft.p...invoicing.html )

Цитата:

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

а вообще чудес не бывает, если удаляется, значит условие отрабатывает.

Чудеса всё-таки бывают о чем можно убедится добавив delete() методы в PurchParmTable, purchParmLine и сравнив tableRefId, но конкретно это закончилось в KB939982

Ключевые слова для гугла: purchParmLine, PurchParmSubTable, purchParmTable, tableRefId, parmId, deleteAction.

[lev]

Цитата:

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

Чудеса всё-таки бывают о чем можно убедится добавив delete() методы в PurchParmTable, purchParmLine и сравнив tableRefId, но конкретно это закончилось в KB939982

Ключевые слова для гугла: purchParmLine, PurchParmSubTable, purchParmTable, tableRefId, parmId, deleteAction.

это не чудеса, а кривизна рук создателей системы особенности системы...

[AndyD]

Цитата:

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

это не чудеса, а кривизна рук создателей системы

А откуда еще чудеса берутся?