Panel Admin: Implementar Operaciones CRUD para Fiscales y Conectar con Endpoints about sistema-anti-fraude-electoral

[gcsis]

Tiro esto acá, porque considero EMHO es x donde se debe enfocar en el diseño del BE (cuento con expertise en BE dev de cómputos electorales).

Estimo debajo un mínimo esta estructura de datos (si se adopta relacional).

Concuerda con las columnas del .csv del sistema Electoral Nacional para poder comparar y detectar desviaciones para denuncias con datos reales y concretos, general y a nivel de mesas.

Estructura de los datos

Estas entities deben contar c/u con su correspondiente CRUD, mas allá de los entry controller especializados q se requieran.

province  ( id, name ) --> es la provincia o CABA
|
|__>> section  ( id, name ) --> Es la sección electoral 
          |
          |__>> district  ( id, name ) --> Es el distrito / municipio / departamento
                    |
                    |__>> circuit  ( id ) --> Es el circuito electoral en el distrito 
	                      |
	                      |__>> table  ( id, v134, v135, vtot, vblank ) --> Es la mesa de votación
		                        |	
		                        |___>> 
                                   _______>>  fiscal_table  ( fiscalId, tableId ) -->> relacion M:M de fiscales de mesas  
	                          |
 	                          |
	                          fiscal  ( id, DNI, telefono, [userId] ) -->> Cada fiscal, persona física (DNI Unique Key)
                      

La tabla "fiscal_table" permite asociar 1 fiscal (o mas) x cada mesa o viceversa.

Aclaración conceptual de CIRCUITO para la detección de Fraudes en c/mesa:

El CIRCUITO es una zona geográfica que no siempre coincide con el concepto de localidad (puede contener mas de una o ser parte de una). Es definida por la Justicia Electoral y divisoria dentro de cada distrito, para contener una cierta cantidad de mesas en donde los votantes empadronados, están ORDENADOS ALFABETICAMENTE. Es decir que dentro de un circuito los promedios de votos resultantes de cada lista política son prácticamente idénticos y están dentro de un "desvío aceptable" o tolerancia.

Lo importante en esto es que, una vez cargada cierta cantidad de mesas, y a los fines de controlar la posibilidad de fraudes, es que conociendo el promedio de votos del partido político XX en un circuito NNNN, no debe haber diferencias importantes en los promedios entre una y otra mesa.

Por ej. si en el circuito 00085 de la mesa 412 de Bahia Blanca hay 40% de votos para LLA y 60% para UXT, pero el PROMEDIO calculado para todo ese circuito es de 52% LLA y 48% UXT, es una mesa con mucha probabilidad de fraude/error del telegrama, y por ende hay que pedir la reapertura de urna, en el turno con la justicia electoral.

Como orientación de su efecto en el FE (no es mi expertise) , con esa dispersión o "diferencia" respecto a la media, debería establecerse una tolerancia (x ej. 15%) desde la que se alerta y/o "colorea" esa mesa para identificarla visualmente en los lists. Se me ocurre que debajo de esa tolerancia es verde, y se va "enrojeciendo" en la medida que la diferencia es mayor.

Por otra parte me parece correcta la decisión de trabajar sobre Nestjs + typeorm para el BE.

Espero haber sido de utilidad y sigo a disposición.

VLLC