Про не может использоваться - это, наверное, из-за того, что Вы дату пересчета через переменную получаете. Если задать переменную в контрольной дате запроса и настроить вид пересчета на эту контрольную дату - то все ОК будет...

Но главную проблему так и не удалось решить Разве что смотреть 2 системы одновременно, нашу и вашу, и сравнивать все настройки, касающиеся валют

Заработало! Надеюсь... Спасибо огромное за помощь. Натолкнуло на решение упоминание о том, что я дату беру из переменной... но я ведь не из переменной, а из объекта (а точнее - из атрибута объекта для которого считаю сумму). И вот тут я вспомнил, что в строках у меня не "чистый объект", а структурка с выбором, который содержит этот объект (по идее - все равно должно было работать, раз работало для рублей, но...). Убрал структуру, вытащил непосредственно сам объект - заработало. Убрал в ведении коэффициентов USD-EUR - работать продолжает, вроде бы.


Итак, резюмируя, при необходимости конвертации какого-то валютного показателя (сумма, цена) через преобразование в базовую валюту (если не ведутся курсы из какждой валюты в каждую), есть 5 пути решения задачи:
1. В строки можно поместить структуру, содержащую "выборы" из признаков и тогда на каждый "выбор" можно задать преобразование валют. Кроме того - преобразование валют может быть определено и для показателя (например, в столбцах), таким образом имеем, что для одной и той же ячейки конвертация валют будет выполняться дважды. В хелпе написано, что порядок конвертаций будет повторять порядок их определения\изменения. "Почти" работает, не довел эксперимент до конца, т.к. стало понятно, что решение не очень подходит, т.к. получается достаточно трудоемко реализовать отчет, у которого в одной строке в разных столбцах будет, например, сумма в валюте документа и сумма в валюте отчета (или только если конвертировать ее назад в ту же валюту), а второй минус в "определении" порядка преобразований - хотелось бы как-то более определенно. Взято отсюда - http://help.sap.com/saphelp_nw04/helpda ... ameset.htm "Multiple Currency Translation Types in One Query"
2. Поставить нужную валюту в качестве базовой для нужного типа курса (SPRO-NetWeaver-Общие-Валюты-Проверка типов курсов) и кросс курсы будут считаться "на лету". Работает вся эта штука несколько странно, если в строках используются структуры, а, возможно, что и еще в каких-то ситуациях. Кроме того, если по бизнес процессу заказчика нужно проводить конвертации, в базовую и из базовой валют, разными типами, то метод неприменим. У меня этот вариант все же подошел, его и выбрал.
3. Написать для конвертации свой любой модуль, который вызывать извращенческими способами из VB рабочей книги.
4. Написать свой модуль для загрузки валют, который будет получать имеющиеся курсы и генерировать из них все кросс-курсы, которые возможны. Вариант не дошел до попытки практической реализации.
5. Преобразование в базовую валюту осуществлять в дополнительный показатель на этапе загрузки данных в куб\ODS. Плюс - теоритически должны лучше и быстрее строиться агрегаты по этому показателю (есть возможность предрассчитать их на определенных уровнях и хранить). Минус - будет работать нормально только при полном обновлении цели данных (т.к., и я на это наткнулся, курсы на прошлые даты могут быть откорректированы "задним" числом).

Вот.

Гы Вот ведь фашисты... Не зря мы им ввалили во второй мировой

С вариантами согласен. Только 3 и 4 - это для извращенцев, вариант 5 - не универсальный, не на любую дату пересчет производить можно будет.

Рад, что все получилось таки.

Продолжаем тему...
Наши симпатичные пересчеты - по типу НН и по типу M валют работают, как часы.
А теперь делаю значит свой кубик, не мультик, с 2 показателями, которые надо пересчитать.
Даты пересчета валют лежат в атрибутах навигации двух признаков, соответственно определяющих эти показатели.
В один показатель загоняю пересчет типа НН, в другой типа М.
Выполняю отчет, ввожу вместо рублей доллары. Получаю предупреждение

"Забиваю" на предупреждение - пересчет по типу НН выполняется, по типу М в столбце пусто.