Precios de competencia — Justificación y requisitos

Relacionado con: RFC 008 (análisis extenso y decisiones), donde se detalla el diseño. Este documento define el qué; el cómo queda fuera de su alcance.

1. Justificación

El precio de venta se determina sin una referencia sistemática del mercado: no existe dónde consultar a cuánto vende la competencia un producto dado ni cuándo cambió ese precio. La consecuencia es el precio estático — fijado una vez y no revisado, porque revisarlo exige relevamiento manual caso por caso.

El proyecto incorpora la observación sistemática de precios de la competencia por producto, para alimentar la analítica de determinación de precios fuera del sistema. No se busca automatizar decisiones de precio: los datos observados no intervienen en el cálculo interno del precio de venta.

2. Alcance

Incluye

• Administrar competidores (2-3 sitios definidos) con su configuración de relevamiento.
• Vincular manualmente productos propios con su página en cada competidor, mediante URL.
• Relevar diariamente precio, precio de lista y disponibilidad de esas páginas, mediante el servicio externo de obtención de páginas ya contratado (ScrapeOps).
• Conservar el último valor observado por producto y competidor, en guaraníes, consultable directamente en la base de datos por las herramientas externas.

Excluye

• Todo efecto sobre el cálculo interno de precios.
• La analítica en sí misma y toda superficie de salida: comparaciones, alertas, reportes, vistas SQL, endpoints o pantallas de consulta. El consumo externo lee las tablas directamente.
• El descubrimiento automático de productos o el match automático producto↔página.
• El historial de precios: se conserva estado, no evolución.

3. Requisitos funcionales

RF-1 · Gestión de competidores

1. Listar, dar de alta, editar y desactivar competidores. No eliminar: la baja es desactivación.
2. Definir por competidor: identificación (nombre, código, dominio), moneda y formato numérico del sitio, frecuencia de relevamiento en días y opciones de obtención de página.
3. Definir por competidor la configuración de extracción: para cada dato a obtener (precio de venta, precio de lista, disponibilidad, título), una lista ordenada de reglas — datos estructurados estándar de e-commerce (schema.org) primero, selectores propios del sitio como respaldo. Modificar esta configuración no debe requerir despliegue de código.
4. Probar la configuración desde la pantalla de edición: dada una URL de muestra, mostrar qué valor extrajo cada campo.
5. Auditar los cambios de configuración.

RF-2 · Vinculación producto ↔ página del competidor

1. Asignar a un producto propio (variante) la URL de su página en cada competidor. Solo productos activos. Tener URL cargada es lo que incorpora el producto al universo relevado.
2. Ofrecer dos puntos de carga:
3. un paso en el formulario de confirmación de productos, listando los competidores con un campo para pegar la URL;
4. una pestaña de competencia en la vista del producto, para actualizar y para cargar URLs de productos ya existentes.
5. Validar al cargar: formato de URL, pertenencia al dominio del competidor y unicidad (una URL no puede repetirse en dos productos; un producto admite una URL por competidor).
6. Verificar la URL extrayendo los datos en el momento y mostrándolos para confirmación del operador. En el formulario de confirmación de productos la verificación no debe bloquear el alta del producto: ante fallo, conservar la URL como pendiente de verificación y resolverla luego desde la pestaña.
7. Permitir pausar la vinculación de un producto sin perder la URL cargada.

RF-3 · Relevamiento diario

1. Ejecutar una vez por día. Seleccionar las URLs a relevar según: competidor activo, vinculación activa, producto activo, condición de stock (RF-3.6) y fecha de último relevamiento anterior a la frecuencia del competidor. Procesar lo más antiguo primero.
2. Obtener cada página a través del servicio externo contratado y extraer los campos según la configuración del competidor.
3. Guardar el precio de venta y el precio de lista convertidos a guaraníes, la disponibilidad y el título. Registrar dos fechas por vinculación: último intento y último relevamiento exitoso.
4. Ante fallo de obtención o de extracción, conservar el último valor conocido. No registrar el motivo en base de datos: derivar el estado de error de la divergencia entre las dos fechas.
5. Rechazar valores implausibles (precio no positivo o desviado del último valor más allá del porcentaje parametrizado) sin sobrescribir el dato anterior.
6. Parametrizar si los productos propios sin stock se relevan o quedan fuera del lote.
7. Registrar en un archivo de log dedicado: cabecera de la corrida, una línea por producto relevado (identificando producto, SKU y desenlace) y resumen final con totales por competidor y tipo de fallo. El resumen debe evidenciar la concentración de fallos de extracción que delata un cambio de estructura del sitio.

RF-4 · Disposición de los datos

1. Conservar en base de datos el último estado por producto y competidor, consultable directamente por las herramientas externas. No construir superficie de salida propia: ni vista SQL, ni endpoints, ni pantallas de consulta.
2. Documentar lo necesario para interpretar los datos desde afuera: considerar solo vinculaciones activas y verificadas, precios en guaraníes, y estado del relevamiento derivado de las dos fechas (vigente / con error / roto).
3. No incluir precios propios ni cálculos comparativos.

4. Requisitos no funcionales

#	Requisito
RNF-1	Los datos observados no deben intervenir en ningún cálculo interno de precios
RNF-2	El costo del servicio de obtención de páginas debe ser controlable: renderizado JavaScript desactivado por defecto y activable por competidor; el volumen diario acotado por la frecuencia y la condición de stock
RNF-3	El relevamiento no debe interferir con los procesos de sincronización existentes
RNF-4	La adaptación a cambios de estructura de un sitio debe resolverse editando la configuración del competidor, no código

5. Modelo de datos

erDiagram
    COMPETITOR ||--o{ COMPETITOR_PRICE : "tiene"
    PRODUCT_ITEM ||--o{ COMPETITOR_PRICE : "observado en"

    COMPETITOR {
        string nombre
        string codigo UK
        string dominio
        string moneda "PYG o USD"
        int frecuencia_dias
        json config_extraccion "reglas por campo"
        bool activo
    }

    COMPETITOR_PRICE {
        string url UK "unica por competidor"
        string estado "pendiente / activa / pausada"
        string titulo "control de identidad"
        decimal precio_venta "PYG"
        decimal precio_lista "PYG"
        string disponibilidad
        datetime ultimo_intento
        datetime ultimo_exito
    }

Una fila por producto × competidor (única). El estado de error no se almacena: se deriva de la divergencia entre ultimo_intento y ultimo_exito; la antigüedad del dato, de la distancia entre ultimo_exito y la fecha actual.

6. Flujo de operación

6.1 Vinculación de un producto

flowchart TD
    A[Operador pega URL<br>en formulario de confirmación<br>o pestaña de competencia] --> B{Formato, dominio<br>y unicidad válidos}
    B -- no --> R[Rechazar]
    B -- sí --> C[Extraer datos de la página]
    C -- éxito --> D[Mostrar título y precio<br>al operador]
    D -- confirma --> E[Vinculación activa]
    D -- no es el producto --> R
    C -- fallo o espera --> P[Pendiente de verificación]
    P -. se resuelve luego<br>desde la pestaña .-> C

6.2 Relevamiento diario

flowchart TD
    S[Corrida diaria] --> Q[Seleccionar URLs:<br>competidor y vínculo activos,<br>producto activo, condición de stock]
    Q --> F[Obtener página vía servicio externo]
    F --> X{Extracción válida<br>y plausible}
    X -- sí --> U[Actualizar precios y fechas<br>de intento y de éxito]
    X -- no --> K[Conservar valores;<br>avanzar solo fecha de intento]
    U --> L[Línea de log]
    K --> L
    L --> Z[Resumen de corrida:<br>totales y fallos por competidor]
    Z --> V[(Último estado en base,<br>consultable desde afuera)]

7. Criterios de aceptación

1. Dar de alta un competidor, configurar sus reglas y validar la extracción con el probador, sin intervención de un desarrollador.
2. Vincular un producto desde ambos puntos de carga; verificar que la URL errónea (dominio ajeno, duplicada) se rechaza y que la extracción fallida no impide confirmar el producto.
3. Comprobar que la corrida diaria releva solo lo vencido y elegible, y que un fallo de relevamiento nunca sobrescribe el último valor válido.
4. Ante un cambio simulado de estructura del sitio, comprobar que el resumen del log evidencia la concentración de fallos y que la corrección se resuelve editando la configuración.
5. Consultar desde una herramienta externa, directamente en la base de datos, el último estado observado por producto y competidor.