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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.03.2013, 05:13   #1  
Romb is offline
Romb
Участник
Аватар для Romb
 
79 / 22 (1) +++
Регистрация: 06.01.2004
Нашлось ли решение ошибки? Мучаюсь с такой же. Отладчик закипает Скажите, если есть рецепт. Спасибо.
Старый 19.04.2013, 03:29   #2  
Romb is offline
Romb
Участник
Аватар для Romb
 
79 / 22 (1) +++
Регистрация: 06.01.2004
Проблема как мне кажется выявлена.
Суть в том, что без этой модификации при наличии разницы округления добавляется запись в LedgerTrans с суммой погрешности установленной только в основной валюте! Т.е. валюта операции в проводке по округлению (LedgerTrans.AmounrCur) нулевая (как видно из начала поста). При этом основные проводки в ГК (т.е. тот набор, что делается обычно без проводок по 99.99 счету округления) идут в двух суммах AmountCur и AmountMST.

На практике это выливается в то, что метод класса LedgerBondServer_RU addCheckBalance()
X++:
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 (ключ делать разный для валюты операции и основной валюты), либо заносить (при совпадении этих валют) в проводку по округлению значение суммы в валюте операции. Что и было сделано в первом сообщении поста. Остается только нюанс.

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

Последний раз редактировалось Romb; 19.04.2013 в 03:32.
Старый 19.12.2013, 19:27   #3  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 523 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Вот еще какая может быть причина
Цитата:
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.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Странная ошибка(Ошибка времени выполнения: Неправильный тип индекса массива.) raniel DAX: Программирование 7 21.01.2011 14:45
Ошибка при разноске заказа на перемещение kalex_a DAX: Функционал 5 28.08.2009 15:54
Странная ошибка при работе в трехзвенке. malex DAX: Администрирование 8 02.05.2008 03:33
Ошибка при разноске касс (только по кредиту) через общий журнал Aquarius DAX: Функционал 12 28.01.2008 20:13
Русская локализация Axapta 3 ? SlavaK DAX: Администрирование 59 01.07.2003 22:38

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:41.