Текущее время: Вт, июл 22 2025, 09:53

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: READ_EXCHANGE_RATE: DERIVED_RATE_TYPE EURX
СообщениеДобавлено: Пт, май 06 2011, 16:54 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, фев 16 2006, 15:46
Сообщения: 451
Откуда: Россия
Скажите, а почему при попытке вызова модуля READ_EXCHANGE_RATE с параметрами

Code:
CLIENT                          100
DATE                            17.07.2007
FOREIGN_CURRENCY                EUR
LOCAL_CURRENCY                  RUB
TYPE_OF_RATE                    M
EXACT_DATE


Он возвращает
Code:
EXCHANGE_RATE  26.98000
FOREIGN_FACTOR 1
LOCAL_FACTOR 1
VALID_FROM_DATE                 01.01.2001
DERIVED_RATE_TYPE               EURX
FIXED_RATE 0
OLDEST_RATE_FROM                01.01.2001


Ну и это совсем не то, что в таблице TCURR по типу M?

Есть какой-нибудь ФМ, который прочтёт таблицу TCURR без этого "DERIVED_RATE_TYPE EURX"?

_________________
Ян Владимирович,
http://www.vladimirovich.net


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: READ_EXCHANGE_RATE: DERIVED_RATE_TYPE EURX
СообщениеДобавлено: Пн, май 09 2011, 14:50 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Ср, апр 12 2006, 12:43
Сообщения: 863
Откуда: СССР
Пол: Мужской
Yanvladimirovich написал(а):
Скажите, а почему при попытке вызова модуля READ_EXCHANGE_RATE с параметрами
.......
Ну и это совсем не то, что в таблице TCURR по типу M?

Есть какой-нибудь ФМ, который прочтёт таблицу TCURR без этого "DERIVED_RATE_TYPE EURX"?

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

Сумма в целевой валюте = Сумма в исходной * "значение курса" * "числитель курса" / "знаменатель курса".

Числитель и знаменатель часто равны 1, но там где курс указан за 10 (как, кажется на Украине с гривной) или за 100 это не так.

Посему придется самому делить/умножать/округлять, т.е. "колхозить".

Удачи.

_________________
Никого не трогаю, примусы починяю.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: READ_EXCHANGE_RATE: DERIVED_RATE_TYPE EURX
СообщениеДобавлено: Вт, май 10 2011, 13:19 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, фев 16 2006, 15:46
Сообщения: 451
Откуда: Россия
А самописный ФМ - сильно сложный?

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

Второй вопрос - если нет на конкретную дату курса, берётся на ближайшую предыдущую, так?

_________________
Ян Владимирович,
http://www.vladimirovich.net


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: READ_EXCHANGE_RATE: DERIVED_RATE_TYPE EURX
СообщениеДобавлено: Вт, май 10 2011, 22:06 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Ср, апр 12 2006, 12:43
Сообщения: 863
Откуда: СССР
Пол: Мужской
Yanvladimirovich написал(а):
А самописный ФМ - сильно сложный?
....

Я не могу подробно расписать.
Давно этим занимался и в другой фирме. На роботе в форум не пишу, а из дома нет доступа к САПу.

Посмотрите ФМ KURS_IN_PREISNOTATION. Там алгоритм близкий к тому, что я помню.
Обратите внимание на знаки множителей в коде. "Это ж не спроста" (ц) :wink:

Удачи!

_________________
Никого не трогаю, примусы починяю.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: READ_EXCHANGE_RATE: DERIVED_RATE_TYPE EURX
СообщениеДобавлено: Ср, май 11 2011, 07:43 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Ср, июн 13 2007, 16:36
Сообщения: 585
Откуда: Belarus
Пол: Мужской
Yanvladimirovich написал(а):
А самописный ФМ - сильно сложный?

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


Да вроде особой сложности там нет. Дёргай себе TCURR на да ту и всё.
На счёт хитрого кэша. На самом деле, ничего хитрого нет. При разработке оценивается приблизительное количество пересчётов. Если уж очень много (несколько сотен и более), то таки да, лучше через кэш работать. Я для этих целей использую обыкновенную внутреннюю сортированную таблицу с дальнейшим READ ... BINARY SEARCH.

Yanvladimirovich написал(а):
Второй вопрос - если нет на конкретную дату курса, берётся на ближайшую предыдущую, так?

Это уже не забота программиста, а требования бизнес-процесса. Обычно - да, ближайшая предыдущая. Но мне доводилось работать на проекте, где требовали ближайшую последующую.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB