List Report

Un list report es adecuado cuando los usuarios parten de un conjunto grande y abierto de business objects y deben acotarlo antes de poder trabajar: revisar los pedidos pendientes de entrega, procesar un conjunto de pedidos de compra, detectar documentos con bloqueo de pago o repetir una selección de cierre de mes mediante una variante guardada.

El criterio de decisión es la forma de la búsqueda. Si los usuarios combinan varios criterios de filtro antes de que la lista tenga sentido, encaja un list report. Si los elementos ya se conocen y son pocos, un worklist es más ligero. Si los usuarios deben analizar con gráficos antes de actuar, la analytical list page encaja mejor.

Ejemplo: los compradores de Alder Manufacturing filtran los pedidos de compra por proveedor y fecha de entrega para encontrar los pedidos retrasados de Cedar Office Supply y, después, abren cada uno en su object page. Un list report es la elección correcta cuando filtrar es el primer paso de la tarea.

Una página de list report se compone de partes estándar, de arriba abajo:

1. Título y gestión de variantes: un control de vistas en el que los usuarios guardan valores de filtro, orden de clasificación y columnas.
2. Barra de herramientas de la cabecera: acciones genéricas de la página, incluido un menú Share.
3. Barra de filtros: los campos de UI.SelectionFields más todos los campos de filtro obligatorios. La búsqueda se ejecuta cuando el usuario elige Go, salvo que esté configurado el modo en vivo.
4. Área de contenido: una tabla, un gráfico o ambos, opcionalmente como varias vistas que se alternan con un botón segmentado o con pestañas.
5. Navegación: elegir una fila abre la object page, opcionalmente en paralelo en el flexible column layout.

Con un servicio con draft habilitado, el framework añade un filtro Editing Status y muestra qué filas tienen un draft o están bloqueadas por otro usuario. Todas las partes de un list report se generan a partir de metadatos, por lo que los list reports se comportan de forma similar en todas las apps.

En ABAP CDS, las dos primeras aparecen como @UI.selectionField y @UI.lineItem en cada elemento; CAP usa los nombres de término de OData. El comportamiento de la página, como la carga inicial, la edición masiva, las vistas y el tipo de tabla, se configura en manifest.json. Las anotaciones deciden qué muestra un list report; el app descriptor decide cómo se comporta el list report.

Carga inicial. Cuando la app se inicia con un contexto de navegación, como parámetros procedentes de otra app o del target mapping, los datos se cargan de inmediato. En caso contrario, decide la variante por defecto del usuario mediante su ajuste Apply Automatically; solo la variante Standard sigue lo indicado en manifest.json:

Los usuarios pueden sobrescribir el ajuste por vista. SAP recomienda valores de filtro por defecto para que la página no se abra vacía.

La edición masiva está desactivada hasta que un desarrollador la habilita. En OData V4, enableMassEdit funciona en el list report (para registros activos sin un draft pendiente) y en la object page en modo de edición; visibleFields o ignoredFields limitan el diálogo. En OData V2, multiEdit funciona solo en el list report, para tablas responsive y grid. Ambos comportamientos del list report son decisiones de configuración deliberadas, no valores por defecto que aceptar sin examinarlos.

Sí, y las opciones dependen de quién sea el propietario de la app:

• App propia, OData V4: los extension points añaden columnas, acciones y campos de filtro personalizados, contenido de cabecera sobre la barra de filtros y vistas personalizadas como pestañas adicionales; los building blocks y las custom pages del flexible programming model cubren carencias mayores.
• App propia, OData V2: las extensiones registradas en manifest.json cubren áreas comparables, como columnas, acciones y filtros.
• Una app entregada por SAP: adaptation projects (SAP Fiori tools) o adaptación key user, sin modificar el código de SAP.

En SAP S/4HANA Cloud Public Edition, compruebe cuáles de estas vías admite SAP para la app y el release. Prueba de decisión: si se necesita código propio más allá de unas pocas columnas, acciones o filtros, reconsidere la elección del floorplan. Extender un list report es barato en los márgenes y caro en el núcleo.

1. Cargar todo al iniciar. Cargar siempre un entity set muy grande hace lento cada arranque; los valores de filtro por defecto son la mejor palanca.
2. Abrir con una tabla vacía sin explicación. Cuando los usuarios notifican "no hay datos", compruebe por este orden: el contexto de navegación, la variante por defecto y su indicador Apply Automatically, el ajuste del manifest y, después, los filtros obligatorios (en OData V2, un filtro obligatorio vacío bloquea la carga inicial).
3. Sobrecargar la barra de filtros. Veinte campos de selección ocultan los tres que importan.
4. Confundir variantes y vistas. Las variantes las guardan los usuarios; las vistas múltiples son pestañas definidas por los desarrolladores.
5. Habilitar la edición masiva para todos los campos. Limite el diálogo a un field group que sea seguro modificar en bloque.
6. Usar un list report para una cola de trabajo. Un conjunto breve y conocido de tareas encaja mejor en un worklist.

La mayoría de los problemas de un list report son problemas de configuración y de diseño de la selección, más que defectos del framework.