Добрый день,

Коллеги, нужен ваш совет.

Для загрузки валютных курсов из сайта местного НацБанка в нашу систему используем BAPI_EXCHANGERATE_CREATE.
Все курсы загружаются корректно, все коэффициенты пересчитываются, вот только изменения данных не отображаются ни в одной таблице.
При вводе курсов стандартно через OKC8 изменения отображаются в таблице DBTABLOG и можно посмотреть в журнале изменений.
Проверили стандартную программу загрузки курсов из txt файла - RFTBFF00. Она тоже не вписывает изменения ни в DBTABLOG, ни в CDHDR /CDPOS.
Сделать загрузку курсов без возможности просмотра изменений не хочется.

Может кто-нибудь уже сталкивался с такой проблемой и может подсказать решение?

Спасибо.

Свой лог вести.
У вас же своя загрузка.
Группа функций SBAL например.

Спасибо за ответ.

Но, к сожалению, нам такой вариант не подходит. Мы автоматическую загрузку курсов будем использовать только для тех валют, которые вводятся каждый день. А для одноразовых вводов будем использовать стандартную тр.OKC8. Получается, что нужно будет искать изменения в разных местах, что кажется очень неудобным.

Есть вариант использовать FM VIEW_WRITE_CHANGELOG_HEADER, которая не из группы функций SBAL, она вызывает VIEW_MARK_WRITE, которая пишет в DBTABLOG.

to Maka, проясните один момент.

Как Вы проверяете, что после успешной отработки бапи(то есть данные уже легли в таблицу TCURR) лог по этому делу не записался?

Еще, одна вещь, Вам не следуем мешать два разных вида логирования - DBTABLOG(это включается админами на уровне всей системы, для всех таблиц с галкой "запись в журнал"/после этого ничего делать не надо, действия логируются в любом случае/просмотр идет через scu3)
и
CDHDR /CDPOS - это документы изменений, настраивается через SCDO и при использовании, нужно везде, где участвует изменение таблицы, прописывать запись в лог...

В Вашем случае, 99% что этот процесс не использует CDHDR /CDPOS. Используется DBTABLOG.

Вопрос. Как Вы проверяете, что лог по таблице TCURR не записался? Просто я посмотрел BAPI_EXCHANGERATE_CREATE, в нем ничего особенного нету, обычный insert в TCURR, то есть если у Вас включен лог(а он включен, так как через sm30 Вы видите лог) + галка записи в журнал на таблице TCURR стоит, то лог записи по этой таблицы должны обязательно быть, имхо.

В чем может бы Ваша проблема? Вы не там и не так проверяете лог. Заходите в OKC8 и смотрите журнал после отработки бапи... Все правильно, там и не будет видно лога, потому что Okc8 показывает лог от V_TCURR и выбирает из таблицы DBTABLOG соответственно, а бапи не посредственно работает с TCURR и закидывает в таблицу DBTABLOG записи с ключом tabname = TCURR. Или же Вы проверяете CDHDR /CDPOS, тоже понятно, там и не будет ничего...

Проверьте через SCU3 или напрямую через таблицу.

Besa,
По порядку.
В настоящее время для ведения курсов валют используется транзакция OKC8 и, вне зависимости от успешности будущих разработок, расставаться с этой транзакцией не планируем. OKC8 имеет лишь одну функциональность просмотра изменений – Утилиты –> Журнал изменений.
Да, вы правы – показывает данные из DBTABLOG по V_TCURR.
Новая разработка планируется лишь как дополнение к OKC8 – облегчить исполнителям внесение курсов. По согласованию с конечными пользователями, через этот интерфейс будут вноситься курсы лишь по постоянно необходимым валютам. А в случае отдельных потребностей – пользователи пойдут через OKC8. Т.е., USD и EUR – ежедневно и через интерфейс, а шведские кроны (например) лишь в случае их необходимости и руками.
Вот и получается, что изначально проблема состоит именно в том, что через «Утилиты –> Журнал изменений» в транзакции OKC8 мы не видим следов работы ни нашего интерфейса, ни даже стандартной программы загрузки курсов из txt файла - RFTBFF00.
Видеть это «где-то в другом месте» - нет смысла!
(«тут играем, а тут рыбу заворачивали (С) Винокур)

Azik подсказал идею использовать FM для формирования лога, но его совет группы функций SBAL не подошел, но подтолкнул к поиску подходящего FM. Препарировали OKC8, обнаружили вызов VIEW_WRITE_CHANGELOG_HEADER (которая всего лишь вызывает VIEW_MARK_WRITE) вот сейчас пытаемся через использование этих FM добиться решения нашей задачи – чтоб все изменения, которые формируются в таблице курсов, при необходимости, было удобно отследить в одном месте. Вне зависимости от того, как вносились изменения/дополнения – через стандартную транзакцию OKC8 или через специально разрабатываемый интерфейс по импорту отдельных курсов с сайта Национального банка.

to Maka, понятно...
OKC8 со своим журналом это одно. Вы там видите кто что менял через OKC8 и теперь хотите продолжать отслеживать любые другие изменения(в том числе и через Вашу разработку) в этом же месте. При этом Ваша разработка исключительно использует бапи BAPI_EXCHANGERATE_CREATE? Если так, то имхо, единственное место через которое можно все видеть это тр SCU3(или набросать свою программку для просмотра логов). Если Ваша разработка будет использовать пакетник на OKC8, то все будет видно через «Утилиты –> Журнал изменений» в транзакции OKC8.
Про RFTBFF00 тоже самое, смотреть тр SCU3 на предмет TCURR. Кстати, Вы проверяли уже лог после изменения курсов Вашей разработкой так как я порекомендовал, логи есть ведь?

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

To Besa

SCU3 –TCURR в списке таблиц с включенной регистрацией в журнале.
BAPI_EXCHANGERATE_CREATE – самостоятельно формирует запись в DBTABLOG (по таблице TCURR);
RFTBFF00 – самостоятельно формирует запись в DBTABLOG (по таблице TCURR).
Принудительный вызов VIEW_WRITE_CHANGELOG_HEADER следом за BAPI_EXCHANGERATE_CREATE в нашей разработке (по аналогии с тем, как это сделано в OKC8) замечательно формирует запись в DBTABLOG (по V_TCURR) и это отлично видно из OKC8.
Besa, или расскажите о многих причинах, почему не следует этого делать.
Или мы будет счастливо думать, что успешно решили свою задачу.

Все правильно.



В этом случае, я опирался на код этих ФМ-ом(к сожалению, проверить не могу всю Вашу цепочку, логирование у нас не включено) , судя по нему, мне тогда вообще не понятно, как заполняется сам лог, то есть что/с какого поля было удалено, изменено или добавлено. То есть, сама запись в DBTABLOG заходит, но вот LOGDATA...

К тому же, к этому моменту, система уже запишет лог изменения таблицы TCURR, то есть у Вас просто будет дубль(TCURR/V_TCURR)...
Так же, изменение таблицы БД, происходит через ФМ-ы обновления, если там что то "упадет", а Ваш Фм по логам вызовется, то занесет в логи не нужную запись, то есть VIEW_WRITE_CHANGELOG_HEADER нужно наверное в очередь все таки поставить.

С другой стороны, пока писал, такая мысль, возможно это просто маркер и этот ФМ работает с глобальными данными из одной группы функций, где есть значения логов, то есть этот ФМ просто добавляет запись в лог с ключом V_TCURR(для того чтобы отделить ручной ввод курсов через OKC8(журнал) и любой другой программный), то есть возможно все нормально. И еще одно, если так, то думаю что этот ФМ нужно вызывать дважды, до и после...

В любом случае, я могу ошибаться как и все , рад что у Вас все работает, потестируйте, если все нормально то нормально

Спасибо.

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