movilba
MOVILBA-366
Dos caminos de import y solo uno resuelve el catalogo de carroceria: public.vehiculos 2411/2412 ligados, rutap.vehiculo_historial_normalizado 0 de 21514
Done normal
cmcoder03-mba-l-cc
Medido el 2026-09-08 por db02-mba-l-cc en DEV, SELECT only, sobre las 21514 filas origen='import'. Sale de la medicion pedida a raiz de MOVILBA-365. EL HECHO. carroceria_id esta en NULL en las 21514 filas. Las 21514. Y carroceria_modelo tambien, en las 21514. El import no resuelve carroceria en absoluto y tampoco guarda el texto crudo del libro, asi que no queda ni el valor resuelto ni el original. POR QUE ES SU PROPIA CLASE. Es la misma forma que chasis - un FK a catalogo que el import nunca resuelve - pero peor en dos sentidos: chasis AL MENOS tiene mecanismo (rutap.chasis_resolver, MOVILBA-199, 9 filas vivas en DEV, cobertura 102/21514 = 0.5%), y carroceria no tiene tabla de resolver propia. Y donde chasis conserva algo, carroceria no conserva ni el modelo en texto. POR QUE NADIE LO NOTO. La ficha se llena a mano: el operador elige una carroceria en el formulario y la pantalla queda completa. El hueco solo se ve contando las filas importadas, que es lo que nadie hace. Es la forma de siempre - un cero que mide la primera capa que se traga el pedido, no al evento. CONTEXTO DE LA MEDICION, poblado/total sobre las mismas 21514 filas: - ENTERAMENTE NULL: carroceria_id 0, carroceria_modelo 0, motivo_id 0, sube_id_validadora 0, sube_mounting_kit 0, openpass_id_validadora 0, openpass_mounting_kit 0. - CASI NULL: chasis_id 102 (0.5%). - PARCIALES: estado_id 3202 (14.9%), expte_baja 13607 (63.2%), fecha_baja 15108 (70.2%), expte_alta 18068 (84.0%), linea_id 96.7%, entidad_id 97.4%, consumo 98.0%, estandar_emisiones_id 99.2%, identificacion_camaras_adas 99.2%, tramite/tramite_id 99.9%. - Las columnas de validadora y motivo NO son de la misma clase: no son columnas del libro. No mezclarlas con esta. QUE HAY QUE ESTABLECER ANTES DE PROPONER NADA: 1. Si el libro TRAE carroceria y con que columna. Si no la trae, esto no es un defecto del import sino un campo que solo se carga a mano, y el item se cierra con esa razon. 2. Si la trae: por que el importer no la toca, y si corresponde una tabla resolver con la forma de MOVILBA-199 o si el catalogo alcanza para un match directo. 3. Cuantas grafias distintas trae el libro, con sus pares de valores - la leccion de MOVILBA-365 es que seis grafias pueden colapsar sobre una opcion viva y que eso lo decide Eugenia, no nosotros. NO EJERCITADO: PROD (DEV only), el camino de carroceria adentro del importer, y si la cobertura de 0.5% de chasis es alcance previsto o backfill frenado. Cero escrituras.
Activity
-
MEDIDO por db02-mba-l-cc, DEV: EL LIBRO SI TRAE CARROCERIA. raw_carroceria esta poblada en 21514 de 21514 filas origen='import'. O sea que este item NO se cierra con 'el libro no la trae', que era la primera de las tres preguntas que deje planteadas. Queda en pie como hueco real: el texto crudo del libro ESTA, y tanto carroceria_id como carroceria_modelo quedan vacios en las 21514. La proxima pregunta pasa a ser por que el importer no lo toca, y cuantas grafias distintas trae raw_carroceria con sus pares de valores - ojo que la leccion de MOVILBA-365 es justo esa: 92 pares de chasis, 73 sin destino.
-
ENCUADRE DE ELAZAR, directo el 2026-09-08, y deja el item en su forma correcta: "carroceria only has one field 'Carroceria' and 'Carroceria Categoria' is all M3, that's why we dont import it, but we should store it" O SEA QUE SON DOS COSAS DISTINTAS Y SOLO UNA ES EL DEFECTO: 1. LA CATEGORIA - resuelta, no hay nada que hacer. Vale M3 en 21514 de 21514 filas, no distingue ningun vehiculo, y por eso NO se importa como campo de negocio. Pero SI se guarda, por fidelidad al libro, y de hecho ya se guarda: carroceria_categoria y raw_carroceria_categoria estan pobladas con M3 en las 21514 filas importadas. Nada que arreglar aca. Es tambien la misma decision que MOBAAPI-661 tomo al dropear categoria_regulatoria_id de la app - guardar el dato crudo no es lo mismo que modelarlo. 2. LA CARROCERIA - ESTE es el defecto, y es el unico campo de carroceria que el libro trae de verdad. El modelo no aterriza nunca: carroceria_id 0 de 21514 y carroceria_modelo 0 de 21514 en las filas origen=import de rutap.vehiculo_historial_normalizado. Y EL CATALOGO YA EXISTE, que es lo que hace al defecto barato de describir y caro de ignorar: public.carrocerias tiene 74 filas (18 vivas), public.vehiculos.carroceria_id es FK a ella y esta poblado en 2411 de 2412 vehiculos vivos, y la UI ya la ofrece por v_ui_carrocerias en el desplegable de carrocerias. O sea que la app sabe elegir una carroceria y el import no sabe ligarla. MISMA FORMA QUE CHASIS (MOVILBA-365/367): el texto del libro llega, y el vinculo al catalogo no se hace nunca. La diferencia es que chasis al menos tiene rutap.chasis_resolver; carroceria no tiene tabla de resolver ninguna. QUE HAY QUE MEDIR ANTES DE PROPONER, y ahora la pregunta es concreta porque ya sabemos que el catalogo existe: 1. Cuantas grafias distintas de carroceria trae el libro, con sus pares de valores y su denominador. 2. De esas, cuantas matchean EXACTO una fila viva de carrocerias, cuantas matchean solo una BORRADA - la leccion de MOVILBA-200, que el dedup del 06-24 borro las filas que el libro nombra verbatim - y cuantas no matchean nada. 3. Recien con esos tres numeros se decide si alcanza con un match directo o si hace falta un resolver con la forma de MOVILBA-199. Lo que NO se hace: inventar un catalogo (ya hay uno), ni modelar la categoria (es constante y ya se guarda), ni adivinar equivalencias. DEV only. NO EJERCITADO: los tres conteos de arriba, el camino de carroceria dentro del importer, y PROD.
-
El import nunca liga la carroceria del libro al catalogo que YA existe: carroceria_id y carroceria_modelo en 0 de 21514 (la categoria es constante M3 y ya se guarda)
-
CANONICAS DE LOS DOS PARES SOSPECHOSOS, buscadas en fuentes publicas por coder02-mba-l-cc el 2026-09-08. Los dos son la MISMA empresa cada uno, y uno de los dos NO es un typo - es marca comercial contra razon social, que es un caso mucho peor porque no se detecta por parecido de texto. 1. NUOVOBUS = HEPRICAR S.A. Nuovobus es la MARCA COMERCIAL de Hepricar S.A., fabrica de carrocerias en el Parque Industrial II de Moreno. Confirmado en varias fuentes independientes: el Ministerio de Transporte de PBA publica la visita a "la fabrica Nuovo Bus", el ministro Marinucci lo escribe explicito como "la planta de Nuovobus (Hepricar S.A.)", y la galeria de Bus America titula sus fichas "NUOVOBUS (HEPRICAR)". EN EL LIBRO ESTAN LAS DOS, COMO SI FUERAN DISTINTAS: HEPRICAR 199 filas y NUOVOBUS 1 fila. Son 200 vehiculos de un mismo fabricante repartidos en dos nombres. Y NO se puede detectar comparando cadenas - no se parecen en nada - asi que cualquier normalizacion por similitud las deja separadas para siempre. 2. TODO BUS = TODOBUS. Todo Bus S.A., fabrica de carrocerias fundada en agosto de 2005 en Lomas de Zamora, filial de DOTA (Doscientos Ocho Transporte Automotor S.A.), primer modelo Pompeya en 2006. La forma canonica de la razon social lleva espacio: "Todo Bus S.A.". En el libro: TODO BUS 1988 filas, TODOBUS 1 fila. Aca si es variacion de escritura. CONSECUENCIA PARA EL VINCULO AL CATALOGO, y es el motivo por el que esto va aca: el libro trae 16 grafias distintas pero NO 16 fabricantes. Son 14. Un match exacto contra el catalogo va a fallar en 200 vehiculos por el par Hepricar/Nuovobus y en 1 por el par Todo Bus, y el de Hepricar va a parecer un fabricante faltante en vez de un duplicado. LO QUE NO SE HACE: no se folda ninguno de los dos en silencio. Cada fila singular es un vehiculo real, y decidir que dos nombres son la misma empresa es una afirmacion sobre el mundo, no una limpieza de texto. Se INFORMA a Eugenia - por regla de commons una contradiccion interna del libro se reporta, no se pregunta - y se deja la equivalencia escrita con su evidencia, que es exactamente para lo que existe la forma de resolver de MOVILBA-199. FUENTES: gba.gob.ar (Ministerio de Transporte PBA), Wikipedia es "Todo Bus", galeria bus-america, revistacolectibondi.com.ar. NO EJERCITADO: no verifique si el catalogo public.carrocerias tiene las dos, ni cual usa; eso esta pedido a db03 junto con el listado de las 74 filas.
-
MEDICION 2026-09-08 db02-mba-l-cc, DEV, SELECT only, cero escrituras. Denominador: 21514 filas origen='import' en rutap.vehiculo_historial_normalizado. 1. LA CATEGORIA NO ES EL ITEM Y YA ESTA GUARDADA. raw_carroceria_categoria 21514/21514 y carroceria_categoria 21514/21514, un solo valor distinto: 'M3'. No hay nada que agregar ni que modelar (MOBAAPI-661 ya habia decidido tirar la categoria regulatoria por constante). 2. EL CAMPO 'Carroceria' DEL LIBRO ES UN FABRICANTE, NO UN MODELO. 16 grafias distintas, con sus pares valor/conteo: TODO BUS 7946, METALPAR 2973, LA FAVORITA 2162, KING LONG 1970, AUTOBUS 1942, ITALBUS 1408, MARCOPOLO 1024, BAM BAM 880, HEPRICAR 796, METALBUS 188, YAXING 100, SALDIVIA 44, CORWIN 44, YUTONG 30, NUOVOBUS 4, TODOBUS 3. Suma 21514. 3. LO GUARDADO Y LO FALTANTE. raw_carroceria 21514/21514 y carroceria_fabricante 21514/21514 SI estan. carroceria_id 0/21514 y carroceria_modelo 0/21514. Falta el VINCULO, no el dato. 4. POR QUE NUNCA SE VINCULO. public.carrocerias tiene 74 filas y esta clavada por (fabricante_id, carroceria_modelo): es un catalogo de MODELOS, y el libro no trae columna de modelo. Pero en 72 de las 74 filas carroceria_modelo es una copia textual del nombre del fabricante; las dos excepciones son id 15 UGARTE/'Bedazzle' e id 11 SALDIVIA/'SALDIVIA A 325 U'. De hecho son 18 filas vivas sobre 18 fabricantes distintos: una por fabricante, sin ambiguedad. 5. MATCH CONTRA EL CATALOGO, medido contra vivas Y borradas por separado como pide la leccion de MOVILBA-200: 15 de las 16 grafias del libro tienen exactamente una carroceria VIVA por fabricante, y cubren 21511 de 21514 filas. Cero grafias matchean solo una fila borrada. La unica que no matchea nada vivo es 'TODOBUS' (3 filas): el fabricante TODOBUS existe vivo, pero sus 9 filas de carrocerias (ids 13, 51-58, todas con carroceria_modelo 'TODOBUS') estan soft-deleteadas, mientras la fila viva id 12 es TODO BUS/'TODO BUS'. Misma forma que MOVILBA-200: el dedup del 06-24 dejo viva una grafia y borro la otra. NO EJERCITADO: PROD; el loader (no se leyo el fuente, asi que no se sabe por que no intenta el vinculo); si 'TODOBUS' y 'TODO BUS' son el mismo carrocero fisico -eso lo contesta Eugenia, no la base; y las 2412 filas de vehiculos cargadas por la app, que si tienen carroceria_id y no se compararon contra el libro. NO SE PROPONE ESCRITURA. Falta el GO de Elazar sobre la regla de mapeo (fabricante del libro -> unica carroceria viva de ese fabricante) y la decision sobre las 3 filas TODOBUS.
-
SPLIT DEL LADO APP + CRUCE LIBRO/APP POR DOMINIO. 2026-09-08 db02-mba-l-cc, DEV, SELECT only, cero escrituras. Pedido por coder02-mba-l-cc. DENOMINADOR CORREGIDO: public.vehiculos tiene 2453 filas, 2426 con carroceria_id y 27 sin. El '2411' que veniamos citando era otra poblacion. TRES VEHICULOS APUNTAN A FILAS DE CATALOGO BORRADAS: id 33 ITALBUS/'ITALBUS' con 2, id 13 TODO BUS/'TODOBUS' con 1. El FK a public.carrocerias no filtra borrado_en, asi que la pantalla puede estar mostrando una carroceria retirada. Es un hallazgo aparte de este item. SPLIT COMPLETO (carroceria_id, fabricante, modelo, catalogo vivo, vehiculos): 12 TODO BUS viva 759; 9 METALPAR viva 345; 68 KING LONG viva 288; 6 LA FAVORITA viva 278; 1 AUTOBUS viva 218; 5 ITALBUS viva 139; 2 BAM BAM viva 114; 7 MARCOPOLO viva 111; 4 HEPRICAR viva 95; 8 METALBUS viva 32; 17 YAXING viva 26; 16 SALDIVIA viva 5; 3 CORWIN viva 5; 71 YUTONG viva 4; 14 UGARTE viva 2; 33 ITALBUS BORRADA 2; 13 TODOBUS BORRADA 1; 18 YUCHAI viva 1; 10 NUOVOBUS viva 1. LO QUE CONTESTA LA PREGUNTA DE FONDO, cruzando por dominio lo que dice el LIBRO contra lo que asigno la APP: libro HEPRICAR -> app HEPRICAR id 4: 95 dominios libro HEPRICAR -> app BAM BAM id 2: 4 dominios libro HEPRICAR -> app AUTOBUS id 1: 1 dominio libro HEPRICAR -> app NUOVOBUS id 10: 1 dominio libro NUOVOBUS -> app HEPRICAR id 4: 1 dominio libro NUOVOBUS -> app NUOVOBUS id 10: 1 dominio libro TODO BUS -> app TODO BUS id 12: 752 dominios libro TODO BUS -> vehiculo sin carroceria_id: 1 dominio libro TODOBUS -> app TODO BUS id 12: 1 dominio CONSECUENCIAS MEDIDAS, no opinadas: a) La app YA cruza NUOVOBUS y HEPRICAR en las DOS direcciones sobre los mismos dominios. Eso es evidencia interna de que son el mismo carrocero, sin depender de ninguna fuente externa. La hipotesis de coder02 (Nuovobus es la marca comercial de Hepricar S.A.) queda sostenida por el comportamiento de los operadores, no solo por la web. b) La app YA colapso TODOBUS en TODO BUS id 12. La grafia 'TODOBUS' no tiene ningun consumidor vivo del lado app: el unico vehiculo sobre id 13 es una fila de catalogo borrada, no una asignacion a 'TODOBUS' como destino elegido. c) O sea que el merge NO es import-only, y un mapeo exacto por grafia reproduciria un split que los operadores ya vienen ignorando. d) Nuevo: 4 dominios que el libro llama HEPRICAR estan cargados como BAM BAM y 1 como AUTOBUS. Eso no es un problema de grafia, es una discrepancia libro/app y hay que reportarla aparte. NO EJERCITADO: PROD; el fuente del loader; por que 27 vehiculos no tienen carroceria_id; y si los 5 dominios HEPRICAR->BAM BAM/AUTOBUS son error de carga o cambio real de carroceria.
-
BUCKETS CORREGIDOS sobre la medicion de db02 (21514 filas de import, DEV, SELECT only). db02 reporto "15 de 16 grafias matchean exacto una sola fila viva, sin ambiguedad". Es cierto como medicion de cadenas y es una conclusion equivocada para una de las 16. NUOVOBUS matchea EXACTO la fila viva id 10 del catalogo. O sea que NO aparece como fabricante faltante: las 4 filas se ligan limpiamente a una segunda entrada del MISMO fabricante y el reporte las cuenta como resueltas. Nuovobus es la marca comercial de Hepricar S.A. - el Ministerio de Transporte de PBA escribe "la planta de Nuovobus (Hepricar S.A.)" y Bus America archiva las fichas como "NUOVOBUS (HEPRICAR)". El catalogo reproduce el corte del libro en vez de resolverlo, y como los dos nombres no comparten un solo caracter ninguna pasada por similitud lo va a mostrar jamas. LOS TRES BUCKETS, que suman 21514: - 21507 filas: match exacto y correcto. - 4 filas: match exacto AL REGISTRO EQUIVOCADO (NUOVOBUS -> id 10, deberia ser el mismo fabricante que HEPRICAR id 4). - 3 filas: sin fila viva (TODOBUS; sus 9 filas de catalogo estan todas soft-deleted mientras vive la id 12 TODO BUS). LA LECCION DE METODO, que vale mas que el numero: un conteo de matches no puede detectar un match correcto-por-forma y equivocado-por-referente. El bucket "matchea exacto PERO al registro equivocado" no sale de ninguna medicion de cobertura; hay que pedirlo aparte y nombrando la hipotesis. Es la misma forma que MOVILBA-200 pero al reves: alli el dedup borro la fila fiel y el match fallaba ruidosamente; aca el duplicado quedo VIVO y el match acierta en silencio. CORRECCION DE UN NUMERO MIO: dije HEPRICAR 199 / NUOVOBUS 1. Contra las 21514 filas de import es 796 / 4. Mi par salio de una poblacion mas chica que no nombre. Gana el de db02, con su denominador. La proporcion no cambia el argumento. PEDIDO A db02, DEV, SELECT only: el reparto de carroceria_id de los 2411 vehiculos cargados por la app, en particular cuantos apuntan a id 10 NUOVOBUS contra id 4 HEPRICAR, y lo mismo para id 12 TODO BUS contra la familia TODOBUS borrada. Si la app viene asignando id 10, la fusion no es solo del import. NO SE DECIDE ACA: que NUOVOBUS y HEPRICAR sean la misma empresa, y que TODOBUS y TODO BUS sean el mismo carrocero, son afirmaciones sobre el mundo. Van a Eugenia como REPORTE, no como pregunta, por regla de commons - una contradiccion interna del libro se reporta. Ninguna se folda en silencio. NO EJERCITADO: PROD; el codigo del loader (por que nunca intenta el vinculo sigue sin medirse); el reparto app-side pedido arriba.
-
LA EVIDENCIA QUE CIERRA EL ENCUADRE VIENE DE ADENTRO DE LA BASE, no de las fuentes web. db02-mba-l-cc, 2026-09-08, DEV, SELECT only, cruzando por DOMINIO el fabricante del libro contra el cargado en la app. Denominador correcto: public.vehiculos 2453 filas, 2426 con carroceria_id, 27 sin. (Mi 2411 era solo vivos y no lo dije; se cita el de db02.) EL CRUCE: - libro HEPRICAR -> app HEPRICAR id 4: 95 dominios - libro HEPRICAR -> app NUOVOBUS id 10: 1 - libro NUOVOBUS -> app HEPRICAR id 4: 1 - libro NUOVOBUS -> app NUOVOBUS id 10: 1 - libro TODO BUS -> app TODO BUS id 12: 752, y 1 vehiculo sin carroceria_id - libro TODOBUS -> app TODO BUS id 12: 1 QUE PRUEBA: los operadores ya cruzan NUOVOBUS y HEPRICAR en LAS DOS DIRECCIONES sobre los mismos dominios, y ya colapsaron TODOBUS dentro de TODO BUS id 12. O sea que la fusion no es del import: la app viene ignorando el corte del libro hace tiempo. Las fuentes publicas (Ministerio de Transporte PBA, Bus America) pasan a ser corroboracion, no el sosten del argumento. Y ESO INVIERTE LA RECOMENDACION, que es lo importante: un mapeo por grafia exacta RECONSTRUIRIA un corte que la app ya ignora. La regla de 366 no es "matchear por fabricante" sino "matchear por fabricante, resolviendo antes NUOVOBUS a id 4 y TODOBUS a id 12". Esa resolucion es exactamente lo que se le INFORMA a Eugenia - reporte, no pregunta. DOS ITEMS DERIVADOS, abiertos, ninguno es 366 y ninguno se arregla dentro de 366: - MOVILBA-375: tres vehiculos apuntan a filas de carrocerias SOFT-DELETED (id 33 ITALBUS x2, id 13 x1) y ninguna lectura filtra borrado_en. Misma clase que MOVILBA-356. - MOVILBA-376: cinco dominios donde el libro y la app dicen fabricantes DISTINTOS (4 HEPRICAR->BAM BAM, 1 HEPRICAR->AUTOBUS). BLOQUEA cualquier mapeo: no se construye un mapeo encima de discrepancias sin clasificar. ESTADO DE 366: la regla de mapeo esta definida y medida, y queda esperando MOVILBA-376. No se propone escritura. NO EJERCITADO: PROD, el codigo del loader, los 27 vehiculos sin carroceria_id, y si los cinco de 376 son error de carga o recarrozado real - eso no se decide desde la base.
-
REGLA FIJADA POR ELAZAR, 2026-09-08, CLI. Reemplaza la regla de mapeo que yo escribi en el evento anterior; esa era mia y estaba mal. TEXTUAL: "if the entidades filed paperwork as Hepricar then we use Hepricar and add a question for Eugenia if we keep it. Typos like TODO BUS and TODO BUS we can fix, but not just replace a name." QUE SIGNIFICA, aplicado a las 21514 filas: 1. LO PRESENTADO MANDA. Las 4 filas presentadas como NUOVOBUS quedan NUOVOBUS y ligan a la id 10. Las 796 presentadas como HEPRICAR quedan HEPRICAR y ligan a la id 4. NO se fusionan. El libro es el registro de la documentacion que las entidades PRESENTARON, y saber que Nuovobus y Hepricar son la misma empresa NO autoriza a reemplazar un nombre presentado. 2. UN TYPO SI SE ARREGLA. TODOBUS -> TODO BUS es la misma razon social mal escrita: las 3 filas ligan a la id 12. 3. LA DISTINCION, que es toda la regla: un typo es la misma cadena mal tipeada; una marca comercial contra una razon social son DOS nombres reales, y quedarse con uno es REEMPLAZAR, no corregir. 4. LO QUE SE HACE CON LA EQUIVALENCIA: una PREGUNTA a Eugenia sobre si NUOVOBUS se mantiene como entrada propia. Nada se folda mientras no conteste. La pregunta esta redactada y va al tracker; el archivo estaba abierto en LibreOffice al momento de escribir esto, asi que la fila no se escribio todavia. MI ERROR, explicito para que no se repita: del cruce bidireccional (libro HEPRICAR -> app NUOVOBUS 1, libro NUOVOBUS -> app HEPRICAR 1) deduje que el corte "ya se estaba ignorando" y que correspondia fusionar. Que la app venga haciendo algo NO es una decision de negocio. Esas dos filas son una DISCREPANCIA app-contra-libro, misma clase que MOVILBA-376, no un precedente. La equivalencia estaba bien probada; la equivalencia no es permiso. REGLA DE MAPEO DEFINITIVA para 366, sin escritura propuesta todavia: - 21507 filas: match exacto por fabricante, se liga y listo. - 4 filas NUOVOBUS: ligan a la id 10. Correcto bajo la regla. Pendiente la respuesta de Eugenia. - 3 filas TODOBUS: ligan a la id 12 por correccion de typo. - raw_carroceria NUNCA se toca: guarda la grafia presentada VERBATIM. Lo unico que se resuelve es el FK. Esto vale para los tres casos. CONSECUENCIA PARA MOVILBA-376: le entran 2 dominios mas (los dos del cruce NUOVOBUS/HEPRICAR), que pasan de "evidencia de fusion" a "discrepancia a clasificar". Queda en 7. NO EJERCITADO: PROD, el codigo del loader, la respuesta de Eugenia, y los 27 vehiculos sin carroceria_id.
-
CORRECCION DE DENOMINADOR PROPIA, 2026-09-08 db02-mba-l-cc. En el evento anterior cite 2453 filas de public.vehiculos con 2426 con carroceria_id, y las use como si fueran el parque. Estan mal como poblacion: 2453 incluye filas SOFT-DELETEADAS. Las vivas son 2412, y 2411 tienen carroceria_id. El 2411 que traia coder02 era el correcto. La misma falta de filtro me hizo reportar '3 vehiculos apuntando a carrocerias borradas' en MOVILBA-375, que tambien queda corregido a CERO. Ademas: el cruce libro/app que reporte -operadores cruzando NUOVOBUS y HEPRICAR en las dos direcciones- se apoyaba en que esas asignaciones las hubiera hecho la app. Medido contra audit_log, no las hizo: ver MOVILBA-376. La conclusion de que NUOVOBUS y HEPRICAR hay que resolverlos juntos puede seguir siendo correcta, pero la evidencia que di NO la sostiene, porque quien escribio esos carroceria_id fue el import.
-
REGLA DE MAPEO — Elazar, directo por CLI, 2026-09-08, relevada por coder02-mba-l-cc. Supersede la propuesta de 'match por fabricante con NUOVOBUS y TODOBUS resueltos primero', que era nuestra y estaba mal. Verbatim: 'if the entidades filed paperwork as Hepricar then we use Hepricar and add a question for Eugenia if we keep it. Typos like TODO BUS and TODO BUS we can fix, but not just replace a name.' LO QUE SE PRESENTO GANA. El corte es entre CORREGIR y REEMPLAZAR: un typo es una sola cadena mal tecleada y se arregla; dos nombres reales distintos son dos nombres, y elegir uno es reemplazar, aunque se pruebe que son la misma empresa. MAPEO FINAL, sin escritura propuesta: 21507 filas match exacto; 4 NUOVOBUS -> carroceria id 10; 3 TODOBUS -> carroceria id 12 (typo). Suma 21514. Las 796 filas HEPRICAR se quedan en HEPRICAR -> id 4. NO hay merge NUOVOBUS/HEPRICAR. raw_carroceria no se toca en ninguno de los tres casos: conserva la grafia presentada verbatim y solo resuelve el FK. ANULA MI PROPIA EVIDENCIA. El cruce bidireccional que reporte -operadores poniendo NUOVOBUS y HEPRICAR sobre los mismos dominios- no funda un merge por dos razones independientes: (a) que la app venga haciendo algo no es una decision de negocio, y (b) medido despues contra audit_log, esas asignaciones no las hizo un operador sino el import (ver MOVILBA-376). Un conteo mide comportamiento, nunca intencion. Pregunta 11 del tracker de Eugenia: si NUOVOBUS se mantiene como carroceria propia. Nada se funde hasta que conteste.
-
LA PREMISA DEL ITEM ESTA INVERTIDA. Medido por db02-mba-l-cc, DEV, SELECT only, 2026-09-08. El titulo dice que el import nunca liga la carroceria al catalogo. Es FALSO para public.vehiculos y VERDADERO solo para la historia normalizada. LOS DOS NUMEROS, uno al lado del otro: - public.vehiculos: 2411 de 2412 vivos tienen carroceria_id, y 2395 de esos 2411 entraron por un camino de IMPORT. El import SI liga. - rutap.vehiculo_historial_normalizado: carroceria_id 0 de 21514 y carroceria_modelo 0 de 21514. SON DOS CAMINOS DE IMPORT Y SOLO UNO RESUELVE EL CATALOGO. Ese es el mecanismo, y es lo que el item tiene que nombrar. La pregunta ya no es "como construimos el vinculo" - existe y funciona en un lado. Es "por que el camino que escribe la historia no hace lo que el camino que escribe vehiculos ya hace". CONSECUENCIA PRACTICA: no hay que disenar un mapeo. Hay que leer el camino que YA resuelve y ver por que el otro no lo llama. Todo el trabajo de mapeo del item anterior queda como verificacion, no como diseno. CORRECCION DE DENOMINADOR, ahora en la otra direccion: db02 retira su 2453/2426, que contaba filas borradas. Va 2412 vivos / 2411 con carroceria_id. RETRACTACION DE db02, textual en su mensaje: "I told you operators cross NUOVOBUS and HEPRICAR". Medido contra public.audit_log - NO contra creado_por, que MOVILBA-354 mostro que la recarga del 06-29 sobreescribio - 12 de los 15 dominios discrepantes NO tienen ningun evento de vehiculos cuyo detalle mencione carroceria. Solo AG358KX, PON576 y AC958LQ lo tienen. En 12 casos lo escribio el import, no un operador. O SEA QUE EL ARGUMENTO CON EL QUE YO QUERIA FUSIONAR NUOVOBUS Y HEPRICAR SE CAYO ENTERO, y ya estaba descartado por la regla de Elazar antes de caerse. Se cayo por dos motivos independientes: la regla dice que un nombre presentado no se reemplaza, y ademas el cruce no lo hicieron operadores. Un mismo error se puede matar dos veces. SIGUE BLOQUEADO POR MOVILBA-376. NO EJERCITADO: PROD, el codigo de los dos caminos de import, y por que 1 vehiculo vivo no tiene carroceria_id.
-
Dos caminos de import y solo uno resuelve el catalogo de carroceria: public.vehiculos 2411/2412 ligados, rutap.vehiculo_historial_normalizado 0 de 21514
-
MOVILBA-366 source verdict: missing carroceria resolution stage, not a failed lookup. tools/rutap-snapshot-import.py:340 requires rutap.proyectar_snapshot; :448 calls it after loading raw rows, before commit. Latest checked-in projector docs/migrations/2026-09-08-movilba-344-raw-en-el-insert-DEV.sql:349 lists carroceria_fabricante, carroceria_modelo, carroceria_categoria, carroceria_id; :387 supplies trimmed source carroceria, NULL, trimmed category, NULL. No public.carrocerias join, no lookup key, no unresolved-carroceria conflict check. Same literal NULL in 269:370 and 341-342:376. Earlier 203-wide-refresh-snapshot10:110 explicitly documents no approved resolver; :241 writes NULL. Source label/raw preserved. Next implementation is add catalog resolution within existing projector and backfill existing imported rows separately (projector refuses re-projection); no new import pipeline required. No code or DB changes made.
-
coder03-mba-l-cc / coder
-
db03 2026-09-18 ~12:55 ART (found while measuring MOVILBA-279; RE-MEASURED today, SELECT only, PROD as svc_nextjs). PROD public.vehiculos: 148 of 2413 LIVE vehiculos have carroceria_id NULL (DEV: 2 of 2430). origen_ingreso: 142 legacy_unknown (created 2025-12-08..2026-03-04) + 6 ssot_import (2026-09-17). The current book names a carroceria for 148 of 148, and each of the 148 normalized texts resolves to exactly 1 LIVE carrocerias row (nothing to choose). Not fixed, not filed as its own item: yours/coder02's resolver work (MOVILBA-492) is the producer side; this is the PROD stock. A PROD write, needs GO. NOT EXERCISED: which of the 148 have a business reason for NULL (none looked at individually).
-
FOLDED into MOVILBA-492 (c8807618, applied PROD+DEV by db02). Re-measured 2026-09-18 db03, SELECT only, inet_server_addr checked: rutap.vehiculo_historial_normalizado origen='import' carroceria_id 5514/5514 and carroceria_fabricante (raw text preserved) 5514/5514 in BOTH DEV (10.9.10.54 movilba_dev) and PROD (10.78.42.168 movilba); the 0-of-21514 the item named no longer holds (import population now 5514, the 21514 was an older snapshot count). carroceria_modelo 0/5514: the book carries only carroceria + carroceria_categoria, no modelo column, so that is not an import defect. Projector writes the resolved id via rutap.clave_carroceria(text) per 492. NOT in 366 scope and NOT closed by it: PROD public.vehiculos 148 live rows with carroceria_id NULL -> MOVILBA-505. NOT EXERCISED: import re-run end to end after 492; DEV app-origin 19 history rows without carroceria_id (99 app rows, 80 populated).
bug
5w ago by wi-cli-venus
4w ago
2026-09-18 16:34