210 filas Modif del libro cambian de empresa, y una transferencia deberia ser Baja+Alta
Medido por audit-mba-l-ca sobre el libro (SSOT) el 2026-08-20 14:02, a pedido de Elazar. El modelo de negocio es: cuando un colectivo pasa de una empresa a otra se hace BAJA en una y ALTA en la otra. Bajo ese modelo, una fila Modif NO deberia cambiar de empresa. Hay 210 que si lo hacen. LAS 210 SON REALES, no artefacto de comparacion: las 210 cambian CUIT y las MISMAS 210 cambian Identificador_Empresa, o sea es una sola senial de transferencia contada en dos columnas, no dos cambios independientes. Transiciones principales de CUIT: 33546610719 -> 30545775855 (93 filas), 30545775782 -> 30546500086 (77), 30546227975 -> 33702234269 (39), 30546500086 -> 30567966859 (1). Las tres primeras concentran 209 de las 210: tienen pinta de tres transferencias de flota completas cargadas como Modif en lote, no de errores sueltos de tipeo. CONTRASTE, mismo criterio de fila anterior por fecha: de 213 filas Alta comparables, 76 (35,7%) cambian CUIT y 212 de 213 (99,5%) cambian al menos un campo de negocio - o sea que el cambio de empresa SI se concentra donde el modelo dice, pero no exclusivamente. QUE HAY QUE DECIDIR, y es de Eugenia porque el SSOT es su libro: si esas 210 son transferencias que debieron cargarse como Baja+Alta y hay que corregirlas en el origen, o si Modif tambien se usa legitimamente para transferir y entonces el modelo que nos dieron es mas laxo de lo que suena. No lo decidimos nosotros y no lo normalizamos por nuestra cuenta. IMPACTO EN MOVILBA-95: mientras esto no se resuelva, esas 210 filas Modif van a mostrar un cambio de empresa en el historial de cambios, que es correcto respecto del dato y raro respecto del modelo.
Activity
-
CORRECCION QUE CAMBIA EL ENCUADRE DE ESTE TICKET (db03-mba-l-ca, 2026-08-20 14:33). El titulo dice 'una transferencia deberia ser Baja+Alta' y eso, medido, NO es lo que el libro hace: en RUTAP NO EXISTE NINGUNA FILA tramite='BAJA'. El cierre de un estado se codifica con fecha_baja/expte_baja sobre la fila anterior, no con una fila de tipo Baja. Y la etiqueta de la fila ENTRANTE es inconsistente entre transferencias igualmente genuinas: AD255RK (LOPE DE VEGA -> BARRANCAS, 2025-12-18) figura como Alta, y AE922EH (GENERAL TOMAS GUIDO -> RIACHUELO, 2026-01-01) figura como Modif. El asunto 23 del tracker confirma que las dos son ventas o cesiones reales. CONSECUENCIA: las 210 filas Modif con cambio de empresa NO son necesariamente un error de carga, que es como las plantee al abrir este ticket. Son dato legitimo bajo un vocabulario que no distingue de forma consistente entre reasignacion y transferencia. La pregunta para Eugenia deja de ser 'corregis estas 210' y pasa a ser 'que distingue una transferencia de una reasignacion en tu libro, si la etiqueta no lo hace'. REGLA GENERAL QUE SALE DE ACA: no inferir semantica de negocio solo del valor de tramite. El cambio de empresa se detecta comparando el CUIT contra la fila anterior, no mirando la etiqueta.
-
WRONG COMO ESTA ESCRITO, dictaminado por db03-mba-l-ca 2026-08-21 08:11. El SSOT actual tiene 210 de 2486 filas Modif comparables que cambian CUIT y entidad juntos - la cifra es correcta - pero eso NO prueba dato malo. El libro no tiene ninguna fila con tramite=BAJA, y las transferencias reales conocidas aparecen etiquetadas tanto Alta como Modif. O sea que la etiqueta del tramite no es un campo confiable para inferir que una transferencia deberia haber sido Baja+Alta: es vocabulario de Eugenia sobre un modelo que en realidad son intervalos de validez (ver MOVILBA-99). REESCRIBIR el item como pregunta para Eugenia, no como defecto a corregir, y NO tocar las etiquetas del libro.
-
CONCLUSION (db03-mba-l-ca, read-only, DEV+PROD reproduced from rutap.v_rutap_latest_norm, matches snapshot5 SQLite source): do NOT rewrite the 210 Modif rows to synthetic Baja+Alta. 208/210 are contiguous close-then-open company handoffs (prior row's Fecha_Baja = new row's start), 209/210 keep same line+interno+chasis - a corporate cesion/transfer, not a replacement registration. 4 handoffs: 93 GENERAL TOMAS GUIDO->TARSA, 77 M.O.D.O.->LA NUEVA METROPOL, 39 12 DE OCTUBRE->NUDO, 1 LA NUEVA METROPOL->VUELTA DE ROCHA. Only AG252UZ and PPF407 are non-contiguous and need source confirmation before classifying. Recommended semantics for the refactor: keep tramite=Modif as the source label; derive 'Cambio de empresa' as a DISPLAY classification (predecessor CUIT/entity comparison), never a written source event. cambios.cuit/company JSON cannot be the basis - DEV has only 188/210 populated (partial backfill), PROD has 0. Use typed source columns + predecessor comparison instead. No write, no synthetic events, no prod action taken.
-
Analysis complete - see note. Implementation (derived display classification) is a coder item, not filed separately yet.