List Report

Um list report é adequado quando os usuários partem de um conjunto grande e aberto de business objects e precisam restringi-lo antes de poder trabalhar: revisar pedidos com entrega prevista, processar um conjunto de pedidos de compra, identificar documentos com bloqueio de pagamento ou repetir uma seleção de fechamento de mês por meio de uma variante salva.

O critério de decisão é o formato da pesquisa. Se os usuários combinam vários critérios de filtro antes que a lista faça sentido, um list report é adequado. Se os itens já são conhecidos e poucos, uma worklist é mais enxuta. Se os usuários precisam analisar com gráficos antes de agir, a analytical list page é mais adequada.

Exemplo: compradores da Alder Manufacturing filtram pedidos de compra por fornecedor e data de entrega para encontrar pedidos atrasados da Cedar Office Supply e, em seguida, abrem cada um em sua object page. Um list report é a escolha certa quando filtrar é o primeiro passo da tarefa.

Uma página de list report é montada a partir de partes padrão, de cima para baixo:

1. Título e gerenciamento de variantes: um controle de visões em que os usuários salvam valores de filtro, ordenação e colunas.
2. Barra de ferramentas do cabeçalho: ações genéricas de página, incluindo um menu Share.
3. Barra de filtros: os campos de UI.SelectionFields mais todos os campos de filtro obrigatórios. A pesquisa é executada quando o usuário escolhe Go, a menos que o live mode esteja configurado.
4. Área de conteúdo: uma tabela, um gráfico ou ambos, opcionalmente em várias visões alternadas por um segmented button ou por abas.
5. Navegação: escolher uma linha abre a object page, opcionalmente lado a lado no flexible column layout.

Com um serviço habilitado para draft, o framework adiciona um filtro Editing Status e mostra quais linhas têm um draft ou estão bloqueadas por outro usuário. Cada parte de um list report é gerada a partir de metadados, por isso os list reports se comportam de forma semelhante em todos os apps.

No ABAP CDS, as duas primeiras aparecem como @UI.selectionField e @UI.lineItem em cada elemento; o CAP usa os nomes dos termos OData. O comportamento da página, como carga inicial, edição em massa, visões e tipo de tabela, é definido no manifest.json. As anotações decidem o que um list report mostra; o app descriptor decide como o list report se comporta.

Carga inicial. Quando o app inicia com um contexto de navegação, como parâmetros vindos de outro app ou do target mapping, os dados são carregados imediatamente. Caso contrário, a variante padrão do usuário decide por meio de sua configuração Apply Automatically; apenas a variante Standard segue o manifest.json:

Os usuários podem sobrescrever a configuração por visão. A SAP recomenda valores de filtro padrão para que a página não abra vazia.

A edição em massa fica desativada até que um desenvolvedor a habilite. No OData V4, enableMassEdit funciona no list report (para registros ativos sem draft pendente) e na object page em modo de edição; visibleFields ou ignoredFields limitam o diálogo. No OData V2, multiEdit funciona apenas no list report, para tabelas responsivas e grid. Os dois comportamentos do list report são escolhas deliberadas de configuração, e não padrões a aceitar sem exame.

Sim, e as opções dependem de quem é o dono do app:

• App próprio, OData V4: pontos de extensão adicionam colunas, ações, campos de filtro, conteúdo de cabeçalho acima da barra de filtros e visões customizadas como abas extras; building blocks e custom pages do modelo de programação flexível cobrem lacunas maiores.
• App próprio, OData V2: extensões registradas no manifest.json cobrem áreas comparáveis, como colunas, ações e filtros.
• Um app entregue pela SAP: adaptation projects (SAP Fiori tools) ou adaptação de key user, sem modificar o código da SAP.

No SAP S/4HANA Cloud Public Edition, verifique quais desses caminhos a SAP suporta para o app e a release. Teste de decisão: se for necessário código customizado além de algumas colunas, ações ou filtros, reavalie a escolha do floorplan. Estender um list report é barato nas bordas e caro no núcleo.

1. Carregar tudo na inicialização. Sempre carregar um entity set muito grande torna cada início lento; valores de filtro padrão são a melhor alavanca.
2. Abrir com uma tabela vazia sem explicação. Quando os usuários relatam "sem dados", verifique nesta ordem: o contexto de navegação, a variante padrão e seu flag Apply Automatically, a configuração do manifest e, por fim, os filtros obrigatórios (no OData V2, um filtro obrigatório vazio bloqueia a carga inicial).
3. Sobrecarregar a barra de filtros. Vinte campos de seleção escondem os três que importam.
4. Confundir variantes e visões. Variantes são salvas pelos usuários; múltiplas visões são abas definidas pelos desenvolvedores.
5. Habilitar a edição em massa para todos os campos. Restrinja o diálogo a um field group que seja seguro alterar em massa.
6. Usar um list report para uma fila de trabalho. Um conjunto curto e conhecido de tarefas combina com uma worklist.

A maioria dos problemas de list report são problemas de configuração e de desenho da seleção, e não defeitos do framework.