Saltar a contenido

Territory Human Review 001 - SOURCE-001 Clientes

Fecha: 2026-06-09

Estado: PAQUETE DE REVISION HUMANA PREPARADO / PENDIENTE DE APROBACION

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/territory/TERRITORY-HUMAN-REVIEW-001.md

Fuentes relacionadas:

  • docs/tenants/alpuntodeventa/business-observer/territory/TERRITORY-NORMALIZATION-STRATEGY.md
  • docs/tenants/alpuntodeventa/business-observer/territory/TERRITORY-ALIAS-CATALOG-001.md
  • docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-RESULTS-001.md
  • docs/tenants/alpuntodeventa/business-observer/mappings/SOURCE-001-CLIENTES-MAPPING.md
  • docs/tenants/alpuntodeventa/business-observer/BUSINESS-OBSERVER-DATA-CONTRACT-001.md

1. Objetivo de la revision

Preparar un paquete claro para que Gabi pueda validar o corregir:

  • aliases territoriales de Provincia, Localidad y Zona
  • decisiones que impactaran el catalogo territorial futuro de SOURCE-001

Este documento:

  • no cierra clasificaciones definitivas sin aprobacion humana
  • no crea tablas
  • no crea migraciones
  • no modifica datos
  • no toca runtime

2. Que debe revisar Gabi

Gabi debe revisar estos frentes:

  • si un alias raw realmente representa el mismo valor canonico propuesto
  • si una variante textual es solo diferencia de forma o cambia significado
  • si una Zona observada realmente corresponde a la agrupacion logistica esperada
  • si una Zona multi-provincia es valida por operacion o si necesita observacion
  • si una Zona no prefijada como MISIONES o CORRIENTES representa provincia, macrozona logistica o uso legado
  • si algun caso debe quedar explicitamente en manual_review

3. Criterios de decision

3.1 Alias territoriales

  • aprobar un alias solo cuando el cambio preserve identidad funcional
  • tratar como cambios aceptables de forma: espacios, puntuacion, abreviaturas controladas y variantes obvias
  • no fusionar valores distintos solo por similitud textual
  • si el cambio altera significado, dejarlo pendiente de revision humana
  • preservar siempre el valor raw

3.2 Clasificacion de Zona

  • clasificar por uso de negocio antes que por apariencia textual
  • no asumir que Zona es geografia pura
  • en SOURCE-001, asumir como regla base que Zona es una agrupacion logistica y no el territorio comercial del vendedor
  • no asumir que una zona igual a una provincia equivale a provincia canonica
  • si no hay evidencia suficiente, dejar unknown
  • si el origen explicita falta de definicion, usar undefined

3.3 Zonas multi-provincia

  • no tratarlas como error automatico
  • marcarlas para observacion cuando el negocio espere cobertura acotada
  • aceptarlas si representan cartera, operacion o logistica transversal

4. Como clasificar Zona

4.1 logistic_zone

Usar cuando la zona represente entrega, reparto, recorrido o logistica.

Indicadores tipicos:

  • rutas de distribucion
  • agrupacion de entregas
  • orden operativo de despacho
  • agrupacion de localidades para armado de rutas
  • formatos tipo Zona xx - Localidad

4.2 undefined

Usar cuando el propio origen declara falta de definicion.

Regla rectora:

  • NO DEFINIDA -> undefined

4.3 unknown

Usar cuando existe un valor, o ausencia de valor, pero todavia no hay una clasificacion confiable aprobada.

Reglas rectoras:

  • NULL/VACIO -> unknown
  • valor textual ambiguo sin aprobacion humana -> unknown

5. Tratamiento de casos especiales

5.1 NO DEFINIDA

  • preservar el texto observado
  • no convertirlo en NULL
  • clasificarlo como undefined
  • no inferir provincia, localidad ni semantica adicional

5.2 NULL/VACIO

  • tratarlo como ausencia de dato
  • diferenciarlo de NO DEFINIDA
  • clasificarlo como unknown
  • no reemplazarlo por una zona inventada

5.3 Zonas multi-provincia

  • preservar el valor raw
  • permitir que sigan activas en el catalogo
  • pedir validacion humana sobre su semantica real
  • no forzar subdivision automatica solo por tocar mas de una provincia

6. Listado inicial de casos a revisar

6.1 Alias de Localidad con variacion textual

  • JOSE C. PAZ -> JOSE C PAZ
  • JOSE C PAZ -> JOSE C PAZ
  • VILLA ADELINA -> VILLA ADELINA

6.2 Zonas con semantica probablemente mixta

  • ZONA 13-JOSE C. PAZ
  • ZONA 01-PALERMO
  • ZONA 01-BALVANERA
  • ZONA 13-SAN MIGUEL
  • ZONA 06-RAMOS MEJIAS
  • ZONA 04-LANUS

6.3 Zonas no prefijadas

  • MISIONES
  • CORRIENTES

6.4 Casos especiales obligatorios

  • NO DEFINIDA
  • NULL/VACIO

6.5 Casos de dispersion multi-provincia a confirmar

  • NO DEFINIDA
  • ZONA 06-RAMOS MEJIAS
  • MISIONES
  • CORRIENTES
  • ZONA 04-LANUS
  • ZONA 13-JOSE C. PAZ

7. Formato recomendado para aprobar o corregir aliases

Formato sugerido por fila de revision:

territory_level alias_raw canonical_value_propuesto zona_type_propuesto decision_humana aprobado_por fecha notas
locality JOSE C. PAZ JOSE C PAZ N/A approve Gabi AAAA-MM-DD misma localidad; cambio solo textual

Valores sugeridos para decision_humana:

  • approve
  • correct
  • keep_raw
  • needs_more_context

Regla operativa:

  • si Gabi corrige el canon propuesto, la correccion humana prevalece
  • si el caso no esta claro, debe quedar needs_more_context

8. Ejemplos de decisiones esperadas

8.1 Alias textual simple aprobado

  • JOSE C. PAZ -> JOSE C PAZ
  • lectura esperada: misma localidad, cambio solo textual, aprobable sin cambiar significado

8.2 Valor observado sin definicion

  • NO DEFINIDA
  • lectura esperada: preservar raw, clasificar undefined, no inventar zona canonica

8.3 Ausencia de valor

  • NULL/VACIO
  • lectura esperada: preservar ausencia, clasificar unknown, no tratarlo como NO DEFINIDA

8.4 Zona prefijada como agrupacion logistica

  • ZONA 13-JOSE C. PAZ
  • lectura esperada: mantener raw, normalizar el formato logistico si corresponde y no usarla para inferir territorio comercial del vendedor

8.5 Zona no prefijada ambigua

  • MISIONES
  • lectura esperada: no asumir que es provincia canonica; revisar con negocio si representa macrozona logistica o uso legado

8.6 Zona multi-provincia valida

  • ZONA 06-RAMOS MEJIAS
  • lectura esperada: no marcar error automatico; confirmar con negocio si esa dispersion responde a una cobertura logistica real

9. Regla de cierre

Este paquete solo prepara la revision humana.

Queda explicitamente pendiente:

  • aprobacion humana real de Gabi
  • carga real del catalogo
  • definicion fisica final de vistas analiticas de territorio comercial
  • diseno fisico final de SOURCE-001
  • geocodificacion futura

10. Confirmaciones de alcance

  • sin runtime
  • sin datos personales
  • sin tablas
  • sin migraciones
  • sin modificaciones de datos
  • clasificacion no cerrada sin aprobacion humana