Я думаю, все люди дали вам все подсказки по оптимизации вашего кода. По сути, поскольку вы хотите оптимизировать только вторую часть, единственные проблемы, по-видимому, связаны с операциями itab (цикл, чтение, изменение), которые вы можете улучшить, используя индекс или хеш-таблицу во внутренней таблице itab. Если эти концепции неясны, я рекомендую документацию ABAP: Затраты на администрирование внутренних таблиц на основе строк и Внутренние таблицы — Примечания по производительности

Еще две вещи:

1. вам следует измерить производительность вашего кода с помощью SAT транзакций, и вы увидите, на какую операцию тратится время.
2. Не по производительности, а по модели данных: ключ финансового документа состоит из 3-х полей, компания (БУКРС), номер документа (БЕЛНР) и год (ГЕАХР). Таким образом, вы не должны группировать («собирать») только по номеру документа, иначе вы рискуете смешать документы разных компаний или лет. Вместо этого оставьте 3 поля.

Теперь, если вы согласитесь адаптировать несколько мелочей в 1-й части, сразу после прочтения строк BSEG каждого документа, тогда вы можете просто зацикливаться на этих строках, не нуждаясь в индексе, двоичном поиске или хэш-таблице, и это Готово. Единственное, что нужно сделать, это сначала сохранить строки BSEG во временном itab_temp, чтобы содержать только строки одного документа за раз, чтобы вы зацикливались только на этих строках, а затем добавляли их в itab.

Если вы хотите обновить компонент BUDAT позже, а не в первой части, сохраните ключ документа + BUDAT в отдельной внутренней таблице (скажем, itab_budat) и определите неуникальный вторичный индекс для itab. с ключевыми полями документа (скажем, by_doc_key), и вам понадобится только этот прямой код:

LOOP AT itab_budat ASSIGNING <line_budat>.
  MODIFY itab FROM itab USING KEY by_doc_key TRANSPORTING budat
       WHERE bukrs = <line_budat>-bukrs
         AND belnr = <line_budat>-belnr
         AND gjahr = <line_budat>-gjahr.
ENDLOOP.

Обратите внимание, что я предлагаю (неуникальный) вторичный индекс, а не первичный, потому что, поскольку вы не хотите изменять (слишком сильно) 1-ю часть, это позволит избежать потенциальных проблем, которые могут возникнуть. имеют первичный индекс.

Если вам нужна дополнительная информация о терминах, синтаксисе и т. д., вы найдете ее в документации по ABAP (встроенной или в Интернете).

Здесь есть несколько проблем с производительностью:

1-я часть:

Никогда не делайте SELECT в LOOP. Я сказал никогда. Вместо этого вы должны сделать SELECT ... FOR ALL ENTRIES или SELECT ... JOIN (BSEG - это кластерная таблица в ECC, поэтому JOIN невозможен, но прозрачная таблица в S4/HANA, поэтому вы можете ПРИСОЕДИНИТЬСЯ к ней с помощью BKPF). Насколько я вижу из кода, вы выбираете элементы ГК, поэтому вы можете проверить, будет ли лучше использовать BSIS/BSAS (вместо BSEG). Вы также можете проверить таблицу BSET (похоже, вас интересуют «налоговые» строки)

2-я часть:

Если вы выполняете LOOP с условием WHERE, вы получаете лучшую производительность, если внутренняя таблица TYPE SORTED (с правильным ключом). Однако ваше условие WHERE использует смещение, поэтому я не уверен, поможет ли таблица SORTED, но попробовать стоит.

Однако настоящая проблема здесь: COLLECT itab2. COLLECT не поддерживается для TYPE STANDARD таблиц (это четко указано в SAPHelp), внутренняя таблица должна быть TYPE HASHED (на то есть технические причины, в подробности не вдаюсь).

После этого вы LOOP одну внутреннюю таблицу (itab2) и READ TABLE другую (itab). Чтобы иметь наилучшую производительность при чтении одной строки, itab должен быть TYPE HASHED (или по крайней мере TYPE SORTED с правильным ключом).

Вместо того, чтобы использовать внутренние таблицы с HEADER LINES, вы должны LOOP ... ASSIGNING FIELD-SYMBOL(<...>), так что вам больше не нужен MODIFY, это также немного улучшит производительность.

Как сказал JozsefSzikszai, вероятно, было бы лучше использовать BSAS/BSIS, поскольку у них есть индексы. Если вы действительно хотите использовать BSEG: BSEG — это кластерная таблица. Насколько мне известно, для этих таблиц предпочтительнее выполнять SELECT с использованием ключевых полей для получения внутренней таблицы, а затем работать с внутренней таблицей для дополнительных полей.

 select * from bseg into corresponding fields of itab
      for all entries in it_bkpf
      where bukrs = it_bkpf-bukrs and
            belnr = it_bkpf-belnr and
            gjahr = it_bkpf-gjahr.
 delete itab where hkont not in s_hkont.

Во второй части вы выполняете READ TABLE для стандартной таблицы (itab). Использование ДВОИЧНОГО поиска значительно сократит ваше время... Чтение таблицы в стандартной таблице — это полное сканирование таблицы (строки считываются до тех пор, пока мы не найдем значение). Сортировка по belnr и hkont (вместо только belnr) и добавление BINARY SEARCH сделает поиск дихотомическим.

Первый быстрее, потому что он просто линейно плохой

Второй — квадратичный.
Первый тоже выглядит квадратичным, но bukrs, belnr, gjahr — это почти полный первичный ключ bseg, поэтому для каждой строки it_bkpf не так уж много строк найдено с помощью SELECT.

Первая часть

Как писал JozsefSzikszai, FOR ALL ENTRIES намного быстрее, чем вложенные SELECT. Более того, огромные объемы ненужных данных перемещаются из БД на сервер приложений, так как SELECT SINGLE — это просто проверка существования, но он читает все 362 столбца BSEG.

Поэтому создайте СОРТИРОВАННУЮ таблицу перед ЦИКЛОМ: ТИПЫ: НАЧАЛО tt_bseg, bukrs TYPE bukrs, belnr TYPE belnr, gjahr TYPE gjahr, END OF tt_bseg.

DATA: lt_bseg2 TYPE SORTED TABLE OF tt_bseg WITH NON-UNIQUE KEY bukrs belnr gjahr.

SELECT bukrs belnr gjahr FROM bseg
    INTO TABLE lt_bseg
    FOR ALL ENTRIES IN it_bkpf
    WHERE bukrs = it_bkpf-bukrs
      AND belnr = it_bkpf-belnr
      AND gjahr = it_bkpf-gjahr
      AND hkont = wtax.

Вместо SELECT SINGLE используйте READ TABLE:

READ TABLE lt_bseg TRANSPORTING NO FIELDS
    WITH KEY bukrs = itab-bukrs
             belnr = itab-belnr
             gjahr = itab-gjahr.

Вторая часть

Это квадратично, потому что для каждой итерации itab2 все строки itab проверяются на MODIFY.

Самое простое решение: вместо SORT itab BY belnr загрузите содержимое itab в таблицу SORTED и используйте ее позже:

DATA: lt_itab TYPE SORTED TABLE OF itab 
            WITH NON-UNIQUE KEY belnr hkont.
lt_itab = itab.
FREE itab.

Было много разумных рекомендаций от ребят, особенно от Сандры Росси, но я просто добавлю свои пять копеек к вашему последнему варианту, который длится 1 час:

• используйте как можно больше полевых символов. Они действительно могут влиять на производительность больших наборов данных (а 1,5 МБ — это много, да!)
• используйте вторичные ключи, как предложила Сандра. Это действительно имеет большое значение (см. стандартную программу DEMO_SECONDARY_KEYS)
• не используйте INTO CORRESPONDING FIELDS без необходимости, это немного замедляет запросы
• какая-то двойная работа в вашем фрагменте, так как вы собираете ненужные строки в первом цикле по itab (BSEG), но BUDAT пишется только тогда, когда сумма позиции BSEG соответствует нижнему верхнему диапазону. Так что некоторые собранные суммы теряют время.

В общем, я не до конца понял вашу логику, так как вы пишете BUDAT не ко всему совпавшему набору строк, а только к первой строке группы с совпавшим BELNR, что не имеет смысла, но тем не менее .

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

* To omit `INTO CORRESPONDING` you should properly declare your structure
* and fetch only those fields which are needed. Also avoid obsolete `OCCURS` syntax.
TYPES: BEGIN OF ty_itab,
        bukrs TYPE bseg-bukrs,
        belnr TYPE bkpf-belnr,
        gjahr TYPE bkpf-gjahr,
        hkont TYPE bseg-hkont,
        dmbtr TYPE bseg-dmbtr,
        shkzg TYPE bseg-shkzg ,
        budat TYPE bkpf-budat,
      END OF ty_itab.

TYPES: begin of ty_belnr_sums,
        belnr type bkpf-belnr,
        dmbtr type bseg-dmbtr,
       end of ty_belnr_sums.
DATA: itab TYPE TABLE OF ty_itab INITIAL SIZE 0,
      con_5per_tax type p decimals 2 value '0.03'.

SELECT g~bukrs g~belnr g~gjahr g~hkont g~dmbtr g~shkzg f~budat UP TO 1500000 rows
INTO table itab
FROM bseg AS g
JOIN bkpf AS f
 ON g~bukrs = f~bukrs
AND g~belnr = f~belnr
AND g~gjahr = f~gjahr.

DATA members LIKE itab.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs_itab>)
                       GROUP BY ( belnr = <fs_itab>-belnr )
                                  hkont = <fs_itab>-hkont )
                       ASCENDING
                       ASSIGNING FIELD-SYMBOL(<group>).
  CLEAR members.
  CHECK <group>-hkont(2) = '73'.

  LOOP AT GROUP <group> ASSIGNING FIELD-SYMBOL(<group_line>).
    members = VALUE #( BASE members ( <group_line> ) ).
  ENDLOOP.

  DATA(sum) = REDUCE dmbtr( INIT val TYPE dmbtr
                            FOR wa IN members
                            NEXT val = val + wa-dmbtr ).

  IF members[1]-dmbtr BETWEEN con_5per_tax * sum - '0.02' AND con_5per_tax * sum + '0.02'.
    <first_line>-budat = '99991231'.
  ENDIF.
ENDLOOP.

Во время моего теста на наборе данных 1,5 млн я измерил время выполнения с помощью GET RUN TIME FIELD и получил следующие результаты.

Старый фрагмент:

Мой фрагмент: