Разработка отчётов в SAP на ABAP – стандартная схема

Напутствия начинающим абаперам на ниве взращивания отчётов.

Черновик статьи.

Есть заметки или наводки? – в комментарии

 

Исходные данные

Для изготовления отчёта нам понадобятся:

В общем случае постановка только содержит уточнение нижеследующих пунктов.

Имя, заголовок и состав

Всегда помнить о “Соглашении об именовании”.

Во многих внутренних документах видел строгие формы заполнения заголовочной части текста главной программы отчёта, хотя на практике реально мало кто это требования соблюдает, а если и соблюдает, то по большей части фиктивно.

Моё мнение: Нужен только простой заголовок, в котором отразить ключевые моменты:

*&———————————————————————*
*& Report  ZFMBO0005
*& Форма № 5-б. Отчет о движении долгосрочных активов
*&———————————————————————*
*& Выборка из таблиц ОС + Прямой экспорт в Excel
*& [TODO] Пересмотреть формирование первой таблицы
*& [TODO] добавить вывод в ALV
*&———————————————————————*

Но кроме этого надо:

 

Кроме этого требования я часто встречал требования делить главную программу на инклюды в стиле *_SCR/FRM/SEL/EVT. И вот что я думаю по этому поводу:

 

Экран выбора

Особое внимание на разницу между PARAMETERS и SELECT-OPTIONS. Если не полностью уверены, то можете сделать через SO, но повесить ограничения (no intervals, no extension). Не бойтесь использовать разного рода переключатели (радиогруппы и чекбоксы).

Старайтесь не дублировать параметры, не спрашивайте то, что можно определить из настроек. Подумайте насчёт обязательности и значений “по умолчанию”: это могут быть и константы, определение через настройки, определение через профиль пользователя или даже простой MEMORY ID.

select-options: s_bukrs for gt_report-bukrs obligatory memory id buk.

При этом используется стандартный параметр BUK, работающий в большинстве транзакций.

Можно даже считывать параметр из профиля, и если там что-то есть, то не давать менять.

Для сложных отчётов на первое время всегда вводите служебные параметры, сужающие область отчёта (номера документов или объектов), они помогут вам в тестировании. Если пользователей они будут смущать – скрывайте, но потом.

Если параметров много или они имеют разный характер – организуйте группы в блоки.

selection-screen begin of block b2 with frame title text-002.
select-options: s_anln1 for gt_report-anln1.
selection-screen end of block b2.

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

В некоторых случаях, к выбору параметра лучше делать текстовый комментарий. Такие комментарии помогают в таких случаях как выбор табельного номера или выбор кредитора.

Обработка ошибок на экране выбора – рядовое дело. Но проверять надо разумно и точно.

Проверка прав

Реально проверка прав нужна только при организационном разделении (в первую очередь – по ГУ). Поэтому в стандартном бухгалтерском отчёте нам понадобится только проверка объекта F_BKPF_BUK на доступ к операции 03. При этом подразумевается, что начальная проверка прав всегда делается на уровне присвоения транзакции в роль пользователя.

В большинстве случаев этот параметр заполняется на  экране выбора, поэтому проверять права следует только в событии AT SELECTION SCREEN.

Выборка

Выборка должна быть отделена от вывода. В результате выборки у нас должна сформироваться таблица (или несколько таблиц), которые уже выводятся на экран без дополнительных выборок и преобразований.

Эти таблицы, на всякий пожарный случай, должны содержать больше данных, чем выводится на экран. Например: если в отчёте выводится инвентарный номер ОС (ANLA-INVNR) и его наименование (ANLA-TXT50), но не выводится номер карточки, то во внутренней таблице оно обязательно должно быть (ANLA-BUKRS + ANLA-ANLN1 + ANLA-ANLN2).

При выборке данных не следует забывать о конструкциях appending и collect. Лучше забыть о конструкциях SELECT-ENDSELECT и LOOP-LOOP.

По моему мнению, необходимо выбирать определённый баланс между простотой восприятия/сопровождения и оптимизацией по скорости выполнения.

Дополнительная обработка

Бывает, что выбранные данные должны быть обработаны до показа на экране. Если такая обработка не является частью выборки, то её следует отдельно процедурно оформить.

Вывод

ALV достаточно прост в использовании, чтобы его можно было использовать в самых примитивных программах. Поэтому “по умолчанию” мы ALV говорим “ДА”, а выводу WRITE говорим “НЕТ”.

Базовый вывод достигается вот таким простым кодом:

data: gr_table type ref to cl_salv_table.
call method cl_salv_table=>factory
IMPORTING r_salv_table = gr_table
CHANGING t_table = gt_report[].
gr_table->display( ).

Если есть противопоказания в части хитрых заголовков, то вы можете сплавить это дело в экспорт.

Форма вывода должна содержать все основополагающие параметры экрана выбора. Например, если вы выбираете данные по заданной БЕ в диапазоне дат, то эти параметры должны отражаться в выходной форме.

 

Проваливание

Я считаю, что проваливание (drill-down) должно быть всегда:

Технология расшифровки суммы не является сложной:

 

Экспорт

Экспорт в Excel – это стандартная возможность, которую просят пользователи. Это необходимо если:

 

С моей точки зрения не должно быть отчётов только с экспортом, но без вывода на экран.

Для некоторых пользователей можно включить такую возможность, равно как и оформить это параметром на экране выбора, но принципиального отсутствия вывода быть не должно.

Библиотека ZWWW даёт простой и быстрый способ реализовать экспорт в Excel, причём ввиду простоты можно всерьёз рассматривать включение такого экспорта “по умолчанию”, если есть зафиксированная форма.

Опубликовано 24.04.2013 в 15:31 · Автор ivan · Ссылка
Рубрики: ABAP

Написать комментарий