Вот хочу спросить как реализовать такое: Есть статья и есть показатель1, показатель2, показатель3.....ну скажем максимум их 10.
нужно вычислить некую динамику этих показателей. Засада в том, что в зависимости от статьи формула может быть разная...либо П1/П2 либо П1/П2*П3/100...либо ещё какая-нить.
Сообственно вопрос - как лучше хранить формулу? Можно конечно перебрать какое-то конечное количество вариантов расчета и их реализовать....но хотется иметь какую-то настройку, не предпологающую разработку. Может у кого есть вариант решения.

Я, видимо, не очень понял твой вопрос... Все это хозяйство высчитывается в рутине, так? Т.е. вопрос в том, как не описывать в рутине формулы в зависимости от статей? Запуталсо

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

Почему не получится? У нас в в bps несколько юзерских отчетов так и сделано... (с поправкой)... Т.е. при запуске книги, имеем в книге 2 листа. Один лист, на который неформатированный запрос выходит, спрятан. А вот второй лист как раз набит кучей всяких формул юзерских, которые фигурируют данными из запраса на спрятаном листе. И все работает чики-пуки. Основной косяк, который может быть, это если случайно ячейки собьются, на которые лукап идет... Но это поправимо.

Под словом не получится я как раз и понимаю что могут сбиваться адреса ячеек. Мы тоже так делали, правда у нас один формат такой был. Просто ищу ещё идеи:)

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

(почему то все равно себя тупым ощущаю, как будто забыл что-то )

Ну вот и я про жеж...вроде по другому и никак...может оно и к лучшему:) меньше героизма будет у пользователя:)

Ну вот и порешили

Не совсем понял - надо, в зависимости от условий, убирать из формулы слагаемые и\или множители или вообще задавать произвольную формулу? Если первое, то можно написать одну большую формулу, охватывающую все показатели, но для каждого такого "убираемого" слагаемого предусмотреть переменную или условие по которому считаем надо или нет учитывать его - и указываем в формуле оператор if, который слагаемое обнуляет (а если множитель - делает его равным 1), если его учитывать не нужно. Вот как-то так.

Вот потом веселуха будет для тех, кто останется на поддержке системы, после внедрения подобных решений...

Боюся мегаформула с компонентами это конечно жесть....
Хотя такое решение полностью настраиваемое.
Насколько я себе вижу надо иметь настраиваемую формулу. А вот что за формула зарание не известно. Она будет состоять из доступных показателей...для конкретной статьи. Другой вопрос что места для хранения такой формулы попросту нету....а если заниматься танцами с дополнительными листами - возникают проблемы сохранения, поддержки актуальности.

RSA1 - Если все эти решения записать в документацию - не так уж и жестко.

Да уж...будет сама по себе все вопросы решать:) Выведет пару чудесных законов вселенной....и смешно и плакать хочится....
Хотя люди жеж как-то реализовали...подобное...
http://krista.ru/products/plan-about.htm

Цитата:

А в твоей практике было хоть один раз такое:

- Вся документация существует.
- Документация в порядке, up-to-date, её легко (ну пyскай можно) найти и даже разобраться в ней.

У меня такого еще не было...

Я особо не видел, чтобы сложные формулы были в документации описаны...