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

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

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

 

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

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

• Чистая посуда
• Форма. Глядя на форму уже можно многое понять.
• Данные. В системе уже должны быть данные, которые этот отчёт должен показывать. Не беритесь за отчёт, если под ним нет данных.
• Постановка. Постановочная часть не бывает лишней, хотя во некоторых случаях можно обойтись и без неё – но только если есть и форма, и данные, и чистая кастрюля голова на плечах.

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

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

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

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

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

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

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

• Корректно заполнять поля в свойствах программы, там модуль и наименование
• Чётко формировать запросы на перенос, формируя прозрачную историю версий

 

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

• Инклюды – это чересчур старый метод модуляризации
• Не делите на инклюды, если программа не подразумевает параллельной работы нескольких разработчиков
• Не делите на инклюды, если текст главной программы меньше некоторой эмпирической цифры в 2000 строк
• Старайтесь избегать однократных инклюдов, а вместо многократных инклюдов во многих случая можно использовать классы или группы функций. Хотя я привык к инклюдам, грешен.

 

Экран выбора

Особое внимание на разницу между 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( ).

1 2 3 4 5

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) должно быть всегда:

• Если строка относится к документу или объекту, то следует показать этот документ
• Делать проваливание по полной строке или делать подсветку ссылки (hotspot) на некоторых ячейках – дело вкуса, хотя я предпочитаю первое
• Если в строке несколько разных объектов, то можно рассмотреть разное проваливание в зависимости от имени колонки
• Если строка содержит общую сумму, то следует показать расшифровку – при этом сумма позиций должна быть точно равна сумме исходной строки

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

• есть основная таблица AAA с подробными данными
• делаем обобщающую таблицу BBB с укороченным ключом (например, через collect)
• показываем таблицу BBB
• при вызове читаем данные ключа из строки BBB по индексу
• очищаем данные в AAA2 (там могли остаться данные с предыдущего раза)
• считываем записи из таблицы AAA в таблицу AAA2 по выбранному ключу
• показываем таблицу AAA2

 

Экспорт

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

• Есть стандартная форма внешней или внутренней отчётности
• Пользователей не устраивает форма ALV (заголовки)
• Требуется красивая печать

 

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

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

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

 

PS. Читаю это шесть лет спустя.