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

jeky · 04.04.2009, 14:56

Доброго!

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

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

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

X++:

        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 · 04.04.2009, 16:04

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

jeky · 04.04.2009, 16:19

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

**sukhanchik** · 04.04.2009, 16:54

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

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

**Андре** · 04.04.2009, 16:55

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

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

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

jeky · 04.04.2009, 17:09

Цитата:

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

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

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

Цитата:

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

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

запрещали..

Цитата:

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

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

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

jeky · 04.04.2009, 17:12

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

Raven Melancholic · 04.04.2009, 17:41

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

Цитата:

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

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

jeky · 04.04.2009, 17:48

Цитата:

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

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

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

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

Raven Melancholic · 04.04.2009, 17:53

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

Raven Melancholic · 04.04.2009, 18:13

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

jeky · 04.04.2009, 18:14

Цитата:

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

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

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

jeky · 04.04.2009, 18:40

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

Цитата:

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

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

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

Raven Melancholic · 04.04.2009, 18:45

Цитата:

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

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

jeky · 04.04.2009, 18:50

Цитата:

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

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

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

Raven Melancholic · 04.04.2009, 18:51

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

Цитата:

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

В разгар кризиса много работы - это же хорошо

. Где такое счастье?

Raven Melancholic · 04.04.2009, 18:53

Цитата:

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

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

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

jeky · 04.04.2009, 19:24

Цитата:

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

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

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

Цитата:

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

В разгар кризиса много работы - это же хорошо

. Где такое счастье?

Да.. счастье-то счастье...

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

jeky · 04.04.2009, 19:28

Цитата:

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

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

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

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

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

jeky · 06.04.2009, 12:06

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
оборотная-ведомость по складу	Blondinka_N	DAX: Функционал	1	06.04.2009 18:30
Оборотная ведомость по складу	Morpheus	DAX: Функционал	15	08.10.2007 17:58
Оборотная ведомость по складу	Morpheus	DAX: Функционал	5	25.09.2007 17:12
Отчёт Упр. Запасами \ Отчёты \ Статус \ Оборотная ведомость по складу	Alks	DAX: Прочие вопросы	23	01.07.2005 18:29
Оборотная ведомость по складу	twilight	DAX: Функционал	8	05.04.2005 12:47