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

[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 - до моих изменений

[sukhanchik]

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

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

[Андре]

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

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

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

[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, если запись не подходит (тут возможны неприятные побочные эфекты)

[Raven Melancholic]

Пока писал, получил ответ и успел посмотреть проект. Но в проекте нет кода, приведенного в собщении. Лучше приложить тот проект, в котором уже есть изменения.
PS: кстати, когда вызываете отчет точно используете свой менюитем, а не стандартный?

[jeky]

Цитата:

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

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

Query уже тоже меняла... путём навеса датасорса, сначала InventJournalTrans с определением рэлейшина по itemid далее датасорс inventJournalTable с рэлэйшином по JournalId и ранжем UNS_isPererabotka - No

[jeky]

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

Цитата:

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

Пока писал, получил ответ и успел посмотреть проект. Но в проекте нет кода, приведенного в собщении. Лучше приложить тот проект, в котором уже есть изменения.

я пыталась его выложить - но он не поместился в положенные на сайте 300 кб, сейчас ещё раз попробую - удалила из query датасоры

[Raven Melancholic]

Цитата:

разъехались остатки на начало и конец периода

Это вполне естественно. Установив фильтр только по журналам, подходящим под условия, вы и получили остатки, сформированные только с учетом таких движений - остальные игнорируются. Вообще, забудьте про получение остатков таким способом, который используется в отчете InventTurnover_RU. Для получения остатков используйте соответствующие классы семейства InventSumDate*. Как их использовать можно посмотреть по ссылке:
http://axapta.mazzy.ru/lib/inventsumdate/

[jeky]

Цитата:

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

Это вполне естественно. Установив фильтр только по журналам, подходящим под условия, вы и получили остатки, сформированные только с учетом таких движений - остальные игнорируются. Вообще, забудьте про получение остатков таким способом, который используется в отчете InventTurnover_RU. Для получения остатков используйте соответствующие классы семейства InventSumDate*. Как их использовать можно посмотреть по ссылке:
http://axapta.mazzy.ru/lib/inventsumdate/

да, спасибо. давно смотрю на эти классы.. но нужно совместить с начальным остатком и конечным приход и расход.. т.е. нужен все-таки оборот..

[Raven Melancholic]

В приложенном отчете InventTurnoverNoStorno_RU та же проблема по остаткам. Остатки считаются только по тем операциям, которые подходят под условие - "это не сторно". Для оборотов это нормально, а для остатков - нет, так как остатки должны формироваться по всем операциям.

Цитата:

у нас на работе завал

В разгар кризиса много работы - это же хорошо . Где такое счастье?

[Raven Melancholic]

Цитата:

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

дно нужно совместить с начальным остатком и конечным приход и расход.. т.е. нужен все-таки оборот..

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

[jeky]

Цитата:

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

В приложенном отчете InventTurnoverNoStorno_RU та же проблема по остаткам. Остатки считаются только по тем операциям, которые подходят под условие - "это не сторно". Для оборотов это нормально, а для остатков - нет, так как остатки должны формироваться по всем операциям.

Да, я уже это поняла спасибо! - очень правильно все разошлось...

Цитата:

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

В разгар кризиса много работы - это же хорошо . Где такое счастье?

Да.. счастье-то счастье... а вот как бы по окончании этой большой работы как бы не пнули под зад!

[jeky]

Цитата:

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

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

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

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

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

[jeky]

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