Consultas varias Diaguita 2.6.0 (RESPONDIDO)

solanet · 13 Mayo, 2019 17:46

Buen día Equipo Diaguita, ¿Como están?

Les cuento que en la Universidad Nacional de Lanus finalmente se está empezando a usar Diaguita 2.6.0 para realizar los circuitos de compras (actualmente solo lo usaba el área de Patrimonio), por lo cual los usuarios funcionales de compras nos reportaron algunas inquietudes que me gustaría compartirla con ustedes para ver si nos pueden ayudar en los siguientes puntos:

Encoding:
Al momento de importar archivos .csv, por ej: —> Solicitudes de bienes y servicios // Items // Importar planilla de carga de ítems en Diaguita veo que hay un problema de encoding, ya que donde hay acentos/ñ en el csv me aparecen “?” en el sistema (adjunto un print para que lo vean)

https://ibb.co/wSZFHvd

Probé cambiarle la codificacion al .csv al momento de guardarlo (previo a importarlo)

https://ibb.co/2cZjcf8

pero al levantarlo en Diaguita me sigue mostrando los “?” donde van los acentos y las ñ

Acá les dejo alguna info que les puede ser de ayuda.

SO: Debian Jessie 8
Diaguita Version: 2.6.0
PHP 7.1.29
BD: Postgres 9.6

CREATE DATABASE diaguita_pre
  WITH OWNER = postgres
       ENCODING = 'LATIN1'
       TABLESPACE = pg_default
       LC_COLLATE = 'es_AR'
       LC_CTYPE = 'es_AR'
       CONNECTION LIMIT = -1;

Separador de listas (; punto y coma)

Voy a intentar ser lo mas claro posible en este punto.
En las PCs de los usuarios de compras el separador de listas (configurable en —> Panel de control\configuracion regional y de idioma\Configuracion adicional\separador de listas) estaba seteado inicialmente con “,” (coma) , por lo que cuando se importaba un .csv en Diaguita los decimales o los comentarios/textos que tenían una “coma” los dividia en distintas columnas deformando todo el contenido del archivo.
Entonces lo que hicimos es poner el separador de listas en cada una de las PCs como ; (punto y coma), pero esto lo que ocasiono fue que empezaron a visualizar mal los números expresados en monedas, por ejemplo: $10.586,30 se ve $10,586.30, se invierte la coma y el punto.
La solucion temporal que encontramos para esto fue que cada vez que vayan a importar un archivo en Diaguita, previamente lo guarden asi https://ibb.co/6bkXnRs , pero cada usuario tienee que hacer esto en cada documento que van a subir , entonces la pregunta es si existe posibilidad de agregar en los parámetros de configuración de SIU-Diaguita la posibilidad de setear para todo el sistema el separador de listas para los archivos a importar… o sino me gustaria saber como hacen el resto de las universidades con estas convenciones.

Actos de apertura

Dentro ----> Actos de apertura / Definitivos / “Ver cuadro comparativo” ¿A este cuadro (excel) se le puede personalizar las columnas? ,si bien no es un reporte de jasper para personalizar con Ireport, la duda surge ya que desde Compras nos dijeron que algunas columnas (como por ej Cantidad Ofertada) hacen que la lectura del cuadro resulte poco practica en los casos que hay muchos proveedores/ofertas en el cuadro, y si eliminas esa columna desde el excel ya exportado directamente altera todo el cuadro (filas, columnas, valores,etc).

Les pido disculpas si fueron muchas consultas juntas, desde ya agradezco el tiempo y la molestia que les pueda ocasionar este post.

Ante cualquier duda o información adicional que requieran para su análisis me lo pueden pedir.

Saludos.

Pablo.

Korol_Fernando_Javie · 13 Mayo, 2019 20:47

Hola Pablo,

Paso a responderte a ver si podemos ir solucionando los inconvenientes que estan teniendo:

1) Encoding:

Lo que encontramos como extraño dentro de la info que nos pasas, es que la BD está en encoding LATIN1, siendo que por lo general, las BD se crean con encoding UTF-8, y luego son configuradas en el bases.ini como LATIN1. Les recomendaría que prueben esto sobre un servidor de testing para ver si no se soluciona el inconveniente con el encoding. También prueben guardar el archivo como latin 1 o su equivalente windows 1252 a ver si les toma correctamente el encoding.

2) Separador de listas (; punto y coma)

Respecto a la separación a los campos de los archivos csv, el separador utilizado por diaguita -y de forma casi universal- es la coma como separador de campos, y por otro lado lo extraño es que el Ms Office no interprete por omisión las columnas de texto. Tienen que tener en cuenta que la importación de documentos csv debe ser el siguiente:

Opción de separación: coma
Encoding: Latin 1 o su equivalente windows 1252
Limitador de texto: comilla doble: "

Como recomendación, evalúen la posibilidad de utilizar el libreOffice / openOffice para trabajar con los documentos csv de diaguita, ya que en nuestras pruebas, al configurarlo con la forma que te mencioné anteriormente, no tuvimos inconvenientes. Adjunto capturas para que sea más representativo.

3) Actos de apertura

Como la generación del cuadro comparativo es realizada desde php, y no hay forma de editarlo visualmente como el caso de jasper, si necesitan modificar la salida, la solución que pueden utilizar es la personalización de todo el proyecto vía colab.
Si quieren leer más sobre el esquema de personalización, te paso el link : http://documentacion.siu.edu.ar/wiki/2.5/RealizarPersonalizaciones/Php

Estamos en contacto,

Saludos,
Fernando.

solanet · 15 Mayo, 2019 14:04

Fernando, buen dia

Muchas gracias por la respuesta de cada punto. Por el momento usando el openOffice veo que se soluciona los errores de encoding/separador de campo, asi que estaremos evaluando internamente si aplicar esta solucion u otra, ya que creé una BD de testing en utf-8 y sigo con los mismos errores al importar los csv en Diaguita (“?” donde van los acentos/ñ).

Saludos!

solanet · 3 Junio, 2019 14:56

Hola,

Con respecto al punto 2) Separador de listas (; punto y coma) ya lo pudimos resolver como nos indicaron. El punto 3) lo dejamos para resolver en breve (cuando tengamos acceso por Colab)

El punto 1) aun nos queda pendiente y es lo que más nos preocupa.

Lo que encontramos como extraño dentro de la info que nos pasas, es que la BD está en encoding LATIN1, siendo que por lo general, las BD se crean con encoding UTF-8, y luego son configuradas en el bases.ini como LATIN1. Les recomendaría que prueben esto sobre un servidor de testing para ver si no se soluciona el inconveniente con el encoding. También prueben guardar el archivo como latin 1 o su equivalente windows 1252 a ver si les toma correctamente el encoding.

Creamos una BD de cero en testing con utf8 (desde PgAdmin)

CREATE DATABASE diaguita_utf8
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'es_AR.UTF-8'
       LC_CTYPE = 'es_AR.UTF-8'
       CONNECTION LIMIT = -1;

Y en el bases.ini está como siempre en latin1, levantamos el Backup (no dio errores) y intenté importar nuevamente dentro de Diaguita a los items (solicitud de bienes y servicios) y sigue mostrandome mal los caracteres (ñ o acentos). Les adjunto print.

Al .csv lo guardamos como nos dijeron: windows 1252/latin (print 2),

Les proporciono alguna info adicional de la configuracion del server linux por si les ayuda,

S.O: Debian GNU/Linux 8

root@SVR-XPREPGSQL-02:/PC# locale -a
C
C.UTF-8
es_AR
es_AR.iso88591
es_AR.utf8
POSIX

root@SVR-XPREPGSQL-02/PC# locale
LANG=es_AR.UTF-8
LANGUAGE=es_AR:es
LC_CTYPE="es_AR.UTF-8"
LC_NUMERIC="es_AR.UTF-8"
LC_TIME="es_AR.UTF-8"
LC_COLLATE="es_AR.UTF-8"
LC_MONETARY="es_AR.UTF-8"
LC_MESSAGES="es_AR.UTF-8"
LC_PAPER="es_AR.UTF-8"
LC_NAME="es_AR.UTF-8"
LC_ADDRESS="es_AR.UTF-8"
LC_TELEPHONE="es_AR.UTF-8"
LC_MEASUREMENT="es_AR.UTF-8"
LC_IDENTIFICATION="es_AR.UTF-8"
LC_ALL=

La BD que veniamos usando normalmente era:

CREATE DATABASE diaguita_pre
  WITH OWNER = postgres
       ENCODING = 'LATIN1'
       TABLESPACE = pg_default
       LC_COLLATE = 'es_AR'
       LC_CTYPE = 'es_AR'
       CONNECTION LIMIT = -1;

encoding diaguita.jpg

encoding diaguita.png

encoding 2.jpg

encoding 2.png

Korol_Fernando_Javie · 4 Junio, 2019 02:05

Hola Pablo,

Te comento que estuvimos haciendo pruebas en varios entornos hasta que logramos reproducir el caso que tienen ustedes que al guardar en “windows 1252/latin1” cuando lo importan en diaguita, se ven mal los caracteres.

La solución a este problema sería el siguiente: Importar el documento desde el libre/Open office y elegir “UTF8”, el resto de las opciones de importación se mantienen. Ante esto van a ver que los textos descripción y especificaciones técnicas se van a ver mal porque justamente estan creadas en LATIN1, pero esto es solo visual. Carguen el documento y guardenlo manteniendo el UTF8.
Luego al importar, les va a tomar correctamente los caracteres.

Avisennos que tal les fue.

Saludos,
Fernando.