Detalle de la Implementación de las aplicaciones

A continuación se detalla la estrategia de desarrollo para la implementación de las aplicaciones desarrolladas.

kiwi.juscaba.jusbaires gov.ar (Interoperabilidad CMCABA/MPF)

La interoperabilidad está desarrollada en una aplicación autónoma denominada “juscaba2” que implementa por sí nuevamente las reglas de negocio requeridas para la interoperabilidad utilizando código original de la aplicación JusCABA. Esto significa que los cambios que deban realizarse para el funcionamiento de JusCABA deben trasladarse al código de JusCABA2 también, para así mantener la integridad de la información en la base de datos.

La interoperabilidad de documentos XML se realiza para las entidades de:

• caso/expediente
• denuncia
• cédula
• audiencia

Para todos los objetos intercambiados anteriormente, la interoperabilidad incluye las siguientes entidades XML:

• persona
• domicilio
• artículo
• infracción

El intercambio de documentos se realiza a través de una interfaz REST que debe ser iniciada por el cliente, en este caso el sistema Kiwi. Este deberá producir un documento UTF-8 compatible y dirigirlo a la URL kiwi.juscaba.jusbaires.gov.ar con los siguientes parámetros:

El documento que ingresa a la interfaz deberá tener una estructura similar a la siguiente para los casos judiciales llevados por el MPF que se convierten en expedientes en JusCABA:

 

 

el documento XML en respuesta será similar al siguiente:

Ambos documentos son a modo de ejemplo y no tienen correlación entre sí.

A través del módulo de auditoría se puede inspeccionar el díalogo en línea entre la aplicación Kiwi y JusCABA, ver los accesos que se producen y de dónde como así también los mensajes de error que se puedan presentar. Para acceder al módulo mencionado se deberá acceder a la URL:

http://kiwi.juscaba.jusbaires.gov.ar/?m=audit

 

Módulo if_kiwi para la interoperabilidad de casos, denuncias, cédulas y audiencias

La estrategia general de la implementación de la interoperabilidad es recorrer un XML y asignar los valores a los objetos impactados en el proceso de la base de datos de JusCABA. En particular, para cargar un nuevo caso que se converte en expediente, al recorrer la entidad “caso” provista por el MPF, este generará un nuevo expediente. El módulo if_kiwi (interfaz kiwi) reemplaza al módulo  cr_forma original del diseño inicial de JusCABA, cuando el MPF realizaba las denuncias vía esa herramienta.

Validaciones de datos aplican para todas las instancias. En primer lugar la interoperabilidad realizar una validación a nivel de XML de los datos recibidos, como ser, que exista un artículo en la denuncia, que existan denunciados, etc. Esto puede modificarse en la instancia del objeto if_kiwi en el proceso if_kiwi_exped:

Como se verá en el código anterior, hay tres métodos significativos para la validación de las variables recibidas en el documento XML:

1. por simple evaluación de valores en las variables;
2. por lookups en base de datos con la función load() para evaluar el valor de una clave foránea en una tabla accesoria;
3. por queries vía la función XSL xpath() para evaluar la existencia o no de elementos XML necesarios para la interoperabilidad.

Para la remisión de un documento XML con un caso, la sucesión de llamados de variables entonces sería la siguiente:

Campos PMJ

Para la resolución de claves foráneas no contempladas intrínsecamente dentro del documento recibido, se ha implementado una serie de valores comunes entre ambos sistemas para su referencia. Esta combinación de valores constantes en formato de cadena de caracteres ha sido combinado entre ambos organismos y así brindar una lingua-franca entre ambos sistemas, que pudieran hablar de lo mismo. Los campos PMJ aparecen en los siguientes objetos/tablas de los sistemas:

• Tipo Causas
• Tipo Pasos Procesales
• Artículos
• Materias
• Tipos de Documentos
• Tipos de Actores
• Comisarías
• Actores Legales
• Nacionalidades (implementa el código alfa-2 de la estandarización ISO-3166-1)
• Calles (realiza un macheo entre Google Maps y el callejero de la CABA)
• Zonas
• Localidades
• Tipos de Domicilios

Para la identificación de las personas involucradas los sistemas intercambian un hash único de 32 caracteres para poder identificar múltiples NN de los cuales no se tengan aún datos y así poder identificar unívocamente a las personas involucradas. Una vez resuelta su identidad definida, se solapa la información con el registro de la persona identificada.

Identificación de infracciones y sus artículos

Para la identificación de los artículos de las leyes que indican las infracciones denunciadas, se ha elaborado un código único de identificación de artículos con la siguiente nomenclatura:

identificando así la jurisdicción, la ley y el artículo, incisos y capítulos, por ejemplo:

Diferencias entre Kiwi y JusCABA

Si bien partieron de un mismo desarrollo ambas aplicaciones no comparten el modelo de base de datos por lo que hubo que realizar una correspondencia completa entre ambas aplicaciones en lo que respecta al espacio de nombres de ambos sets de datos: estas diferencias requieren modificaciones en ambas aplicaciones son fundamentales para la identificación de los actores particulares:

En particular, JusCABA no tiene la habilidad de identificar las infracciones por cada uno de los actores, mientras que Kiwi lo hace. Esto sucede por ejemplo cuando hay delitos colectivos y los participantes tienen distintos roles. La interoperabilidad resuelve estas diferencias y pone los datos como los acepta JusCABA.

Georreferencia de las infracciones

Kiwi incorpora entre sus funciones un mapa del delito, para ello incorporó herramientas de Google Maps y así proveer valores para latitud y longitud. Es por esto el motivo principal del por qué de la utilización de callejeros diferentes. Como beneficio de esa decisión, Kiwi envía latitud y longitud de la georreferencia de la infracción, datos que no podían faltar en JusCABA. Para ello se modificó la base de datos en particular de la tabla denuncia agregado los valores correspondientes. JusCABA debe aprovechar valiosa información e incorporar su propia georreferencia.

Otros datos personales

Kiwi registra también información sobre email y redes sociales del involucrado, esta información no está implementada aún en la interoperabilidad.

Roles y usuarios judiciales entre las aplicaciones

Si bien todas las transacciones se hacen a través de un solo usuario “kiwi” la interoperabilidad debe recrear el perfil del usuario tal como si lo estuviera escribiendo sobre la interfaz de JusCABA: el método de la clase if_kiwi usuario_efectivo() realiza la operación de transposición de identidad y la asigna al usuario actuante que está en la variable global $xpdoc:

Macheo entre Google Maps y el callejero de la CABA

Ciclópea tarea hubiera sido a mano realizar el macheo uno por uno de las calles de un callejero y otro, principalmente por que está alterado el orden de los nombres, tal como se comentó anteriormente. Para ello se desarrolló la función busca_calle() que trata de machear entre ambos callejeros:

Si la calle es encontrada por su PMJ y hay un solo resultado, la función devuelve el ID de la calle tal como lo necesita JusCABA. En caso de no encontrarse, la función hace un split entre los componentes del nombre, es decir, separa las palabras entre ellas, por ejemplo, para la calle “MARIA ANTONIA DE LA PAZ Y FIGUEROA” (para el callejero de la ciudad la mencionada calle se llama “DE LA PAZ Y FIGUEROA, MARIA ANTONIA”) dividirá la consulta en un array de LIKE en combinación con operadores AND:

Nótese que los resultados están ordenados por el más largo primero, esto indica que la primera calle es la mejor candidata. Configurado de tal forma, la aplicación puede asignar automáticamente este primer resultado al PMJ e señalar en el campo “revisar” que la asignación ha sido automática y debe ser cotejada por un operador para resolver las referencias. Cabe señalar que por algún motivo en particular, los strings de las calles de Google Maps enviados por el Kiwi alternan entre mayúsculas y minúsculas, aunque esto no altera la operación del algoritmo, sin embargo en los listados de calles por su PMJ se nota esta diferencia.

La función busca_localidad(), también implementada, contiene un algoritmo similar.

Fechas de ingreso vs. flagrancia

Junto con la identificación de los involucrados y la privacidad de este dato,  las fechas de ingresos de causas resulta crítico para la conversión de casos en causas en expedientes. La ley indica que

si el hecho es flagrante, la fecha fecha del hecho será tomada para el sorteo del juez
caso contrario se tomará la fecha de la denuncia del caso en la comisaría interviniente

Esa distinción entonces se opera a través de la siguiente línea de código:

Sorteo de causas en el fuero CyF

 

El algoritmo realiza los siguientes pasos:

• Habiendo flagrancia, se toma la fecha del hecho
• Caso contrario se toma la fecha de ingreso
• Se identifica la zona asociada a la fiscalía interviniente
• Si es menor, sortea sobre la tabla “turno_juzgado_juvenil”
• Si no lo es, sortea sobre la tabla “turno_juzg”
• Se realiza la búsqueda y se obtiene el juzgado con los parámetros zona, fecha_inicio

 

 

Identificación de menor sobre el documento XML de la transacción

La identificación del menor se realiza a través del descubrimiento de valores vía XPATH sobre el documento XML:

Estos fragmentos de código se encuentran repartidos entre la funcion if_kiwi_exped() y los métodos del objeto “exped”

Incorporación de Actores Judiciales al Expediente

Una vez recibido un caso dentro del proceso de la interoperabilidad y habiendo una o más denuncias asociadas al caso, el primer actor a incorporar con el rol manifiesto resulta ser la comisaría, luego la fiscalía interviniente, las UIT y UTE, la Fiscalía General y por último se sortea el juzgado. Toda esa regla de cómputo es seleccionar adecuadamente a los actores del MPF que intervienen en la causa, JusCABA asigna todos los actores judiciales, inclusive lo que están fuera de su órbita funcional. Si bien esto resulta razonable, el algoritmo en realidad debería recibir los actores que remite el Kiwi y validar si son los correctos. Paradójicamente resulta más dificil realizar lo segundo que lo primero ya que se requiere de un mapeo completo de la regla computacional detrás de todos los actores y el mapa judicial en la seleección de su competencia.

La implementación actual se realiza entonces a través de una cadena recursiva de guardar (store) actor_rol que se encadenan de la siguiente forma:

Recursividad en la selección de los actores judiciales

Esta tarea la realiza el método actor_rol.post_check(): una vez que haya sido cargado el primer actor, en este caso la comisaría, la función que se ejecuta luego de grabar el actual actor_rol. Ahí comienza entonces la recursión a través de un “switch” que puede generar nuevos actores y así sucesivamente, hasta que no se agreguen nuevos integrantes. En el caso de victimas, damnificados, denunciantes la determinación se realiza fuera del “switch” consultando si la persona es menor o incapaz. Para todos los casos se incorpora al coordinador fiscal. Por último, si el actor judicial es ingresado en forma manual e interactiva dentro de JusCABA, se agrega un paso adicional denominado “AFECTAR_ACTOR_LEGAL” anunciando a las partes intervinientes que se a agregado un nuevo actor, con fecha y hora de su incorporación:

Mantenimiento de tablas de sorteos de juzgados

Se deben mantener en buena salud las tablas de sorteo de juzgados, no pueden faltar datos en el vértigo del código ejecutándose. En caso de no haber un turno, la “pelota” quedará del lado del CMCABA hasta tanto intervenga un administrador de la aplicación a resolver el inconveniente, ya que no puede rechazar la transacción en tanto y en cuanto el Kiwi haya remitido correctamente toda la información. Para mantener la tabla de juzgados entonces se debe incorporar:

• un índice único para los juzgados, turnos y zonas
• incorporar los datos a través de un producto cartesiano en SQL para que atomáticamente repita todos los turnos para todos los juzgados
• verificar a través de consultas de rangos de tiempos posibles “gaps” en blanco que no haya cobertura temporal

 

Exped Fix

Juscaba2 incorpora el método “exped_fix()” para reasignar el turno del juzgado a través de la interfaz interactiva, en donde se vuelve a repetir el algoritmo de sorteo con los mismos datos originales. Este algoritmo llama a sorteo_juez() y asigna correctamente la zona y la fiscalía:

 

 

Generación de la Carátula del Expediente

Esta función ha sido redefinida, hubo planteos por parte de los usuarios judiciales sin embargo no hubo un planteo definitivo al respecto durante las reuniones de la Comisión de JusCABA. El motivo del reclamo principalmente se debe a que la interfaz debe generar automáticamente la carátula y ha sido redefinida incluyendo los artículos infringidos. La aparición del artículo en forma normalizada tal como se describió anteriormente pudo haber sido la incomodidad planteada por el área usuaria. Una vez siendo de uso corriente no se tuvo novedades sobre el reclamo. El algoritmo de generación de carátula es el siguiente:

Cierre y conclusión

Se han descripto los aspectos más relevantes de la operación de la interoperabilidad if_kiwi siendo aún menores a la implementación detallada y completa, el resto de las instrucciones resultan más triviales para el programador y están generalmente descritas a detalle en comentarios del código o bien en el código fuente de la implementación.

La interoperabilidad entre el Consejo de la Magistratura y el Ministerio Público Fiscal funcionando ya hace más de dos años resulta ser un hito relevante para un intercambio de información esencial entre las aplicaciones de gestión de justicia de ambas instituciones, iniciativa que ha agilizado la labor de los actores judiciales, aún habiendo dos moles informáticas con criterios diferentes como Kiwi y JusCABA. Como contrapartida, la ausencia de este mecanismo hubiera obligado a abandonar el procedimiento de judicializar una causa al papel, con la perdida de tiempo y ganancia en errores que esto conlleva, dando independencia operativa a la gestión y desarrollo de las principales aplicaciones de justicia en el ámbito de la ciudad de Buenos Aires.