Ошибка Microsoft

[NNB]

Добрый день
При отмене закрытия склада в некоторой специфической ситуации (думаю в данном случае не важно в какой) вдруг перестала перестали корреспондитоваться постинги в LedgerTrans.
После разбирательства показалось станным, что в методе LedgerVoucherTransList.first() не меняется значение refId_RU.
Вставка оператора refId_RU = ledgerTransObject ? transIterator.key() : 0; исправила ситуацию. (Ax3, Ax4, Ax5 - все аналогично). Судя по всему ошибка локализации

[Logger]

Можете подробнее указать место ?

[b_nosoff]

Там мало того, что при выборке первого элемента не инициализируется refId, так еще и в LedgerVoucherTransList.next() происходит неявное приведение str к int А сработает эта мина в том случае, если вдруг кто захочет еще разок пройтись по этому итератору и вызовет first()...

[NNB]

По просьбе Logger:
Класс LedgerVoucherTransList метод first()

В нашем случае получилась явно неправильная корреспонденция
Надо выбрать время и посмотреь что было в других ситуациях

Я так понимаю что Microsoft готовит следующую локализациют (набирает людей). Господа исправьте пожалуйста

[Владимир Максимов]

Прежде, чем бросаться громкими заявлениями, неплохо бы посмотреть а для чего это значение вообще используется. Насколько я вижу, цикл first()...next() использует refId_RU только для индикатора прогресса. Просто, чтобы показать, что процесс идет. Так что, без разницы, что там будет за значение. Разумеется, если Вы сами не прикрутили какой-то функционал к этой переменной именно в цикле first()..next().

Так что, очень даже имеет смысл пояснить о какой такой "специфической ситуации" идет речь. Т.е. где-это Вам потребовалось использовать значение refId_RU иначе чем индикатор прогресса.

[b_nosoff]

Zitat:

Zitat von Владимир Максимов

Насколько я вижу

LedgerVoucherObject.postRoundingDifferencesPerDate()

ledgerBondServer.findBondTransObject(ledgerTransList.itemRefId_RU())

ну, т.е., вы согласны, что это потенциальная бомба, если только никто не будет бросаться громкими заявлениями?

[NNB]

Что бы на бросаться громкими фразами предлагаю заинтересовавшихся запустить поиск refId_RU по классам LedgerVoucherObject, LedgerVoucherTransList, LedgerBondServer_RU, LedgerBoundTransList_RU, LedgerBondClient_RU, LedgerBondTransObject_RU (для начала хватит) и сделать собственные выводы

[Владимир Максимов]

Zitat:

Zitat von b_nosoff

LedgerVoucherObject.postRoundingDifferencesPerDate()

ledgerBondServer.findBondTransObject(ledgerTransList.itemRefId_RU())

ну, т.е., вы согласны, что это потенциальная бомба, если только никто не будет бросаться громкими заявлениями?

Не уверен. Выдранный кусок кода, в данном случае, ни о чем не говорит. Надо же поднять всю историю. Откуда взялся экземпляр ledgerBondServer? Какое значение идентификатора он ожидает получить? То, что он получает, соответствует ожиданиям?

Zitat:

Zitat von NNB

Что бы на бросаться громкими фразами предлагаю заинтересовавшихся запустить поиск refId_RU по классам LedgerVoucherObject, LedgerVoucherTransList, LedgerBondServer_RU, LedgerBoundTransList_RU, LedgerBondClient_RU, LedgerBondTransObject_RU (для начала хватит) и сделать собственные выводы

Найти классы по перекрестным ссылкам - не проблема. Куда бОльшая проблема понять, для чего используется то или иное значение. Особенно, когда конечная цель "погребена" под многочисленной иерархией вложенных классов. Вы можете "человеческим" языком объяснить как используется полученное значение? Ну, получили в коде значение refId_RU. Ну, передали его как параметр в другой класс. А зачем передали-то? Как, в конце концов, это значение было использовано?

[NNB]

Могу
Только завтра - сегодня некогда

[b_nosoff]

Zitat:

Zitat von Владимир Максимов

Не уверен. Выдранный кусок кода, в данном случае, ни о чем не говорит. Надо же поднять всю историю. Откуда взялся экземпляр ledgerBondServer? Какое значение идентификатора он ожидает получить? То, что он получает, соответствует ожиданиям?

Вот на таких домыслах система и превращается в неуправляемого монстра.
А ItemRefId не что иное, как порядковый номер проводки в списке ваучера. И значение его должно быть вполне предсказуемо.
Я вас убедил, или вы все еще рассматриваете локализацию LedgerVoucherTransList как образцовую?

[Владимир Максимов]

Zitat:

Zitat von b_nosoff

Вот на таких домыслах система и превращается в неуправляемого монстра.
А ItemRefId не что иное, как порядковый номер проводки в списке ваучера. И значение его должно быть вполне предсказуемо.
Я вас убедил, или вы все еще рассматриваете локализацию LedgerVoucherTransList как образцовую?

Нет. Не убедили. Поскольку Вы смотрите на конечную точку безотносительно истории. Сразу же возникает вопрос, а откуда взялся объект ledgerTransList? А у него значение refId_RU на момент вызова корректно? Оно вообще как-то связано с циклом по first()..next()?

Я же говорю, "тщательнЕе" надо. Более внимательно изучать код. То, что это идентификатор и так понятно. Но в данном случае есть проблема с идентификаторами? Насколько я вижу, методы first() и next() вообще не имеют никакого отношения к идентификации. Они существуют "паралельно" с методом add(), который как раз и относится к идентификации.

Как образцовую, я реализацию LedgerVoucherTransList естессвенно, не рассматриваю. Именно в силу не очевидности кода. Существование в одном и том же классе неких "паралельных" логических структур.

[b_nosoff]

Zitat:

Zitat von Владимир Максимов

Нет. Не убедили.

Ну и ладно. Может кого другого убедил.

Просто, в качестве заключения - я полностью уверен в том, что это была попытка добавить к итератору функционал получения индекса текущего элемента. Duck typing, знаете ли...

[Владимир Максимов]

Zitat:

Zitat von b_nosoff

Просто, в качестве заключения - я полностью уверен в том, что это была попытка добавить к итератору функционал получения индекса текущего элемента. Duck typing, знаете ли...

Так я тоже в этом уверен.

В данном случае я не уверен в том, что методы first()..next() имеют какое-либо отношение к этому самому индексу текущего элемента. Неужели с Ax3.0 никто не налетал на эти грабли?

Ведь очевидно же, что метод next() противоречит методу add(). Метод next() на последнем элементе даст значение 1. Метод first() на первом элементе даст значение либо 1 (после последнего next()), либо elements()+1 (после add()). Явно же, что после использования методов first() и next() метод itemRefId_RU() возвращают какую-то ерунду, а не идентификаторы. Просто некий счетчик, не имеющий вообще никакого отношения к идентификаторам.

Вот в эту ловушку NNB и попал. Он использовал first() .. next() как способ получения идентификатора. А в данном классе это не так.

[fed]

После использования методов first() и next(), метод itemRefId_ru() возвращает как раз не ерунду. Достаточно посмотреть на код из LedgerVoucherObject.Post().

Просто ошибка эта может стрельнуть только в случае, если происходит повторный вызов first() на полпути, так сказать. Типа начали итерацию, поитерировали, а потом не дожидаясь исчерпания итератора (возвращения значения false методом next()), попробовали вызвать first(). В этом случае, следующий вызов itemRefId_ru() вернет значение рассинхронизированное с методом item().
Однако, я в коде стандартных классов, такого места не нашел. Везде вызывается first() и потом итерируется до тех пор, пока next() не вернет false, сбросив, таким образом, refId_ru в исходное нулевое значение.
Так что на первый взгляд:

• Если вы не изменяли стандартные классы корреспонденции и разноски в ГК,отсутствие инициализации никогда не должно приводить к ошибкам.
• Возможно, отсутствие инициализации - это баг.А возможно и нет. Я не уверен, что по идеологии работы с итераторами, их можно многократно итерировать, не закончив предыдущую итерацию. Мне, конечно тоже отсутствие инициализации глаз режет, но не уверен что это формально можно считать ошибкой...

[Pustik]

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

[Владимир Максимов]

Zitat:

Zitat von fed

После использования методов first() и next(), метод itemRefId_ru() возвращает как раз не ерунду. Достаточно посмотреть на код из LedgerVoucherObject.Post().

А дальше? Ну, получили значение lastRefId и как оно дальше было использовано? В классе LedgerVoucherObject - никак. Так какая разница, что именно в этой переменной записано?

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

=============================
И, кстати, насчет идентификации...

На всякий случай напомню, что MAP автоматически упорядочивает список по значению ключа. Но порядок следования чисел в символьном представлении отличается от порядка следования в числовом представлении.

Так что, и с этой стороны данный класс "не подарок" И опять же, явно противоречит использованию first() и next(). Не та последовательность перебора элементов. Отличная от последовательности создания элементов.

static void Job_Test(Args _args)
{
    MAP         transObject  = new Map(Types::String, Types::Integer);
    MapIterator  transIterator;
    ;

    transObject.insert('2', 1);
    transObject.insert('11', 1);

    transIterator = new MapIterator(transObject);
    while (transIterator.more())
    {
        info(transIterator.key());    // Сначала будет "11", потом "2"
        transIterator.next();
    }
}

Я просто не вижу зачем вообще нужно значение refId_RU при переборе элементов через first() и next(). Не вижу его использование как идентификатора именно после этих методов. После метода add() - есть использование. А после first(), next() - нет.

[Владимир Максимов]

Zitat:

Zitat von Pustik

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

Угу. Использование refId_RU в методе LedgerVoucherTransList.next() если не бессмысленное, то, как минимум, не очевидное. По крайней мере, я до сих пор не понимаю, зачем оно там вообще? А у автора, видимо, на этом какой-то свой функционал был построен. На чем он и "погорел".

[b_nosoff]

Zitat:

Zitat von Владимир Максимов

И, кстати, насчет идентификации...

На всякий случай напомню, что MAP автоматически упорядочивает список по значению ключа.

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

[Pustik]

Zitat:

Zitat von b_nosoff

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

Детально обсуждалось здесь Не корректная сортировка в Map-e и Set-е. AX2009 RU5

[fed]

Zitat:

Zitat von Владимир Максимов

А дальше? Ну, получили значение lastRefId и как оно дальше было использовано? В классе LedgerVoucherObject - никак. Так какая разница, что именно в этой переменной записано?

Сохраненное значение возвращается методом ledgerVoucherObject.lastRefid_ru(). Который, в свою очередь, активно вызывается и используется методом ledgerBondServer.splitTrans() Фактически этот метод вынимает из lastRefId идентификатор последнего обрабатываемого постинга, который сейчас разносится. Метод splitTrans(), как раз таки вызывается по цепочке ledgerVoucherObject.Post()->LedgerVoucherTransObject.post()->LedgerVoucher.postGroup()->ledgerBondServer.splitTrans(). То есть - это как раз позволяет классу корреспонденции добраться до контекста верхнего уровня и понять чего же это мы сейчас разбиваем в списке проводок (в случае детального постинга - без группировки сходных разносок).