Al arrancar produccion, expediente_alta y expediente_baja solo aceptan un numero de expediente: validar formato en formulario y servidor
Decision de Elazar, 2026-09-01. Las tres cosas conviven y no se contradicen: 1. IMPORT (ahora): la frase 'Se modifican datos a pedido de la empresa' que el libro trae en Expte. Alta / Expte. Baja se guarda VERBATIM. No se transforma, no se omite, no se marca como drift. Es la convencion de origen de Eugenia hasta que ella conteste. 472 filas / 474 celdas medidas sobre 2026-09-01-1440: 271 en Expte. Alta (50 de ellas en fila VIGENTE) y 203 en Expte. Baja (todas cerradas). 2. PREGUNTA (abierta): la pregunta 1 del tracker de Eugenia sigue en pie - si podemos dejar esas dos celdas vacias y quedarnos la frase en Observaciones. Su respuesta puede cambiar el punto 1; hasta entonces no cambia nada. 3. ESTE ITEM (al arrancar): desde el dia que MovilBA entra en produccion, expediente_alta y expediente_baja SOLO ACEPTAN UN NUMERO DE EXPEDIENTE. Prosa libre deja de poder entrar por la app. ALCANCE DE ESTE ITEM - lo escrito a mano de aca en adelante, NO lo ya importado. Los datos historicos quedan como estan (punto 1); esto gobierna la escritura nueva. QUE HAY QUE HACER: - Definir el formato aceptado. Lo observado en el libro es EX-AAAA-NNNNNNNN- -GCABA-DGGSM, con variantes reales que hay que decidir si se aceptan o se normalizan: minuscula 'Ex-2025-29950556' existe en el libro, y hay doble espacio entre los guiones. Sin un formato escrito no hay validacion posible. - Validar en el formulario (mensaje claro al usuario) Y en el servidor. Solo cliente no alcanza. - NO poner un CHECK constraint en la columna sin resolver antes que pasa con las 474 celdas historicas que no cumplen: un CHECK las volveria no actualizables. Si se quiere constraint, va con NOT VALID o filtrado por fecha. - Cubre las dos columnas y toda pantalla que las escriba (ver MOVILBA-46 / MOVILBA-168, que unifican los caminos de edicion). MEDICION DE HOY, por si sirve de gate: expediente_alta en PROD tiene 2121 celdas no vacias de 2388.
Activity
-
Un gate de FORMATO no alcanza, y hay un caso medido que lo prueba. AC966VL: el libro trae 'Res-SECT-2025-214 Cesion T.GUIDO/TARSA' en una fila y 'Res. SECT 214/2025' en la siguiente; PROD guarda 'Res-2025-214-GCABA-SECT', la misma resolucion en un tercer formato que el libro NUNCA usa. Tiene forma de resolucion valida y pasaria cualquier validador que yo escriba en este item. Conclusion: hacen falta DOS gates y no se sustituyen. 1. Este item: gate de FORMA sobre lo que un usuario ESCRIBE en la app de aca en adelante. 2. Import (MOVILBA-155/180): gate de VALOR - cada expediente que se persiste tiene que existir en alguna celda del libro vigente. Es lo unico que detecta un valor que tiene forma correcta y no esta en la fuente. El test que hay que usar para (2) ya esta probado: membresia contra las 24958 celdas distintas de TODAS las hojas del workbook. Corriendolo sobre las dos columnas de expediente aparecieron 40 celdas de PROD ausentes del libro vigente, 39 de ellas sobrevivientes de un export de diciembre 2025.
-
coder03-mba-l-cc
-
Gate de formato shippeado a dev v5.4.118 (89ced9b6). EX- canonico (EX-AAAA-NNNNNNNN-GCABA-dependencia) via services/vehiculos.ts createColectivo (unico camino de escritura vivo - updateColectivo no persiste expediente aun, registrarExpediente esta muerto). Cliente + servidor, normaliza antes de rechazar. Verificado contra las 3814 celdas no vacias de expte_alta en DEV: 3431 validas, 383 rechazadas (3 basura preexistente + 38 EX- con contaminacion real tipo AC966VL, resto Res/Resol fuera de alcance por decision).