[Javier Ader]

Buenas, tanto tiempo (hace nada que no posteo nada por aca…). Estuve mirando todo el código relacionado al reporteador interno y me lo puse a comparar con el código fuente de otros proyectos que tienen la misma base que Libertya (en particular Adempiere) y con los bugs que estos han ido solucionando con el tiempo.
Bueno, me tome el trabajo de ir trasladando los bugfix y nuevas funcionalidades que encontraba (y de paso reporte un par de errores en los otros proyectos… como para compensar) a Libertya, y aca les dejo el resultado (esto lo hice sobre 10.03, pero deberia tranquilamente aplicarse a 10.09 ya que si no me equivoco todo lo que yo toque no se modifico en 10.09)

– corrección de formateo de código fuente (lineas larguísimas, falta de comentarios, falta de genericidad… todo esto hace al código inmantenible)
-bugfixs:
–exportación a HTML, CSV,SSV,TXT no se hacia en UTF8
–los reportes se generaban con filas “vacías” (se hizo una moficación en el pasado y no se comento una linea de código); esto no solo hace los reportes innecesariamente más largos si no que ademas cuando se exporta a CSV (u otro formato) tambien van estas lienas vacias
–cuando un usuario no tiene permisos de edición se estaba abriendo la ventana de edicion de todas maneras.
–en ReportEngine cuando se reportea de manera “especial” (en realidad, no se cuando se llama este codigo; el metodo es ReportEngine.get( Properties ctx,int type,int Record_ID )), es un pedido o factura en estado draf el reporte que se busca es incorrecto (el tema es que se busca por DocType_ID, pero en estado draf este va campo tiene valor 0; se soluciona mirando en ese caso C_DocTypeTarget_ID)
–varios otros…

– nuevas características:
— soporte de zoom (gentileza de Adempiere)
— se puede usar PageUp PageDown para cambiar de pagina (idem)

– se modifico el codigo para que la exportación a pdf se haga directamente con la versión de iText con la que se compila todo el sistema (presumo que es la misma que va a usar Jasper Reports), en lugar de usar la versión interna de iText modificada (org.openxpertya.print.pdf.* ; todo esos fuentes habria que eliminarlos directamente) [nota: me falto modificar ArchiveEngine para que use las nuevas interfaces… después subo este archivo). Ahora la exportación esta encapsulada en el nuevo archivo org.openxpertya.pdf.DocumentPDF.

Le dejo el código fuente (de paso, este codigo también tiene unos nuevos drivers Hasar en org.openxperyta.print.fiscal; si quieren eso no lo usen) , un cliente pesado 10.03 (deberían poder probarlo contra cualquier instalación 10.03; esto es por si no quieren andar compilando para probar) y un par de imágenes:

http://www.mediafire.com/?sh7igo20ncqmc

Imagen de libro de IVA con bug de filas vacias (parecen ser algo visual, pero son filas):
[img]http://www.eltita.com.ar/libertya/reporteador/imagenes/libro-iva-error-filas-de-mas.JPG[/img]

Imagen con bug corregido:
[img]http://www.eltita.com.ar/libertya/reporteador/imagenes/libro-iva-error-filas-de-mas-Corregido.JPG[/img]

Zoom:
[img]http://www.eltita.com.ar/libertya/reporteador/imagenes/reporteador-zoom.JPG[/img]

Si conocen algún otro problema o posible mejora, avisen.

[Federico Cristina]

Buenisimo el aporte! Ya lo estaremos revisando para el próximo release!

Saludos,
Federico

[Javier Ader]

Gracias Federico. Te comento que a lo que habria que tal vez prestarle atencion es a
ReportEngine.get( Properties ctx,int type,int Record_ID )
porque ahi si se cambio un poco la funcionalidad; antes se terminaba buscando otro formato de impresión en el caso de los pedidos y facturas no completadas (el tema viene por C_DocTye es 0). Más alla de que no pude testear esa modificación especifica (FIX 13 en el codigo) la nueva sentencia sql creo que esta bien (no la testie porque este metodo es llamado para impresiones “especiales” de facturas/pedidos/remitos y un par de documentos más, los ids de reportes que afecta están hardcodeados por ej proceso 119 para las facturas si mal no recuerdo); no afecta (o no debería) a la impresión de facturas normal.
Otra cosa a tener en cuenta es que el nuevo código usa la libreria iText directamente (por eso hay que incluirlo en el classpath en el print/build.xml, si no, no compila por ant), via la clase DocumentPDF; vi que en 10.09 estan iText 1.5.4 mientra que 10.03 esta usando 2.1.5 (o sea, se paso a una libreria mas vieja); yo lo probe exportando un informe con 2.1.5 y anduvo bien. Lo que si, DocumentPDF explícitamente setea la versión de documento pdf a generar a 1.2 (miras las propiades del documento pdf y te muestra esta versión), el código anterior no especificaba esto (y generaba un documento pdf version 1.4); Jasper no se a que versión estará exportando, pero debería andar con iText 2.1.5 (creo haber exportado mas de una vez).

Más allá de esto, acá subo las ultimas modificaciones (ya que me había olvidado de tocar ArchiveEngine):
-modifique ArchiveEngine para que utilice DocuemntPDF para generar la exportación
-elimine directamente iText interno (para sanear un poco el código) ; esto es todo el directorio org.openExpertya.print.pdf (no confundir con org.openXpertya.pdf; ese paquete nuevo tiene a DocumentPDF).
-tuve que tocar ArchiveDesign (en client) porque esta era la ultima clase que usaba el iText interno (y por lo tanto, me tiraba errores de compilación); de todas maneras, esta clase se podría directamente eliminar (no se usa en ningún lado)
-finalmente, los archivos true.gif y false.gif en org.openXpertya.print.layout estaban corruptos (no eran gif validos), los reemplace con los gif que encontré en adempiere (que supongo que son los mismos, salvo que antes de corromperse). Esto gifs se usan cuando se reportean columnas booleanas (algo con lo que nunca me tope pero seguro se iban a mostrar mal).

Finalmente, hice con éxito un build completo desde ant por si algún otro código que no vi estaba usando el iText interno. Las modificaciones deberían andar tranquilamente en 10.09, con cualquiera de las versión de iText (bah, con 2.1.5 seguro; creo que igual se debería usar esta versión ya que la exportación pdf desde el Jasper de 10.03 no parecía tener problemas); salvo como ya dije antes, el subpaquete fiscal NO hay que usarlo (tiene nuevos drivers Hasar y otras modificaciones pero para 10.03; tal como están, seguro que trae problemas para 10.09).

http://www.mediafire.com/?4zktf3ocbn0rc1m
build.xml -> pirnt/build.xml (pra que incluya itext 2.1.5 en el class path)
src->print/src (pero NO pisar el subpaquete fiscal)
En-client-Src-org-openXpertya-print -> archivos modificados de suproyecto client (son 4 nada mas; en dos de ellos solo agreque comentarios y genericidad cuando era necesario; los que realmente importan son Viewer y ArchiveDesign)

Saludos

[Mariano Oscherov]

Esto se va a implementar?.

Saludos.

Mariano.

[Autor]

Entradas