Imp. Ganancias - Form Mensual: Error JS PDF/XML (Mapuche 3.4.4/3.4.5)

Tenemos implementado SIU Mapuche 3.4.4 y 3.4.5 en plataforma Linux (Debian) y surge el siguiente error al querer generar el Formulario Mensual de Impuestos a las Ganancias (de cualquier mes de cualquier agente):

Error en la respuesta.
Error JS:
TypeError: Cannot read property ‘0’ of null
Mensaje Server: null

Al realizar el filtrado del año elegido, el listado se genera correctamente, el inconveniente surge al querer imprimir, al seleccionar PDF se genera el error ya mencionado, al seleccionar XML el sistema informa que no existe el archivo.

En los logs de Mapuche no aparece ningún error, en los logs de Apache figura un error de memoria: El SO tiene asignado 12GB RAM y php.ini tiene establecido memory_limit 512MB, también con 1024MB el problema persiste.

[Wed Apr 18 10:21:52.404710 2018] [core:notice] [pid 2239] AH00094: Command line: ‘/usr/sbin/apache2’
[Wed Apr 18 10:27:35.148489 2018] [php7:error] [pid 2252] [client 10.20.15.84:61825] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 266342400 bytes) in Unknown on line 0, referer: http://10.20.15.220/siu/mapuche/aplicacion.php?tm=1&tcm=central&ai=mapuche||67000013
[Wed Apr 18 10:32:03.250975 2018] [php7:notice] [pid 2258] [client 10.20.15.84:62035] SQLSTATE[22P02]: Invalid text representation: 7 ERROR: la sintaxis de entrada no es v\xe1lida para integer: \xab\xbb\nLINE 33: WHERE dh01.nro_legaj = ‘’\n ^, referer: http://10.20.15.220/siu/mapuche/aplicacion.php?ah=st5ad74695163e82.91073204&ai=mapuche||67000013
[Wed Apr 18 10:32:03.277212 2018] [php7:notice] [pid 2258] [client 10.20.15.84:62035] toba_error_db:

SQLSTATE: db_22P02

CODIGO: 7

MENSAJE: ERROR: la sintaxis de entrada no es v\xe1lida para integer: \xab\xbb\nLINE 33: WHERE dh01.nro_legaj = ‘’\n ^

SQL: SELECT\tdh01.nro_legaj,\r\n\t\t\t\t\t\tdh01.desc_appat,\r\n\t\t\t\t\t\tdh01.desc_apmat,\r\n\t\t\t\t\t\tdh01.desc_apcas,\r\n\t\t\t\t\t\tdh01.desc_nombr,\r\n\t\t\t\t\t\tdh01.desc_appat || ', ’ || dh01.desc_nombr AS agente,\r\n\t\t\t\t\t\tdh01.nro_tabla,\r\n\t\t\t\t\t\tdh01.tipo_docum,\r\n\t\t\t\t\t\tdh01.nro_docum,\r\n\t\t\t\t\t\tLPAD(dh01.nro_cuil1::varchar, 2, ‘0’) || LPAD(dh01.nro_cuil::varchar, 8, ‘0’) || dh01.nro_cuil2 AS cuil,\r\n\t\t\t\t\t\tLPAD(dh01.nro_cuil1::varchar, 2, ‘0’) || ‘-’ || LPAD(dh01.nro_cuil::varchar, 8, ‘0’) || ‘-’ || dh01.nro_cuil2 AS cuil_desc,\r\n\t\t\t\t\t\tdh01.tipo_sexo,\r\n\t\t\t\t\t\tdh01.fec_nacim,\r\n\t\t\t\t\t\tdh01.nro_ficha,\r\n\t\t\t\t\t\tdh01.tipo_estad,\r\n\t\t\t\t\t\tdh01.nombrelugarnac,\r\n\t\t\t\t\t\tdh01.periodoalta,\r\n\t\t\t\t\t\tdh01.anioalta,\r\n\t\t\t\t\t\tdh01.periodoactualizacion,\r\n\t\t\t\t\t\tdh01.anioactualizacion,\r\n\t\t\t\t\t\tdh09.codc_estcv,\r\n\t\t\t\t\t\tdh09.fecha_…SIGUE…, referer: http://10.20.15.220/siu/mapuche/aplicacion.php?ah=st5ad74695163e82.91073204&ai=mapuche||67000013

Adjuntamos imagen.

Quedamos pendientes de cualquier novedad.

Desde ya muchas gracias.


m3.4.4_3.4.5implistado.png

m3.4.4_3.4.5implistado.png

m3.4.4_3.4.5imppdf.png

m3.4.4_3.4.5imppdf.png

m3.4.4_3.4.5impxml.png

m3.4.4_3.4.5impxml.png

Buenas,

El primer problema viene por la falta de memoria, prueben subiéndole la memoria a 3 o 4 gigas (tienen 12 les quedan 8 para el SO).
Porque el 2do problema puede venir derivado del primero .

Cuantos legajos quieren mandar a imprimir?

saludos

Hola Miguel, gracias por responder.

Aumentamos el límite de memoria por script (memory_limit) a 3GB y al parecer el módulo funciona, pero funciona muy lento y notamos que el consumo es casi de 2.5GB RAM por script. Por cada cambio de página (para ver los agentes de la página siguiente o anterior) o solicitud de impresión el sistema queda procesando al menos 1 minuto. En algunos casos el PDF no se genera, pero tampoco muestra errores.

Consideramos que es un límite muy alto por script, si tuviésemos cinco scripts corriendo en paralelo, pero a su vez son independientes entre sí, tendríamos 5x2.5GB igual a 12.5GB, al menos dos scripts fallarían o al menos los procesos de dos usuarios fallarían.

El módulo de Formulario Anual de Impuestos a las Ganancias funciona muy rápido. El tiempo que lleva traer el listado es de 11segundos y la descarga correspondiente a un agente es instantánea. El cambio de página (ver agentes de la página anterior o siguiente) es instantánea. El consumo promedio de este módulo es de 350MB.

El módulo de Formulario Mensual de Impuestos a las Ganancias funciona muy lento. El tiempo que lleva traer el listado es de 127segundos (2:07min), seleccionar un mes de un agente tarda 10segundos (dejar de mostrar “Procesando” en la parte superior), hacer clic en el botón imprimir y que muestre la ventana emergente tarda 20segundos, otros 15 segundos más para terminar de mostrar el contenido de dicha ventana (dejar de mostrar “Procesando” en la parte superior), 10 segundos para generar el PDF. Cambiar de página (ver agentes de la página anterior o siguiente) 20 segundos. El consumo promedio de este módulo es de 2.2GB.

Quedamos atentos a cualquier novedad. ! Muchas Gracias ¡

Hola Marcelo,

El problema uds lo tienen en la cantidad de datos que filtran, con el formulario mensual lo que tienen que tener en cuenta es que realiza muchos cálculos por mes por legajo, en esto es distinto al formulario anual que es muchísimo mas rápido.
Si utilizan los filtros para traer menos datos el formulario va a andar mucho mas rápido (lo que es lógico), tengan en cuenta que si tienen para mostrar 1000 paginas la búsqueda arrojo 24000 registros, y cada uno de esos registros (que son meses) tienen que hacer sus cálculos. Luego cuando se va a imprimir para no hacer todos los cálculos nuevamente se guardan los datos en memoria para poder obtenerlos de la nueva ventana que se abre.

Quedaría como pendiente analizar si se pueden paralizar los procesos de cálculos,

Saludos
Poli

Hola Poli, buen día, muchas gracias por responder.

Comprendemos lo que expresas, solo que al probar los módulos con las configuraciones que establece el instalador, memoria, codificación, etc., notamos que el módulo de Formulario Mensual fallaba.

Estableceremos un nivel alto de memory_limit para evitar este inconveniente.

Paralelizar los procesos de cálculos es buena idea.

Concientizaremos a los usuarios sobre el módulo y que filtren lo máximo posible, que eviten el filtrado por año y sean más específicos con los agentes.

Muchas gracias por su tiempo. !Saludos¡