Skip to content

fix(catalogo): el catalogo manda — el matcher deja de inventar empresas

Rafael Bautista requested to merge ti into qa

Tres entradas de _ALIAS_OVERRIDE apuntaban a un PORTAFOLIO en vez de a una empresa (CORPORATIVO->CONSOLIDADO ENI, IAL INFRA->NO OPERATIVA, DRIVE APP-> DRIVE). El pase 4 no encontraba destino y resolvia a None EN SILENCIO: el efecto contrario al que buscaban. Se retiran. No cambia el cruce — nunca cruzaron: 383/951 activos (40%) y 2,299/4,437 tickets (52%) siguen en "(sin portafolio)", que ahora es la señal honesta. Se curan como alias en /admin.

Para que no vuelva a fallar callado, audit_alias_override() clasifica cada entrada en rotos/redundantes/vigentes contra el catalogo VIVO, build_canon_index avisa por log una vez por proceso, y un test lo vuelve fallo de CI. Es por entorno a proposito: el catalogo de local/QA/prod diverge y la misma entrada puede estar sana en uno y rota en otro.

Auditando eso salio un bug mas grave. match_titular() no tenia el guard de ambiguedad que si tienen su pase 2 y build_canon_index: 'CORPORATIVO' es razon social 'ssbt' de TRES empresas, _pick_fiscal desempataba por id y devolvia Fundacion Grupo Caabsa. Hay 13 razones sociales compartidas por mas de una empresa (NO OPERATIVA en 117, PATRIMONIAL en 30, SERVICIOS en 14). Su pase 3 tenia el mismo hueco con aliases compartidos. Importa porque match_titular es lo que PERSISTE empresa_id en asambleas, avisos, corporativo y participacion — misma clase de bug que el incidente que documenta test_empresa_matcher.py.

De paso, los dos caminos resolvian distinto: match_titular exigia nombre_comercial exacto en el pase 4 y _CanonIndex.resolve aceptaba cualquier cosa indexada, asi que 5 de 18 overrides daban resultado distinto segun quien preguntara. Ambos usan ahora _match_grupo, con la misma precedencia (nombre_comercial gana al alias de otra) y el mismo guard.

Verificado: 22 tests en test_empresas_catalogo_lookup.py, suite 235 passed. El guard se comprobo inyectando una entrada rota — truena. Los 7 fallos de test_juicios_api.py son pre-existentes (db_juridico local vacia), confirmado corriendo esa suite sin estos cambios.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Merge request reports

Loading