оборотная ведомость по складу необходимо добавить ещё один фильтр

[jeky]

Доброго!

у наших журналов есть дополнительный признак (наша доработка) да/нет
в отчет должны попадать журналы с со значение признака Нет

просмотрела код отчета (InventTurnover_RU)

попыталась добавить join и наложить условие в calcAll - не получилось

        while select RecId, CostAmountPosted, CostAmountAdjustment, Qty,
                     DatePhysical, Direction, TransRefId, InvoiceId from searchInventTrans
            where searchInventTrans.DatePhysical  <= endDate                            &&
                  searchInventTrans.ItemId        == inventTable.ItemId                 &&
                  searchInventTrans.Direction     != InventDirection::None              &&
                  searchInventTrans.StatusIssue   != StatusIssue::OnOrder               &&
                  searchInventTrans.StatusIssue   != StatusIssue::Picked                &&
                  searchInventTrans.StatusIssue   != StatusIssue::ReservOrdered         &&
                  searchInventTrans.StatusIssue   != StatusIssue::ReservPhysical        &&
                  searchInventTrans.StatusIssue   != StatusIssue::QuotationIssue        &&
                  searchInventTrans.StatusReceipt != StatusReceipt::Registered          &&
                  searchInventTrans.StatusReceipt != StatusReceipt::Arrived             &&
                  searchInventTrans.StatusReceipt != StatusReceipt::QuotationReceipt    &&
                  searchInventTrans.StatusReceipt != StatusReceipt::Ordered
        join inventDim
            where inventDim.inventDimId           == searchInventTrans.inventDimId      &&
                  inventDim.InventLocationId      == InventLocationId
//мои изменения -->
        join InventJournalTrans
            where InventJournalTrans.InventTransId == searchInventTrans.InventTransId
        join inventJournalTable
            where inventJournalTable.JournalId     == InventJournalTrans.JournalId      &&
                  inventJournalTable.UNS_IsPererabotka == NoYes::No
//мои изменения <--

так же попыталась добавить такой же join в CostAmountPosted здесь же calcAll, тоже не помогло.. join-ы работают - проверяла и в обозревателе и в студии...
помогите, пожалуйста, в пн. с утра сдавать очет....

[jeky]

так же попыталась навесить цепочку из датасорсов в query отчета в AOD c ранджем на нужном поле - Нет
тоже ни к чему не привело...

[jeky]

если все же кто-то мимоходом заглянет...
after - мои изменения - к сожалению превысил лимит в 300кб
before - до моих изменений

[Андре]

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

Как правило, оборотка и так не самый быстрый отчет, а join 2-х дополнительных таблиц отрицательно скажется на ее быстродействии.

Кроме того, я бы имел в виду, что разнесенные журналы могут быть удалены. Если не сразу, то через пару лет в момент "обрезания" базы данных. А в этом случае ваш отчет будет работать не корректно.

[jeky]

Цитата:

Сообщение от Андре

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

Как правило, оборотка и так не самый быстрый отчет, а join 2-х дополнительных таблиц отрицательно скажется на ее быстродействии.

Кроме того, я бы имел в виду, что разнесенные журналы могут быть удалены. Если не сразу, то через пару лет в момент "обрезания" базы данных. А в этом случае ваш отчет будет работать не корректно.

спасибо! буду над этим думать, только вряд ли мне сейчас на это выделят время...
у нас на работе просто пожар..

[jeky]

вобщем поступила совершенно бесцеремонно и некрасиво ..
вытащила из searchInventTrans id проводки.. по ней делаю дополнительный селект из проводок с уже проверкой сторно это или нет, если да, то в пеменную isStorno запоминаю а дальше закрыла под неё вычисление оборотов, а остатки на конец и начало вычисляются по-прежнему...
самое быстрое, что смогла на сегодня утро придумать... а дальше будем посмотреть ...

[sukhanchik]

Против непосредственно наложения фильтра ничего не имею, но... почему Вы решили что все складские операции (searchInventTrans) порождены из складских журналов (InventJournalTrans)? Да и разнесенный складской журнал - в общем-то никто не мешает удалить (если это не запрещали в рамках доработки).

Тут более правильно будет не джойниться с InventTrans, а уже внутри цикла каждый раз делать find к InventJournalTrans. Это конечно будет медленнее. Ну либо - not exists join к InventJournalTrans, где поле UNS_IsPererabotka == NoYes::Yes. Но этот запрос тоже надо замерять по времени

[jeky]

Цитата:

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

Против непосредственно наложения фильтра ничего не имею, но... почему Вы решили что все складские операции (searchInventTrans) порождены из складских журналов (InventJournalTrans)?

не знаю.. полностью отчет писала не я .. мне просто нужно исключить проводки относящиеся к журналам переработки

Цитата:

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

Да и разнесенный складской журнал - в общем-то никто не мешает удалить (если это не запрещали в рамках доработки).

запрещали..

Цитата:

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

Тут более правильно будет не джойниться с InventTrans, а уже внутри цикла каждый раз делать find к InventJournalTrans. Это конечно будет медленнее. Ну либо - not exists join к InventJournalTrans, где поле UNS_IsPererabotka == NoYes::Yes. Но этот запрос тоже надо замерять по времени

проблема, что в InventJournalTrans не пишется этот признак - он есть только у InventJournalTable
за идею спасибо! буду думать как же это применить

[jeky]

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

[Raven Melancholic]

Давайте попробуем начать сначала:

Цитата:

не получилось

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

[jeky]

Цитата:

Сообщение от Raven Melancholic

Давайте попробуем начать сначала:

То есть запрос должен выбирать только те операции, которые принадлежат нужным журналам. Значит "не получилось" это что-то другое. А вот что?

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

[Raven Melancholic]

Посмотрел сам отчет (мы его не используем по той причине, что определение остатков там выполняется "с начала времен", что при 5 летней базе не есть гуд).
Кажется догадался, что "не получается" это то, что в отчет попадают все номенклатуры. Но так и должно быть - calcAll всего лишь считает для конкретной номенклатуры данные, но номенклатура уже выбрана и в отчет попадает. Вам нужно модифицировать сам query (надеюсь, что на копии, а не на оригинальном отчете). Так же, если по каки-то причинам Query менять нельзя, то можно отсекать лишние записи либо переопределив fetch, либо программно модифицировать QueryRun перед выполнением на конкретный сеанс, ну и не очень красиво - в executeSection не вызывать super, если запись не подходит (тут возможны неприятные побочные эфекты)