Проблема возникает при настройки ретракции в PSM_FM. Когда пытаемся прописать соответствие полей, проваливаемся в Абап-ошибку. Например, когда прописываем в поле УБ "Сумма" BW-объект, то выходит ошибка
An error occurred when executing a REMOTE FUNCTION CALL. It was logged under the name "DYNPRO_SEND_IN_BACKGROUND" on the called page,
хотя сгенерированный bw-объект для этого поля должен подставиться автоматически (запрос служит как источник данных, соответствующую галку поставили).
Может у нас проблемы в с bw-системой, в которой мы прописываем это соответствие?

Стыдно, но не понятно.

С помощью FMCYCOPI_BW ретракцию выыполняете?

Note 997002 - FMCYCOPI_BW: Message F6001 "Error in accessing function.." не подойдет?

нет, это не то. До запуска FMCYCOPY_bw не доходит, еще поля не прописаны. К тому же запрос у нас ограничен одним финансовым годом.

проблемы были с соединением, справились, данные передаются нормально. Вот только у нас планирование ведется в тыс. , в FM же нет, надо передать данные увеличенные в тыс, к тому же надо добавить НДС к передаваемым данным. В запросе это сделать нет возможности, в соответствии полей тоже этого нет. Т.е. можно обойтись только, манипулируя настройками куба, дополнительной загрузкой с помощью правил переноса и т.д.? Есть ли еще какой-нибудь способ? Вы не встречались с этим? Как вы настраивали ретрактор в таких случаях?

А почему нет возможности настроить это в запросе?

При передаче данных мы используем показатель 0amount, он имеется у нас в запросе и прописан в соответствии полей. Если вместо этого показателя мы используем формулу «показатель*1000», то при запуске ретракции значения в запросе не определяются, соответственно ничего не передается.

Как вариант можно использовать масштабирование = 3 в форматах планирования.

нет, не подойдет, нам ведь нужно наоборот в сторону увеличения, т.е. если был бы коэффициент масштабирования 0,001, то проблема частично была бы решена, но кроме того остается ндс.

Как раз все правильно, если Вы планируете в тысячах, то в формат вводится, например, 35, а куб и в отчет попадает 35000, то что Вам нужно.
С НДС хуже. Можно использовать два показателя в кубе - один с НДС другой без. Для ретракции использовать с НДС.

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

Данные можно трансформировать, домножить на тысячу FOXом прямо в продуктиве. Только конечно надо делать это очень аккуратно и заранее сделать бэкап. Плодить в системе избыточные операции не очень хорошо.