В новом синтаксисе ABAP SQL появилась возможность прописывать условия для таблиц LEFT JOIN в WHERE.
Однако есть существенное отличие между условием прописанным после ON и в условии WHERE.
В новом синтаксисе ABAP SQL появилась возможность прописывать условия для таблиц LEFT JOIN в WHERE.
Однако есть существенное отличие между условием прописанным после ON и в условии WHERE.
Создание динамической таблицы для ALV в зависимости от структуры.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
create_dyn_struc IMPORTING iv_infty TYPE infty EXPORTING es_infty_str TYPE REF TO data. METHOD create_dyn_struc. DATA: ref_table_descr TYPE REF TO cl_abap_structdescr. DATA(lv_name) = |P{ iv_infty }|. ref_table_descr ?= cl_abap_typedescr=>describe_by_name( lv_name ). DATA(lt_lvc_fieldcatalog) = VALUE lvc_t_fcat( FOR ls_tab_struct IN ref_table_descr->components[] ( fieldname = ls_tab_struct-name ref_table = lv_name ) ). DATA: dyn_table TYPE REF TO data, dyn_line TYPE REF TO data. " Создаем динамически таблицу" CALL METHOD cl_alv_table_create=>create_dynamic_table EXPORTING it_fieldcatalog = lt_lvc_fieldcatalog IMPORTING ep_table = dyn_table. FIELD-SYMBOLS: <fs_data> TYPE STANDARD TABLE, <fs_wa_data> TYPE any. ASSIGN dyn_table->* TO <fs_data>. CREATE DATA dyn_line LIKE LINE OF <fs_data>. ASSIGN dyn_line->* TO <fs_wa_data>. CREATE DATA es_infty_str LIKE <fs_wa_data>. ENDMETHOD. |
Немного сумбурных мыслей.
Информация для разработчиков, которые ранее не работали с модулем HR и не очень понимают, зачем при разработке в данном модуле использовать ЛБД или ФМ для выборки данных вместо селектов. Как всегда более подробно в курсах. В данном случае это HR350. Не претендую на идеальное и полное изложение материала.
Читать далее «ФМы для чтения ИТ и ЛБД в HR. Почему их надо использовать»
Business Add-Ins
User-Exits позволяют клиентам прикрепить дополнительный код для стандартных SAP исходный код без необходимости изменения исходного объекта. Business Add-Ins SAP методика расширений, основанная на ABAP Objects.
Служат для того, чтобы вносить модификацию в алгоритм обработки объекта и свести к минимуму работы при обновлении системы.
Основным преимуществом данной концепции является возможность повторного использования. BAdI может быть реализован несколько раз.
Читать далее «BADI. Поиск и использование»FIELD-SYMBOL используют все и везде, но до сих пор многие не умеют их отлаживать и даже считают это невозможным. Но это не так.
Читать далее «Отладка FIELD-SYMBOL»Для заполнения дополнительных полей в инфо-наборе можно сделать следующее:
1. Создать расширенную структуру CI_Pnnnn_AF для ИТ;
2. Создать ФМ для заполнения дополнительных полей. Для образца можно взять ФМ RPAQ_GET_AF_NNNN;
3. В таблице T770AF прописать структуру и ФМ для заполнения дополнительных полей к ней;
4. В таблице T77ID прописать дополнительную структуру для ИТ;(Скорее всего необходимость данного пункта была из-за особенностей моей системы. В идеале запись должна создаваться автоматически)
5. Актуализируем дополнительные поля в инфо-наборе Инфо-набор->Другие функции->Актуализировать дополн. поля в HR.
В результате тестирования разработки оказалось, что при выборке из Z* таблицы выбираются не все значения.
В таблице у нас находятся 15 записей. В se11 мы видим, что у пяти записей в поле del_flag = 'X', у десяти del_flag пустой.
Далее выполняем три запроса к таблице:
1 2 3 |
SELECT * FROM z_table INTO TABLE @DATA(lt_table_1). SELECT * FROM z_table INTO TABLE @DATA(lt_table_2) WHERE del_flag = @abap_true. SELECT * FROM z_table INTO TABLE @DATA(lt_table_3) WHERE del_flag @abap_true. |
В результате имеем: все 15 записей в таблице lt_table_1, 5 записей с del_flag = 'X' в таблице lt_table_2 и ТОЛЬКО 5 записей в таблице lt_table_3 с del_flag 'X'. Куда же делись еще 5 записей, которые должны были выбраться в таблицу ls_table_3 ?
В одной из программ потребовалось вызвать транзакцию QE01 ввести там данные и вернуться в исходную транзакцию. Но в некоторых случаях вместо возврата в исходную программу, возвращалиcь в меню SAP. Оказалось, что транзакция в некоторых случаях вызывала другие при помощи LEAVE TO TRANSACTION, причем экраны были практически идентичны. А LEAVE очищает стек вызовов, и после выполнения транзакции просто некуда было возвращаться. В нашем случае, если были частичные партии, вызывалась транзакция QE14. Проблему решили тем, что теперь мы вызываем две транзакции в зависимости от наличия частичных партий QE01 и QE14 соответственно. Проблема с возвратом в исходную программу решена.
Если необходимо вывести ALV на полный экран, то не надо создавать контейнер на экране, из-за возможных проблем с отображением на экранах с различным расширением. Нужно просто записать:
1 2 3 4 5 6 7 8 9 10 11 12 |
DATA: lo_grid1 TYPE REF TO cl_gui_alv_grid, " объект ALV * Создаём объект грида CREATE OBJECT lo_grid1 EXPORTING i_parent = cl_gui_container=>default_screen EXCEPTIONS error_cntl_create = 1 error_cntl_init = 2 error_cntl_link = 3 error_dp_create = 4 OTHERS = 5. |
При необходимости добавить информацию перед таблицей cl_gui_alv_grid, может возникнуть вопрос как это сделать, т.к. Непосредственно сам класс, нам это не позволяет. В общем случае алгоритм точно такой же как и при выводе нескольких ALV в одном контейнере. Только вместо одной из таблиц мы будем выводить текст.