Группировка

hub2002

Здравствуйте.
Вопрос такой:
Кто-нибудь задумывался над проблемой создание ФМ для группировки произвольной таблицы?

Удав

Да, и даже реализовали :wink:

1.ФМ для выбора полей
-На вход подается fieldcatalog
-На выходе - fieldcatalog для результирующей таблицы
2.ФМ для создания структуры данных по выбранным полям и выполнения COLLECT
-На входе:
fieldcatalog для результирующей таблицы
таблица с данными
-На выходе - REF TO DATA (указатель к результрующей таблице)

hub2002

Поделитесь идеей

если не жалко конечно

Удав

Для выбора полей подойдет стандартный ФМ FIELD_CHOICE, динамическое создание таблицы многократно обсуждалось

hub2002

А можно чуть поподробней.
Я не особо понял с обработкой таблицы.
на вход необходимо дать таблицу type table ?
у меня вопрос как унифицировать группировку - механизм какой

(просто я туплю... )

Удав

На вход - нетипизированная таблица data_in (в TABLES).
А дальше так:

Code:

  CREATE DATA dref_in LIKE LINE OF data_in.
  ASSIGN dref_in->* TO <fs_s_in>.

  ASSIGN data_out->* TO <fs_t_out>.
  CREATE DATA dref_out LIKE LINE OF <fs_t_out>.
  ASSIGN dref_out->* TO <fs_s_out>.

и цикл по data_in

Art386

Code:

*"----------------------------------------------------------------------
*"*"Globale Schnittstelle:
*"  IMPORTING
*"     IT_FCAT TYPE LVC_T_FCAT
*"     IT_SRC  TYPE STANDARD TABLE
*"  EXPORTING
*"     ERF_DATA TYPE REF TO DATA
*"----------------------------------------------------------------------

Code:

DATA:
LRF_NEW_LINE TYPE REF TO DATA.

FIELD-SYMBOLS:
<FS_OUT_TAB> TYPE STANDARD TABLE,
<FS_LINE1>       TYPE ANY,
<FS_LINE2>       TYPE ANY,
<FS_FIELD1>     TYPE ANY,
<FS_FIELD2>     TYPE ANY,
<FS_FCAT>        TYPE LVC_S_FCAT.
* 


CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE(
  EXPORTING
    IT_FIELDCATALOG = IT_FCAT[]
  IMPORTING
    EP_TABLE = ERF_DATA ).


ASSIGN ERF_DATA->* TO <FS_OUT_TAB>.
CHECK SY-SUBRC = 0.

CREATE DATA LRF_NEW_LINE LIKE LINE OF <FS_OUT_TAB>.
ASSIGN LRF_NEW_LINE->* TO <FS_LINE2>.
CHECK SY-SUBRC = 0.

LOOP AT IT_SRC ASSIGNING <FS_LINE1>.
  CLEAR <FS_LINE2>.
  LOOP AT IT_FCAT ASSIGNING <FS_FCAT>.
    ASSIGN COMPONENT <FS_FCAT>-FIELDNAME OF STRUCTURE <FS_LINE1> TO <FS_FIELD1>.
    CHECK SY-SUBRC = 0.

    ASSIGN COMPONENT <FS_FCAT>-FIELDNAME OF STRUCTURE <FS_LINE2> TO <FS_FIELD2>.
    CHECK SY-SUBRC = 0.
    
    <FS_FIELD2> = <FS_FIELD1>.
  ENDLOOP.
  COLLECT <FS_LINE2> INTO <FS_OUT_TAB>.
ENDLOOP.

hub2002

Спасибо.
посмотрю...

Art386

hub2002 написал(а):

Спасибо.
посмотрю...

Только учтите, что суммовые поля в каталоге полей должны быть описаны с запасом по длине, чтобы при коллекте входной таблицы в выходную они не переполнились, иначе получите "авар - динамическая ошибка"

Удав

Art386 написал:

Code:

  LOOP AT IT_FCAT ASSIGNING <FS_FCAT>.
    ASSIGN COMPONENT <FS_FCAT>-FIELDNAME OF STRUCTURE <FS_LINE1> TO <FS_FIELD1>.
    CHECK SY-SUBRC = 0.

    ASSIGN COMPONENT <FS_FCAT>-FIELDNAME OF STRUCTURE <FS_LINE2> TO <FS_FIELD2>.
    CHECK SY-SUBRC = 0.
    
    <FS_FIELD2> = <FS_FIELD1>.
  ENDLOOP.
 

Вместо этого нужно использовать

Code:

MOVE-CORRESPONDING <FS_LINE1> to <FS_LINE2>

Besa

to Удав
в 4.6 такая конструкция не сработает :wink:

http://sapboard.ru/forum/viewtopic.php?f=13&t=59842&start=0

Удав

Besa, я в курсе

Art386

Цитата:

Вместо этого нужно использовать

Почему же так категорично? "нужно"? Я бы сказал, "можно"

Ибо, как было сказано выше, не везде будет работать такая конструкция. А мой пример будет работать везде

А так ведь непринципиально... так или эдак

Удав

Art386 написал:

А так ведь непринципиально... так или эдак

Как это непринципиально?

А в SE30 смотрели, что получается при Вашем варианте в случае обработки большого объема данных? :wink:

Art386

Удав написал(а):

Art386 написал:

А так ведь непринципиально... так или эдак

Как это непринципиально?

А в SE30 смотрели, что получается при Вашем варианте в случае обработки большого объема данных? :wink:

UPD:
В плане производительности я с вами абсолютно согласен!! Это замечание в тему.
Уточню, я имел в виду: непринципиально в плане кода (и тот, и тот работает правильно и выдает одинаковый результат). Я думаю, понятно, что встроенный оператор наверняка выполнит операцию быстрее, чем покомпонентное присваивание через field-symbols...

Итого, надо было изначально написать так:
- система до 4.7: используется первый вариант;
- система выше - второй вариант.

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

Группировка

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