Appearance
Preguntas sobre Condicion IVA
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 en el backend
Observacion: El endpoint legacy server/backend/ordiva.php expone metodos GET, PUT y PATCH pero no POST ni DELETE. Sin embargo, el formulario del frontend (public/js/components/forms/ventas/cond-iva.js) implementa logica para crear nuevos registros via request.post('cond-iva', condIva), lo que significa que el frontend proxy public/php/backend/cond-iva.php no maneja el metodo POST (solo GET, PUT, PATCH). Ademas, el boton de alta en la vista (btn_alta) muestra un mensaje "Esta opcion esta deshabilitada".
Pregunta: Se pueden crear nuevas condiciones de IVA? El boton de alta esta deshabilitado intencionalmente o es una funcionalidad pendiente? Se pueden eliminar condiciones de IVA? Si no, es por restriccion de integridad referencial (ordcon, cpdprov, contactos dependen de ordiva)?
Impacto: Define si documentar como recurso con CRUD completo o solo lectura + modificacion parcial.
2. El boton de alta esta deshabilitado con mensaje informativo
Observacion: En public/js/view/mod-ventas/cond-iva.js linea 59, el boton de alta ejecuta showModal('info', 'Esta opcion esta deshabilitada'). Sin embargo, el formulario (cond-iva.js componente) tiene logica completa para crear registros (linea 97-103: request.post('cond-iva', condIva)).
Pregunta: La creacion de condiciones de IVA estaba habilitada antes y fue deshabilitada? O nunca se implemento completamente? Los codigos de condicion IVA estan regulados por ARCA (ex-AFIP) y por eso no se permite crear nuevos?
Impacto: Determina si la operacion de alta debe documentarse como funcionalidad existente deshabilitada o como funcionalidad no implementada.
3. Campos ipor e ipor2 marcados como "Sin uso" en la migracion
Observacion: La migracion de la tabla ordiva documenta los campos ipor (Porcentaje de IVA aplicado) e ipor2 (Segundo porcentaje de IVA aplicado) como "Sin uso". Sin embargo, los datos seed los populan con valores como 21, 10.5, 0.
Pregunta: Estos campos alguna vez se usaron para calcular IVA? Fueron reemplazados por otra logica? Es seguro ignorarlos en la documentacion o tienen uso en algun proceso no detectado?
Impacto: Afecta la documentacion de la entidad de negocio y sus campos relevantes.
4. Tabla ordiva compartida entre multiples modulos
Observacion: La migracion NewTableOrdiva evalua shouldExecute() verificando si estan habilitados los modulos Ventas, CtaCte, CRM o Compras. La tabla es referenciada por ordcon (clientes), cpdprov (proveedores) y contactos (CRM). El campo civa actua como foreign key en estas tablas.
Pregunta: Cual es el modulo "propietario" de las condiciones de IVA? Es correcto que la documentacion se ubique en el modulo Ventas o deberia estar en un modulo compartido (General/Fiscal)? Cambios en condiciones de IVA afectan a todos los modulos simultaneamente?
Impacto: Define la ubicacion correcta de la documentacion y las dependencias cross-module.
Preguntas Tecnicas (Afectan la documentacion tecnica)
5. Error de sintaxis en el metodo update del modelo
Observacion: En CondicionIva.php linea 103, la sentencia SQL del metodo update() tiene una coma faltante entre ivadiscri = :discrimina_iva y defecto = :defecto. Esto generaria un error de SQL si se ejecutara.
Pregunta: Este metodo de update completo se utiliza en produccion? Se ha detectado este bug? El PUT del frontend envia los campos correctamente pero el SQL fallaria en ejecucion.
Impacto: Documenta un potencial bug en produccion que afecta la operacion de modificacion.
6. Logica de exclusividad del campo "defecto" sin transaccion
Observacion: En CondicionIva::partialUpdate(), cuando se marca una condicion como defecto, primero se ejecuta UPDATE ordiva SET defecto = FALSE (para desmarcar todas) y luego UPDATE ordiva SET defecto = :defecto WHERE civa = :id (para marcar la nueva). Estas dos operaciones no estan envueltas en una transaccion explicita.
Pregunta: Han tenido problemas de concurrencia con esta logica? Si dos usuarios cambian el defecto simultaneamente, podrian quedar dos registros con defecto = true? Deberia documentarse como riesgo de concurrencia?
Respuesta: No hemos tenido inconvenientes aunque sería conveniente cambiarlo en algún momento
Impacto: Afecta la documentacion de reglas de negocio y riesgos tecnicos.
7. Campo "letra" en la tabla ordiva esta "Sin uso" pero existe en Domain Layer
Observacion: La tabla ordiva tiene un campo letra (VARCHAR 2) marcado como "Sin uso" en la migracion. Sin embargo, en el Domain Layer existe TipoComprobanteCatalog que maneja la logica de letras de comprobante (A, B, C) basandose en la condicion IVA del emisor/receptor. La relacion entre la condicion IVA y la letra del comprobante se resuelve en el Domain, no en la tabla.
Pregunta: El campo letra fue reemplazado por la logica del TipoComprobanteCatalog? Es seguro que nunca se lee de la base de datos? Hay codigo legacy que aun lo utilice?
Impacto: Documenta campos deprecados y la evolucion de la arquitectura.
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