Странная ошибка при разноске

[Link]

Добрый день,

После перехода с 4ки на 2009 стали получать ошибку при разноске. Место где не проходит проверка в \Classes\LedgerVoucherObject\checkBalancePerDate. Суть ошибки не понятна, так как настройки не меняли и все работало, проблема возникает только при разноске в валюте компании.
Проверили класс LedgerVoucherObject - никаких модификаций нет. Но в тоже время обнаружили, что в 4ке изменен один из методов, который, как оказалось, "исправляет" эту ошибку. Изменения в 4ке не имели комментариев и не были перенесены в новую систему.

\Classes\LedgerVoucherObject\postRoundingDifferencesPerDate
- изменен только первый вызов этого метода, второй без изменений.

            this.addTrans(
                LedgerVoucherTransObject::newVoucherTrans(
                    this,
                    LedgerPostingType::MSTDiff,
                    accountNum,
                    dimension,
                    companyCurrencyCode,
                    transactionTxt.txt(),
                    ledgerTrans.TransDate,
                    0,
                    -ledgerTrans.AmountCur, //0, mxk - Invoice issue in GBP
                    -ledgerTrans.AmountMST,
                    0,
                    NoYes::No,
                    true,
                    tmpVoucherMap),
                false);

Т.е. изменен параметр "AmountCur" c значения по умолчанию "0" на "-ledgerTrans.AmountCur".
Не понятно, почему без него возникает эта ошибка. Просмотрел вроде никаких других модификаций в этом функционале у нас нет.

Партнеры как обычно ничего полезного не посоветовали, кроме стандартных настроек, которые мы и так смотрели.

С одной стороны вроде проблему решили изменив метод, но вот только не понятна причина и следствия

AX 2009 SP2 Appl 5.0.1500.4570

[Ivanhoe]

Какие настройки в параметрах ГК по максимальному допустимому расхождению в основной валюте? Какие настройки округления в самой валюте (основной)?

Судя по инфологу, у вас для коррекции сальдо по основной валюте создается проводка по округлению в основной валюте на 1 копейку. При этом по валюте операции такого округления нет, в итоге не балансирует сальдо в валюте операции (сложите все суммы в валюте операции - получится как раз 1 копейка). Указанная модификация добавляет эту самую копейку в валюте операции (в ту же проводку, в которой корректируется баланс в основной валюте) и баланс восстанавливается.

Думаю, все-таки это связано с настройками, которые не смогли победить на старой версии системы и просто сделали тогда такую заплатку.

[Link]

Цитата:

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

Какие настройки в параметрах ГК по максимальному допустимому расхождению в основной валюте? Какие настройки округления в самой валюте (основной)?

Судя по инфологу, у вас для коррекции сальдо по основной валюте создается проводка по округлению в основной валюте на 1 копейку. При этом по валюте операции такого округления нет, в итоге не балансирует сальдо в валюте операции (сложите все суммы в валюте операции - получится как раз 1 копейка). Указанная модификация добавляет эту самую копейку в валюте операции (в ту же проводку, в которой корректируется баланс в основной валюте) и баланс восстанавливается.

Думаю, все-таки это связано с настройками, которые не смогли победить на старой версии системы и просто сделали тогда такую заплатку.

Вот наши настройки. Мы в тесте разносили убрав проверку и сумма по транзакциям была 0. Если бы была разница, то вопросов бы не возникло, или может что не так делаем?

[belugin]

Попробуйте выяснить при огруглении чего озникает ошибка в валюте операции. Проводка с типом LedgerPostingType::MSTDiff и не нулевой суммой в валюте проводки выглядит очень странно.

Валюта компании отличается от валюты операции?

Sending shipment на каком слое реализован?

[Ivanhoe]

Суммы для разноски откуда берутся? Не программно ли?

[Link]

Цитата:

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

Попробуйте выяснить при огруглении чего озникает ошибка в валюте операции. Проводка с типом LedgerPostingType::MSTDiff и не нулевой суммой в валюте проводки выглядит очень странно.

Валюта компании отличается от валюты операции?

Sending shipment на каком слое реализован?

Именно, что странно, поэтому мы не понимаем в чем причина. Поковыряю еще, спасибо!

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

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

Цитата:

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

Суммы для разноски откуда берутся? Не программно ли?

Все суммы стандартные, их ничего не модифицирует.

[Ivanhoe]

Налоги в разноске есть? Какое округление в налоговом коде?
Нужно найти причину, по которой у вас сумма в валюте операции не балансирует. Т.е. если бы валюта операции так и была GBP, а основная валюта - RUR, то ошибка все равно бы была.

[belugin]

Цитата:

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

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

Стандартные классы не модифицированны?
Ошибка воспроизводится на plain valinilla sys? Свежей инсталляции Ax без партнерских решений и пр.

Я бы сделал так:

- либо нашел спеца по функционалу, который бы сказал в какой проводке копейка лишняя

- либо брейкпоинт на LedgerVoucherObject.addTrans, вынос суммы и счета добавляемой проводки в окно watch и ходить вверх по коллстеку выясняя, откуда взялся лишний пенни (или как он там) с копированием подозрительных коллстеков в OneNote.

[fed]

Еще интересно было бы сделать запрос в ledgerTrans напрямую в SQL Management Studio и посмотреть на какой счет там упало больше чем надо. Весьма вероятно что у вас каким-то невероятным способом обошли проверку на попытку разноски суммы не округленной до одного пенса. В итоге - в Axapta это не видно, но сиквеловский запрос покажет истинные суммы. Если поймете на каком счете болтаются неокругленные суммы - смотрите какой кусок кода их создает...

[Link]

Цитата:

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

Налоги в разноске есть? Какое округление в налоговом коде?
Нужно найти причину, по которой у вас сумма в валюте операции не балансирует. Т.е. если бы валюта операции так и была GBP, а основная валюта - RUR, то ошибка все равно бы была.

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

Цитата:

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

Стандартные классы не модифицированны?
Ошибка воспроизводится на plain valinilla sys? Свежей инсталляции Ax без партнерских решений и пр.

Я бы сделал так:

- либо нашел спеца по функционалу, который бы сказал в какой проводке копейка лишняя

- либо брейкпоинт на LedgerVoucherObject.addTrans, вынос суммы и счета добавляемой проводки в окно watch и ходить вверх по коллстеку выясняя, откуда взялся лишний пенни (или как он там) с копированием подозрительных коллстеков в OneNote.

Классы разноски не модифицированы. Попробуем на чистой Аксапте. Вроде партнеры еще смотрят, но я сомневаюсь, что они найдут причину. Так что будем смотреть в отладчике.

[Link]

Цитата:

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

Еще интересно было бы сделать запрос в ledgerTrans напрямую в SQL Management Studio и посмотреть на какой счет там упало больше чем надо. Весьма вероятно что у вас каким-то невероятным способом обошли проверку на попытку разноски суммы не округленной до одного пенса. В итоге - в Axapta это не видно, но сиквеловский запрос покажет истинные суммы. Если поймете на каком счете болтаются неокругленные суммы - смотрите какой кусок кода их создает...

Спасибо, будем иметь в ввиду, если ничего не найдем в отладке.

[Romb]

Нашлось ли решение ошибки? Мучаюсь с такой же. Отладчик закипает Скажите, если есть рецепт. Спасибо.

[Romb]

Проблема как мне кажется выявлена.
Суть в том, что без этой модификации при наличии разницы округления добавляется запись в LedgerTrans с суммой погрешности установленной только в основной валюте! Т.е. валюта операции в проводке по округлению (LedgerTrans.AmounrCur) нулевая (как видно из начала поста). При этом основные проводки в ГК (т.е. тот набор, что делается обычно без проводок по 99.99 счету округления) идут в двух суммах AmountCur и AmountMST.

На практике это выливается в то, что метод класса LedgerBondServer_RU addCheckBalance()

protected void addCheckBalance(LedgerTrans _ledgerTrans, Sign _sign = 1)
{
    void addKey(TransDate _transDate, CurrencyCode _currencyCode, Amount _amount)
    {
        str key = strfmt("@SYS76785", _transDate, _currencyCode);

        if (balanceMap.exists(key))
        {
            balanceMap.insert(key, balanceMap.lookup(key) + _amount);
        }
        else
        {
            balanceMap.insert(key, _amount);
        }
    }

    if (! balanceMap)
    {
        balanceMap    = new Map(Types::String, Types::Real);
    }

    addKey(_ledgerTrans.TransDate, _ledgerTrans.CurrencyCode, _ledgerTrans.AmountCur * _sign);
    addKey(_ledgerTrans.TransDate, mstCode, _ledgerTrans.AmountMST * _sign);
    addKey(_ledgerTrans.TransDate, mstSecondCode, _ledgerTrans.AmountMSTSecond * _sign);
}

неправильно считает "балансы". И неправильно он это делает просто потому, что, как видно при совпадении основной валюты и валюты операции карта balanceMap по одному и тому же ключу суммирует значения этих сумм (т.е. с одной стороны погрешность сначала удваивается, а с другой стороны вычитание суммы погрешности округления происходит только 1 раз, т.к. она указана только в одной валюте). В общем это выливается в дальнейшую ошибку "не балансирует", т.к. при таком алгоритме в balanceMap остается как раз сумма погрешности.

Решение - либо менять алгоритм наполнения и проверки balanceMap (ключ делать разный для валюты операции и основной валюты), либо заносить (при совпадении этих валют) в проводку по округлению значение суммы в валюте операции. Что и было сделано в первом сообщении поста. Остается только нюанс.

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

[Link]

Вот еще какая может быть причина

Цитата:

One possible cause of this issue is the duplication of number sequences. In Project management and accounting, there are separate number sequence setups available for On-Account Invoice, Invoice, On-Account Credit Note and Credit Note document types. If the number sequences are not uniquely defined, in the posting process, when the records are fetched from the projProposalJour\ProjInvoiceJour it is possible that posting a credit would fetch the corresponding invoice with the same number sequence and vice versa. This would then result in a situation where the merger of the documents results in an out of balance transaction, and then you would receive the error: "The transactions on voucher xxxxxxx do not balance as per xx/xx/xxxx. (Company currency: -x.xx - secondary currency: x.xx)".

To resolve this issue, you have a few options:
1.Uniquely define the number sequences with a character segment specific to each document type.
2.Use the same number sequence for the document types.
3.You could also resolve the error by bumping up the next number to something that would not be a duplicate. However, this would be a temporary solution as you would likely run into the error in the future on other documents.