Source Inventory Checklist 001 - APV Business Observer¶

Fecha: 2026-06-08

Estado: GUIA OPERATIVA DE RELEVAMIENTO

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-CHECKLIST-001.md

1. Introduccion¶

Este relevamiento existe para identificar, de forma ordenada y progresiva, que fuentes reales de datos tiene hoy APV y cuales de esas fuentes pueden sostener al Business Observer.

Todavia no se implementa nada.

Todavia no se disena SQL.

Todavia no se disenan APIs.

Todavia no se disena IA.

Todavia no se crean tablas.

Primero debemos identificar que existe realmente, con que nombre aparece, que campos trae, que calidad tiene y que evidencia concreta podemos guardar para auditarlo despues.

Este documento sirve como guia practica para Gabi.

Su objetivo es que el relevamiento no dependa de memoria, intuicion ni explicaciones verbales sueltas.

2. Prioridad 1 - Informacion critica¶

La prioridad 1 busca confirmar las fuentes minimas que sostienen sobre todo UC001, UC002, UC005, UC006, UC008 y UC009.

Clientes¶

Que buscar¶

fuente real donde viva el maestro de clientes
nombre de la tabla, vista, exportacion o reporte
identificador unico del cliente
nombre o razon social
vendedor asignado
localidad
provincia
zona
estado del cliente

Por que buscarlo¶

porque UC001 necesita identidad comercial confiable
porque UC002 y UC008 necesitan saber a que cliente pertenece cada oportunidad
porque UC004, UC006 y UC009 necesitan contexto territorial
porque sin cliente estable no se puede unir venta, riesgo, surtido y abastecimiento

Como validar que sirve¶

confirmar que el identificador no cambia entre reportes
confirmar que no aparecen clientes duplicados con el mismo codigo
confirmar que el vendedor asignado existe y se puede cruzar con la fuente de vendedores
confirmar que localidad, provincia y zona no estan vacias en la mayoria de los registros utiles
confirmar que el estado permite distinguir al menos activo e inactivo

Que ejemplo compartir¶

3 a 5 clientes activos de distintos vendedores
1 cliente inactivo o pausado si existe
1 caso donde se vea claramente localidad, provincia y zona

Que evidencia guardar¶

captura de pantalla de la fuente abierta
exportacion corta con columnas visibles
nombre exacto del reporte, vista o tabla observado
fecha del relevamiento
comentario breve indicando si el codigo parece estable o dudoso

Productos¶

Que buscar¶

fuente real del maestro de productos
SKU
descripcion
marca
proveedor
categoria
unidades por bulto
estado del producto

Por que buscarlo¶

porque UC002, UC006, UC008 y UC009 necesitan granularidad por SKU
porque UC001 y UC008 necesitan lectura por marca
porque UC009 necesita proveedor para leer criticidad de abastecimiento
porque sin unidad por bulto se debilitan comparaciones operativas de UC004, UC005, UC008 y UC009

Como validar que sirve¶

confirmar que cada SKU aparece una sola vez o con una version claramente vigente
confirmar que marca y proveedor no quedan vacios en los productos de mayor movimiento
confirmar que categoria existe aunque luego necesite normalizacion
confirmar que unidades por bulto tiene sentido comercial y no valores inconsistentes
confirmar que el estado distingue al menos activo, discontinuado o similar

Que ejemplo compartir¶

3 a 5 SKU de marcas distintas
1 producto activo de marca estrategica si ya esta identificado
1 producto discontinuado o pausado si existe
1 ejemplo donde se vea claramente la unidad por bulto

Que evidencia guardar¶

captura del maestro o reporte
exportacion corta de ejemplo
nombre exacto de la fuente observada
fecha del relevamiento
nota breve sobre si SKU, marca y proveedor parecen confiables

Ventas¶

Que buscar¶

fuente real de ventas historicas
nombre de la tabla, vista, reporte o exportacion
fecha
comprobante
estado del comprobante
cliente
vendedor
SKU
unidades
importe

Por que buscarlo¶

porque la venta es el hecho base de UC001, UC002, UC005, UC006, UC007, UC008 y UC009
porque sin fecha y estado no se puede distinguir venta valida de anulacion
porque sin cliente, vendedor y SKU no se puede explicar riesgo, crecimiento ni surtido

Como validar que sirve¶

confirmar que la fuente permite ver ventas reales con fecha
confirmar que el comprobante tiene algun identificador util
confirmar que el estado permite reconocer anulados, notas o documentos que no deben leerse igual
confirmar que cliente, vendedor y SKU pueden cruzarse con sus maestros
confirmar que unidades e importe tienen valores coherentes
confirmar que la salida itemizada equivalente a Tabla 2 sea la base real de sync y que otros reportes sean solo derivados
confirmar si existe algun identificador de linea visible o si la clave futura debera resolver repeticion de SKU dentro del mismo comprobante

Que ejemplo compartir¶

3 a 5 lineas de venta reales de fechas distintas
1 caso anulado o no vigente si existe
1 ejemplo donde se vea el mismo cliente con mas de un SKU

Que evidencia guardar¶

captura del reporte o consulta visible
exportacion corta con columnas clave
nombre exacto de la fuente observada
fecha maximo dato visto
comentario breve sobre si el estado documental parece claro

Vendedores¶

Que buscar¶

fuente real del maestro de vendedores
codigo de vendedor
nombre
supervisor
estado

Por que buscarlo¶

porque todos los UC usan vendedor como owner comercial directo
porque UC002, UC003, UC007 y UC009 necesitan supervision y jerarquia
porque sin vendedor confiable no se puede leer cartera, foco ni ejecucion

Como validar que sirve¶

confirmar que el codigo es estable
confirmar que el nombre coincide con la operacion real
confirmar que supervisor existe o que la ausencia esta explicada
confirmar que el estado permite separar activos de bajas o licencias

Que ejemplo compartir¶

3 a 5 vendedores activos
1 vendedor con supervisor visible
1 vendedor inactivo o de baja si existe

Que evidencia guardar¶

captura de la fuente
exportacion corta
nombre exacto del reporte, vista o tabla observado
fecha del relevamiento
nota breve sobre si supervisor y estado parecen completos

3. Prioridad 2¶

La prioridad 2 mejora madurez operativa y temporal, especialmente para UC004, UC005, UC006 y UC009.

Stock¶

Que buscar¶

stock actual
stock por deposito si existe
fecha u hora de actualizacion

Por que buscarlo¶

porque UC004 y UC009 necesitan disponibilidad real
porque UC005 necesita leer cobertura operativa
porque UC007 no deberia recomendar vender sin stock

Como validar que sirve¶

confirmar si el stock es teorico, disponible o vendible
confirmar si la fecha de actualizacion esta visible
confirmar si el dato existe por SKU
confirmar si el stock por deposito es real o solo un agregado

Que ejemplo compartir¶

3 a 5 SKU con stock positivo
1 SKU en cero
1 ejemplo donde se vea mas de un deposito si existe

Que evidencia guardar¶

captura de pantalla
exportacion corta
nombre exacto de la fuente observada
fecha y hora visibles del corte si existen
comentario sobre si el stock parece disponible o solo teorico

Costos¶

Que buscar¶

costo actual
fecha de actualizacion del costo

Por que buscarlo¶

porque UC006 necesita leer costo con vigencia
porque UC007 no deberia sugerir acciones sin contexto minimo de margen

Como validar que sirve¶

confirmar que el costo esta identificado por SKU
confirmar que existe fecha de vigencia o de ultima actualizacion
confirmar que no se trata de un valor viejo sin referencia temporal

Que ejemplo compartir¶

3 a 5 SKU con costo actual visible
1 ejemplo donde se vea claramente la fecha de actualizacion

Que evidencia guardar¶

captura de pantalla
exportacion corta
nombre exacto de la fuente observada
fecha del ultimo cambio visible
nota breve sobre cobertura real del costo

Precios¶

Que buscar¶

lista de precio
vigencia de la lista o del precio

Por que buscarlo¶

porque UC006 necesita precio propio con fecha
porque UC007 necesita contexto para no recomendar acciones comerciales con precio fuera de vigencia

Como validar que sirve¶

confirmar que el precio esta asociado a SKU
confirmar que la lista tiene nombre, codigo o identificador entendible
confirmar que existe fecha desde la cual rige
confirmar si hay mas de una lista y si eso queda visible

Que ejemplo compartir¶

3 a 5 SKU con precio vigente
1 ejemplo donde se vea el nombre o codigo de lista
1 ejemplo con vigencia visible

Que evidencia guardar¶

captura de pantalla
exportacion corta
nombre exacto de la fuente observada
fecha de vigencia visible
nota breve sobre si hay una sola lista o multiples listas

4. Prioridad 3¶

Esta prioridad incluye informacion que probablemente no exista hoy como fuente madura dentro de APV:

precio competencia
demanda no atendida
acciones comerciales
sustituciones
oportunidades detectadas

Lectura esperada:

si esta informacion no aparece en una fuente real actual, no debe inventarse
si aparece solo en comentarios sueltos, mensajes o memoria comercial, debe clasificarse como captura futura necesaria y no como dato real ya gobernado
lo mas probable es que estos dominios requieran captura futura minima, disciplinada y con owner claro

Para esta prioridad, Gabi debe relevar sobre todo:

si hoy existe algun formulario, planilla, reporte o practica informal
quien la completa
con que frecuencia
que campos reales contiene
que tan auditable es

5. Evidencias minimas a pedir¶

Para cada fuente relevada pedir siempre, como minimo:

Que captura compartir¶

captura completa de pantalla donde se vea el nombre del modulo, reporte o consulta
captura donde se vean las columnas clave
captura con fecha visible si la fuente la muestra

Que exportacion compartir¶

exportacion corta a Excel, CSV, PDF o formato equivalente
no hace falta exportacion masiva
alcanza con una muestra chica pero real que deje ver estructura y contenido

Que consulta compartir¶

nombre exacto de la consulta, vista, reporte o menu usado
si fue una consulta manual, guardar el texto exacto usado
si no existe consulta reusable, dejar escrito como se llego a la pantalla

Que ejemplo real compartir¶

al menos 3 a 5 registros reales por fuente
al menos 1 caso borde si existe: inactivo, anulado, sin stock, discontinuado, supervisor vacio, etc.
al menos 1 ejemplo donde se vea la relacion con otro dominio: cliente con vendedor, venta con SKU, producto con proveedor, etc.

Que evidencia guardar¶

fecha del relevamiento
nombre de quien compartio la evidencia
nombre exacto de la fuente
captura
exportacion
nota breve de validacion inicial: confiable, incompleta o dudosa

6. Validacion¶

Dato confiable¶

Clasificar como dato confiable cuando:

tiene fuente clara
tiene nombre exacto de origen
tiene ejemplo real
tiene campos consistentes
puede cruzarse razonablemente con otras fuentes
tiene fecha o vigencia cuando corresponde

Dato incompleto¶

Clasificar como dato incompleto cuando:

existe la fuente, pero faltan campos importantes
el campo existe solo para una parte de los registros
hay dudas de cobertura: por ejemplo zona vacia, supervisor vacio, costo sin fecha, stock sin corte
el dato sirve parcialmente, pero no todavia como verdad fuerte

Dato dudoso¶

Clasificar como dato dudoso cuando:

no queda claro de donde sale
cambia entre reportes sin explicacion
no tiene fecha cuando la fecha es critica
no puede cruzarse con maestros basicos
aparece como comentario o memoria, no como fuente gobernada
nadie puede explicar quien lo mantiene o cuando se actualiza

Regla practica:

si hay duda entre incompleto y dudoso, tratarlo como dudoso hasta que aparezca evidencia mejor

7. Orden recomendado¶

Secuencia exacta de relevamiento:

Paso 1¶

Clientes

Primero confirmar identidad comercial, asignacion de vendedor y territorio.

Paso 2¶

Productos

Despues confirmar SKU, marca, proveedor, categoria y estado.

Paso 3¶

Ventas

Con clientes y productos ya identificados, validar la fuente transaccional.

Paso 4¶

Vendedores

Luego confirmar codigos, nombres, supervisor y estado para cerrar ownership.

Paso 5¶

Stock

Con maestros y ventas ya ubicados, validar disponibilidad actual y corte.

Paso 6¶

Costos

Despues validar costo actual con fecha de actualizacion.

Paso 7¶

Precios

Por ultimo validar lista y vigencia para sostener lectura de UC006.

Regla de orden:

no avanzar a mapeo detallado si antes no quedaron cerrados clientes, productos y ventas
no tratar precio o costo como confiables si no tienen fecha o vigencia
no tratar stock como confiable si no se entiende que significa exactamente

8. Proximo paso esperado¶

Una vez relevadas las fuentes reales, el siguiente documento correcto debera ser:

SOURCE-INVENTORY-RESULTS-001

Avance actual registrado:

SOURCE-001 documentado para clientes: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-001-SGC-CLIENTES.md
fuente real identificada: ecommerce.dbo.VCLIENTES
tipo: MSSQL / SGC
estado del hallazgo: primera fuente real identificada, pendiente de validacion de muestra
SOURCE-002 documentado como fuente real para productos: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002-SGC-PRODUCTOS.md
SOURCE-002 actualizado como maestro de productos completo y autoridad vigente para producto, marca, stock, proveedor, costos, precios, IVA y logistica comercial
confirmacion humana registrada: Gabi confirma que la query preservada de SOURCE-002 es la autoridad vigente y que SKU NOT IN ('0124', '3857', '3998', '3793') es la primera lista conocida de exclusiones operativas por uso interno o no tradicional
criterio documental para futura sincronizacion: esa lista de SKU excluidos debera mantenerse como regla configurable y no como hardcode sin explicacion
SOURCE-002B documentado como fuente complementaria real para imagenes: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002B-WOOCOMMERCE-IMAGENES.md
SOURCE-003 documentado como fuente real calculada para ventas y comprobantes: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-003-SGC-VENTAS-COMPROBANTES.md
decision documental cerrada para SOURCE-003: sincronizar solo Tabla 2; Tabla 1/3/4/5/6 quedan como reportes derivados reconstruibles
SOURCE-002C documentado como fuente funcional futura para snapshot diario: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002C-STOCK-DAILY-SNAPSHOT.md
SOURCE-002D documentado como fuente funcional futura para stock intradiario: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002D-STOCK-CURRENT-10MIN.md
reporte de recuperacion de query creado: docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002-QUERY-RECOVERY-REPORT.md

Ese documento debera registrar:

que fuente existe
que campos reales aporta
que nivel de calidad tiene
que dominios quedaron confirmados
que dominios siguen incompletos o dudosos
que calculos deben respetarse sin simplificacion, especialmente en SOURCE-003
que la salida sincronizable de ventas es Tabla 2 y no los reportes agregados derivados

Recien despues deberia hacerse:

MAPEO ORIGEN -> CONTRATO DE DATOS

Orden oficial:

inventario real de fuentes
resultados del inventario
mapeo origen -> contrato de datos
recien despues, cualquier diseno posterior

Validacion de coherencia¶

Resultado esperado de este checklist:

coherencia con BUSINESS-OBSERVER-DATA-CONTRACT-001.md: SI
coherencia con UC001 a UC009: SI
coherencia Core vs Tenant: SI
no disena implementacion: SI
no disena SQL: SI
no disena APIs: SI
no disena IA: SI
no crea tablas: SI

Confirmaciones de alcance¶

no se toco runtime
no se toco VPS
no se toco Docker
no se toco OpenClaw runtime
no se toco Portainer
no se toco NPM
no se disenaron SQL
no se disenaron APIs
no se diseno IA
no se crearon tablas
no se crearon scripts