Documentación del Sistema

Appearance

Preguntas sobre Vendedores ​

Informacion Requerida - Preguntas generadas durante analisis retrospectivo el 2026-02-09

Preguntas Criticas (Afectan la documentacion de negocio) ​

1. Tabla compartida entre modulos (ordven) ​

Observacion: La tabla ordven se crea condicionalmente cuando esta habilitado el modulo de Ventas, CtaCte O CRM (isVentasEnabled() || isCtaCteEnabled() || isCRMEnabled()). Esto indica que el recurso Vendedor es compartido entre multiples modulos del sistema.

Pregunta: Cual es el rol exacto del vendedor en los modulos CtaCte y CRM? Se usa solo como referencia (ej: vendedor asignado a un cliente) o tiene funcionalidad propia en esos modulos?

Impacto: Afecta la seccion de dependencias y alcance del recurso. Si es cross-module, la documentacion debe reflejarlo claramente.

2. Nivel de tenancy configurable (EMPRESA vs SUCURSAL) ​

Observacion: La migracion define getDefaultLevels() como [LEVEL_EMPRESA, LEVEL_SUCURSAL]. Esto significa que la tabla puede existir a nivel empresa (compartida entre sucursales) o a nivel sucursal (cada sucursal tiene sus propios vendedores), segun la configuracion de cada empresa.

Pregunta: Cual es el escenario de negocio mas comun? Los vendedores se comparten entre todas las sucursales o cada sucursal gestiona sus propios vendedores? Que criterio usa la empresa para elegir uno u otro nivel?

Impacto: Afecta la documentacion de reglas de negocio sobre visibilidad y alcance de los datos de vendedores.

3. Relacion vendedor-localidad ​

Observacion: El campo vloc fue migrado de un campo de texto (nombre de localidad) a un entero (ID de localidad). El formulario frontend usa un autocomplete que busca localidades por codigo postal, nombre o provincia.

Pregunta: La localidad del vendedor es obligatoria o simplemente opcional para informacion de contacto? Tiene algun impacto en la asignacion de vendedores a zonas o rutas de venta?

Impacto: Si la localidad tiene impacto en logica de asignacion de zonas, debe documentarse como regla de negocio.

4. Vendedor por defecto "CASA CENTRAL" ​

Observacion: El seed crea un vendedor con codigo 1 y nombre "CASA CENTRAL". Este parece ser un vendedor generico/por defecto del sistema.

Pregunta: El vendedor "CASA CENTRAL" tiene un rol especial? Se usa como vendedor por defecto cuando no se asigna uno especifico? Puede ser eliminado o modificado?

Impacto: Afecta las reglas de negocio sobre eliminacion y datos por defecto del sistema.

5. Campos sin uso en la tabla (vpos, vfoto, password, usuario) ​

Observacion: La migracion documenta explicitamente que los campos vpos, vfoto, password y usuario estan "Sin uso". Sin embargo, se mantienen en la tabla.

Pregunta: Estos campos son remanentes de un sistema anterior? Hay planes de utilizarlos en el futuro (ej: foto del vendedor, acceso al sistema como usuario)? Se pueden considerar deprecados?

Impacto: Afecta la documentacion de la entidad y si deben mencionarse o no en la especificacion.

Preguntas Tecnicas (Afectan la documentacion tecnica) ​

6. Generacion de codigo con MAX(CVEN) + 1 sin transaccion ​

Observacion: El metodo insert() del modelo genera el proximo codigo de vendedor usando SELECT MAX(CVEN) AS CVEN FROM ordven, y luego lo incrementa en 1. Esta operacion no esta envuelta en una transaccion ni usa locks.

Pregunta: Se han observado problemas de duplicacion de codigos en entornos con multiples usuarios concurrentes? Se deberia usar una secuencia de PostgreSQL o un lock FOR UPDATE para garantizar unicidad?

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

Impacto: Potencial race condition documentable como riesgo tecnico.

7. Eliminacion sin verificacion de integridad referencial ​

Observacion: El metodo delete() del modelo realiza un soft delete (UPDATE SET DELETED_AT = NOW()) sin verificar si el vendedor esta asociado a facturas, notas de credito, notas de debito, pedidos, clientes u otros registros (las tablas de facturacion usan el campo vend que referencia al codigo del vendedor).

Pregunta: Se permite eliminar un vendedor que tiene comprobantes asociados? Deberia mostrarse una advertencia o impedirse la eliminacion en ese caso?

Respuesta: No posee FK de momento, sólo FK lógica como muchas de las FK del sistema

Impacto: Riesgo de inconsistencia de datos si se elimina un vendedor referenciado en documentos comerciales.

8. Hook useVendedorData con useState en lugar de TanStack Query ​

Observacion: El hook useVendedorData.ts en el frontend React usa useState + useEffect + api.get() para obtener vendedores, en lugar de usar TanStack Query (useQuery). Sin embargo, existen query keys definidas para vendedores en queryKeys.ts.

Pregunta: El hook esta pendiente de migracion a TanStack Query? Es el patron legacy de integracion parcial?

Respuesta: Se refactorizará en un futuro como todo recurso pero de momento quedan así

Impacto: Afecta la documentacion frontend sobre el patron de state management utilizado.

9. Endpoint registrado fuera del grupo de modulo ventas ​

Observacion: La ruta /vendedor esta registrada directamente en el grupo raiz del backend (junto a external-error-log y fast-view), no dentro del grupo /mod-ventas. Esto significa que la URL es /vendedor en lugar de /mod-ventas/vendedor.

Pregunta: Es intencional esta ubicacion fuera del grupo de modulo? Hay otros recursos que usan el vendedor desde fuera del modulo ventas que requieren esta ruta mas corta?

Impacto: Afecta la documentacion de endpoints y la organizacion del API.

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**: {Texto de la respuesta aqui}

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

Estado de Validacion ​

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