Добрый день, коллеги!

Имеется отчет ИНДЕКСЫ ЦЕН, показывающий соотношение уровня цен отчетного и базисного периодов, в нем отображены номенклатурные позиции, закупка по которым производилась в отчетном и в базисном периоде. Первичный расчет формируется на основе данных по счетам-фактурам, в разрезе номенклатурных позиций. В расчет включены только позиции, по которым осуществлялась закупка, как в базисном, так и в отчетном периоде. По этим позициям осуществляется проверка – на сопоставимость данных, если в рамках одной номенклатурной позиции цены отличаются более чем в 10 раз, такие данные исключаются из расчета, собираются на отдельном листе – несопоставимые позиции. По позициям прошедшим проверку формируется основной отчет для расчета индексов цен, по следующей формуле:
ИНДЕКС ЦЕН = ∑(Pотч*Qбаз)/∑( Pбаз*Qбаз),
где
Pотч- цена номенклатурной позиции отчетного периода,
Qбаз – количество номенклатурной позиции базисного периода,
Pбаз - цена номенклатурной позиции базисного периода.
Затем по выбранной пользователем группировке (по классам или по выбранным группам) формируется итоговый расчет. ИТОГО отчет имеет вид таблицы excel на 3 листах: первичный расчет, основной расчет, итоговый расчет.

Вопрос в следующем: стоит задача доработки механизма удаления несопоставимых данных: из совокупности данных по одной номенклатурной позиции должна удаляться только несопоставимая счет фактура, а не все данные по этой номенклатуре (например 1 из 10 счетов фактур).

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

сделать подпрограмму на трансформации в нужном месте

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

сверять данные

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

Базисный период всегда один или определяется на основе пользовательского выбора?
В каких разрезах данные лежат в кубе?
Пс. Не думали про использование виртуального провайдера?

И базисный и отчетный периоды определяются на основе пользовательского выбора.
Данные в кубе лежат в разрезах: документа (№, поз., дата проводки счетов-фактур), номенклатуры (материал) по каждой сч.ф. есть сумма и кол-во.
Насчет виртуального провайдера, можете немного подробнее? Какой посоветуете использовать в данной ситуации, и в чем будет его приемущество наряду с созданием доп. уровня агрегации и объединения его в мультик вместе с кубиком?

Виртуальный куб позволит выполнять любую нетривиальную логику расчета. Например если для разных значений на СЭ нужно выполнять разные расчеты.


В Вашем случае на ум приходят еще 2 идеи, которые сильно проще в реализации:
1) Использование огараничения по документам с помощью пути-замены:
1.1 Делаете 2 квери, у которых ограничения совпадают с вашим текущим отчетом
1.2 В первом квери выводите только те позиции(не группы), которые с "хорошим" соотношением, во втором с "плохим"
1.3 В отчте, выводящемся пользователю, ограничиваете признак позиции переменной над соответствующем запросом

2) Использование формул в бексе и специальной агрегации
2.1 делаете формулу(синтаксис не соблюден!!!) (Ротч/Рбаз >=10 ; 0; Ротч * Qбаз ) - получаем 1ую часть Вашей формулы
2.2 В спец агрегации указываете ссылочный признак - позиция и расчет до агрегации
2.3 Могу ошибаться в точном написании формулы, но ключевое это расчет отдельных значений до агрегации, а потом уже суммирование

Оба способа должны работать. Единственно надо проверять как будет быстрее с Вашими объемами данных, впринципе и тот и другой задействует OLAP Engine, что достаточно быстро.

dedemedved
спс за советы, буду разбираться.

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

Из перечисленного только 4ый пунк - вопрос?=)

Совершенно верно, первые три пункта это критерии, исходя из которых хотелось бы услышать ответ...