Ах2009 Запрос - ОСВ по складу

[Arahnid]

В одной из компаний не видятся проводки в таблице InventSettlenment c типом корректировка при формировании отчета Управление зарасами\проводка\Оборотная ведомость по складу.

Что интересно:
В классе InventSumDateFinancialCalc_RU в методе calcTransFinancialSettlements считаются корректировки.
Видит он это из
[s] \Classes\InventSumDateFinancialCalc_RU\calcItem 13
[s] \Classes\InventSumDateFinancialCalc_RU\calcItems 16
[s] \Classes\InventSumDateFinancialCalc_RU\run 10
[s] \Classes\InventTurnoverReport_RU\calcTrans 3
[s] \Classes\InventTurnoverReport_RU\run 11
[s] \Classes\InventTurnoverReport_RU\main 8
[s] \Classes\MenuFunction\runServer
[c] \Classes\FormFunctionButtonControl\Clicked

Беру оборотку. Теретически в нее должен попасть персчет склада с типом Разноска в сальдо на начало периода (проблема анлогичная и с оборотами).. Не попадает.

При этом если убрать условие
settlement.SettleModel != InventSettleModel::PhysicalValue
Начинает попадать. Только вопрос в том, что проводка итак Корректировка.

Оставляю условие SettleModel
и комментирую условие на начальную дату, проводка попадает.
При этом попробовала добавить в группировку SettleModel. Проводка действительно Корректировка и все должно быть хорошо.


Может есть какие-то дополнительные настройки?

[S.Kuskov]

Цитата:

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

если убрать условие
settlement.SettleModel != InventSettleModel::PhysicalValue
Начинает попадать. Только вопрос в том, что проводка итак Корректировка.

Оставляю условие SettleModel
и комментирую условие на начальную дату, проводка попадает.
При этом попробовала добавить в группировку SettleModel. Проводка действительно Корректировка и все должно быть хорошо.

Возможно где-то анализируются уже агрегированные данные. (допустим если значение ноль, то в отчёт не выводить). Как только вы меняете условие отбора записей для суммирования - часть слогаемых отсекается, сумма становится не нулевой и попадает в отчёт.

Когда вы добавляли группировку по SettleModel случайно не появлялись отрицательные значения, которые могли бы объяснить возможное обнуления суммы? Хотя проверка на ноль - это только гипотеза, в реальности там может быть что-то ещё.

[Arahnid]

Проверка на сумму там есть, но я вообще в этом цикле отключала все условия.
Оставляла 3: номенклатура, тип движения и начальная дата. Эффект тот же.

Отключила условие на
settlement.InventTransCurrency_RU == InventTransCurrency_RU::PrimaryCur все в том же классе InventSumDateFinancialCalc_RU в методе calcTransFinancialSettlements . Оставила остальные условия и заработало.
InventTransCurrency_RU - эту колонку вижу в таблице inventsettlement. Делаю открыть таблицу черз аксапту - нет.
Открываю СКУЛЬ. Смотрю колонки - нет такой. Глобальная компиляция не помогла.
Что это за реквизит?
Почему только в одной компании такая проблема не ясно.

Двух валютный склад отключен.

[Raven Melancholic]

Цитата:

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

Двух валютный склад отключен.

Именно поэтому - это поле как раз сидит на конфигурационном ключе двухвалютного склада.

[Arahnid]

Так куда посмотреть. Проводки в inventsettlement в двух компаниях абсолютно идентичны по заполняемости реквизитов. Но в одной работает, а в другой нет..

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

Ну, собственно, в подобных случаях везде в коде делают проверку на тот факт, что необходимый ключ включен. Вероятно, именно в данном месте это сделать забыли. Надо просто добавить эту проверку примерно так

Boolean isEnabledKey = global::isConfigurationkeyEnabled(configurationkeynum(InventClosingSecCur_RU));

while select ...
...
&& (! isEnabledKey || settlement.InventTransCurrency_RU == InventTransCurrency_RU::PrimaryCur)
...

Хотя обычно подобная проверка выполняется при конструировании Query и это является признаком того, надо ли создавать дополнительный Range или нет. Для прямого select не вполне понятно как это сработает.

PS: Если поле таблицы есть в AOT, но физически его не существует, то это явное указание на то, что отключен соответствующий ключ.

[Arahnid]

Не помогло условие на ключ.
Мне тогда проще строку комментировать, т.к. двухвалютного склада у нас нет и не будет

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

На всякий случай, а что, собственно, возвращает

    print global::isConfigurationkeyEnabled(configurationkeynum(InventClosingSecCur_RU));
    pause;

В смысле, ключ действительно отключен? Имею в виду, что по этому поводу "думает" Axapta именно в этой компании.

[Damn]

А я в методе calcTransPhysicalSettlements класса InventSumDateFinancialCalc_RU наткнулся на то, что некорректно работала вот эта часть запроса (27-я строка в методе) :

&& positive * settlement.CostAmountAdjustment  > 0

Записи в InventSettlement есть, но не возвращаются запросом (заметил это на записях с отрицательным CostAmountAdjustment). Вставил вместо такого сложного условия более простое и понятное (заодно от лишней переменной избавился) :

&& ( ( _positive && settlement.CostAmountAdjustment  > 0)
  || ( !_positive && settlement.CostAmountAdjustment  < 0 ))

и запрос заработал корректно.
На всякий случай такое же изменение вставил и в метод calcTransFinancialSettlements.

[Zabr]

Damn, Аксапта не всегда правильно определяет порядок выполнения операторов. Возможно, в стандартном коде достаточно было просто расставить скобки.

[Damn]

Цитата:

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

Damn, Аксапта не всегда правильно определяет порядок выполнения операторов. Возможно, в стандартном коде достаточно было просто расставить скобки.

Зная такое непредсказуемое поведение аксапты я перестраховался и на всякий случай решил в этом месте даже от умножения избавиться. От греха, так сказать.
Ну то есть не "даже избавиться", а просто не напрягать аксапту таким сложным арифметическим действием в условиях запроса. И заменить его на понятные ей "скобки + логические операторы".

[Damn]

Заглянул в Hotfix Rollup 8. Там это место не поправлено.