Cuando necesitamos crear un informe en Microsoft Dynamics NAV/BC la parte del diseño suele ser la más compleja. Da igual qué herramienta de las permitidas utilicemos (Microsoft Visual Studio, Microsoft SQL Report Builder…). Las características a tener en cuenta son prácticamente las mismas, al igual que los fallos generados por no seguirlas.
En este artículo hablaremos de algunos errores que podemos encontrarnos a la hora de probar nuestros informes RDLC y cómo solucionarlos para no volvernos locos buscando dónde está el problema. ¿Empezamos?
Puede ocurrir que al imprimir un report, la información aparezca solapada. Como consecuencia, no podemos ver bien el contenido.
El problema vendrá porque esos objetos Tablix en el layout estarán solapados. Es muy común añadir una tabla con líneas de detalle, y que debajo de esa tabla haya otra con p. ej. comentarios. Creamos ambas tablas y ajustamos los espacios. Pero de repente, necesitamos crear más líneas en nuestra tabla de detalle, con lo que realizamos la acción Nueva línea y añadimos el contenido a nuestra línea sin acordarnos del resto de tablas.
Si dejamos así el informe y probamos, la información del cuadro de arriba se verá solapada por la información del cuadro de abajo. Un caso así se soluciona revisando las tablas que tengas en tu layout y separándolas.
Imaginad un rango de documentos de venta, que al imprimirlo obtenéis toda la información mezclada en una sola página, cuando lo que vosotros queríais es obtener un registro por página. ¿Qué puede haber pasado?
El cuerpo de un informe debe estructurarse de la siguiente forma:
Es muy común realizar una impresión con rango cuando se trata de documentos, ya sean de venta, compra… de forma que ahorramos tiempo al no tener que ir imprimiendo uno por uno. Pero podemos encontrarnos al probar nuestros informes con que los datos que aparecen en la cabecera (nº documento, datos de cliente, etc.) son los mismos para todos los documentos, aunque sabemos que no es verdad. Aquí pueden darse dos problemas:
En el caso 1, habría que revisar si los campos que necesitamos mostrar están configurados en el textbox donde se configura en SetData. Una vez comprobados (y añadidos si es necesario), se configurarán en los campos correspondientes de la cabecera.
El caso 2 se nos puede dar ya desde el principio, o una vez hayamos realizado los cambios del caso 1. En este caso habría que revisar la propiedad Parent de la tabla que contengan el textbox con el SetData. ¿Por qué? Porque lo más probable es que no esté apuntando al rectángulo contenedor del cuerpo (recordemos lo explicado antes para la creación del cuerpo, primero tabla, después rectángulo, y entonces ya ir añadiendo dentro las distintas tablas que formen nuestro informe, siempre con el rectángulo como Parent). Tendremos que mover esa tabla de sitio para que el layout recoja al rectángulo como su Parent.
¡Espero que estas anotaciones os ayuden en vuestros futuros diseños!
Sandra Cruz
Dynamics