AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.03.2011, 11:12   #1  
Damn is offline
Damn
Участник
 
436 / 154 (6) ++++++
Регистрация: 28.05.2003
Адрес: в глуши
Ax2009 RU5: LedgerTrans.reverseSettlement()
В этом методе входной параметр - RecId из таблицы LedgerTrans. Вызывается reverseSettlement в одном месте - LedgerVoucher.post(), в качестве входного параметра передаётся переменная sourceRecid, которая заполняется значением RecId из записи ledgerTrans, являющейся на тот момент временной записью. RecId во временных таблицах совсем не такие как в постоянных.
Вследствие чего в таблице LedgerTransSettlement появляются записи со значениями типа 3, 4, 5, 6 и т.д. в поле TransRecId (таких записей не большинство, но они есть). И изредка во время разноски возникают ошибки о невозможности вставки записи в эту таблицу, так как TransRecId должно быть уникально.
Не могу понять какую всё-таки цель пытались добиться разработчики и что изменить чтобы ошибка не возникала.
__________________
Дмитрий
Старый 26.03.2011, 16:54   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
аналогичный вопрос. и аналогичная проблема - не понимаю.
ax2009, sp5

докопался до класса LedgerVoucherTransList
в котором редиска-локализатор (нехороший человек) использует refId_RU как счетчик записей внутри списка.
но потом возвращает этот счетчик как нормальный recId.

у аксапточки "едет крыша" от такого издевательства.

==============
также похоже, что LedgerSettlement - это буржуйская корреспонденция (необязательная).
==============

Есть мысли как избавиться от ошибки об неуникальности вставляемых записей?
Может кто знает на уровне функционала для чего именно используется таблица LedgerSettlement? (Перекрестные ссылки смотрел - много где используется)
__________________
полезное на axForum, github, vk, coub.
Старый 27.03.2011, 17:37   #3  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от mazzy Посмотреть сообщение
Может кто знает на уровне функционала для чего именно используется таблица LedgerSettlement? (Перекрестные ссылки смотрел - много где используется)
Может все-таки таблица LedgerTransSettlement, как написано в первом сообщении темы? Если LedgerTransSettlement - то это сопоставления проводок ГК, что-то наподобие сопоставлений по клиентам/поставщикам, только для проводок ГК.

Сопоставлют проводки ГК из меню "ГК-Периодические операции-Сопоставления ГК" (как-то так, но точно не помню, а Аксапты под рукой нет). Сопоставленные проводки просматриваются из формы проводок ГК по кнопке "Сопоставления ГК" (или как-то так).
__________________
Dynamics AX Experience
Старый 26.01.2012, 08:31   #4  
Андрей К. is offline
Андрей К.
Постигающий
 
152 / 10 (1) +
Регистрация: 09.04.2007
!
Цитата:
Сообщение от Damn Посмотреть сообщение
В этом методе входной параметр - RecId из таблицы LedgerTrans. Вызывается reverseSettlement в одном месте - LedgerVoucher.post(), в качестве входного параметра передаётся переменная sourceRecid, которая заполняется значением RecId из записи ledgerTrans, являющейся на тот момент временной записью. RecId во временных таблицах совсем не такие как в постоянных.
Вследствие чего в таблице LedgerTransSettlement появляются записи со значениями типа 3, 4, 5, 6 и т.д. в поле TransRecId (таких записей не большинство, но они есть). И изредка во время разноски возникают ошибки о невозможности вставки записи в эту таблицу, так как TransRecId должно быть уникально.
Не могу понять какую всё-таки цель пытались добиться разработчики и что изменить чтобы ошибка не возникала.
мы тоже наткнулись на эту проблему. во время сторнирования! дело тут не во временных таблицах. вместо них используется RecordList. покопавшись в коде, нашел место LedgerVoucher.postGroup, строка 44

X++:
if (localDetailSummary == DetailSummary::Detail )
        {
            recId++;
            ledgerTrans.RecId = recId;
        }
тот самый счетчик, который заменяет реальные recId и далее попадает в LedgerTransSettlement
хотел добавить условие (как в 73 строке этого самого LedgerVoucher.postGroup)
X++:
if (localDetailSummary == DetailSummary::Detail && !reversal)
        {
            recId++;
            ledgerTrans.RecId = recId;
        }
но пока не хватает уверенности.
кто-то еще сталкивался с проблемой описанной в перовом посте? как решали?

Последний раз редактировалось Андрей К.; 26.01.2012 в 08:40.
Старый 26.01.2012, 23:06   #5  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
По-моему, тут было про то же самое:
AX2009: не работает рассопоставление проводок при ВЫключенной корреспонденции и DetailSummary::Detail
Старый 27.01.2012, 07:18   #6  
Андрей К. is offline
Андрей К.
Постигающий
 
152 / 10 (1) +
Регистрация: 09.04.2007
Цитата:
у нас проблема при включенной корреспонденции. мне кажется локализаторы все перепутали в коде

Последний раз редактировалось Андрей К.; 27.01.2012 в 07:46.
Старый 30.07.2012, 21:35   #7  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Никто не раскопал в чем было дело и как лечить ?
Старый 06.08.2012, 18:46   #8  
N.D.P. is offline
N.D.P.
Участник
 
6 / 14 (1) ++
Регистрация: 18.07.2007
Logger, на проекте в свое время исправил аналогично способу, описанному выше Андрей К., все довольны, ошибка не появляется, корреспонденция работает.
За это сообщение автора поблагодарили: Logger (3).
Старый 10.04.2013, 09:51   #9  
avm is offline
avm
Участник
 
6 / 10 (1) +
Регистрация: 25.02.2003
Для себя решили проблему путем внесения изменения в метод post класса LedgerVoucher.
X++:
                  if (reversal && sourceRecid && !correspondenceEnabled)
//                if (reversal && sourceRecid)  mav bugFix
                {
                    ledgerTrans.reverseSettlement(sourceRecid);
                }
При сторнировании проводки в форме "Проводки по счету" вызвав пукнт меню "Сторнировать проводку", переменная sourceRecid равна recId сторнируемой проводки. Далее происходит поиск предыдущего сопоставления сторируемой проводки с последующим удалением найденного сопоставления и создание нового сопоставления сторнируемой проводки со сторно проводкой.

Результат сопоставленные проводки не переоцениваются алгоритмом курсовой разницы (КР) счетов ГК.
Ниже код из класса LedgerExchAdj метода run().
X++:
                while select ledgerTrans
                    where ledgerTrans.AccountNum   == ledgerTable.AccountNum   &&
                          ledgerTrans.TransDate    >= searchDate               &&
                          ledgerTrans.TransDate    <= toDate                   &&
                         (ledgerTrans.CurrencyCode >= fromCur || ! fromCur)  &&
                         (ledgerTrans.CurrencyCode <= toCur   || ! toCur)
                    notexists join legderTransSettlement 
                       where ledgerTrans.RecId == legderTransSettlement.TransRecId
Если возникнет потребность исключить из расчета КР проводки, можно их сопоставить в форме сопоставлений проводок ГК.
Старый 09.10.2013, 17:13   #10  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
Цитата:
Сообщение от Андрей К. Посмотреть сообщение
X++:
if (localDetailSummary == DetailSummary::Detail && !reversal)
        {
            recId++;
            ledgerTrans.RecId = recId;
        }
Таким образом лучше не исправлять - добавление условия - "&& ! reversal", конечно если на ваших настройках системы все работает, это хорошо, но вообщем случае это приводит к проблемам, мало ли какие настройки поменяете.

На приложении DAX 2009 RU8 только, что столкнулся с последствиями данного исправления, как минимум(мне показали только данный случай) при отмене сопоставления накладной с предоплатой появляется сообщение "Установлена не верная корреспонденция. Корреспонденция будет отменена." и часть проводок ГК(налоговые) формируются без корреспонденции. (возможно это как то зависит от конфигурации налогов и самого приложения, но от этого не легче).

Если вы не пользуетесь функционалом сопоставления ГК, то алгоритм исправления я бы смотрел в сторону предложенную avm, отключение формирования записей в данной табличке.
__________________
Sergey Nefedov

Последний раз редактировалось SRF; 09.10.2013 в 17:17.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Ax2009 RU5: класс SysOperationProgressServer Damn DAX: Программирование 2 29.09.2010 22:18
Ax2009 RU5: Итоги в отчётах, сгруппированные по полям с типом UtcDateTime Damn DAX: Программирование 5 13.09.2010 15:54
AX2009 RU5: невозможно открыть "журнал восстановления НДС"... EVGL DAX: Функционал 8 09.09.2010 23:20
Ax2009 RU5: Не заполняется CreatedDateTime в SysDatabaseLog Damn DAX: Администрирование 2 07.09.2010 15:29
AX2009 RU5: ADORecordSet, вопрос на 16 баллов DSPIC DAX: Программирование 6 01.09.2010 18:19
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:24.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.