Ошибка в расчете курсовых разниц

[Silphidae]

Добрый день.

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

Вот так выглядит код в котором идет обновление данных в таблице VendSettlement (метод updateSettlement в классе CustVendTransData):

public CustVendSettlement updateSettlement(CustVendTransOpen _custVendTransOpen,
                                           DiscAmount        _utilizedCashDisc   = 0,
                                           PennyDiff         _pennyDiff          = 0,
                                           NoYes             _canBeReversed      = NoYes::No,
                                           boolean           _setOffsetRecId     = false,
                                           boolean           _update             = false,
                                           Dimension         _cashDiscDimension  = custVendTrans.Dimension,
                                           Voucher           _taxVoucher         = '')
{
    CustVendTrans       this_Orig           = custVendTrans.orig();
    CustVendSettlement  custVendSettlement  = this.parmCustVendTransStatic().custVendSettlement();
    ;
    ttsbegin;
    if (_update)
    {
        ...
        //тут все нормально
    }
    else
    {
        custVendSettlement.clear();
        if (custVendTrans.ExchAdjustment != this_Orig.ExchAdjustment)
        {
            custVendSettlement.AccountNum           = custVendTrans.AccountNum;
            custVendSettlement.OffsetTransVoucher   = custVendTrans.LastSettleVoucher;
            custVendSettlement.TransDate            = max(custVendTrans.TransDate, custVendTrans.LastExchAdj);
            custVendSettlement.TransRecId           = custVendTrans.RecId;
            custVendSettlement.ExchAdjustment       = custVendTrans.ExchAdjustment - this_Orig.ExchAdjustment;
            custVendSettlement.DueDate              = _custVendTransOpen.DueDate;
        }
        if (custVendTrans.SettleAmountMST  != this_Orig.SettleAmountMST ||
            custVendTrans.SettleAmountCur  != this_Orig.SettleAmountCur ||
            _utilizedCashDisc                                  ||
            !custVendSettlement.AccountNum)
        {
            custVendSettlement.AccountNum           = custVendTrans.AccountNum;
            custVendSettlement.OffsetTransVoucher   = custVendTrans.LastSettleVoucher;
            custVendSettlement.TransDate            = max(custVendTrans.TransDate, custVendTrans.LastSettleDate);
            custVendSettlement.TransRecId           = custVendTrans.RecId;
            custVendSettlement.SettleAmountMST      = custVendTrans.SettleAmountMST- this_Orig.SettleAmountMST;
            custVendSettlement.SettleAmountCur      = custVendTrans.SettleAmountCur- this_Orig.SettleAmountCur;
            custVendSettlement.UtilizedCashDisc     = _utilizedCashDisc;
            custVendSettlement.PennyDiff            = _pennyDiff;
            custVendSettlement.CashDiscDate         = _custVendTransOpen.CashDiscDate;
            custVendSettlement.OffsetRecId          = _setOffsetRecId ? custVendTrans.OffsetRecId : 0; //custVendSettlement.SettleAmountCur ? this.offsetRecid : 0;
            custVendSettlement.DueDate              = _custVendTransOpen.DueDate;
            custVendSettlement.LastInterestDate     = _custVendTransOpen.LastInterestDate;
            custVendSettlement.CanBeReversed        = _canBeReversed;
            custVendSettlement.CashDiscAccount      = _custVendTransOpen.CashDiscAccount;
            if ( _canBeReversed && _utilizedCashDisc)
            {
                custVendSettlement.Dimension        = _cashDiscDimension;
            }

            custVendSettlement.TaxVoucher_RU         = _taxVoucher;
        }
        custVendSettlement.insert();
    }
    ttscommit;
    return custVendSettlement;
}

Есть подозрение, что clear() таблицы не успевает отработать до insert().
Подскажите, пожалуйста, как решить эту проблему. АХ 4sp2, MS SQL 2005

[Jabberwocky]

Да, есть бага в этом фрагменте. Причина проблемы в том, что если после строки

custVendSettlement.clear();

ни одно из if-условий не равно TRUE, то в таблицу VendSettlement будет вставляться пустая запись. Эту ошибку можно исправить введением дополнительной проверки на "заполненность" буфера:

insertRecord = false;
custVendSettlement.clear();

if (custVendTrans.ExchAdjustment != this_Orig.ExchAdjustment)
{
.....
insertRecord = true;
}

if (...)
{
.....
insertRecord = true;
}

if (insertRecord)
{
     custVendSettlement.insert();
}

В версии 2009 бага поправлена.

[Silphidae]

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

[SRF]

Попробуйте у таблицы VendSettlement свойство OccEnabled выставить в No. Только учтите, что время обновления данных по данной таблице увеличится, но ошибка по идее должна пропасть.

[Silphidae]

Спасибо, SRF
Установка указанного свойства в No решила проблему. А можно спросить, что это свойство определяет?

[SRF]

Цитата:

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

А можно спросить, что это свойство определяет?

Почитайте вот эту тему aEremenko: Излучая оптимизм

[Jabberwocky]

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

[ena_ax]

Цитата:

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

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

Нельзя сопоставить 2 документа друг с другом несколькими частями, система сигнализирует об ошибке. По крайней мере у меня так.
Axapta 4.0 SP2. (Именно друг с другом, т.е. добиться чтобы по 2-м документам было несколько сопоставлений между собой).

[Jabberwocky]

Можно сопоставить несколькими частями, но на разные даты.
Попробуйте взять реализацию классов CustVendExchAdjustment_W и CustVendReversePosting иэ этого пакета (здесь наиболее актуальные версии этих классов): https://mbs.microsoft.com/customerso...alculations_ru

Возможно, у Вас не установлен какой-то хотфикс.

[raz]

Нашел еще ошибку в расчете курсовой.

DAX 2009

\classes\CustVendExchAdjustment_W.calcUnrealizedExchAdj()


        if (Currency::amount(abs(_settleAmountCur), _custVendTrans.CurrencyCode) <= abs(pendingSettledAmountCur))
        {
            //NDN10966_CustVendExchAdjustment, [], edd, 21.09.2012 -->
            //openAmountCur += _settleAmountCur;
            openAmountCur  = abs(openAmountCur);
            openAmountCur += abs(_settleAmountCur);
            //NDN10966_CustVendExchAdjustment, [], edd, 21.09.2012 <--
        }

Проблема при exchRateDiffCalcType != ExchRateDiffCalcType_W::Standard.

[Sada]

переменная openAmountCur будет только положительной. Это правильно? а могла быть любой. Просто я лично с этим кодом пока не сталкивался, но в системе есть глюки с расчетом курсовой. Изучаю стандартные глюки на форуме...

[Maximin]

Если вы посмотрите ниже,

        unrealisedAmountMST  = Currency::amount(_exchRateDiff * abs(_settleAmountCur / (openAmountCur ? openAmountCur : _settleAmountCur)));

то вы поймете, что, на самом деле, этот фикс вообще никак не влияет на результат, т.к. отношение _settleAmountCur / (openAmountCur ? openAmountCur : _settleAmountCur) берется по модулю и важно само отношение, но не его знак.

[Sada]

Цитата:

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

Если вы посмотрите ниже,

        unrealisedAmountMST  = Currency::amount(_exchRateDiff * abs(_settleAmountCur / (openAmountCur ? openAmountCur : _settleAmountCur)));

то вы поймете, что, на самом деле, этот фикс вообще никак не влияет на результат, т.к. отношение _settleAmountCur / (openAmountCur ? openAmountCur : _settleAmountCur) берется по модулю и важно само отношение, но не его знак.

если openAmountCur = -3 а _settleAmountCur = -3, то будет ноль в стандарте, и будет -3 в скобках, после фикса будет 6

[Maximin]

Цитата:

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

если openAmountCur = -3 а _settleAmountCur = -3, то будет ноль в стандарте, и будет -3 в скобках, после фикса будет 6

Чего-то мне всегда казалось что -3 + (-3) будет -6. Соотв, разницы никакой.
А, поскольку у openAmountCur и settleAmountCur знак всегда совпадает (вот если нет - будут проблемы, да, и фикс это вылечит), то все будет нормально работать. Но могут ли они по смыслу быть с разным знаком? По сути, это открытая сумма и сопоставленная сумма. И в getOpenAmount видны усилия по приведению всего в вид с одинаковым знаком...

[Sada]

Ну да с математикой я обложался Потому и спрашиваю - в чём грабли?

[raz]

Не проще настроить и попробовать?
Проблема была найдена при помощи отладчика, не хотите патчить, оставьте как есть.