Buenas tardes, como están?
estoy empezando a personalizar algunos reportes con Jasper, en particular el de Alta de Bienes Patrimoniales. En el detalle de Datos de los Bienes el valor unitario se muestra con el simbolo del Euro, donde se puede cambiar eso?
Estuve buscando pero no me doy cuenta donde ni como cambiarlo.
Muchas gracias!
Saludos…
Lucila.
Hola Lucila, esto les sucede en entorno de producción? ¿Cuando prueban el diseño con el iReport? ¿Bajo que sistema operativo?
Estoy en entorno de prueba, lo veo cuando pruebo el diseño con iReport. Tengo iReport instalado en un windows.
Todavia no he probado pasar lo que modifique con iReport a mi instalación de diaguita prueba.
Copié los archivos generados desde iReport a la instalacion de Diaguita Prueba y al generar el reporte desde Diaguita me muestra el signo $.
Sera algo de configuración? de todas maneras ya esta solucionado.
Gracias!!
Bueno, si todavía sigue el problema, bajo windows se trata de la configuración regional y de idioma. No está en la que corresponde para Argentina. ISO-8859-1 u LATIN1 no son las configuraciones de nuestra moneda/idiona/regionalización. Bajo un servidor Diaguita que por ej. este instalado en un Linux, si este esta configurado con el idioma español y la ubicación regional de argentina, va a mostrar el simbolo $.
Saludos!
Nosotros tenemos el mismo problema.
Lo que hicimos fue simplemente aplicar un parche, colocando un condicional al momento de colocar el signo monetario desde el ireport.
En nuestro caso, se utiliza el “Peso Argentino”, “Dolar estadounidense”, “Euro”. Las primera 2 monedas tienen el símbolo “$” incluído ($, u$s) excepto el “€”.
Entonces con la siguiente sentencia:
( $V{simbolo}.contains( '$' ) ? $V{simbolo} : '€' )
se salva este inconveniente de encoding.
Obviamente es un parche que hay que aplicar a cada reporte que presente símbolos monetarios, por eso no es la solución más óptima para salvar esto.
¿En producción? Porque si es únicamente con el uso del iReport y no dentro del sistema en producción, uno podría llegar a hacer la vista gorda… o corregir la configuración regional 
El field @simbolo que tienen varias salidas solo viene separado en casos donde está la posibilidad de mostrar en la moneda original o la local (ej. USD o PESOS). De todas formas, es bueno revisar y determinar si con configurar correctamente el idioma/regionalismo del sistema pueden evitarse tocar este detalle en absolutamente todas las salidas con monedas.
Saludos!
Un detalle, la base de datos de diaguita está en LATIN-1. Si uno quisiera agregar el símbolo € le da el error que se adjunta en la imagen a continuación (moneda.png).
Si uno configura la moneda desde las tablas maestras de la aplicación, en la base de datos la guarda con el símbolo que aparece en la otra imagen adjunta (moneda2.jpg).
Ahora bien, la aplicación en las tablas maestras aparece bien el símbolo euro según lo que guardó. Pero los reportes (salidas en pdf) donde viene el campo “moneda” por separado, coloca cualquier basura o no coloca nada (moneda3.png).
Eso es lo que nos está pasando a nosotros. ¿Qué sugieren hacer en este caso?
Nosotros corremos la aplicación en Debian.
Hola Seba, te respondo por partes…
En la pregunta está la respuesta: el cluster de la base de datos está iniciado como LATIN1, mientras que con el cliente PGADMIN están accediendo e intentando guardar un caractér € que se escribió con codificación UTF8 (esto sería el hexadecimal que te muestra en el error). Es un problema de conversión de tipos, aunque creería que el € tiene que ser posible guardarlo en LATIN1 si el cliente (PGADMIN) establece la conexión con la sentencia SQL:
set client_encoding='UTF8'
Con JasperReports tienen problemas porque recibe un dato LATIN1 pasado por la función utf8_decode(). No sabría darte la solución adecuada en este caso puntual, pero podría ser correr la JVM en LATIN1, o al menos el servicio de reportes.
Todo este problema en general surge porque Diaguita (y Toba además) trabaja con LATIN1, pero ello no significa que la base de datos tenga que tener un cluster iniciado en dicho encoding. O sea, la base de datos es aconsejable tenerla siempre en el encoding nativo donde corre dicho servicio: Debian + Argentina = UTF8.es_AR
Lo del idioma puede pasar sin mayores inconvenientes, pero que sea UTF8 el cluster es necesario. Internamente Diaguita cuando hable con el motor, le va a ir pidiendo los datos o suministrandolos siempre utilizando o anteponiendo el client_encoding = LATIN1 por lo que no hay mayores preocupaciones a nivel aplicación.
Espero no haber complicado más el problema 
Hola Sergio, tengo un problema tal vez relacionado con la configuracion regional con puntos y comas decimales, en mi instalacion local en windows un importe en el pdf generado por jasper lo veo $ 1.234,56 y en linux produccion $ 1,234.56 con los simbolos intercambiados, estimo que es configuracion del Servidor pero no se bien donde sería
Muchas Gracias
Hola Ulises, te respondo acá y si sigue el problema por otro motivo que no sea lo que ya esta en este hilo, lo separamos 
Exactamente este problema que no es tal, es resultado de lo que se conoce como configuración regional. En EEUU (y la que muchísimas veces está por defecto para formato interno hasta en nuestras cosas), la configuración regional aplica separadores decimales con el punto y de millar con la coma. En otros lugares como Argentina, es al revés. Y para saber que configuración regional te pertenece, simplemente hay que seguir el estándar que lo define como IDIOMA + PAIS + ENCODING. Ejemplos serían:
En tu caso, tienen que garantizar que tu servidor esté corriendo con el esquema es_AR.ENCODING mínimamente. Luego puede ser que el reporte Jasper tenga otra “asperezas” que la podemos ir viendo en un paso posterior. El encoding del servidor debería ser UTF8 siempre, ya que es el que maneja nuestro esquema de caractéres español. LATIN1 es una configuración europea que no podemos recomendar utilizar en nuestras instalaciones.
Para configurar esto en linux, primero existe el comando locale que te permite consultar la configuración actual y luego realizar los ajustes necesarios con otras herramientas. Este es un ejemplo de como se cambia en Debian Linux.
Saludos!
PD: esta tarea de verificar y corregir la configuración regional muchas veces es responsabilidad del sysadmin del grupo, por lo que siempre requiere de conocimientos puntuales. Si pueden corroborarlo con el de su equipo, mucho mejor. Además, si ya tienen instancias de servicios vários (llámese PostgreSQL, etc), un cambio del encoding del SO afecta en cierta forma todos sus servicios alojados.
La configuracion regional estaba correctamente configurada pero al correr la maquina virtual de java con el Bridge para Jasper no tomaba la configuracion, lo solucionamos poniendo directamente en el script esta configuración regional en diaguita_reportes.sh linea 32 modificamos
DAEMON=“/usr/bin/java – -jar $PATH_JASPER SERVLET:8081 $DEBUG_LEVEL $DEBUG_FILE”
por
DAEMON=“/usr/bin/java – -Duser.language=es -Duser.country=AR – -jar $PATH_JASPER SERVLET:8081 $DEBUG_LEVEL $DEBUG_FILE”
y funciono perfectamente.
Igualmente queda la duda de porque la maquina virtual no nos toma directamente la configuracion regional en los servidores linux.
Muchas Gracias
Saludos