Documentación del Sistema

Appearance

Preguntas sobre Cotizacion Dolar ​

INFORMACION REQUERIDA - Preguntas generadas durante analisis retrospectivo el 2026-02-09

Preguntas Criticas (Afectan la documentacion de negocio) ​

1. Ausencia de operaciones DELETE y listado historico ​

Observacion: El backend (server/backend/dolar.php) solo implementa GET (ultima cotizacion) y POST (insertar/actualizar). No existe endpoint para eliminar registros ni para consultar el historial completo de cotizaciones.

Pregunta: Se pueden eliminar cotizaciones anteriores? Existe necesidad de un listado historico de cotizaciones? Actualmente solo se puede ver la ultima cotizacion registrada.

Impacto: Si se requiere historial o eliminacion, la documentacion de negocio debe incluir esos casos de uso. Actualmente solo se documenta "consultar ultima" y "registrar/actualizar".

2. Tabla compartida entre modulos Ventas y Compras ​

Observacion: La migracion NewTableDolar se ejecuta cuando isVentasEnabled() || isComprasEnabled(), y la tabla se crea en niveles EMPRESA y SUCURSAL. El modulo de Compras (subdiario-compras) tambien lee la ultima cotizacion del dolar para registrarla en comprobantes. El modulo sensor legacy tambien lee la tabla para dolarizar montos.

Pregunta: La cotizacion del dolar es un recurso compartido entre Ventas, Compras y Sensores? Deberia documentarse como recurso cross-module? Quien es el "duenio" del recurso?

Impacto: Afecta donde se ubica la documentacion de negocio y si debe haber un modulo "shared" para este recurso.

3. Significado del campo "dolar" en tabla factura ​

Observacion: La tabla factura tiene un campo dolar marcado como "(Sin uso)" en los comentarios de la migracion. Sin embargo, el sensor legacy lee factura.dolar para calcular proyecciones.

Pregunta: El campo dolar en la tabla factura esta realmente en desuso? El sensor legacy esta obsoleto o sigue activo? Se almacena la cotizacion vigente al momento de emitir una factura?

Impacto: Si el campo esta en uso, la documentacion deberia explicar la relacion entre la cotizacion del dolar registrada y las facturas emitidas.

4. Nivel de schema: EMPRESA vs SUCURSAL ​

Observacion: La migracion crea la tabla dolar en niveles EMPRESA y SUCURSAL (getDefaultLevels retorna ambos). Esto significa que cada sucursal podria tener su propia cotizacion, independiente de la empresa.

Pregunta: Cada sucursal maneja su propia cotizacion del dolar? O la cotizacion deberia ser unica a nivel empresa? Tiene sentido que distintas sucursales registren cotizaciones diferentes?

Impacto: Afecta como se documenta el alcance multi-tenant de la funcionalidad y las reglas de negocio sobre unicidad de la cotizacion.

Preguntas Tecnicas (Afectan la documentacion tecnica) ​

5. Upsert sin constraint UNIQUE en fecha ​

Observacion: El POST hace un SELECT para verificar si existe cotizacion del dia, y luego decide entre UPDATE o INSERT. Sin embargo, la tabla dolar no tiene un constraint UNIQUE sobre la columna fecha (segun la migracion). Esto podria generar duplicados en caso de requests concurrentes.

Pregunta: Se han detectado duplicados de cotizacion para la misma fecha? Deberia existir un constraint UNIQUE en fecha? El patron upsert deberia usar INSERT ... ON CONFLICT en lugar de SELECT + INSERT/UPDATE separados?

Respuesta: No hemos tenido inconvenientes aunque sería conveniente cambiarlo en algún momento

Impacto: Afecta la documentacion de reglas de negocio (unicidad por fecha) y la documentacion tecnica (patron de persistencia).

6. API externa dolarapi.com ​

Observacion: El frontend consume https://dolarapi.com/v1/ambito/dolares/oficial y https://dolarapi.com/v1/ambito/dolares/blue para mostrar cotizaciones de referencia. Esta API es externa y no controlada por el sistema.

Pregunta: La API dolarapi.com es confiable para uso en produccion? Existe un plan de contingencia si la API deja de funcionar o cambia su estructura? Se deberia cachear la respuesta? Se podria usar para pre-cargar automaticamente el valor del dolar?

Impacto: Afecta la documentacion de dependencias externas y la robustez de la funcionalidad.

7. Redireccion post-guardado ​

Observacion: Despues de guardar exitosamente, el frontend redirige al menu principal de ventas (?loc=mv). No hay posibilidad de registrar multiples cotizaciones consecutivas ni de permanecer en la pantalla.

Pregunta: Es intencional que al guardar se vuelva al menu? Se necesitaria un flujo para registrar cotizaciones de varios dias seguidos? O el uso tipico es registrar una sola cotizacion por sesion?

Impacto: Afecta la documentacion de flujos de usuario y experiencia.

Como Usar Este Documento ​

Este documento contiene preguntas que surgieron durante el analisis del codigo. Cada pregunta incluye espacio para agregar la respuesta:

Formato de respuesta:

Respuesta:

Una vez respondidas, estas respuestas se incorporaran a la documentacion final.

Estado de Validacion ​

  • [ ] Preguntas criticas respondidas (4)
  • [ ] Preguntas tecnicas respondidas (3)
  • [ ] Respuestas validadas con stakeholders
  • [ ] Documentacion actualizada con respuestas