Documentación del Sistema

Appearance

Preguntas sobre Condicion de Venta ​

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

Preguntas Criticas (Afectan la documentacion de negocio) ​

1. Ausencia de operaciones POST y DELETE ​

Observacion: El endpoint legacy (server/backend/condvta.php) solo implementa los metodos HTTP GET y PUT. No existe endpoint para crear (POST) ni eliminar (DELETE) condiciones de venta. El controller (CondicionVentaController) tampoco tiene metodos insert() ni delete().

Pregunta: Las condiciones de venta se crean directamente en base de datos (seed/migracion) o existe otro proceso para darlas de alta? Se pueden eliminar? Cual es la razon por la que no se implementaron estas operaciones?

Impacto: Afecta la documentacion de operaciones disponibles y el tipo de recurso documentado (mantenimiento parcial vs CRUD completo).

2. Restriccion de edicion: solo porcentaje de recargo ​

Observacion: El metodo update() del modelo solo permite modificar el campo porcentaje_recargo. Los campos nombre, defecto, es_tarjeta no son editables desde la interfaz. El campo nombre se muestra como readonly en el formulario del modal.

Pregunta: Es intencional que solo se pueda modificar el porcentaje de recargo? Existe algun otro mecanismo o pantalla de administracion donde se gestionen los demas campos (nombre, defecto, es_tarjeta)? O estos datos se consideran fijos/de sistema?

Impacto: Determina si la documentacion debe reflejar esto como una decision de negocio deliberada o como funcionalidad pendiente.

3. Campo defecto y logica de seleccion por defecto ​

Observacion: El campo defecto (T/F) determina cual condicion de venta se preselecciona automaticamente en facturacion (condiciones.find((e) => e.defecto) ?? condiciones[0]). Sin embargo, no hay logica que garantice que solo una condicion tenga defecto = 'T' (exclusividad). El campo no es editable desde la interfaz.

Pregunta: Debe existir exactamente una condicion de venta marcada como defecto? Que sucede si hay multiples condiciones con defecto = 'T'? Como se gestiona este campo actualmente (solo via base de datos)?

Impacto: Afecta la documentacion de reglas de negocio y validaciones.

4. Columnas sin uso en la tabla condvta ​

Observacion: La migracion define dos columnas con comentario "Sin uso": tipo (VARCHAR(1)) y funesp (VARCHAR(100)). Estas columnas no se usan en el modelo PHP, no se exponen en el DTO ni se muestran en la interfaz.

Pregunta: Estas columnas son herencia de un sistema anterior? Estan planificadas para uso futuro? Se pueden eliminar en una migracion futura?

Impacto: Afecta la completitud de la documentacion de schema de base de datos y puede sugerir una migracion de limpieza.

5. Valores posibles de condicion de venta ​

Observacion: El enum CondicionVenta define tres valores: CONTADO (1), CTA_CTE (2), TARJETA (3). Sin embargo, la tabla condvta no tiene restriccion de foreign key ni CHECK constraint que limite los registros a estos tres valores. El campo cod es un integer libre.

Pregunta: Los valores 1, 2, 3 son los unicos que existiran siempre? Es posible que una empresa tenga condiciones de venta adicionales (ej: cheque, transferencia)? El enum en PHP es solo para logica de negocio o refleja todos los posibles valores?

Impacto: Determina si la documentacion lista las condiciones de venta como fijas (3 tipos) o como catalogo extensible.

Preguntas Tecnicas (Afectan la documentacion tecnica) ​

6. Nivel de tenancy configurable (EMPRESA y SUCURSAL) ​

Observacion: La migracion NewTableCondvta define getDefaultLevels() retornando [LEVEL_EMPRESA, LEVEL_SUCURSAL], y extiende ConfigurableMigration. Esto significa que la tabla puede existir a nivel empresa (compartida entre sucursales) o a nivel sucursal (cada sucursal tiene sus propias condiciones).

Pregunta: En la practica, la mayoria de las empresas tienen las condiciones de venta a nivel EMPRESA (compartidas) o a nivel SUCURSAL (independientes)? El nivel configurable se usa activamente o todas las empresas usan el default?

Impacto: Afecta la documentacion de multi-tenancy y el flujo de datos documentado.

7. Uso del campo es_tarjeta en facturacion ​

Observacion: En el frontend de facturacion (form-header.js), cuando se selecciona una condicion de venta con es_tarjeta = true, se habilita el selector de tarjetas. Ademas, si el modulo Tesoreria esta habilitado y se esta en modo prueba, no se permite seleccionar condicion de venta tipo tarjeta.

Pregunta: La restriccion de tarjeta en modo prueba cuando Tesoreria esta habilitada, a que logica de negocio responde? Es porque las operaciones con tarjeta requieren integracion con Tesoreria y en modo prueba no se deben generar movimientos?

Impacto: Afecta la documentacion de reglas de negocio condicionales y las interacciones entre modulos.

8. Campo porcentaje_recargo tipo DECIMAL(5,3) en base de datos ​

Observacion: La migracion define porcentaje_recargo como decimal(5,3). Esto permite valores de hasta 99.999%. En el frontend, el campo se muestra con badge "P" (porcentaje) via setInputBadge. La validacion del proxy solo verifica numeric|min:0 pero no establece un maximo.

Pregunta: Cual es el rango valido para el porcentaje de recargo? Puede ser mayor a 100%? Es correcto que solo se valida min:0 sin un maximo? El tipo DECIMAL(5,3) es suficiente o se necesita mayor precision?

Respuesta: Los límites siempre deben corresponder a la base de datos, esto añadelo a un TODO.md en Bautista/

Impacto: Afecta la documentacion de validaciones y restricciones de datos.

Como Usar Este Documento ​

Este documento contiene preguntas que surgieron durante el analisis del codigo implementado para "Condicion de Venta" del modulo Ventas. 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 (3)
  • [ ] Respuestas validadas con stakeholders
  • [ ] Documentacion actualizada con respuestas