Ax2009 RU5: LedgerTrans.reverseSettlement()

[Damn]

В этом методе входной параметр - RecId из таблицы LedgerTrans. Вызывается reverseSettlement в одном месте - LedgerVoucher.post(), в качестве входного параметра передаётся переменная sourceRecid, которая заполняется значением RecId из записи ledgerTrans, являющейся на тот момент временной записью. RecId во временных таблицах совсем не такие как в постоянных.
Вследствие чего в таблице LedgerTransSettlement появляются записи со значениями типа 3, 4, 5, 6 и т.д. в поле TransRecId (таких записей не большинство, но они есть). И изредка во время разноски возникают ошибки о невозможности вставки записи в эту таблицу, так как TransRecId должно быть уникально.
Не могу понять какую всё-таки цель пытались добиться разработчики и что изменить чтобы ошибка не возникала.

[mazzy]

аналогичный вопрос. и аналогичная проблема - не понимаю.
ax2009, sp5

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

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

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

Есть мысли как избавиться от ошибки об неуникальности вставляемых записей?
Может кто знает на уровне функционала для чего именно используется таблица LedgerSettlement? (Перекрестные ссылки смотрел - много где используется)

[CDR]

Цитата:

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

Может кто знает на уровне функционала для чего именно используется таблица LedgerSettlement? (Перекрестные ссылки смотрел - много где используется)

Может все-таки таблица LedgerTransSettlement, как написано в первом сообщении темы? Если LedgerTransSettlement - то это сопоставления проводок ГК, что-то наподобие сопоставлений по клиентам/поставщикам, только для проводок ГК.

Сопоставлют проводки ГК из меню "ГК-Периодические операции-Сопоставления ГК" (как-то так, но точно не помню, а Аксапты под рукой нет). Сопоставленные проводки просматриваются из формы проводок ГК по кнопке "Сопоставления ГК" (или как-то так).

[Андрей К.]

Цитата:

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

В этом методе входной параметр - RecId из таблицы LedgerTrans. Вызывается reverseSettlement в одном месте - LedgerVoucher.post(), в качестве входного параметра передаётся переменная sourceRecid, которая заполняется значением RecId из записи ledgerTrans, являющейся на тот момент временной записью. RecId во временных таблицах совсем не такие как в постоянных.
Вследствие чего в таблице LedgerTransSettlement появляются записи со значениями типа 3, 4, 5, 6 и т.д. в поле TransRecId (таких записей не большинство, но они есть). И изредка во время разноски возникают ошибки о невозможности вставки записи в эту таблицу, так как TransRecId должно быть уникально.
Не могу понять какую всё-таки цель пытались добиться разработчики и что изменить чтобы ошибка не возникала.

мы тоже наткнулись на эту проблему. во время сторнирования! дело тут не во временных таблицах. вместо них используется RecordList. покопавшись в коде, нашел место LedgerVoucher.postGroup, строка 44

if (localDetailSummary == DetailSummary::Detail )
        {
            recId++;
            ledgerTrans.RecId = recId;
        }

тот самый счетчик, который заменяет реальные recId и далее попадает в LedgerTransSettlement
хотел добавить условие (как в 73 строке этого самого LedgerVoucher.postGroup)

if (localDetailSummary == DetailSummary::Detail && !reversal)
        {
            recId++;
            ledgerTrans.RecId = recId;
        }

но пока не хватает уверенности.
кто-то еще сталкивался с проблемой описанной в перовом посте? как решали?

[gl00mie]

По-моему, тут было про то же самое:
AX2009: не работает рассопоставление проводок при ВЫключенной корреспонденции и DetailSummary::Detail

[Андрей К.]

Цитата:

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

По-моему, тут было про то же самое:
AX2009: не работает рассопоставление проводок при ВЫключенной корреспонденции и DetailSummary::Detail

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

[Logger]

Никто не раскопал в чем было дело и как лечить ?

[N.D.P.]

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

[avm]

Для себя решили проблему путем внесения изменения в метод post класса LedgerVoucher.

                  if (reversal && sourceRecid && !correspondenceEnabled)
//                if (reversal && sourceRecid)  mav bugFix
                {
                    ledgerTrans.reverseSettlement(sourceRecid);
                }

При сторнировании проводки в форме "Проводки по счету" вызвав пукнт меню "Сторнировать проводку", переменная sourceRecid равна recId сторнируемой проводки. Далее происходит поиск предыдущего сопоставления сторируемой проводки с последующим удалением найденного сопоставления и создание нового сопоставления сторнируемой проводки со сторно проводкой.

Результат сопоставленные проводки не переоцениваются алгоритмом курсовой разницы (КР) счетов ГК.
Ниже код из класса LedgerExchAdj метода run().

                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

Если возникнет потребность исключить из расчета КР проводки, можно их сопоставить в форме сопоставлений проводок ГК.

[SRF]

Цитата:

Сообщение от Андрей К.

if (localDetailSummary == DetailSummary::Detail && !reversal)
        {
            recId++;
            ledgerTrans.RecId = recId;
        }

Таким образом лучше не исправлять - добавление условия - "&& ! reversal", конечно если на ваших настройках системы все работает, это хорошо, но вообщем случае это приводит к проблемам, мало ли какие настройки поменяете.

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

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