Хранение проводок LedgerVoucherTransList

[Kainix]

Добрый день.

Такой вопрос возник, зачем в классе LedgerVoucherTransList, в методе add, используют строковый ключ для мапы? Из за этого возникают глюки с корреспонденцией, при условии что корреспондируется один счет и уровень детализации Сводка. Вызвано это тем когда дебетовая и кредитовая части проводки разрываются. Если ключ текстовый то перебор идет не в порядке записи проводок. Пример. загружаем 15 (30 ledgerTrans) проводок, начинаем считывать, порядок будет следующий
1 - 2 - 11 - 12 - 13 - 14 - 15 - 16 - 17 - 18 - 19 -20 -3 - 21 -22 - 23 - 24 - 25 - 26 - 27 - 28 - 29 - 30 - 4 - 5 - 6 - 7 - 8 - 9 из за такого порядка сбивается корреспонденция. Если строковый ключ заменить на int то все ок. Хочу спросить на что такая замена может повлиять?
Ax 2009 Ru 6

[Logger]

А какие именно глюки с корреспонденцией ?

[Kainix]

не корреспондирует проводки, когда одинаковый счет и аналитики, и при этом несколько наборов аналитик. Пишет ошибка в корреспонденции, но вручную все корреспондирует

[Pustik]

Quote:

Originally Posted by Kainix

Добрый день.
Такой вопрос возник, зачем в классе LedgerVoucherTransList, в методе add, используют строковый ключ для мапы?

Quote:

Originally Posted by Kainix

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

В Axapta 3.0 сортировка(упорядочивание) символьных строк была идентична сортировке, если бы эти символьные строки можно было бы преобразовать в число. Поэтому в старой версии все работало правильно.В АХ2009 сортировка символьных строк изменилась.Существенную роль в сортировке стал играть символ дефиса и количество символов в строке. Интересную версию рассказал AndyD. Подробнее здесь Не корректная сортировка в Map-e и Set-е. AX2009 RU5.
Скорее всего, при переходе на новую версию, здесь на это просто не обратили внимание.

[Kainix]

Спасибо за ответ, но это пол беды.
На что может повлиять, такое изменение в классе LedgerVoucherTransList. я думаю, не на что, но хочется убедится, если так, то ошибка устраняется, переводом ключа на тип int.

[Pustik]

Quote:

Originally Posted by Kainix

Спасибо за ответ, но это пол беды.
На что может повлиять, такое изменение в классе LedgerVoucherTransList. я думаю, не на что, но хочется убедится, если так, то ошибка устраняется, переводом ключа на тип int.

Сложно сходу ответить. Но, предварительно посмотрев, вроде от этого класса никто не унаследован. Там, где к нему обращаются напрямую, используют метод add (где уже все должно быть настроено на int). И в этом классе нет метода, который возвращает этот map.Так что, по первичным предварительным признакам ничего страшного быть не должно.

[Kainix]

Значит бага с корреспонденцией, одного счета и тогоже счета с одинаковыми аналитиками, исправляется следующим образом.
В классе LedgerVoucherTransList
Метод new

void new()
{
    // + iau для корректной корреспонденции проводок, необходимо проводки по порядку считывать, для этого используем ключ int
    
    //transObject  = new Map(Types::String, Types::Class);

    transObject  = new Map(Types::Integer, Types::Class); 
    // - iau для корректной корреспонденции проводок, необходимо проводки по порядку считывать, для этого используем ключ int
    
}

Метод add

public boolean add(LedgerVoucherTransObject _ledgerTransObject)
// </GEEU>
{
    str keyString;
    ;
    // + iau для корректной корреспонденции проводок, необходимо проводки по порядку считывать, для этого используем ключ int    

    //keyString = strfmt('%1', this.elements());
    //transObject.insert(keyString, _ledgerTransObject);
    
    transObject.insert(this.elements(), _ledgerTransObject);
    // - iau для корректной корреспонденции проводок, необходимо проводки по порядку считывать, для этого используем ключ int
    // <GEEU>

    refId_RU = this.elements() - 1;

    // </GEEU>
    return true;
}