Обнаружилась специфика использования коэффициентов массштабирования в отчетах с двумя структурами.
Note 528960 - Scaling factors are not displayed
Note 337742 - Scaling factors not displayed
Note 568630 - FAQ: Information about structures in queries
+ даже если не рассматривать описанные ситуации кофликта приоритетов... иногда BEx глючит с отображением строки с массштабами - workaround - включать опции массштабирования не на ячейках данных, а на заголовке показателя. Причем если до этого пытались включить массштаб на блоке ячеек, и после этого строка исчезла, то пока не прокликаешь заголовки всех показателей - строка не появится.
среда, 17 октября 2012 г.
2SIM vs 1SIM + redirect
MTS вышел на полноценный уровень переадресации, теперь можно переадресовать не только звонки, но и sms.
Вызов:
http://www.mts.ru/services/direction_calls/keeping_call/redirect_call/
Я выбрал опцию - Если телефон выключен или вне зоны покрытия
SMS:
Можно сделать через сервис CMC Pro.
https://smspro.ssl.mts.ru/Login/Login.aspx
http://www.mts.ru/messaging/sms/performance/smspro/
Правда на посланный смс (номер 232 текст ОN) ответа не пришло. Пришлось писать в support.
C support'a услугу включили. Да, стоимость 0, если не в роуминге.
Зашел на сайт, восстановил пароль.
Подключил через сайт номер переадресации.
p.s. Все таки таскать один телефон удобней, чем (N > 1).
Вызов:
http://www.mts.ru/services/direction_calls/keeping_call/redirect_call/
Я выбрал опцию - Если телефон выключен или вне зоны покрытия
SMS:
Можно сделать через сервис CMC Pro.
https://smspro.ssl.mts.ru/Login/Login.aspx
http://www.mts.ru/messaging/sms/performance/smspro/
Правда на посланный смс (номер 232 текст ОN) ответа не пришло. Пришлось писать в support.
C support'a услугу включили. Да, стоимость 0, если не в роуминге.
Зашел на сайт, восстановил пароль.
Подключил через сайт номер переадресации.
p.s. Все таки таскать один телефон удобней, чем (N > 1).
вторник, 16 октября 2012 г.
RRI
Для перехода из BEx надо поставить галку у клиента:
Если переходим в ERP и не указана трансформация (хотя она там по сути нахрен не нужна), то появятся окна визарда - пользователям не нравится. Достаточно указать самую безопасную трансформацию. см. Note 1053310 - Report-report interface: Application rules пункт 4d.
Вызов1 Вызов2
Если переходим в ERP и не указана трансформация (хотя она там по сути нахрен не нужна), то появятся окна визарда - пользователям не нравится. Достаточно указать самую безопасную трансформацию. см. Note 1053310 - Report-report interface: Application rules пункт 4d.
Вызов1 Вызов2
понедельник, 10 сентября 2012 г.
F4 Games
по следам sapforum'a
1. BADi RSR_VARIABLE_F4_RESTRICT_BADI ...
2. В SAP Help = Search Help Exit
3. Class CL_RSR_WWW_VARIABLE_SCREEN ...
4. SAP Note 1080863 - FAQ: Input helps in Netweaver BI ...
Поигрался маленько с exit'ом. В общем нормально, кроме того момента что:
- все значения проверяются через SID таблицу, т.о. нет возможности подсунуть "временные" значения. По мне бы лучше бы если это поведение было опционально
- при реализации переменной через DUMMY показатель, надо быть окуратнее с ограничениями... особенно с ограничением по провайдеру... столкулся с тем, что он показывал только те значения которые попадали в ограничения (правда в добавок это был compaund признак)
- сделал ограничения по валюте, но этот exit не отрабатывает через локальный пересчет - и в отчете видна вся валюта ( Query Properties >> Curremcy Conversion )
1. BADi RSR_VARIABLE_F4_RESTRICT_BADI ...
2. В SAP Help = Search Help Exit
3. Class CL_RSR_WWW_VARIABLE_SCREEN ...
4. SAP Note 1080863 - FAQ: Input helps in Netweaver BI ...
Поигрался маленько с exit'ом. В общем нормально, кроме того момента что:
- все значения проверяются через SID таблицу, т.о. нет возможности подсунуть "временные" значения. По мне бы лучше бы если это поведение было опционально
- при реализации переменной через DUMMY показатель, надо быть окуратнее с ограничениями... особенно с ограничением по провайдеру... столкулся с тем, что он показывал только те значения которые попадали в ограничения (правда в добавок это был compaund признак)
- сделал ограничения по валюте, но этот exit не отрабатывает через локальный пересчет - и в отчете видна вся валюта ( Query Properties >> Curremcy Conversion )
понедельник, 3 сентября 2012 г.
Пара вьюшек
Может конечно и виноградный велосипед, но пришлось создать две вью, чтобы посмотреть след.информацию...
Роль - профайл - объект авторизации - поле - значение
Join condition:
View: (зеленым веделены интересные для анализа)
Роль - GUID Workbook - GUID Query - infocube - query id
Join
View
Conditions
Дополнительно
SMEN_BUFFC - таблица с фаворитами пользователя
Долго лазил по профилям, пока не нашел.
0COSTCENTER = K_CSKS, поле KOSTL
0PROFIT_CTR = C_PRPS_PRC, поле PS_ACTVT
Роль - профайл - объект авторизации - поле - значение
Join condition:
| Table | Field | Table | Field | |
| AGR_1016 | MANDT | = | UST10S | MANDT |
| AGR_1016 | PROFILE | = | UST10S | PROFN |
| UST10S | AUTH | = | UST12 | AUTH |
| UST10S | AKTPS | = | UST12 | AKTPS |
| UST10S | OBJCT | = | UST12 | OBJCT |
| UST10S | MANDT | = | UST12 | MANDT |
View: (зеленым веделены интересные для анализа)
| View Field | Table | Field |
| MANDT | AGR_1016 | MANDT |
| ROLE_NAME | AGR_1016 | AGR_NAME |
| PROFILE | AGR_1016 | PROFILE |
| COUNTER | AGR_1016 | COUNTER |
| AKTPS | UST10S | AKTPS |
| OBJCT | UST10S | OBJCT |
| AUTH | UST10S | AUTH |
| FIELD | UST12 | FIELD |
| VON | UST12 | VON |
| BIS | UST12 | BIS |
Роль - GUID Workbook - GUID Query - infocube - query id
Join
| Table | Field | Table | Field | |
| AGR_HIER | SAP_GUID | = | RSRWORKBOOK | WORKBOOKID |
| RSRREPDIR | GENUNIID | = | RSRWORKBOOK | GENUNIID |
| RSRREPDIR | OBJVERS | = | RSRWORKBOOK | OBJVERS |
View
| View Field | Table | Field |
| MANDT | AGR_HIER | MANDT |
| ROLE_NAME | AGR_HIER | AGR_NAME |
| WORKBOOK_GUID | AGR_HIER | SAP_GUID |
| NUM | AGR_HIER | OBJECT_ID |
| QUERY_GUID | RSRWORKBOOK | GENUNIID |
| QUERY_COUNT | RSRWORKBOOK | SUBNR |
| OBJVERS | RSRWORKBOOK | OBJVERS |
| COMPUID | RSRREPDIR | COMPUID |
| INFOCUBE | RSRREPDIR | INFOCUBE |
| COMPID | RSRREPDIR | COMPID |
Conditions
| Table | Field Name | Operator | Value | AND\OR |
| AGR_HIER | REPORT | EQ | 'RRMX' | AND |
| RSRWORKBOOK | OBJVERS | EQ | 'A' |
Дополнительно
SMEN_BUFFC - таблица с фаворитами пользователя
Долго лазил по профилям, пока не нашел.
0COSTCENTER = K_CSKS, поле KOSTL
0PROFIT_CTR = C_PRPS_PRC, поле PS_ACTVT
четверг, 9 августа 2012 г.
Проблемы с структурами 2LIS*
Однажды как то пришлось исполнять эту ноту, геморой ещё тот, ибо проблемы были с 03 экстрактором, а склады прерывали свою работу только раз в году и то на 2 дня , на новый год.
Температура за окном +30 подсказывала что новый год не скоро, а проблема с очередью в SMQ1 и разностью структур экстратора уже есть.
В последствии нота затерялась. Но вот случай завставил её найти. В общем как всегда, дабы не забыть. Хотя сейчас походу убью и перегружу данные - ибо так проще.
Note 835466 - Using the repair mode of the hash solution
Symptom
With the function for checking the LBWQ for structure changes (the hash solution), a termination is forced when the update report RMBWV3xx is run (xx = application number) if the structure of the data in the LBWQ does not correspond to the current ABAP Dictionary version.
This occurs when changes are made to extract structures of the LO Customizing Cockpit, even though data of the 'old' structure was contained in the extraction queue (LBWQ).
The update can only run successfully if the LBWQ contains only the data of the currently valid ABAP Dictionary version.
You can use repair mode to update the data with the 'old' structure.
This note describes how to carry out the data correction.
Note:
During the check, the entire interface of the extraction module is checked. Note also that changing an inactive DataSource means changing the interface. Extract structures can only be changed if there is no data in the LBWQ (see also Note 762951).
Reason and Prerequisites
Note 834897 and the relevant application-specific notes for the hash solution are prerequisites.
Solution
The subsequent actions must take place in a posting-free period. It is absolutely essential that new data does not arrive in LBWQ during repair mode.
Step 1:
Lock your users and ensure that no IDocs are imported and that no batch tasks are running, and so on.
Step 2:
Ensure that there is no longer any data in transaction RSA7.
Step 3:
Then set the user parameter MCEX_REPAIR_MODE with the application-specific value. You will find this value in the relevant note of the application for the hash solution.
Step 4:
Undo the change to the extract structure/DataSource and replicate the DataSource to BW. Activate the transfer rules of the DataSource.
Step 5:
Then start the report RMBWV3xx (xx = application number) manually in transaction SE38.
This report MUST be executed by the same user for which the user parameter was set.
All data that was generated with the 'old' structure is then updated and set in transaction RSA7.
The program termination occurs again when the first data record is posted with the 'new' structure.
Step 6:
Then load the data in transaction RSA7 into BW.
Step 7:
Then restore the structure changes. Replicate the DataSource into BW again and activate the transfer rules.
Step 8:
Start the update report again. You should now be able to update all data.
Step 9:
Finally, delete the user parameter MCEX_REPAIR_MODE.
Step 10:
Document processing can now be reactivated.
For example:
Initial situation in LBWQ:
Data record 1 - structure 1
Data record 2 - structure 1
Data record 3 - structure 1
Data record 4 - structure 2
Data record 5 - structure 2
1.) Steps 4 - 6: Structure 1 is restored and the relevant data is updated.
New situation in LBWQ:
Data record 4 - structure 2
Data record 5 - structure 2
*клево. только обычно операция на живой системе происходит и у Вас уже есть Data record 6 - structure 1 :(
2.) Steps 7 - 8: Structure 2 is restored and the data is updated.
There is no longer any data in LBWQ.
If several structure changes occurred one after the other, and there are more than two structure versions in LBWQ, you must proceed step by step in the same sequence in which the versions were generated. Steps 4 to 8 must be executed repeatedly until the update report runs successfully again.
Температура за окном +30 подсказывала что новый год не скоро, а проблема с очередью в SMQ1 и разностью структур экстратора уже есть.
В последствии нота затерялась. Но вот случай завставил её найти. В общем как всегда, дабы не забыть. Хотя сейчас походу убью и перегружу данные - ибо так проще.
Note 835466 - Using the repair mode of the hash solution
Symptom
With the function for checking the LBWQ for structure changes (the hash solution), a termination is forced when the update report RMBWV3xx is run (xx = application number) if the structure of the data in the LBWQ does not correspond to the current ABAP Dictionary version.
This occurs when changes are made to extract structures of the LO Customizing Cockpit, even though data of the 'old' structure was contained in the extraction queue (LBWQ).
The update can only run successfully if the LBWQ contains only the data of the currently valid ABAP Dictionary version.
You can use repair mode to update the data with the 'old' structure.
This note describes how to carry out the data correction.
Note:
During the check, the entire interface of the extraction module is checked. Note also that changing an inactive DataSource means changing the interface. Extract structures can only be changed if there is no data in the LBWQ (see also Note 762951).
Reason and Prerequisites
Note 834897 and the relevant application-specific notes for the hash solution are prerequisites.
Solution
The subsequent actions must take place in a posting-free period. It is absolutely essential that new data does not arrive in LBWQ during repair mode.
Step 1:
Lock your users and ensure that no IDocs are imported and that no batch tasks are running, and so on.
Step 2:
Ensure that there is no longer any data in transaction RSA7.
Step 3:
Then set the user parameter MCEX_REPAIR_MODE with the application-specific value. You will find this value in the relevant note of the application for the hash solution.
Step 4:
Undo the change to the extract structure/DataSource and replicate the DataSource to BW. Activate the transfer rules of the DataSource.
Step 5:
Then start the report RMBWV3xx (xx = application number) manually in transaction SE38.
This report MUST be executed by the same user for which the user parameter was set.
All data that was generated with the 'old' structure is then updated and set in transaction RSA7.
The program termination occurs again when the first data record is posted with the 'new' structure.
Step 6:
Then load the data in transaction RSA7 into BW.
Step 7:
Then restore the structure changes. Replicate the DataSource into BW again and activate the transfer rules.
Step 8:
Start the update report again. You should now be able to update all data.
Step 9:
Finally, delete the user parameter MCEX_REPAIR_MODE.
Step 10:
Document processing can now be reactivated.
For example:
Initial situation in LBWQ:
Data record 1 - structure 1
Data record 2 - structure 1
Data record 3 - structure 1
Data record 4 - structure 2
Data record 5 - structure 2
1.) Steps 4 - 6: Structure 1 is restored and the relevant data is updated.
New situation in LBWQ:
Data record 4 - structure 2
Data record 5 - structure 2
*клево. только обычно операция на живой системе происходит и у Вас уже есть Data record 6 - structure 1 :(
2.) Steps 7 - 8: Structure 2 is restored and the data is updated.
There is no longer any data in LBWQ.
If several structure changes occurred one after the other, and there are more than two structure versions in LBWQ, you must proceed step by step in the same sequence in which the versions were generated. Steps 4 to 8 must be executed repeatedly until the update report runs successfully again.
понедельник, 6 августа 2012 г.
Признак с большим кол-вом записей
Сценарий проблемы:
Имеется признак с большим кол-вом записей и большим кол-вом навигационных атрибутов (приблизительно более 45). В признак добавляется новый навигационный атрибут или дисплей атрибут переводится в навигационный. При переносе в продуктив очищается X-таблица (Сиды атрибутов) и выполняется Insert во временную таблицу (что бы потом ее содержимое записать в X-таблицу). Это команда выполняется часами. Отчеты не работают.
Решение от SAP в письме ниже.
Мы применили ноты 536223 и 1466536.
После применения ноты 536223 система стала загружать сиды частями, по 10 атрибутов за раз. Общее время переноса сократилось до нескольких минут.
Имеется признак с большим кол-вом записей и большим кол-вом навигационных атрибутов (приблизительно более 45). В признак добавляется новый навигационный атрибут или дисплей атрибут переводится в навигационный. При переносе в продуктив очищается X-таблица (Сиды атрибутов) и выполняется Insert во временную таблицу (что бы потом ее содержимое записать в X-таблицу). Это команда выполняется часами. Отчеты не работают.
Решение от SAP в письме ниже.
Мы применили ноты 536223 и 1466536.
После применения ноты 536223 система стала загружать сиды частями, по 10 атрибутов за раз. Общее время переноса сократилось до нескольких минут.
Dear Customer,Спасибо, Митя!
In first place,
According to the note 536223 (the instructions provided in 'Solution'
part), you should try to set the value of parameter SPLIT_SX_TABL_THRES
to 10, and try to run the transport again.
Also, please implement:
1466536 Long runtimes when transporting InfoObjects
1556266 RSD1:Err. converting display attribute to navigation attrib.
1618989 Error when using SID for conversion to navigation attribute
If you havent already implemented.
This will improve performance.
Подписаться на:
Сообщения (Atom)