Totales con vRepor


([N4] PedroN) #1

Hola a todos.
Al problema planteado Soporte me da una respuesta que no me convence y es el paso de parámetros.
Me dirijo a la Comunidad por si a alguien le ha pasado y encontró otra solución un poco más…
Para una herramienta “orientada al desarrollo de soluciones de gestión empresarial” pensaba yo que estaría más… fácil.
La cuestión:
Se dispone de un fichero Maestro FACTURAS que, entre otros, tiene un plural ALBARANES.
Se persigue un informe como el de la imagen adjunta en el que los totales correspondan a las líneas de las FACTURAS en negrita y que, como se observa, no tienen que corresponder necesariamente a los sumatorios de los detalles (ALBARANES).
Como se observa acumula en la variable tantas veces como pasa por detalle.
En el diseño de vRepor el Comienzo del Informe es FACTURAS y ALBARANES se trata como Origen de datos hijo (subconsulta).
Gracias de antemano.


([N4] PedroN) #2

No sube adjunto


03-07-2017-.pdf (24.4 KB)


([N4] Infortic) #3

Hola.

No entiendo muy bien el problema, no sé qué le has consultado a soporte ni lo que te ha contestado, tampoco sabemos la estructura de tu report ni la de tus tablas…

Entiendo que lo que quieres es que el total general sea la suma sólo de las líneas en negrita ¿no?

Supongo que el problema viene de que cada vez que se imprime un detalle te suma en la variable el total de la factura en lugar de sumar sólo cuando se imprime la primera línea (la de la factura).

Creo recordar que eso me ha pasado y no he conseguí que vReport sumara correctamente, no sé si vreport sigue haciendo lo mismo.

Yo probaría a:

1 - Crear un campo en FACTURAS llamado PRI_ALB que es un singular de plural por posición 1 de la tabla de albaranes.

De esta forma tienes en la cabecera de facturas un enlace al primer albarán, te servirá para saber si estás imprimiendo el primer albarán o no.

2 - El report lo haría de la tabla de albaranes, no de la de facturas.

El report agrupará por FACTURA y la primera línea será la cabecera de grupo, no un detalle.

3 - Sólo quiero sumar 1 vez cada factura (ese creo que es el problema de fondo).

Para ello la fórmula que acumula en la variable debe contemplar este hecho:

choose(#ID=#FACTURA.PRI_ALB.ID,#TOTAL_FACTURA,0)

Esto quiere decir que si el albarán que estoy imprimiendo en estos momentos es el primero de la factura acumulo, si no, no lo hago.

Como digo, por lo que he podido entender, no sé si el problema es realmente ese.

Un saludo.


([N4] PedroN) #4

Hola Infortic.
Muchas gracias por la respuesta.
Efectivamente has entendido el problema. El modificar el modelo de datos por un informe… me parece excesivo y sí, ciertamente, eso solucionaría el problema. El partir del detalle es otra opción que ya hemos explorado en otras ocasiones pero añade programación extra al ser el origen una lista/ficha de Facturas.
Sencillamente se trata de dejar de manifiesto que algo tan simple, en los tiempos que corren, no debería ser objeto de las eternas “astucias” y se debería dotar a la herramienta de funcionalidades acordes con el tiempo y/o programación que vivimos.
A quien corresponda, creo haría bien en dedicarle un poco de tiempo a los informes, impresión de gráficos, etc.
Pero bueno, igual que a otros les queda París a nosotros, JavaScript y/o QML y el modelo original (que nos enganchó en su momento) se va quedando… olvidado.
Gracias de nuevo y un saludo.


([N3] pacosatu) #5

Hola PedroN.

Sería una lástima que, como bien dices, una cuestión tan sencilla quedara sin resolver.

Sin tocar nada de tu proyecto, y como bien indica Infortic, puedes condicionar la fórmula que acumula los importes en la variable del informe.
Siempre podrás hacerlo si puedes determinar qué líneas son las que deben sumar (las que aparecen en negrita).

De todas formas, en la imagen que adjuntas, creo que los Totales no suman bien, tampoco por importe en negrita.

Saludos
Paco Satué


([N4] Infortic) #6

El problema en este caso es cómo maneja los subinformes vReport.

Cualquier diseñador de informes permite detalles anidados, pero vReport la única forma que permite para ésto es que cada uno sea un informa completo distinto del original, con su cabecera de informe, pie, etc… lo que hace que uso de variables que acumulan etc… no sean usables en muchos casos.

La verdad, comparas vReport con FastReport o similar y es bastante penoso…


([N4] PedroN) #7

Hola.
Gracias por las respuestas que, como comento, evidencian la falta de evolucionar hacia algo… mejor.
No digo nada de las variables internas de vReport que no son usables… Las comparativas con FastReport, iReport, etc mejor no comentar.
Amigo Paco, los totales en negrita no siempre han de coincidir con la suma de las líneas al poder contemplar un descuento, por ejemplo, en la factura y no en las líneas.
Un saludo,


([N4] Infortic) #8

Hola Pedro.

Por delante decir que estoy de acuerdo en gran parte de tu argumentación, velneo sin duda se está quedando atrás en muchos aspectos, negarlo es absurdo viendo el nivel de algunos frameworks.

[quote quote=50762]Hola Infortic.
El modificar el modelo de datos por un informe… me parece excesivo
[/quote]

Con respecto a lo del modelo de datos, esto es inevitable en velneo.

Velneo no es una bbdd SQL, no existen métodos de agregación ni de consulta avanzada, por lo tanto, todo lo que no esté contemplado en el modelo de datos te será complicado explotarlo en capa de aplicación de forma eficiente. Es por esto que existen tipos de campo enlace de distintos tipos, actualizadores etc… .

El modelo de bbdd es muy distinto con sus pros y contras.

Contras: Ya los sabes, no hay datos agregados a no ser que los modelices en la bbdd.

Pros: Al estar ya todo modelizado, los cálculos hechos a base de actualizadores triggers etc, estar indizado en tu modelo como quieres etc… el sistema no degradará su rendimiento cuando aumenten los registros (al menos no mucho si lo has hecho bien).

Es velocidad contra versatilidad, tú eliges que tipo de proyecto le va bien a velneo y cual no, pero si lo eliges para algún proyecto, es inevitable que ante un nuevo requerimiento de la aplicación haya que añadir algún campo, enlace o trigger, al menos si quieres que esa funcionalidad “se mueva” como es debido, si no… irá a pedales.

Un saludo.


([N3] pacosatu) #9

Hola PedroN.

Ya imagino que habrá razones de lógica de negocio para que las líneas no sumen lo mismo que el importe final de la factura.

Pero estamos hablando de forma genérica de cómo acumular los importes de n-líneas de detalle en un Informe de Velneo, teniendo en cuenta que algunos importes no deben acumularse.

En tu ejemplo, de 6 líneas de Detalle, he entendido que solo quieres acumular los importes que están en negrita, es decir, 2 líneas de detalle.

De ahí lo de condicionar la fórmula que acumula los importes en la variable, así de simple.

En cuanto a los generadores de Informes, estoy de acuerdo que vReport es de juguete comparado con la competencia en .NET o JAVA.
Sin embargo dudo mucho que Velneo no se haya planteado este tema y no haya hecho nada, quizás porque no tiene demanda.

La fuerte integración de VReport en un producto exclusivo como Velneo, yo lo veo más como un privilegio frente a la competencia.

De todas formas, siempre tendremos la opción de exportar los datos a un formato que entienda el motor de Informes que más nos guste.

Saludos
Paco Satué


([N4] PedroN) #10

Hola.
Yo puedo saber qué detalle es el primero, independientemente de si hay más o no, mediante una variable que se resetee a nivel de grupo FACTURA. En ese momento obtener el valor del registro apuntado del maestro FACTURAS y leer el Total BI que ya llevará descuento si lo hubiere. Pero ese valor es el que es necesario acumular para llegar al Total General.
Pero vRepor no permite (o yo no se) referencias entre variables.
Y el problema es independiente de partir del detalle (ALBARANES) que de maestro/detalle (FACTURAS/ALBARANES).
¿Y cuando es necesario agrupar y totalizar por Zona, Ruta, Cliente y Factura? ¿Y encima explotarlo en la nube?
Perdonad, pero no veo cómo hacerlo de una forma sencilla.
Pero muchas gracias a ambos por vuestra atención y tiempo.
Un saludo,