basquetWi + New ticket
movilba MOVILBA-81

CONTESTADO por Eugenia: expediente vacio y la frase a Observaciones - 474 celdas, regla de import en el ultimo evento

Done normal dmdb03-mba-l-ca

Elazar decision: prose in SSOT Expte. Alta or Expte. Baja, including Se modifican datos a pedido de la empresa, is Eugenia source data and is NOT an import error, column shift, or reason to omit/transform it. For historical MovilBA rows, import the literal value into the corresponding expediente field. The open/current projection follows the open source row; closed-row prose belongs to history. The unresolved work is stakeholder clarification of the convention and whether the source should ever be changed, not a database cleanup. The tracker holds four explicit questions, with the 50 open Expte. Alta cases separated from closed history.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 2026-08-20
  • wi-cli-venus commented · 2026-08-20
    MEDIDO INDEPENDIENTE por coder02 y COINCIDE con db02: 271 en Expte. Alta + 203 en Expte. Baja = 474 exactas, string literal unico 'Se modifican datos a pedido de la empresa', no una familia de frases parecidas. TRES NUMEROS NUEVOS: (1) 50 de esas 474 estan en la FILA VIGENTE - MovilBA muestra hoy esa frase donde va el expediente para 50 colectivos activos, eso lo vuelve urgente y no archivo. (2) La misma frase aparece 2870 veces en Observaciones, que es donde corresponde - ya no es hipotesis de corrimiento de columna: la frase TIENE su columna y en 474 celdas se cayo a la de al lado. (3) Sobre 7574 celdas de expediente con contenido es el 6 por ciento. La fila E-020 de Eugenia dice EXPLICITAMENTE que las resoluciones NO estan incluidas y que no le pedimos nada sobre ellas - sin esa aclaracion miraria las columnas y 'arreglaria' 515 celdas legitimas. No se propone valor: no tenemos de donde sacar el expediente de cada una; la pregunta es de donde se puede sacar y que poner si para algunas no existe.
  • wi-cli-venus commented · 2026-08-20
    BARRIDO AJ/AK/AL HECHO (audit, filas 3-5088): el UNICO solapamiento exacto entre Observaciones y cualquiera de las dos columnas de expediente, y el unico valor con forma de prosa en AK/AL, es 'Se modifican datos a pedido de la empresa' - 271 en Expte. Alta y 203 en Expte. Baja, ya contadas. NO se encontro ninguna otra huella de desplazamiento desde AJ. CONSECUENCIA SOBRE LA HIPOTESIS: yo (coder-mba-l-cc) llame a esto 'firma de corrimiento de columna' basandome SOLO en la adyacencia AJ->AK/AL, que era inferencia y no medicion. Con una sola frase desplazada y ningun otro valor arrastrado, la lectura de 'corrimiento sistematico de columna' se DEBILITA y la de 'alguien tipeo repetidamente en la casilla equivocada' se fortalece. No esta probada ninguna de las dos; lo unico medido es que una frase, la mas frecuente de AJ (2870), aparece 474 veces en sus dos columnas vecinas y ninguna otra lo hace. La conclusion practica no cambia: dos campos de texto libre adyacentes juntaron 474 valores mal puestos, asi que no reproducir esa adyacencia en nuestra UI.
  • wi-cli-venus commented · 2026-08-20
    REPORTADO POR db03-mba-l-ca 2026-08-20: dice que Elazar confirma que las 203 ocurrencias en Expte. Baja (AL) son SOP INTENCIONAL del equipo que mantiene el libro, NO un corrimiento de columna ni un defecto de import. Si se confirma, NO son un error, NO hay que tratarlas como tal y NO hay que crear un campo de workaround. PENDIENTE DE CONFIRMAR DIRECTAMENTE CON ELAZAR antes de cerrar: llego por relevo de un agente, no de su boca a este carril, y cambia la naturaleza del ticket (de defecto de dato a convencion del libro). Ojo que el ticket cubre 474 = 271 en Expte. Alta + 203 en Expte. Baja: la afirmacion cubre explicitamente las 203 de AL y NO dice nada de las 271 de AK.
  • wi-cli-venus commented · 2026-08-20
    CONFIRMADO EN DEV, y confirma el origen: AG358KX (vehiculo 4453) tiene dos filas con el texto de observaciones metido en la columna de expediente - fila 7938 con expte_alta='Se modifican datos a pedido de la empresa' y fila 7939 con expte_baja con el mismo texto. db-mba-l-cc lo verifico byte a byte contra rutap.v_rutap_latest_norm filas_excel 1103 y 1104: EL LIBRO TRAE ESE VALOR EN LA CELDA DE EXPEDIENTE. No lo corrompio nuestro import - alguien pego el texto en la columna equivocada en el archivo de origen. O sea que este ticket NO se arregla del lado nuestro sin decidir antes que hacemos: pedirle la correccion a Eugenia en el libro, o normalizarlo en la importacion (y ahi hay que definir si el valor se descarta, se mueve a observaciones, o se deja como esta). Es una pregunta para Eugenia, no una limpieza que podamos decidir solos, porque el SSOT es su Excel. Encontrado de paso mientras Elazar preguntaba que decia una Modif de AG358KX.
  • wi-cli-venus verified · 7w ago
    DEV read-only recheck 2026-08-28 (current rutap.v_rutap_latest snapshot_id=7): 472 rows, not the original 474, contain exact observations text 'Se modifican datos a pedido de la empresa' in expediente columns; 271 expte_alta, 203 expte_baja, 2 both, across 269 domains. This is source/book data quality; no database mutation performed. First affected source row: fila 398 / Excel 400, AF393PB, expte_baja. Authoritative correction remains required before any import repair.
  • wi-cli-venus assigned · 7w ago
    db02-mba-l-ca / db
  • wi-cli-venus verified · 7w ago
    CORRECCION DE REDACCION (db02-mba-l-cc 2026-08-28, confirmado por db-mba-l-ca que emitio la medicion original): el evento previo dice '472 rows, not the original 474', que se lee como si el libro hubiera perdido dos filas. NO ES ASI. 472 y 474 son la MISMA realidad contada con dos claves distintas: 472 FILAS afectadas, 474 CELDAS afectadas. Reproducido de forma independiente sobre DEV rutap.v_rutap_latest snapshot_id=7: 472 filas, 269 dominios, 271 en expte_alta, 203 en expte_baja, y 2 filas que traen el texto en LAS DOS columnas -> 271+203=474 celdas sobre 472 filas. El conteo original de 474 (snapshot 4) contaba celdas y era correcto. No hay evidencia de que el libro haya cambiado entre snapshot 4 y 7 en este eje. Sigue vigente lo demas: 50 de esas filas son la fila VIGENTE del dominio, o sea que MovilBA hoy muestra prosa donde va el expediente para 50 vehiculos activos. El blocker no cambia: hace falta la correccion autoritativa en el libro.
  • wi-cli-venus assigned · 7w ago
    db02-mba-l-cc / db
  • wi-cli-venus note · 7w ago
    RELEVO DE CARRIL Y CIERRE DE UN LOOP ABIERTO DESDE EL 08-20 (db02-mba-l-cc, 2026-08-28). El item pasa de db02-mba-l-ca (retirado hoy) a db02-mba-l-cc. Antes de retirarse le pregunte EXPLICITAMENTE por el punto que mas cambia el alcance y respondio: NO recibio confirmacion directa de Elazar de que las 203 ocurrencias en Expte. Baja sean SOP intencional del equipo que mantiene el libro. O sea que el comentario del 08-20 - que llego por relevo de db03-mba-l-ca y ya venia marcado como PENDIENTE DE CONFIRMAR - sigue SIN confirmar ocho dias despues, y nadie lo verifico en el medio. CONSECUENCIA OPERATIVA: NO se puede angostar este item a las 271 de Expte. Alta, y no se toca ninguno de los dos grupos apoyandose en esa afirmacion. La verdad segura sigue siendo 472 filas / 474 celdas afectadas sobre 269 dominios, preservando la fuente exactamente. Lo que destraba el item es una decision autoritativa externa sobre tratamiento/convencion - de Elazar o de Eugenia -, no una medicion nuestra: ya esta medido. Nota de metodo: una afirmacion relevada que cambia la naturaleza de un ticket (de defecto de dato a convencion del libro) tiene que confirmarse en la voz de quien decide antes de usarse; esta sobrevivio ocho dias como si fuera un hecho.
  • wi-cli-venus priorityChanged · 6w ago
    0
  • wi-cli-venus note · 6w ago
    Elevado a prioridad 0 = espera decision de Elazar. Lo unico que hace falta: confirmar si las 203 ocurrencias de texto en Expte. Baja son convencion intencional del libro. Esa afirmacion llego por relevo el 2026-08-20 ya marcada como pendiente y nunca se confirmo con Elazar - 11 dias. Si es intencional el item se parte al medio; si no, no se angosta.
  • wi-cli-venus verified · 6w ago
    Re-medido el 2026-09-01 contra el libro aprobado 2026-09-01-1440-parque-rutap.xlsx, partiendo cada fila por estado (Fecha_Baja null = abierta). Hallazgo de db02-mba-l-cc, confirmado independientemente por coder02-mba-l-cc: Expte. Alta 271 filas = 221 cerradas + 50 ABIERTAS sobre 50 dominios distintos; Expte. Baja 203 filas, las 203 cerradas. Total 474. O sea que 50 colectivos VIGENTES tienen hoy un expediente de alta que no es un expediente - no es solo historia cerrada, como veniamos diciendo. NO bloquea el import: expte_alta/expte_baja son texto sin tipar (MOVILBA-39), el valor del libro entra verbatim y reescribirlo seria el defecto. Es calidad de dato y pregunta para Eugenia. Preguntado por primera vez el 20/08, sin respuesta. Escrito en la hoja Para Eugenia, asunto 49, con los 50 dominios nombrados.
  • wi-cli-venus titleChanged · 6w ago
    RUTAP expediente prose convention: preserve verbatim; questions for Eugenia
  • wi-cli-venus descriptionChanged · 6w ago
    was: Medido por db02-mba-l-cc 2026-08-20 sobre snapshot 4, denominador 5086. El valor 'Se modifican datos a pedido de la empresa' aparece 474 veces como expte_alta y expte_baja. Es texto de observaciones en una columna de instrumento legal - corrimiento de columna sistematico en el libro, no un typo. DISTINTO de las 515/487 celdas que no empiezan con EX: la mayoria de ESAS son RESOLUCIONES legitimas (Res. SECT, cesiones, fusiones, bajas de oficio) y no se tocan. Va a la hoja de Eugenia. El backfill de MOVILBA-76 paso 2 NO debe escribir estos 474 como si fueran instrumentos.
  • wi-cli-venus decision · 6w ago
    Elazar: treat prose in Expte. Alta/Expte. Baja as valid SSOT convention. Preserve it verbatim in historical expediente fields; never report its presence alone as an import defect.
  • wi-cli-venus decision · 6w ago
    Elazar decidio (2026-09-01, relayado por db03-mba-l-ca): 'Se modifican datos a pedido de la empresa' en Expte. Alta / Expte. Baja es una CONVENCION VALIDA DE ORIGEN de Eugenia, no un error de import ni un corrimiento de columna. Se preserva VERBATIM en el campo de expediente historico correspondiente. No se marca, no se transforma, no se omite, y su presencia NO cuenta como drift de import solo por ser prosa. Esto INVALIDA la premisa con la que se abrio este item: la descripcion dice 'corrimiento de columna sistematico en el libro' y eso queda retractado. No es texto de observaciones metido en la columna equivocada; es como ella documenta ese tramite. Medicion contra el libro aprobado 2026-09-01-1440 (db02-mba-l-cc, hoja Base, header fila 2, 5319 filas): la frase aparece 271 veces en Expte. Alta (221 cerradas + 50 ABIERTAS) y 203 en Expte. Baja (203 cerradas, CERO abiertas). El total de 474 del titulo se sostiene, pero el corte que importa es por estado de fila, no el agregado. Consecuencia para el modelo, que sigue en pie despues de la decision: en vehiculo_historial la prosa va verbatim en las filas que la traen. En vehiculos_datos_colectivos, que es estado corriente derivado de la fila ABIERTA, expte_baja queda NULL en los 203 casos (ninguno esta abierto) y expte_alta SI recibe la frase en los 50 dominios vigentes que la tienen. Preservar verbatim no cambia de que FILA se deriva el estado corriente. Sin trabajo pendiente: PROD ya guarda la frase en expte_alta de esos 50 y no la tiene en expte_baja de ningun vigente. Nada que escribir.
  • wi-cli-venus priorityChanged · 6w ago
    2
  • wi-cli-venus note · 6w ago
    Baja de p0 a p2: p0 significa bloqueado-en-Elazar y Elazar ya decidio hoy. No queda decision suya pendiente aca. Lo que sigue abierto es la pregunta de calidad de dato para Eugenia sobre los 50 dominios VIGENTES que tienen prosa en Expte. Alta - ya escrita en su tracker (asunto 49, coder02) - y eso no es un bloqueo nuestro ni justifica p0.
  • wi-cli-venus questionAnswered · 6w ago
    CONTESTADO por Eugenia, recogido del tracker el 2026-09-02 y confirmado por Elazar en CLI. Respuesta textual en la columna 'Tu respuesta': 'Si, dejar vacia y colocar texto en Observaciones'. REGLA DE IMPORT RESULTANTE (medida sobre 2026-09-01-1440, 472 filas / 474 celdas): 1. expediente_alta / expediente_baja = NULL donde la celda del libro sea exactamente 'Se modifican datos a pedido de la empresa'. 271 en Alta (50 de fila vigente) + 203 en Baja (todas cerradas). 2. observaciones = la celda Observaciones del libro, sin tocar. Nunca se appendea ni se pisa. 3. Solo donde la Observaciones del libro esta VACIA se escribe la frase. Los tres baldes, porque 'mover el texto a Observaciones' a secas escribe mal 318 de 472: 300 Observaciones YA tiene esa frase -> no se toca (escribirla otra vez la duplica) 154 Observaciones VACIA -> se escribe. Es el unico balde que recibe un write. 18 Observaciones con OTRO texto -> se deja como esta, NO se appendea. El criterio de los 18 es una decision, no una medicion: la regla permanente de Elazar es que observaciones coincida con el libro, y appendear los haria diferir de la fuente por una nota generica que no agrega informacion. 18 filas, reversible. ALCANCE: la respuesta cubre SOLO esa frase. Los otros valores que tampoco son expedientes siguen como estan y los resuelve MOVILBA-184 en la UI: 'Res. SECT 56/2026' (38), 'Segun Planilla presentada por la empresa' (6), 'Se modificaron datos a solicitud de la empresa' (10). Preguntado el 2026-08-20, contestado el 2026-09-02.
  • wi-cli-venus statusChanged · 6w ago
    Contestado por Eugenia. La regla de import esta escrita en el ultimo evento; ejecuta db03 bajo MOVILBA-155.
  • wi-cli-venus titleChanged · 6w ago
    CONTESTADO por Eugenia: expediente vacio y la frase a Observaciones - 474 celdas, regla de import en el ultimo evento
  • wi-cli-venus assigned · 6w ago
    db03-mba-l-ca / db
  • wi-cli-venus completed · 5w ago
    Business question answered by Eugenia and import rule recorded. Execution belongs to MOVILBA-155; this decision item has no independent work remaining.
bug
2026-08-20 by wi-cli-venus
5w ago
2026-09-10 14:48