Коллеги, день добрый.
Есть необходимость поменять введенные значения признаков в IP, web. Есть форма ввода с кучкой полей, вводятся они на разных этапах, пользователь первоначально заполняет часть признаков и показателей, на след этапе оставшиеся, вот только у оставшихся признаков стоит решетка, и их-то он ввести не может. Вводить нолик в показатели и заполнять все заново не вариант... Как можно решить данную проблему? Или мож подскажите названия классов, которые отвечают за вывод формы ввода на экран и ее чтение?

Может помочь:How to Flexibly Change Characteristic Values and Comments in BI Integrated Planning
Но там говорится что можно только в Web шаблонах такое, для Excel не нашёл как.

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

Была идея с помощью макросов в Excel сделать автоматизацию изменения признаков таким образом: Копирование значений показателей и признаков в массив, обнуление, перенос, создание новой записи с измененными признаками, но это было бы совсем извращением и работало бы "не быстро". Сейчас пользователи сами делают эти операции вручную, но тоже хотят чтобы можно было менять сразу в самой таблице. Плохо что SAP не предусмотрел такую возможность.

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

Могу предположить что такой вариант подойдет:
Если у вас этапы строго опередены, то сделайте формат ввода для отчета, далее сохранение с проверкой введенных данных не на #, и обнуление решетки.

Мне почему-то кажется, что проблема в архитектуре системы и поэтому возникают такие проблемы. Может Вы приведете какой-то конкретный пример формы и данных и что потом нужно сделать?
Если у Вас пользователь сохраняет данные "на решетку", то они ложатся на определенный срез, а потом Вы хотите срез "поменять". В кубах любого производителя в таком случае может быть определена только операция сторнирования всего среза и заполнение другого заново.
Попробую предположить. Если подразумевается, что сумма с решетки может быть потом распределена по каким-то значениям, то не совсем понятно, что мешает это сделать, вроде бы нет проблемы потом добавлять записи с отличными от решетки значениями? Если хочется, чтобы просто пользователь не обнулял или менял вручную значение на решетке, то просто реализовать свою сложную логику функциями планирования. У меня в похожей ситуации (необходимость более сложно, чем в стандарте менять зависимые значения) была только проблема в том, чтобы иметь возможность определить - какие показатели были изменены пользователем. В этом случае можно просто добавить признак и разделить по срезам. Например добавить признак "срез" и значения "текущий" и "сохранено". На форме использовать уровень планирования, ограниченный значением признака "срез" = "текущий", а функцию планирования написать и запускать в контексте уровня с неограниченным признаком "срез", тогда в функции можно будет сравнить - что было и что ввел пользователь и обработать согласно своему алгоритму. При сохранении, разумеется, надо копировать информацию с уровня "срез"="текущий" на уровень "срез"="сохранено" (через последовательность функций планирования). Таким способом можно попробовать реализовать и "замену" (сделать отдельную форму, на которой вывести введенные признаки, дать дропдаунлисты со справочников не введенных признаков, пользователь выбирает и потом жмет кнопку "заменить" и далее функциями копируем данные, а на старом срезе - обнуляем или не обнуляем, но предусматриваем потом в отчетах и дальнейших расчетах, что на решетке лежат данные, которые не надо учитывать).
Также я могу ошибаться, но в случае, если сумму надо распределять, то в форме значение на решетке будет само корректироваться. То есть, если в куб "год, месяц, количество" и введем "2009, #, 100", а потом "2009, 1, 20" и "2009, 2,30", то в кубе запись на решетке изменится на "2009, #, 50" (верне, после первой на решетку запишется сторно -20 и после второй -30). Или нет?
Ну и для системы бюджетирования выглядит немного странной ситуация, что кто-то вводит цифры, а кто-то другой знает на каком срезе эти цифры должны быть. Мне кажется, что или первый знает на каких срезах или второй знает какие цифры. Вот кто знает - тот пусть вводит все. Или, возможно, просто неправильно выбран инструмент, это же не универсальные формы для ввода, а именно система сбора бюджетных показателей.

З.Ы. Если ошибся, то буду рад, если поправят, у меня опыта в SEM немного и его, к тому же, сейчас нет под рукой, чтобы проверить.

Не всегда BPS и Integration Planning используются для систем бюджетирования)
Ситуация, с которой у меня возникли проблемы, выглядела следующим образом:
Пользователь на нижнем орг уровне вводит перечень актов по своей организационной единице. 1 строка - 1 уникальный номер акта + набор признаков и показателей (характеристики акта). На следующем орг уровне ответственный присваивает этим рассчитанным актам счета. Основываясь на ТЗ, я решил что к каждому акту присваивается уникальный номер счета(соответственно тоже признак). Поэтому у ответственного пользователя вываливалась простыня из актов, которым надо присвоить каким-то образом счета. Сделать переменные "номер акта" и "номер счета" и функциями планирования присваивать к каждому акту свой счет просто, но тут бы получил вопль от пользователей, какого такого нам надо жать на кнопку, мы хотим прям в форме вводить номер счета. С ними тягаться бесполезно, хотим так и все, причем претензии вида - "а че это у вас переменных на отчете много, уменьшите в два раза" или "а че это в рабочей книге три листа, нам один нужен" (хотя эти три листа сделаны, чтоб ошибок при вводе и проверке не возникало).
Поэтому я и написал на форум узнать, нагибал ли кто-нить сап настолько, что закрытые для ввода поля признаков сохраненной в кубе стоки становились открытыми.
Правда, когда эта проблема у меня возникла, ТЗ уточнили, и вылезло, что одному счету соответствует несколько актов, поэтому я вполне успешно ограничился функционалом из хаутушки во втором посте.

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

Всегда так: на абаперов денег нет, а на консультантов есть.

Извините, но наболело.

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

Рекомендую почитать http://rdaemons.blogspot.com/2008/02/sap-bw-oltp-1.html
Вот в чем обычно корень бед: большинство внедрятелей думает, что IP (или BPS) - это система ввода циферок, даже не задумываясь, а для чего же собственно предназначался IP.

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

А потому что обычно люди представляют, что есть разные инструменты для решения разных задач. Вот вы человек (судя по тому, что вы написали), который овладел одним инструментом, а другие не применяет или из-за лени или отсутствия возможности учить их, либо из-за нежелания пускать чужаков к своей кормушке, т.к. придется делиться. Понятное дело, вы зарабатываете себе на кусок хлеба с маслом и даже красной икрой, и говорите окружающим: "не стреляйте в пианиста - он играет как умеет."

Просто жизнь такая штука: может быть через год, после того, как вы сдадите этот проект, кого-нибудь наймут доделывать ваш функционал. Этот кто-то поох...ет пару дней, пошлет пачку проклятий в адрес того, кто все это написал, да и перепишет на другом инструменте. И возможно цикл продолжится.

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

Я не очень хочу попадать в такие ситуации, но, увы, они у меня уже встречались. Этим и вызвана моя негативная реакция, а так - nothing personal.

Поверьте, я б с удовольствием выучил что-то новое (например BObj и BPC) и реализовывал проекты, для которых и предназначены данные продукты, но у меня есть проект, который я не выбирал, и срок - реализовать это за 1,5 месяца, одному, а не несколько абаперов и год времени, мое руководство устраивает, как я работаю на этого заказчика, поэтому так просто они меня с этой сковородки не выпустят.

Что довольно знакомое и близкое.

Испытывал схожие чувства с автором при виде данной системы.


Выводы в конце статьи верные, (которые в "Оставьте ваши притязанья").

Корень бед -- в кривых руках.
Не поверите, IP -- система ввода циферек в хранилище SAP. Более того, если приглядеться к API BPS, то там все именно так и происходит как надо топикстартеру -- просто пишется новый срез данных полностью затирая старый.


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

А если по существу, то лицензия на ERP и пара абаперов вряд ли обойдутся дешевле написания и поддержки консультантом пары-тройки тысяч строк кода на VBA.

Продолжим обмен ссылками - http://www.itoday.ru/24992.html

Цитата оттуда: