RecoilmeНе подскажете с какого боку подойти к решению такой задачи:
есть Год/Месяц/День, товар, кол(Qty) (+ и -)
Надо расчитать процент наличия товара на полке за месяц....

Т.е. типа расчитать остатки на каждый день в заданном измерении, например, месяц, выбрать количество записей когда рассчитанный Qty > 0 и соотнести с количеством дней в месяце...

Как бы так извратиться???? Очень не хочется на SQL|Axapta кодить.... точнее на аксапта уже закодена такая хрень, но работает очень долго хочется в кубике/рубике....

1. А что такое % наличия товара на полке? Как это можно интерпретировать? [Количество Дней когда остаток > 0]/[Количество Дней]*100?

2. Для начала построить куб остатков (а может быть и движений). На форуме это достаточно часто обсуждалось, так что рекомендую "поиск".

Recoilme
Меня совсем прёт, или г-н backfire сейчас черкнет длинный непонятный текст который можно впендюрить в куб и поиметь счастье??? :)

Я не шаман, шаман сидит на другом берегу Большого Пруда.

Вы про кубик то подробнее расскажите. Что в таблице фактов? Голые движения? Начальные остатки тоже как движения? Или есть отдельно остатки на начала месяцев (дней, кварталов, лет - нужное подчеркнуть)

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

max_spbtiМона и так, только при выборе нескольких элементов измерения [Дата] неработает

IIf(ISLeaf([Номенклатура]) and IsLeaf([Склад]),IIF(isleaf([Дата]),
IIF([Measures].[Остаток]>0,1,null),Sum([Дата].Children)),null)

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

1. Должны ли выбранные периоды быть смежными или нет
2. Что такое начальный и конечный остаток.
3. Насколько просядет перформанс по сравнению с широкоупотребимыми формулами, если все таки такую формулку сможем создать.

Dmitry Biryukovдля смежных периодов, вроде бы уже придумали формулу
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!113.entry

начальный остаток (если мы говорим о днях) это остаток на начало первого дня периода = остаток на конец дня, который идёт перед первым днём в периоде
аналогично конечный остаток это остаток на конец последнего дня периода = остаток на начало дня, который идёт первым после последнего дня в периоде

или на языке MDX (если выбран один элемент измерения Date)

начальный -

конечный

как в оборотке - начальный+приход-расход=конечный

третий вопрос - таки да. имхо, надо из приложения генерить MDX, в зависимости от multiselect или singleselect измерения data.

тогда при singleselect получим не меньшую производительность, а при multiselect, как говорится, сами же просили...

Дмитрий, простите за наивеый вопрос, правильно ли я понял, что
под Date.Levels(THE_LOWEST_LEVEL_NUMBER) вы имелли ввиду

Date.Levels.Item(Date.Levels.Count - 1) или THE_LOWEST_LEVEL_NUMBER недокументированная фича в MDX? (В чем я глубоко сомневаюсь)

з.ы. Позвольте полюбопытствовать. В свободное от МДХ время вы пишете на Басике какой то масти?

Кстати о птичках (PrevMember). Тут намедни в форуме был разговор в котором Моша признался о существовании бага в PrevMember, NextMember etc. Так что поосторожней с ними.

RecoilmeЗадача:
Расчитать возможные продажи товара при условии постоянного наличия товара

В рамках задачи предлагается решить следующие подзадачи:
1. Расчет количества дней, когда товар был в наличии (остаток на конец каждого дня > 0) в заданном периоде
2. Расчет общего количества дней в периоде
3. Расчет отношения "1" к "2" (коэффициент наличия товара)
4. Расчет произведения реально проданного количества на "3"

Допущения и ограничения:
1. Периоды могут быть только смежными если это необходимо
2. См. выше
3. Желательно чтоб перфоманс сел не более чем на 200% по сравнению с сажанием перфоманса при использовании функции периодс2дате :)
4. Инструменты MS AS + Excel 2002/2003

Бюджет проекта: 0 руб 00 коп.

Сроки: безумные

А в какой прикладной области вы решаете задачу?
Опт, Розница?
Характер товаров?
Какова конечная цель?
Просто посмотреть на возможные продажи и облизнуться или использовать эти данные для управления закупками во избежание OOS (Out-of-Stock)?

Я в свое время решал эту задачу для оптового торговца продуктами питания (во времена когда MS AS еще не существовал и все решеник было построено в MS SQL тогда 6.5). И по началу считал именно так как и вы (коэффициент наличия товара). Но практика показала, что п.4 выдает завышенные результаты ибо не учитывает того эффекта, что в первые дни появления товара после нескольких дней OOS, дневные продажи существенно выше, чем если бы товар был все время на складе (эффект "выбросили дефицит"). Если доля постоянных клиентов высока и они знают, когда будет товар и покупают его тогда когда он есть, ибо знают когда он появится, то ваша теория "возможных продаж" валится как карточный домик. Ваша теория хороша для розницы (noname customer or relationless customer), но и то в известных пределах.

Если же абстрагироваться от вопросов применительности вашего метода и спуститься к постным MDX проблемам, то перформанс видится слабым и болезненным, особенно если в качестве FrontEnd выступает Excel с его "высокоинтеллектуалтным" генератором MDX запросов.
Я бы взял уж како нибудь FrontEnd, где можно custom mdx отрабытывать. Тот же Reporting Services может вам очень помочь (конечным юзерам MDX Sample Applicatioin ведь не дашь)

А что там на pivotview.com?

А то у меня

Forbidden
You don't have permission to access / on this server.


--------------------------------------------------------------------------------

Apache/1.3.23 Server at www.pivotview.com Port 80

Dmitry Biryukov RecoilmeЖалко что чудесная формула Дмитрия возвращает ноль, а не нулл...Это можно настроить с помщью non empty behaviour или через банальный IIF

RecoilmeМожно ещё вопрос?? Как половчей посчитать количество дней в выбраном периоде (если несколько элементов выбрано)?


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

1. с помщью non empty behaviour вы вряд ли добъетесь чего либо толкового ибо non empty behaviour ведет себя как хочет.

2. Ваша формула вернет количество дней когда были факты в кубе, а не количество дней. Для этого NECJ гораздо скорострельнее. А вот количество дней под членом измерения я бы считал просто как


Но при multiple select не катит. Там надо в MDX иметь set из выбранных членов измерения, а не СM от них. Из CM сет не выудишь. И если CM делается во FrontEnd, то сушите весла.

Dmitry Biryukovвот именно, что моя формула считает правильно даже при мультиселекте - проверено.

" формула вернет количество дней когда были факты в кубе, а не количество дней " вот это конечно верно.

Если Вас не затруднит, пожалуйста приведите пример запроса желательно на FoodMart, где она считает правильно на MultiSelect