reportes dinamicos.....

[[oscarac]]

estoy probando delphi MVC sin librerias y tengo un problema con un reporte
genero el query de manera dinamica y en el reporte "seteo" los campos

Código Delphi [-]
procedure TrepListadoMensualCuentaNormal.MapearCamposReporte(ADataSet: TDataSet);
begin
  if ADataSet = nil then Exit;

  
  qrepListadoMensualCuentaNormal.DataSet := ADataSet;
  qrb_GrupoCuenta.Master                 := qrepListadoMensualCuentaNormal;
  qrb_GrupoCuenta.Expression             := 'Cuenta'; // Limpio, sin prefijos


  qrdbtxtLibro.DataSet            := ADataSet;
  qrdbtxtLibro.DataField          := 'Libro';

  qrdbtxtVoucher.DataSet          := ADataSet;
  qrdbtxtVoucher.DataField        := 'Voucher';

  qrdbtxtRgt.DataSet              := ADataSet;
  qrdbtxtRgt.DataField            := 'RGT';

  qrdbtxtDocumento.DataSet        := ADataSet;
  qrdbtxtDocumento.DataField      := 'Documento';

  qrdbtxtFechaDoc.DataSet         := ADataSet;
  qrdbtxtFechaDoc.DataField       := 'FechaDocumento';

  qrdbtxtFechaVencimiento.DataSet := ADataSet;
  qrdbtxtFechaVencimiento.DataField := 'FechaVencimiento';

  qrdbtxtRazonSocial.DataSet      := ADataSet;
  qrdbtxtRazonSocial.DataField    := 'RazonSocial';

  qrdbtxtGlosa.DataSet            := ADataSet;
  qrdbtxtGlosa.DataField          := 'glosa';

  qrdbtxtmnd.DataSet              := ADataSet;
  qrdbtxtmnd.DataField            := 'Mnd';

  qrdbtxtCCosto.DataSet           := ADataSet;
  qrdbtxtCCosto.DataField         := 'CCosto';

  // Asignación de importes con limpieza de propiedad previa
  qrdbtxtDEBE.DataSet             := ADataSet;
  qrdbtxtDEBE.DataField           := 'DEBE';
  qrdbtxtDEBE.Mask                := '#,##0.00;-#,##0.00;0.00';

  qrdbtxthaber.DataSet            := ADataSet;
  qrdbtxthaber.DataField          := 'HABER';
  qrdbtxthaber.Mask               := '#,##0.00;-#,##0.00;0.00';


  qrexSumaDebe.Master  := qrepListadoMensualCuentaNormal;
  qrexSumaHaber.Master := qrepListadoMensualCuentaNormal;
  QRExpr6.Master       := qrepListadoMensualCuentaNormal;

  qrexSumaDebe.ResetAfterPrint  := False;
  qrexSumaHaber.ResetAfterPrint := False;
  QRExpr6.ResetAfterPrint       := False;

  qrexSumaDebe.Expression  := 'SUM(DEBE)';
  qrexSumaHaber.Expression := 'SUM(HABER)';
  QRExpr6.Expression       := 'SUM(DEBE) - SUM(HABER)';


  qrexSumaDebe.Mask  := '#,##0.00;-#,##0.00;0.00';
  qrexSumaHaber.Mask := '#,##0.00;-#,##0.00;0.00';
  QRExpr6.Mask       := '#,##0.00;-#,##0.00;0.00';
end;

me muestra el detalle, perfecto, pero los totales no es decir SUM(DEBE) o SUM(HABER) o la diferencia entre ellos no las muestra, no se si me estoy haciendo entender

[Casimiro Noteví]

Yo no tengo ni idea, aunque te pego lo que dice el primo chatgpt:
Ufff... se ha descuadrado la respuesta.

En este tipo de casos en QuickReport (o componentes similares en Delphi), cuando el detalle se muestra bien pero los SUM no aparecen, el problema casi nunca está en la expresión SUM(DEBE), sino en el contexto de evaluación del QRExpr dentro del ciclo de impresión del reporte. Lo primero importante es entender que los agregados como SUM dependen de que el reporte esté realmente recorriendo el dataset durante el proceso de impresión; no basta con asignar el DataSet al reporte o al Master, sino que el motor del reporte tiene que estar en ejecución con el dataset activo y completamente preparado antes de imprimir. En tu caso, al generar el query de forma dinámica y luego mapear los campos, es muy probable que el reporte ya haya sido preparado internamente antes de que el dataset esté completamente estable o antes de que los enlaces estén bien establecidos, y eso hace que las expresiones de agregación no se inicialicen correctamente. Otro punto clave es la ubicación de los QRExpr: SUM solo funciona correctamente si los QRExpr están dentro de una banda que participe en el recorrido del dataset, normalmente un SummaryBand o un GroupFooterBand que dependa del mismo dataset maestro; si están en un band que no se recorre o no está correctamente enlazado al flujo del reporte, el valor nunca se acumula. También es importante que el dataset esté activo en el momento exacto en que el reporte se prepara, porque si el dataset se asigna pero todavía no está abierto o se abre después de configurar el reporte, los cálculos agregados pueden quedar vacíos. En muchos casos con QuickReport dinámico, cuando se cambian campos o dataset en tiempo de ejecución, es necesario forzar una nueva preparación del reporte después del mapeo, porque si no el motor mantiene una estructura interna anterior y no recalcula expresiones como SUM o diferencias. Además, debes confirmar que los campos DEBE y HABER son realmente numéricos (por ejemplo Float o Currency) y no strings, porque si vienen como texto desde una consulta dinámica, SUM no va a funcionar correctamente aunque el detalle sí se muestre. Finalmente, el hecho de que tengas ResetAfterPrint := False indica que quieres acumulación global, lo cual está bien, pero si el ciclo de impresión no se está ejecutando correctamente o el dataset no está siendo iterado por el reporte, ese acumulador nunca llega a activarse. En resumen, lo más probable en tu caso es una combinación de que el reporte se está preparando antes de que el dataset dinámico esté completamente listo, o que los QRExpr no estén dentro de una banda que realmente recorra el dataset durante la impresión, o que el dataset no esté activo en el momento de calcular las expresiones. Si quieres afinarlo al 100%, habría que ver en qué banda están esos QRExpr y en qué momento exacto abres el dataset respecto a este método de mapeo, porque ahí normalmente está la clave del fallo.

[Felinotronica]

No se si te han contestado o ya tienes la solución, entiendo que lo que haces es un control de libro de caja, con gastos (Debe) ingresos (haber). Lo que no veo son varias cosas si usas procedimientos almacenados ni la base de datos sobre la que trabajas, tampoco aparece la transacción y el commit de datos, pero cuando me pasan estas cosas hago una simplificación: crea un prototipo sencillo que haga la tarea que necesitas, y revisa el funcionamiento. Aveces es preferible perder un día o 2 a estar semanas dando vueltas. Redúcelo a un ejemplo simple, viendo solo la asignación de los dataset y los campos es complicado, no se donde están en el UML, ni como tienes diseñada la capa y las conexiones, siquiera vemos la clase. Con códigos largos, simplifica y revisa todo desde lo mas sencillo, es lo que mejor me funciona para resolver estos casos.

[emailx45]

Para obtener un resumen de los valores, ¡debes establecer un orden acorde con el resultado que esperas obtener!
Por ejemplo, supongamos que deseas conocer el valor resultante de cada día de ventas:
a) agrupar e ordenar la columna de la fecha de venta;
b) indicar el campo o los campos que se utilizarán para realizar la suma.

De lo contrario, la función de agregado (SUM) no tendría un criterio para efectuar la suma de los valores, ¿entiendes?

Código SQL [-]
SELECT 
    Data,
    SUM(CASE WHEN Tipo = 'DEB' THEN Valor ELSE 0 END) AS TotalDebito,   // TIPO = DEB ou CRE abajo
    SUM(CASE WHEN Tipo = 'CRE' THEN Valor ELSE 0 END) AS TotalCredito
FROM (
    SELECT Data, 'DEB' AS Tipo, Valor FROM TableDEB
    UNION ALL
    SELECT Data, 'CRE' AS Tipo, Valor FROM TableCRE
) AS Movimentacoes
GROUP BY Data
ORDER BY Data;

Cómo funciona:
UNION ALL interno: Combina todos los registros de débitos y créditos, añadiendo una columna virtual Tipo ('DEB' o 'CRE') para identificar el origen de cada valor.

SUM(CASE ... END): Separa los valores de forma condicional según la fecha, creando columnas de subtotal independientes para débitos y créditos en cada día.

GROUP BY Fecha y ORDER BY: Agrupa y ordena cronológicamente por fecha, generando el informe contable diario.

Suma final: En su informe (por ejemplo, en Delphi/FireDAC), basta con añadir un pie de página (utilizando TClientDataSet o TFDQuery con agregados, o bandas de informe) que sume las columnas TotalDebito y TotalCredito.

[emailx45]

Otra cosa: si estás utilizando dos tablas para obtener datos y, a partir de ellas, generar una tercera tabla con el resultado, podrías emplear una "VIEW" (una estructura que genera resultados automatizados y que puede activarse o desactivarse según sea necesario) en SQL, o bien un "STORED PROCEDURE" (procedimiento almacenado) para obtener resultados bajo demanda:

1) La "VIEW" o el "STORED PROCEDURE" pueden contener la consulta SQL ya preparada dentro de tu base de datos.
2) Tanto la "VIEW" como el "STORED PROCEDURE" pueden utilizarse en una sentencia `SELECT` de forma habitual, incluso admitiendo parámetros.
3) De este modo, evitarías incluir todo el código dentro de tu aplicación Delphi y prescindirías de configuraciones manuales. Todo podría gestionarse directamente en el componente SQL —como `FDQuery`, `IBQuery`, `UniQuery`, etc.— utilizando el *Object Inspector* del IDE (a través de sus propiedades visuales). Además, podrías emplear el editor de campos (*Field Editor*) para definir detalles como el formato, entre otros.
4) Utilizar una "VIEW" o un "STORED PROCEDURE" para crear tu nueva consulta resulta mucho más práctico y limpio, ya que facilita el mantenimiento sin necesidad de modificar el código de la aplicación.
5) ¡Tenlo en cuenta!
6) Para tu caso, considero que una "VIEW" es la mejor opción: reside en la base de datos, se actualiza automáticamente a medida que los datos en tus tablas cambian (ya sea por inserciones o eliminaciones), admite parámetros, es sencilla de integrar en un componente y se basa en el uso natural de `SELECT` en SQL. ¡Es la solución ideal!

Código SQL [-]
CREATE VIEW VW_ExtratoContabil AS
SELECT 
    Data,
    SUM(CASE WHEN Tipo = 'DEB' THEN Valor ELSE 0 END) AS TotalDebito,
    SUM(CASE WHEN Tipo = 'CRE' THEN Valor ELSE 0 END) AS TotalCredito
FROM (
    SELECT Data, 'DEB' AS Tipo, Valor FROM TableDEB
    UNION ALL
    SELECT Data, 'CRE' AS Tipo, Valor FROM TableCRE
) AS Movimentacoes
GROUP BY Data;

Código SQL [-]
SELECT * FROM VW_ExtratoContabil ORDER BY Data;