Source 001 - SGC Clientes

Fecha: 2026-06-09

Estado: FUENTE REAL VALIDADA PARCIALMENTE CON EVIDENCIA

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-001-SGC-CLIENTES.md

Autoridad preservada: docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-001-CLIENTES-VCLIENTES-AUTHORITY.md

Mapping relacionado: docs/tenants/alpuntodeventa/business-observer/mappings/SOURCE-001-CLIENTES-MAPPING.md

1. Objetivo

Documentar la primera fuente real identificada para el Business Observer de APV sin implementar nada, sin disenar SQL final y sin tocar runtime, infraestructura ni contenedores.

2. Fuente detectada

• nombre exacto observado: ecommerce.dbo.VCLIENTES
• tipo de fuente: MSSQL / SGC
• dominio funcional: Clientes
• origen declarado por evidencia: mssql:mssql-sgc-ecommerce
• filtro observado en el script existente: WHERE [Codigo] IS NOT NULL

Regla documental adicional para sync futura:

• la extraccion base de SOURCE-001 no debe agregar WHERE Estado = 'CLIENTE ACTIVO'
• el filtro por estado comercial vendible pertenece a vistas, datasets derivados o capas de consumo y no a la base sincronizada

3. Evidencia disponible

La evidencia provista por Gabi indica que un script existente ya consume la vista ecommerce.dbo.VCLIENTES como maestro operativo de clientes.

La misma evidencia tambien indica que el flujo contemplado alrededor de esa extraccion incluye:

• tenant_id obligatorio
• origen mssql:mssql-sgc-ecommerce
• destino postgres:postgres-alpuntodeventa-dev-env
• plugin alpuntodeventa
• normalizacion analitica de WhatsApp
• validacion simple de CUIT
• validacion de cliente minimo saludable
• dry-run
• limite controlado hasta 500 filas
• reporte de riesgos: CUIT ausente, WhatsApp ausente o invalido, geodatos faltantes, duplicados por codigo y WhatsApp repetido

Estado de preservacion actual:

• existe evidencia completa preservada
• la query autoridad textual queda preservada en: source-authority/SOURCE-001-CLIENTES-VCLIENTES-AUTHORITY.md
• la referencia oficial de preservacion queda en: source-authority/SOURCE-AUTHORITY-REGISTRY.md
• la autoridad proviene del script de sincronizacion aportado por Gabi: C:\APV\gestor-de-negocios\backend\app\scheduler\scripts\sync_sgc_customers_canonical.py
• Telefono debe considerarse WhatsApp del cliente porque la query expresa: RTRIM([Telefono]) AS whatsapp
• validacion real agregada al 2026-06-08: distribucion de Estado y relacion con Fecha_Baja observadas en consulta real de solo lectura, registradas en docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-RESULTS-001.md
• validacion real agregada al 2026-06-08: unicidad de Codigo normalizado observada en consulta real de solo lectura, sin nulos, vacios ni duplicados y con igualdad exacta entre filas_totales y codigos_normalizados_distintos
• validacion real agregada al 2026-06-08: calidad de Telefono usado como WhatsApp, con 7107 informados, 4294 vacios, mayoria en largos controlables de 10 a 13, pero con 350 telefonos repetidos entre clientes distintos y formatos ambiguos que impiden cerrar normalizacion definitiva

3.1 Inventario real observado de Estado

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados.

Resultado observado:

Estado observado	Cantidad total	Fecha_Baja null	Fecha_Baja informada	Primera Fecha_Baja	Ultima Fecha_Baja
CLIENTE ACTIVO	5938	5938	0	NULL	NULL
CLIENTE DE BAJA	5372	0	5372	2018-11-16	2026-05-27
CLIENTE SUSPENDIDO	91	91	0	NULL	NULL

Validacion cerrada con evidencia:

• valores distintos observados: CLIENTE ACTIVO, CLIENTE DE BAJA, CLIENTE SUSPENDIDO
• valores inesperados: NO
• NULL/VACIO: NO
• total agregado observado: 11401

Lectura funcional respaldada:

• CLIENTE ACTIVO aparece alineado con Fecha_Baja = NULL
• CLIENTE DE BAJA aparece alineado con Fecha_Baja informada
• CLIENTE SUSPENDIDO aparece con Fecha_Baja = NULL

3.2 Inventario real observado de unicidad de Codigo

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados, usando la canonicalizacion:

NULLIF(LTRIM(RTRIM([Codigo])), '')

Resultado observado:

Medida	Resultado observado
filas totales	11401
codigos normalizados distintos	11401
codigos nulos o vacios	0
exceso sobre unicidad	0
codigos duplicados distintos	0
filas involucradas en duplicados	0

Validacion cerrada con evidencia:

• SELECT 1 AS ok ejecutado con resultado 1
• no aparecieron codigos nulos ni vacios
• no aparecieron codigos duplicados
• no fue necesario ejecutar la Query 1B de detalle de duplicados

Lectura funcional respaldada:

• Codigo normalizado se sostuvo como identificador comercial fuerte en la corrida real observada
• la clave logica tenant_id + codigo_cliente queda respaldada por evidencia real para SOURCE-001
• esta evidencia fortalece la recomendacion documental de usar codigo_cliente = NULLIF(LTRIM(RTRIM([Codigo])), '') en destino

3.3 Inventario real observado de WhatsApp

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados y ejemplos enmascarados.

Resultado observado para cobertura:

Medida	Resultado observado
filas totales	11401
telefono vacio	4294
telefono informado	7107
cobertura informada	62.3%

Resultado observado para formato sobre telefonos informados:

Medida	Resultado observado
largo entre 10 y 13 sin separadores	7027
largo menor a 10	64
largo mayor a 13	16
con caracteres no habituales	35

Distribuciones mas frecuentes observadas:

Largo original	Largo sin separadores	Caracteres no habituales	Casos
11	11	0	5768
10	10	0	517
13	12	0	445
14	13	0	168
12	12	0	56

Resultado observado para repetidos:

Medida	Resultado observado
telefonos repetidos distintos	350
filas involucradas	760
clientes involucrados	760
maximo clientes distintos por telefono	14

Ejemplos enmascarados observados:

Tipo	Ejemplo	Casos
formato frecuente	911******88	199
formato frecuente	911******66	116
formato frecuente	911******99	110
repetido entre clientes distintos	911*11	14
repetido entre clientes distintos	9*9	7
repetido entre clientes distintos	+54********00	4

Lectura funcional respaldada:

• Telefono sirve como base operativa de contacto, pero no cubre a toda la cartera
• la mayoria de los valores observados parece normalizable con reglas controlables
• no corresponde tratar whatsapp como identificador unico porque hay repetidos reales entre clientes distintos
• no corresponde cerrar todavia una normalizacion definitiva porque la heterogeneidad de formato sigue siendo real
• veredicto documental recomendado para calidad actual de WhatsApp: AMARILLO

3.4 Inventario real observado de vendedor

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados.

Resultado observado:

Medida	Resultado observado
filas totales	11404
vendedor codigo vacio	0
vendedor codigo informado	11404
vendedor nombre vacio	0
vendedor nombre informado	11404
codigos vendedor distintos	76
nombres vendedor distintos	76
pares codigo + nombre distintos	76
codigos con multiples nombres	0
nombres con multiples codigos	0

Lectura funcional respaldada:

• Codigo_vendedor y Nombre_Vendedor aparecen completos en la corrida observada
• la relacion codigo_vendedor <-> nombre_vendedor se sostuvo 1:1 dentro de VCLIENTES
• el ownership comercial de SOURCE-001 queda utilizable con semaforo recomendado VERDE dentro de esta fuente

3.5 Inventario real observado de Frecuencia y dias de visita

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados.

Resultado observado para frecuencia:

Medida	Resultado observado
filas totales	11404
cod_frec vacio	0
cod_frec informado	11404
frecuencia vacia	0
frecuencia informada	11404
codigos distintos	4
etiquetas distintas	4
codigos con multiples etiquetas	0
etiquetas con multiples codigos	0

Distribucion observada:

cod_frec	frecuencia	cantidad_clientes
FVC001	SEMANAL	11198
FVC004	EVENTUAL	166
FVC002	QUINCENAL	39
FVC003	MENSUAL	1

Resultado observado para dias:

Dia	Informado	Vacio
lunes	9539	1865
martes	9557	1847
miercoles	9585	1819
jueves	9546	1858
viernes	9669	1735
sabado	10508	896

Valores observados:

• solo se observaron S, N y NULL/VACIO en los campos diarios
• sabado tiene mayor volumen de S que el resto de los dias
• la cardinalidad de dias informados no es uniforme: la mayoria de SEMANAL queda con 6 dias informados, pero tambien existen bordes con 1-5 dias informados y EVENTUAL concentra sobre todo 1 dia

Lectura funcional respaldada:

• CodFrec y Frecuencia quedan respaldados como senales consistentes y directamente aprovechables dentro de VCLIENTES
• los campos diarios no mostraron texto libre sorpresa en esta corrida
• aun asi no corresponde cerrar todavia el diseno fisico final solo con esta evidencia; conviene preservar la frontera documental hasta cerrar tambien la estrategia final de tablas y la normalizacion pendiente de otros campos

3.6 Inventario real observado de territorialidad

Consulta real ejecutada el 2026-06-08 sobre [ecommerce].[dbo].[VCLIENTES], en modo de solo lectura y registrando solo agregados.

Resultado observado para cobertura:

Medida	Resultado observado
filas totales	11404
localidad vacia	0
localidad informada	11404
provincia vacia	0
provincia informada	11404
zona vacia	1
zona informada	11403
provincias distintas	24
localidades distintas	516
zonas distintas	365

Resultado observado para provincias:

• cartera concentrada en BUENOS AIRES=7311 y CABA=3749
• esas dos provincias explican 11060 / 11404 clientes, equivalente a 97.0%
• aun asi se observaron 24 provincias distintas en la vista

Resultado observado para zonas:

• NO DEFINIDA=1522
• NULL/VACIO=1
• zonas con prefijo ZONA = 9437
• zonas textuales no prefijadas = 444

Resultado observado para consistencia:

• 289 zonas quedaron acotadas a 1 sola provincia
• 76 zonas mezclan multiples provincias
• 6365 clientes quedan dentro de zonas multi-provincia
• aparecieron tambien variantes textuales de localidad compatibles con necesidad futura de higiene, por ejemplo JOSE C. PAZ y JOSE C PAZ

Lectura funcional respaldada:

• Localidad y Provincia quedan respaldadas como senales territoriales claras y con cobertura completa
• Zona queda respaldada como senal logistica util, pero no como catalogo geografico perfectamente limpio ni como territorio comercial del vendedor
• la estrategia canonica futura para normalizar Provincia, Localidad y Zona queda documentada en territory/TERRITORY-NORMALIZATION-STRATEGY.md
• veredicto documental recomendado para territorialidad actual: AMARILLO
• la fuente sirve para analitica territorial y para futuros casos de uso por cobertura y volumen, pero sigue requiriendo normalizacion posterior para cerrar jerarquias fisicas definitivas

4. Campos disponibles

Campos extraidos por el SELECT relevado sobre VCLIENTES:

Campo de salida	Expresion observada	Lectura funcional inicial
codigo_cliente	RTRIM([Codigo])	identificador comercial del cliente
cliente_nombre	COALESCE(NULLIF(RTRIM([Nombre]), ''), NULLIF(RTRIM([Nombre_en_Factura]), ''), RTRIM([Codigo]))	nombre principal visible
razon_social	RTRIM([Nombre_en_Factura])	razon social o nombre de factura
direccion_pedidos	RTRIM([Direccion_de_pedidos])	direccion operativa de entrega o pedido
localidad	RTRIM([Localidad])	localidad comercial
provincia	RTRIM([Provincia])	provincia comercial
entre_calles	RTRIM([EntreCalles])	referencia adicional de ubicacion
zona	RTRIM([Zona])	agrupacion logistica territorial
horarios_entrega	RTRIM([Nota_en_comprobante])	nota operativa util para entrega
whatsapp	RTRIM([Telefono])	Telefono tratado como WhatsApp del cliente
lista_precio	RTRIM([Lista_Precio])	lista comercial asignada
canal	RTRIM([Ramo])	canal o ramo comercial
categoria	RTRIM([Categoria])	categoria del cliente
codigo_vendedor	RTRIM([Codigo_vendedor])	identificador del vendedor
nombre_vendedor	RTRIM([Nombre_Vendedor])	nombre visible del vendedor
vendedor_nombre	derivado desde Nombre_Vendedor	separacion analitica del nombre
vendedor_apellido	derivado desde Nombre_Vendedor	separacion analitica del apellido
fecha_ultima_compra	CAST([Fecha_Ultima_Compra] AS date)	ultima fecha de compra visible
fecha_alta	CAST([Fecha_Alta] AS date)	fecha de alta del cliente
fecha_baja	CAST([Fecha_Baja] AS date)	fecha de baja del cliente
condicion_venta	RTRIM([Condicion_de_venta])	condicion comercial de venta
condicion_iva	RTRIM([Condicion_Iva])	condicion impositiva
cuit	RTRIM([Cuit])	identificacion fiscal
ingresos_brutos	RTRIM([Ing_Brutos])	dato impositivo complementario
descuento	RTRIM([Descuento])	descuento parametrizado
cobrar_pib	RTRIM([Cobrar_PIB])	marca relacionada con PIB
porc_pib	RTRIM([Porc_PIB])	porcentaje relacionado con PIB
limite_credito	RTRIM([Limite_Credito])	limite crediticio
mora_permitida	RTRIM([MoraPermitida])	tolerancia de mora
estado	RTRIM([Estado])	estado comercial observado
estado_texto	RTRIM([Estado])	duplicado textual del estado
administracion	RTRIM([Fax])	dato hoy interpretado como contacto administrativo
email	RTRIM([mail])	correo del cliente
cod_frec	RTRIM([CodFrec])	codigo de frecuencia
frecuencia	RTRIM([Frecuencia])	frecuencia comercial
lunes	RTRIM([lunes])	disponibilidad o frecuencia por dia
martes	RTRIM([martes])	disponibilidad o frecuencia por dia
miercoles	RTRIM([miercoles])	disponibilidad o frecuencia por dia
jueves	RTRIM([jueves])	disponibilidad o frecuencia por dia
viernes	RTRIM([viernes])	disponibilidad o frecuencia por dia
sabado	RTRIM([sabado])	disponibilidad o frecuencia por dia

5. Campos utiles para Business Observer

Campos que ya muestran utilidad directa para el Business Observer:

• codigo cliente: codigo_cliente
• nombre: cliente_nombre
• razon social: razon_social
• direccion: direccion_pedidos
• localidad: localidad
• provincia: provincia
• zona: zona
• regla critica: Zona debe leerse como agrupacion logistica para rutas y reparto; no define vendedor responsable
• regla critica: el vendedor responsable sale de codigo_vendedor y nombre_vendedor
• regla critica: el territorio comercial del vendedor debe derivarse de la cartera real de clientes asignados y cruzarse luego con localidad, provincia, zona logistica, ventas y productos
• vendedor: codigo_vendedor, nombre_vendedor, vendedor_nombre, vendedor_apellido
• WhatsApp: whatsapp
• lista precio: lista_precio
• canal: canal
• categoria: categoria
• CUIT: cuit
• estado: estado, estado_texto
• frecuencia: cod_frec, frecuencia, lunes, martes, miercoles, jueves, viernes, sabado
• fecha alta: fecha_alta
• fecha baja: fecha_baja
• fecha ultima compra: fecha_ultima_compra

5.1 Regla de relacion del cliente fuente

Todos los campos expuestos por SOURCE-001 salen de la misma fila de ecommerce.dbo.VCLIENTES y pertenecen al mismo cliente SGC.

Regla documental cerrada:

• el campo origen comun es Codigo
• la query autoridad lo expone como RTRIM([Codigo]) AS codigo_cliente
• la forma canonica recomendada en destino es: codigo_cliente = NULLIF(LTRIM(RTRIM([Codigo])), '')
• la clave logica recomendada para cualquier capa derivada es: tenant_id + codigo_cliente
• la validacion real del 2026-06-08 no encontro nulos, vacios ni duplicados bajo esa canonicalizacion
• ningun grupo derivado debe interpretarse como cliente independiente

Implicancia:

• si a futuro se separan capas como customers_core, customers_contact, customers_address, customers_tax, customers_commercial, customers_sales_owner y customers_visit_schedule, todas siguen siendo grupos logicos del mismo cliente SGC
• esa separacion solo ordena dominios funcionales y no implica multiplicar clientes ni cerrar todavia el diseno fisico de tablas
• el primer mapeo campo por campo para esa separacion queda documentado en: mappings/SOURCE-001-CLIENTES-MAPPING.md

5.2 Regla de preservacion de clientes no vendibles

En APV, un cliente suspendido o de baja no implica eliminacion.

Lectura obligatoria para SOURCE-001:

• la sync futura debe preservar CLIENTE ACTIVO, CLIENTE SUSPENDIDO y CLIENTE DE BAJA
• el valor textual de Estado en SGC debe guardarse como estado_raw
• el estado operativo derivado recomendado es: CLIENTE ACTIVO -> active / can_sell = true
• el estado operativo derivado recomendado es: CLIENTE SUSPENDIDO -> suspended / can_sell = false
• el estado operativo derivado recomendado es: CLIENTE DE BAJA -> inactive / can_sell = false
• si estado, estado_texto o fecha_baja indican suspension o baja, el cliente debe seguir preservado en el dominio analitico
• la suspension o baja debe tratarse como estado comercial y referencia temporal
• el cliente sigue formando parte del territorio comercial historico de la empresa
• no corresponde filtrar clientes suspendidos o de baja como si fueran descartables para todas las capas futuras
• la desaparicion completa del registro en una extraccion futura debe tratarse como evento distinto de Estado = CLIENTE DE BAJA
• el futuro diseno Postgres no debe habilitar hard delete por baja comercial

Usos obligatorios de preservacion:

• analisis historico
• medicion de perdida de territorio
• medicion de recuperacion comercial
• campanas de reactivacion
• calculo de masa comercial total
• evaluacion de desempeno comercial por zona, vendedor y periodo
• clientes necesarios para recomponer masa comercial

6. Casos de uso consumidores

Relacion inicial entre esta fuente y UC001 a UC009:

Caso de uso	Dependencia	Motivo funcional
UC001 - Clientes en riesgo comercial	principal	necesita identidad comercial, estado, vendedor y fecha ultima compra
UC002 - Crecimiento y colocacion estrategica	principal	necesita cliente, territorio, vendedor, canal y lista comercial
UC003 - Impacto y aprendizaje comercial	secundaria	aporta cliente, vendedor y contexto territorial para leer acciones
UC004 - Demanda no atendida y oportunidad perdida	principal	aporta cliente, localidad, provincia, zona y telefono de contacto
UC005 - Calendario operativo e inteligencia temporal	secundaria	aporta frecuencia, estado y fechas de alta o baja como contexto temporal
UC006 - Inteligencia de mercado y pricing	principal	aporta territorio, lista precio, canal y categoria del cliente
UC007 - Recomendaciones comerciales priorizadas	principal	aporta ownership comercial y estado base para priorizar senales
UC008 - Inteligencia de surtido y mix	principal	aporta cliente, canal, categoria, vendedor y ultima compra
UC009 - Inteligencia de proveedores y abastecimiento	secundaria	aporta territorio y cartera cliente para medir impacto de faltantes

7. Calidad esperada

Campos confiables

• codigo_cliente
• cliente_nombre
• razon_social
• codigo_vendedor
• nombre_vendedor
• cod_frec
• frecuencia
• fecha_ultima_compra
• fecha_alta
• fecha_baja
• estado

Lectura inicial:

• se consideran confiables de forma preliminar porque el script existente ya los consume como campos estructurales base
• igual requieren validacion de muestra real antes de promoverlos a verdad fuerte

Campos a validar

• cuit
• lista_precio
• canal
• categoria

Campos con evidencia real parcial

• whatsapp
• localidad
• provincia
• zona

Lectura actual:

• Telefono como WhatsApp tiene evidencia real de utilidad operativa, pero con cobertura incompleta y heterogeneidad de formato
• la calidad observada al 2026-06-08 recomienda semaforo AMARILLO
• la normalizacion definitiva sigue pendiente mientras existan formatos ambiguos
• los repetidos reales obligan a no usar whatsapp como clave unica
• Localidad y Provincia tienen cobertura completa y Zona cobertura casi completa, pero la territorialidad observada sigue en AMARILLO por dispersion textual en localidades y mezcla multi-provincia en parte de las zonas; la arquitectura canonica futura queda fijada como provincia_raw + provincia_normalized, localidad_raw + localidad_normalized y zona_raw + zona_type + zona_normalized
• en SOURCE-001, esa Zona debe interpretarse como zona logistica y no como territorio comercial

Campos dudosos

• administracion derivado desde Fax
• horarios_entrega derivado desde Nota_en_comprobante
• vendedor_nombre derivado desde Nombre_Vendedor
• vendedor_apellido derivado desde Nombre_Vendedor
• cobrar_pib
• porc_pib
• mora_permitida

Campos que pueden venir vacios

• entre_calles
• whatsapp
• email
• zona
• fecha_baja
• ingresos_brutos
• descuento
• limite_credito
• campos diarios: lunes, martes, miercoles, jueves, viernes, sabado

8. Riesgos detectados

• drift futuro en vendedor: no se observaron vacios ni inconsistencias 1:1 en la corrida del 2026-06-08, pero sigue siendo un control estructural que conviene mantener si la fuente cambia
• WhatsApp mal normalizado: puede romper contacto comercial y analitica de cobertura; la validacion real ya observo 4294 vacios, 350 telefonos repetidos entre clientes distintos y formatos heterogeneos
• CUIT invalido: afecta confiabilidad administrativa y posibles cruces externos
• localidad o provincia incompletas: deja de ser el principal riesgo en la corrida del 2026-06-08 porque la cobertura quedo completa; el riesgo vigente pasa a ser la necesidad de normalizacion textual y consistencia de Zona
• Zona demasiado amplia o inconsistente: puede mezclar mas de una provincia o macroterritorios no equivalentes y sesgar lecturas territoriales finas si se la toma como jerarquia cerrada
• estado mal interpretado: puede mezclar clientes activos, inactivos, pausados o de baja y llevar a borrar relacion historica que debe preservarse
• frecuencia o dias reinterpretados en exceso: aunque la corrida del 2026-06-08 solo observo 4 frecuencias y valores diarios S/N/NULL, conviene no saltar directo a un cierre fisico rigido sin dejar trazabilidad del origen
• duplicados por codigo: quedan sin evidencia en la corrida real del 2026-06-08; mantener control futuro igual porque siguen siendo un riesgo estructural si la fuente cambia
• campos de geolocalizacion no presentes: limita analitica territorial fina porque no hay latitud ni longitud

9. Que debe validar Gabi

• si VCLIENTES es la fuente correcta y oficial del maestro de clientes
• si Estado distingue de forma confiable activo, inactivo, pausado o baja
• si Fecha_Baja representa baja comercial y no eliminacion fisica
• si Codigo_vendedor vincula un vendedor real del maestro correspondiente
• si Fecha_Ultima_Compra es confiable para analitica comercial
• si Localidad, Provincia y Zona se usan operativamente en APV
• si el formato esperado de Zona queda formalmente alineado a Zona xx - Localidad y ZONA 00 - INTERIOR DEL PAIS
• si Lista_Precio es confiable y refleja vigencia comercial real

10. Proximo paso

Tomar la siguiente validacion real de SOURCE-001 sobre agregados o muestra anonimizada controlada para cerrar:

• cobertura territorial
• utilidad real de Lista_Precio y Frecuencia
• implementacion posterior de la estrategia de normalizacion territorial para Localidad, Provincia y Zona
• decision final de modelado fisico una vez consolidados WhatsApp, territorialidad y bloques futuros

Lectura actualizada al 2026-06-08:

• el primer mapeo origen-destino de SOURCE-001 ya queda documentado
• vendedor y frecuencia ya quedan respaldados con evidencia real util dentro de VCLIENTES
• la estrategia territorial canonica ya deja cerrada la lectura de Zona como agrupacion logistica y separa el territorio comercial del vendedor como una construccion derivada
• sigue pendiente su implementacion fisica junto con la normalizacion definitiva de WhatsApp y la estrategia final de tablas

11. Confirmaciones de alcance

• no se implemento codigo
• no se crearon tablas
• no se crearon scripts nuevos
• no se toco runtime
• no se toco VPS
• no se toco Docker
• no se diseno SQL final