Appearance
Preguntas sobre Carteras
Informacion Requerida - Preguntas generadas durante analisis retrospectivo el 2026-02-09
Preguntas Criticas (Afectan la documentacion de negocio)
1. Ausencia de operacion DELETE - Contexto especifico de Carteras
Observacion: El backend (server/backend/carteras.php) implementa GET, POST y PUT, pero no existe un endpoint DELETE. El modelo Cartera.php tampoco tiene un metodo de eliminacion (ni siquiera soft delete).
Pregunta: No se pueden eliminar carteras porque hay clientes asignados a carteras y no se quiere perder referencia, o es funcionalidad pendiente de implementar?
Impacto: Determina si la documentacion debe indicar "las carteras no se pueden eliminar" como regla de negocio, o si debe listarse como funcionalidad faltante.
Respuesta: No existe deleted_at en casi ningun legacy resource. Carteras conserva referencias de clientes por integridad referencial.
2. Tabla deu_acr compartida como "carteras de proveedores"
Observacion: El modelo Cartera.php en su metodo getAll() tiene doble comportamiento: cuando tipo === 'cliente' consulta la tabla carteras, pero cuando tipo === 'proveedor' consulta la tabla deu_acr (que es la tabla de terceros/proveedores). Los campos difieren significativamente: para proveedores devuelve codigo, descri y cuenta, mientras que para clientes devuelve ccar y nombre.
Pregunta: Es correcto que la "cartera de proveedores" sea realmente la tabla de acreedores/deudores (deu_acr) y no una tabla de agrupacion similar a carteras? El concepto de "cartera" para proveedores tiene un significado distinto al de clientes?
Impacto: Afecta fundamentalmente la descripcion de la entidad de negocio. Si las carteras de proveedores son en realidad registros de un concepto diferente (acreedores/deudores), la documentacion debe reflejar esta dualidad con precision.
3. Campo cuenta en la tabla carteras no utilizado
Observacion: La migracion de la tabla carteras define tres columnas: ccar (smallinteger, PK), cuenta (decimal, nullable) y nombre (string). Sin embargo, el campo cuenta no se utiliza en ningun lugar del codigo analizado: no se lee en getAll(), no se escribe en insert() ni en update(), y no aparece en el formulario frontend.
Pregunta: Cual es el proposito del campo cuenta? Es una referencia a una cuenta contable? Deberia estar visible/editable en el formulario de carteras? O es un campo legacy sin uso actual?
Impacto: Si el campo cuenta tiene un proposito de negocio (vinculacion contable), deberia documentarse como funcionalidad existente pero no expuesta en la UI. Si es legacy, se documentara como campo sin uso.
Respuesta: No se les dio uso de momento. TODO: Investigar si el campo cuenta tiene proposito contable futuro o debe eliminarse.
4. Funcionalidad condicional por empresa (flag cartera en empres)
Observacion: La tabla empres tiene un campo booleano cartera que determina si la empresa maneja carteras. En el sidebar del frontend, la opcion de Carteras solo aparece si $empres['cartera'] es true. Tambien la migracion de la tabla carteras solo se ejecuta si empres.cartera es true.
Pregunta: Cuando una empresa no maneja carteras, que sucede con el campo ccar en la tabla de clientes (ordcon)? Se ignora? Los clientes quedan sin agrupacion? O hay un comportamiento por defecto?
Impacto: Afecta la documentacion de precondiciones y la relacion entre la configuracion de empresa y la funcionalidad de carteras.
Preguntas Tecnicas (Afectan la documentacion tecnica)
5. Race condition en generacion de ID (MAX(ccar) + 1)
Observacion: El metodo insert() en Cartera.php genera el nuevo ccar con MAX(ccar::int) + 1 sin usar transaccion explicita ni bloqueo. Si dos usuarios crean carteras simultaneamente, podrian obtener el mismo ID.
Pregunta: Se han detectado problemas de duplicacion de codigos en produccion? Se deberia documentar como riesgo conocido? Existe algun mecanismo externo (constraint UNIQUE en BD) que proteja contra esto?
Impacto: Afecta la documentacion tecnica en cuanto a integridad de datos y posibles problemas de concurrencia. Tambien podria requerir una recomendacion de mejora.
Respuesta: No hemos tenido inconvenientes aunque seria conveniente cambiarlo en algun momento. TODO: Evaluar migracion a secuencias de PostgreSQL para generacion de IDs.
9. CarteraSelect ubicado en modulo ctacte en lugar de ventas
Observacion: Los componentes React de Cartera (CarteraSelect.tsx, ControlledCarteraSelect.tsx, useCarteraData.ts, carteras.ts) estan ubicados en public/ts/ctacte/ (modulo Cuenta Corriente), no en public/ts/ventas/. Sin embargo, la pagina de ABM de carteras esta en view/mod-ventas/cartera.php.
Pregunta: La ubicacion en ctacte es intencional porque CarteraSelect se usa principalmente en contextos de cuenta corriente? O es un recurso compartido que deberia estar en core/ o shared/?
Impacto: Afecta la documentacion tecnica frontend en cuanto a la organizacion del codigo y las dependencias entre modulos.
10. Seed de cartera "General" por defecto
Observacion: El seed Carteras.php crea automaticamente una cartera con ccar=1 y nombre='General' cuando la tabla esta vacia.
Pregunta: La cartera "General" tiene un significado especial en el negocio? Es la cartera por defecto que se asigna a nuevos clientes? Puede ser eliminada o modificada? Hay logica que dependa de que exista la cartera con ID 1?
Impacto: Afecta la documentacion de datos por defecto y restricciones de negocio. Si la cartera General es inmutable, debe documentarse como restriccion.
6. Formulario HTML con maxlength=20 vs campo BD de 30 caracteres
Observacion: El formulario HTML (cartera.html) define maxlength="20" para el campo denominacion, y el proxy frontend valida max:20. Sin embargo, la columna nombre en la tabla carteras tiene un limite de 30 caracteres.
Pregunta: Cual es el limite correcto? 20 caracteres (como en el frontend) o 30 caracteres (como en la BD)? Es una inconsistencia intencional?
Impacto: Afecta la documentacion de validaciones. La documentacion debe reflejar el limite real que se aplica, que actualmente es 20 (limitado por el frontend).
Respuesta: Los limites siempre deben corresponder a la base de datos. TODO: Ajustar validacion frontend de 20 a 30 caracteres para alinear con BD.
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
- [ ] 6 preguntas especificas requieren validacion con stakeholders
- [ ] 3 preguntas genericas respondidas con respuestas estandar
- [ ] Documentacion actualizada con respuestas