UC006 - Pricing Scope Audit

Fecha: 2026-06-03

Estado: AUDITORIA FUNCIONAL Y DE GOBIERNO

Scope: tenant

tenant_id: alpuntodeventa

Owner auditoria: Codex / apoyo documental

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/UC006-PRICING-SCOPE-AUDIT.md

1. Objetivo

Delimitar el alcance oficial de un futuro UC006 - Inteligencia de Mercado y Pricing para el tenant alpuntodeventa antes de crear el caso completo.

Esta auditoria no diseña implementacion.

Esta auditoria no diseña runtime, SQL, APIs, IA, dashboards ni tablas.

Su objetivo es responder si el caso merece existir, que debe incluir, que no debe incluir y como debe separarse de UC004 y UC005.

2. Restricciones respetadas

• sin runtime
• sin VPS
• sin Docker
• sin OpenClaw runtime
• sin Portainer
• sin NPM
• sin SQL
• sin APIs
• sin IA
• sin dashboards
• sin tablas
• sin agentes

3. Documentos revisados

Lectura completa realizada sobre:

• docs/tenants/alpuntodeventa/business-observer/BUSINESS-OBSERVER-AUDIT-001.md
• docs/tenants/alpuntodeventa/business-observer/BUSINESS-OBSERVER.md
• docs/tenants/alpuntodeventa/business-observer/DATA-NEEDS.md
• docs/tenants/alpuntodeventa/business-observer/DECISIONS.md
• docs/tenants/alpuntodeventa/business-observer/GROWTH-PLACEMENT-RULES.md
• docs/tenants/alpuntodeventa/business-observer/GROWTH-PLACEMENT.md
• docs/tenants/alpuntodeventa/business-observer/IMPACT-AND-LEARNING.md
• docs/tenants/alpuntodeventa/business-observer/OPERATING-CALENDAR-AND-TIME-INTELLIGENCE.md
• docs/tenants/alpuntodeventa/business-observer/PRICING-AUDIT-001.md
• docs/tenants/alpuntodeventa/business-observer/PROJECT-STATE.md
• docs/tenants/alpuntodeventa/business-observer/README.md
• docs/tenants/alpuntodeventa/business-observer/ROADMAP.md
• docs/tenants/alpuntodeventa/business-observer/RULES.md
• docs/tenants/alpuntodeventa/business-observer/UNSERVED-DEMAND.md
• docs/tenants/alpuntodeventa/business-observer/USE-CASES.md
• docs/business/OPENCLAW-BUSINESS-OBSERVER.md
• docs/PROJECT-STATE.md
• docs/ROADMAP.md

4. Resumen ejecutivo

Veredicto:

• UC006 merece existir como caso de uso separado
• no debe absorber UC004
• no debe absorber UC005
• debe nacer como caso tenant APV
• no debe nacer todavia como implementacion

Pregunta central propuesta:

como debe leer APV la relacion entre mercado, competencia, costo, precio, vigencia temporal y rentabilidad para tomar mejores decisiones comerciales

5. Por que UC006 merece existir

UC006 merece existir porque hoy el tema pricing aparece distribuido en fragmentos dentro de UC002, UC004, UC005, UC003 y el documento Core, pero no tiene aun un sujeto funcional propio.

Sin un caso dedicado, APV corre tres riesgos:

• mezclar crecimiento con politica de precio
• mezclar demanda no atendida con inteligencia de mercado
• mezclar lectura temporal con decisiones comerciales de margen y competencia

El problema no es solo saber si falta stock o si conviene crecer.

El problema es entender cuando el precio propio, el costo, la competencia, la oferta puntual o el precio esperado por el cliente cambian la viabilidad comercial real.

6. Que problema resuelve

Resuelve la falta de una lectura gobernada sobre:

• si APV esta caro, alineado o agresivo frente al mercado
• si un cambio de costo ya exige revisar precio
• si la competencia esta operando con stock viejo, oferta puntual o precio sostenido
• si una diferencia de precio puede explicar baja rotacion, sustitucion, rechazo o perdida de volumen
• si ciertas zonas o clientes toleran estructuras de precio distintas

No resuelve la operacion de venta.

No resuelve la reposicion por si sola.

No resuelve la demanda no atendida por si sola.

Resuelve lectura y criterio comercial.

7. Que informacion de mercado deberia analizar

Deberia analizar:

• precio relevado de mercado
• precio relevado de competencia
• marca competidora observada
• presentacion competidora observada
• zona, localidad y provincia del relevamiento
• canal o tipo de cliente donde se relevo
• disponibilidad observada en mercado
• oferta puntual vs precio estable
• frecuencia o repeticion de la observacion
• contexto comercial informado por vendedor

Lectura funcional esperada:

• comparacion territorial
• comparacion por canal
• comparacion por marca
• comparacion por presentacion
• lectura de dispersion de mercado

8. Que informacion de precios deberia analizar

Deberia analizar:

• precio propio vigente
• precio propio previo
• fecha de vigencia del precio propio
• precio esperado por el cliente
• precio relevado de mercado
• precio relevado de competencia
• diferencia entre precio propio y mercado
• diferencia entre precio propio y competencia
• diferencia entre precio esperado y precio propio
• oferta puntual, promocion o descuento observado
• cambios de precio viejo vs nuevo

La clave es leer precio siempre con fecha y contexto.

9. Que informacion de costos deberia analizar

Deberia analizar:

• costo vigente
• costo previo
• fecha de actualizacion de costo
• variacion reciente de costo
• brecha entre cambio de costo y cambio de precio
• rentabilidad o margen esperado como lectura comercial
• casos donde el precio queda atrasado frente al costo
• casos donde el precio se movio pero el mercado no acompano

No debe bajar todavia a formulas finales.

Debe quedar en nivel funcional.

10. Que informacion temporal deberia analizar

Deberia analizar:

• fecha de relevamiento
• fecha de compra del cliente cuando exista
• fecha de oferta observada
• fecha de ultimo cambio de costo
• fecha de ultimo cambio de precio
• vigencia del precio propio
• vigencia observada del precio competidor
• ventana previa y posterior a cambios relevantes
• comparacion entre precio viejo y precio nuevo
• desfases temporales entre costo, precio propio y precio de mercado

Esta capa temporal es obligatoria porque el mismo precio significa cosas distintas segun el momento en que se observa.

11. Que informacion relevada por vendedores deberia analizar

Deberia analizar:

• cliente
• vendedor
• fecha del relevamiento
• localidad
• provincia
• producto o SKU
• marca
• precio observado
• competidor o marca alternativa observada
• presentacion observada
• comentario comercial
• precio esperado por el cliente cuando aplique
• si el cliente acepto o rechazo una alternativa
• si el relevamiento refleja oferta puntual o precio habitual

El relevamiento del vendedor debe servir como evidencia comercial, no como verdad absoluta sin contexto.

12. Que informacion NO deberia incluir UC006

No deberia incluir:

• diseno de formulas finales de precio
• reglas automaticas de repricing
• ejecucion automatica sobre listas de precio
• SQL
• APIs
• IA
• dashboards
• tablas
• agentes
• decisiones automaticas de compra
• prediccion avanzada de elasticidad
• cierre contable
• control operativo de stock
• captura completa de demanda no atendida
• catalogo operativo de acciones comerciales

Tampoco deberia convertirse en un caso general de rentabilidad total del negocio.

Su foco es mercado, precio, costo y lectura comercial asociada.

13. Que debe permanecer dentro de UC004

Debe permanecer dentro de UC004:

• demanda no atendida
• pedido no atendido aunque no exista factura
• faltante observado
• demanda confirmada vs demanda estimada
• oportunidad economica perdida como estimacion comercial
• margen no generado por demanda frustrada
• sustitucion aceptada o rechazada
• aviso de reposicion pedido por cliente
• causas de demanda no atendida

Tambien debe permanecer en UC004 el precio esperado por el cliente cuando aparece como evidencia de una venta frustrada puntual.

Lo que no debe pasar es que UC004 pase a monitorear mercado de forma sistematica.

14. Que debe permanecer dentro de UC005

Debe permanecer dentro de UC005:

• dias calendario
• dias laborables teoricos
• feriados
• dias realmente trabajados
• dias con comprobantes emitidos
• productividad por dia trabajado
• forecast por dias efectivos
• cobertura operativa de stock
• dias efectivos sin stock
• comparaciones temporales justas entre periodos

Tambien debe permanecer en UC005 la temporalidad transversal como capacidad de comparar dias operativos.

UC006 puede consumir temporalidad, pero no debe redefinir el calendario operativo.

15. Que es Core y que es APV

Core

Pertenece al Core:

• patron reusable para observar precio, costo, mercado y tiempo
• principio de aislar por tenant
• trazabilidad por tenant_id y source_system
• preguntas genericas sobre brecha entre costo, precio y mercado
• gobierno, permisos y auditoria
• capacidad generica de comparar viejo vs nuevo y propio vs competencia

APV

Pertenece a APV:

• zonas, localidades y provincias concretas de lectura
• criterio comercial de que productos o marcas observar primero
• vendedores concretos y su relevamiento
• precio esperado por el cliente segun contexto APV
• criterios comerciales para aceptar o rechazar ciertas brechas
• prioridades de marca, proveedor y producto propias del tenant
• cualquier regla concreta de decision comercial

16. Que decisiones comerciales podria ayudar a tomar

Podria ayudar a tomar decisiones como:

• revisar si un producto quedo desalineado frente al mercado
• revisar si un cambio de costo ya exige discusion comercial
• priorizar que marcas o SKU merecen relevamiento mas frecuente
• detectar zonas donde el precio propio queda especialmente tensionado
• distinguir oferta puntual de cambio estructural de mercado
• revisar si una sustitucion puede estar empujada por precio
• decidir donde conviene defender margen y donde conviene defender volumen
• priorizar revision comercial con compras o direccion

Ayuda a decidir mejor.

No reemplaza la decision humana.

17. Que decisiones NO deberia tomar

No deberia tomar por si solo:

• cambiar precios automaticamente
• aprobar descuentos automaticamente
• disparar compras automaticamente
• definir margen minimo final sin criterio humano
• cerrar una politica comercial definitiva
• sancionar vendedores por relevamientos aislados
• concluir que toda caida de venta se explica por precio
• concluir que toda diferencia con competencia exige bajar precio

Debe asistir criterio.

No debe automatizar gobierno comercial.

18. Que riesgos existen

Riesgos principales:

• duplicar contenido de UC004
• duplicar contenido de UC005
• leer precios sin contexto temporal
• confundir oferta puntual con precio estructural
• confundir comentario de vendedor con evidencia confirmada de mercado
• mezclar rentabilidad general del Core con reglas comerciales APV
• sobredimensionar el precio como unica causa de perdida comercial
• abrir un alcance demasiado grande con mercado, competencia, costo, precio, sustitucion y proveedor todo junto sin frontera clara

Riesgo de gobierno:

• que ejemplos o reglas APV terminen absorbidos en el Core

Riesgo funcional:

• que UC006 nazca como pseudo motor de pricing en vez de caso de observacion

19. Que valor aporta por rol

Direccion Comercial

Aporta:

• criterio para revisar posicion de precio
• visibilidad sobre tensiones de mercado
• lectura de margen vs volumen
• mejor priorizacion comercial

Compras

Aporta:

• visibilidad sobre casos donde costo y precio quedan desacoplados
• contexto comercial para negociar con proveedor
• senales de mercado utiles para reposicion y acuerdos

Vendedores

Aporta:

• lenguaje comun para reportar mercado
• respaldo documental para explicar rechazo por precio
• mejor criterio sobre oferta puntual, sustitucion y posicion competitiva

Supervisores

Aporta:

• lectura comparativa por zona y equipo
• mejor revision de relevamientos
• mejor acompanamiento comercial sobre casos sensibles

Gerencia General

Aporta:

• visibilidad sobre posicion competitiva
• lectura mas ordenada del impacto comercial del precio
• mejor criterio para decidir entre defender margen, defender volumen o revisar estrategia

20. Propuesta de estructura futura del UC006

Estructura futura recomendada:

1. Problema de negocio

• por que APV necesita inteligencia de mercado y pricing

2. Pregunta central

• que decision comercial ayuda a tomar

3. Definicion conceptual

• mercado
• competencia
• precio propio
• precio de mercado
• costo
• rentabilidad
• oferta puntual
• vigencia temporal

4. Datos funcionales necesarios

• sin disenar tablas

5. Relevamiento comercial

• que debe poder observar el vendedor

6. Temporalidad de pricing

• viejo vs nuevo
• vigencia
• desfases

7. Lecturas comparativas

• propio vs mercado
• propio vs competencia
• costo vs precio
• zona vs zona

8. Relacion con otros casos

• UC002
• UC004
• UC005

9. Riesgos y limites

• que no debe concluir automaticamente

10. Decisiones habilitadas

• donde ayuda
• donde no debe decidir

11. Core vs Tenant

• patron reusable
• reglas APV

12. Roadmap UC006

• definicion funcional
• reglas tenant
• datos necesarios
• operacion futura

21. Validacion de duplicaciones, contradicciones y fronteras

Duplicaciones

Resultado:

• hay riesgo de duplicacion con UC004 en precio esperado, sustitucion y margen perdido
• hay riesgo de duplicacion con UC005 en temporalidad
• hay riesgo de duplicacion con UC002 en uso de margen como prioridad de crecimiento

Control recomendado:

• UC004 usa precio como evidencia de demanda frustrada
• UC005 usa tiempo como capa transversal de comparacion
• UC006 usa precio, costo y mercado como objeto principal de observacion

Contradicciones

Resultado:

• no se detectan contradicciones funcionales fuertes con los documentos revisados

Lectura:

• la auditoria previa y PRICING-AUDIT-001.md ya apuntaban a separar pricing como caso propio
• la documentacion vigente no obliga a integrarlo dentro de UC004 ni UC005

Superposicion con UC004

Existe, pero es controlable si la frontera queda asi:

• UC004 pregunta que demanda no pude atender
• UC006 pregunta que estructura de mercado, costo y precio ayuda a explicar o contextualizar esa dificultad

Superposicion con UC005

Existe, pero es controlable si la frontera queda asi:

• UC005 gobierna la temporalidad operativa del negocio
• UC006 consume temporalidad para leer vigencia de costo, precio y oferta

Mezcla Core / Tenant

Riesgo:

• medio si se documentan ejemplos concretos de APV como si fueran regla universal

Control:

• mantener el patron reusable en Core
• mantener productos, zonas, prioridades y criterio comercial concreto en APV

22. Frontera funcional oficial propuesta

UC006 debe quedar oficialmente definido como:

un caso de uso tenant para observar la relacion entre precio propio, costo, mercado, competencia y vigencia temporal, con el fin de mejorar decisiones comerciales humanas sobre posicion de precio, defensa de margen, defensa de volumen y lectura competitiva.

No debe quedar definido como:

• caso de demanda no atendida
• caso de calendario operativo
• caso de aprendizaje comercial
• motor automatico de repricing
• modulo tecnico de SQL, API o IA

23. Recomendacion final

Recomendacion:

• GO

Justificacion:

• el tema tiene entidad funcional propia
• la documentacion previa ya mostro fragmentacion y riesgo de mezcla
• hoy ya existe base suficiente para delimitar su alcance sin implementarlo
• la frontera con UC004 y UC005 puede dejarse clara desde el inicio
• su creacion documental ayudaria a ordenar futuras decisiones sin tocar runtime

Condicion obligatoria del GO:

• crear UC006 solo como caso documental y funcional
• no abrir implementacion tecnica
• no absorber dentro de UC006 lo que pertenece a UC004 o UC005

24. Cierre de auditoria

Confirmaciones:

• 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 diseno SQL
• no se disenaron APIs
• no se diseno IA

Resultado final:

• UC006 queda recomendado como siguiente caso documental futuro de pricing y mercado para APV
• su alcance queda delimitado
• su frontera con UC004 y UC005 queda funcionalmente gobernable