Възможно ли е генериране на ABAP отчет по време на изпълнение?

1. Възможни са общи отчети

Вашият проблем е, че ще трябва да начертаете строга рамка за това какво е общо и какво не, това означава, че някои неща ТРЯБВА да бъдат толкова общи, че ще се занимават с КАКВОТО и да искате да направите преди (предимно селекцията), по време на ( най-вече манипулация ---> бих предложил badi за това ), и изход. Това означава, че има поне изходна стъпка, която може да бъде валидна за ВСИЧКИ данни, произтичащи от предишните стъпки. Помислете за общ ALV-table_output, има много примери в репото. Ако искате нещата да бъдат отпечатани просто като списък, това може да включва повече работа, като например колко голяма е структурата, кога Dou Вие обвивате ред и т.н., обмислете използването на флаг, който позволява превключване на типа изход .

2. Общите отчети са преносим обект.

Това се отнася за точка едно. Определете ясни етапи и граници. Какво прави докладът и какво не може да направи. Защото дори и да е в пространството на имената на клиента, всяка модификация пак ще бъде поставена в транспортни слоеве. Следователно е необходима стриктна дефиниция на характеристиките/лимитите, така че количеството транспорти, дължащи се на "о, но ние също се нуждаем от това" - изявления да не стане безкрайно.

2. Общите доклади са строги.

Какво означава това ? Може да искате да анализирате подадените данни (имена на таблици, свързване на присъединяване, стойности на параметри за избор) и да хвърляте изключения, ако не са правилно зададени. Много работа. Трябва да предложите бади за това. Ако не направите това, очаквайте свалка. нека се изхвърли. В крайна сметка потребителят на Вашия доклад-api трябва да знае (може би чрез документация) как да го извика. Ако не, резултатът ще бъде динамичен SQL дъмп.

3. Общите отчети могат да се възползват от badis/exits.

Мисля, че това се обяснява от само себе си. Особено общият/динамичен избор/модификация/показване на данни трябва да може да се разширява по отношение на персонализирани модификации. Когато проверите как работи f4-search-help exit, ще разберете какво имам предвид.

4. Генеричното кодиране е трудно за отстраняване на грешки, най-вече черна кутия. Самообяснявайки се, в секцията с код по-долу мога да маркирам някои от тези секции.

5. Генеричното кодиране има някои примери за най-добри практики в репото.

Не преоткривайте колелото. Проверете как работи se16n, като го дебъгвате, проверете как работи se11, като го дебъгвате. Проверете как изглежда SQL-Query-builder в дебъгера. Много скоро ще разберете идеята, а копи-пейстът трябва да е най-лесната част от работата ви.

6. Това са основните части на това, което можете да използвате.

Определяне на клауза Where и настройка на параметрите.

 data lt_range     type rsds_trange.
 data ls_range_f   type rsds_frange.
 data lt_where     type rsds_twhere.
 data ls_where     like line of lt_where.


ls_range_f =  value #( sign   = _sign
                       option = _option
                       low    = _low
                       high   = _high ). 


.
.
.

append ls_frange to lt_range.
.
.
.

 call function 'FREE_SELECTIONS_RANGE
data(lt_key) = value abap_keydescr_tab( for line in _joinfields)
                                                  ( name = fieldname ) ).
data(lo_structdescr) = cast cl_abap_structdescr(    cl_abap_structdescr=>describe_by_name( _struct_name ) ).
data(lo_tabledescr)  = cl_abap_tabledescr=>create( line_type  = lo_structdescr                                                       p_key        = lt_key ).

create data ro_data type handle lo_tabledescr.
WHERE'
  exporting
    field_ranges  = lt_range
  importing
    where_clauses = lt_where.

Имате параметъра, нека създадем таблицата за избор на резултат.

data(lt_key) = value abap_keydescr_tab( for line in _joinfields)
                                                  ( name = fieldname ) ).
data(lo_structdescr) = cast cl_abap_structdescr(    cl_abap_structdescr=>describe_by_name( _struct_name ) ).
data(lo_tabledescr)  = cl_abap_tabledescr=>create( line_type  = lo_structdescr                                                       p_key        = lt_key ).

create data ro_data type handle lo_tabledescr.

. . .

 select  (sel_st)
    from    (sel_bind)
    into    corresponding fields of table t_data
    where   (dyn_where).

След това присвоете seelct-table-result-reference към генеричната таблица на този select.

Имате ли нужда от повече съвети?

Трябва да обмислите използването на SAPQuery. SAP документация тук: https://help.sap.com/saphelp_erp60_sp/helpdata/en/d2/cb3efb455611d189710000e8322d00/content.htm

Да, такава възможност съществува, но не чрез функционални модули. INSERT REPORT изявление позволява генериране на отчет чрез попълване на неговия код от вътрешна текстова таблица:

INSERT REPORT prog FROM itab 
          [MAXIMUM WIDTH INTO wid] 
          { [KEEPING DIRECTORY ENTRY] 
          | { [PROGRAM TYPE pt] 
              [FIXED-POINT ARITHMETIC fp] 
              [UNICODE ENABLING uc] } 
          | [DIRECTORY ENTRY dir] }.