Appearance
Preguntas sobre Conceptos de Notas
INFORMACION REQUERIDA - Preguntas generadas durante analisis retrospectivo el 2026-02-09
Preguntas Criticas (Afectan la documentacion de negocio)
1. Significado del campo "tipo" (tipcon)
Observacion: El formulario HTML presenta tres opciones para el campo "tipo":
S= "Sin detalle"D= "Con articulos"C= "Cancelacion"
Ademas, en los seeds se observan valores adicionales:
F(en concecre, seed: "POR ANULACION Y/O MODIFICACION DE FACTURA")B(en concecre, seed: "POR BONIFICACION PRONTO PAGO")
Sin embargo, para notas de debito, la opcion "D" (Con articulos) se elimina del formulario en el frontend (linea 57-60 de form-conceptos-notas.js).
Pregunta: Cual es el significado exacto de negocio de cada valor de tipcon? Los valores F y B que aparecen en los seeds no estan disponibles en el formulario actual, fueron deprecados o se cargan de otra manera?
Impacto: El documento de negocio necesita definir claramente los tipos permitidos y su semantica. Los datos semilla contienen valores que no son seleccionables desde la interfaz.
2. Relacion entre conceptos de notas y comprobantes de facturacion
Observacion: En form-header.js (facturacion), se consumen los conceptos de comprobante (concepto-comprobante) con el codigo del comprobante actual. En la tabla credito, el campo concep referencia a CONCECRE.ID. Igualmente en debito el campo concep referencia a CONCEDEB.ID.
En el modelo Minuta.php, se realiza un JOIN manual entre las tablas credito/debito y concecre/concedeb para obtener la cuenta contable de cada concepto, usado en la generacion de asientos contables.
Pregunta: Cual es el flujo completo de negocio? El concepto se selecciona al momento de crear una nota de credito/debito en facturacion, y luego determina la cuenta contable para el asiento? Hay restricciones adicionales sobre que conceptos pueden usarse con que tipos de comprobantes?
Impacto: Afecta la documentacion de las integraciones del recurso y sus casos de uso reales mas alla del ABM.
3. Diferencia entre tablas separadas para credito y debito
Observacion: Existen dos tablas independientes (concecre y concedeb) con exactamente la misma estructura (descri, cuenta, tipcon, id, deleted_at). Se manejan con dos modelos separados (ConceptoNotaCredito, ConceptoNotaDebito) que heredan de ConceptoComprobante. La diferenciacion se realiza mediante el parametro codigo que mapea a los codigos ARCA de tipo de comprobante.
Pregunta: Por que se decidio tener dos tablas separadas en lugar de una sola tabla con un campo discriminador? Es un requerimiento de negocio (los conceptos de credito y debito son fundamentalmente diferentes?) o una decision tecnica heredada?
Impacto: Afecta la comprension de la arquitectura de datos y las decisiones de diseño documentadas.
4. Restriccion de no eliminar el ultimo concepto
Observacion: El metodo delete() en ConceptoComprobante (Model) implementa una restriccion: no se permite eliminar el ultimo registro activo de la tabla. Si se intenta, lanza una excepcion BadRequest("No se puede eliminar el ultimo concepto de comprobante.").
Pregunta: Cual es la razon de negocio para esta restriccion? Es porque al crear un comprobante de nota de credito/debito siempre debe existir al menos un concepto disponible para seleccionar? Hay alguna otra validacion que requiera siempre al menos un concepto?
Impacto: Regla de negocio importante que necesita documentarse con su justificacion.
5. Breadcrumb incorrecto en la vista
Observacion: El breadcrumb de la pagina conceptos-notas.php muestra: Home > Modulo Tesoreria > Valores de Terceros. Sin embargo, esta funcionalidad pertenece al modulo de Ventas (la URL es ?loc=mvcn, el sidebar se encuentra en main-sidebar-venta.php y el permiso es VENTAS_BASES_CONCEPTOS-NOTAS).
Pregunta: Es un error de copia del breadcrumb desde otra vista o esta funcionalidad historicamente pertenecia al modulo de tesoreria y fue movida a ventas?
Impacto: Afecta la documentacion de ubicacion del recurso dentro de los modulos del sistema.
Preguntas Tecnicas (Afectan la documentacion tecnica)
6. Diferencia en tipo de dato del campo "cuenta" entre concecre y concedeb
Observacion: En la migracion de concecre, el campo cuenta se define como decimal(10) (y ademas tiene una migracion legacy que lo altera: 20250417132539_alter_column_concecre_cuenta). En la migracion de concedeb, el campo cuenta se define como biginteger.
Pregunta: Por que los tipos de datos difieren? El campo cuenta referencia al numero de cuenta contable (cuentas.numero). Cual es el tipo correcto? Fue intencional o es una inconsistencia?
Impacto: Afecta la documentacion del esquema de base de datos y puede representar un problema de integridad.
7. Metodo getConceptoAnulacion() - Uso en proceso de anulacion
Observacion: La clase ConceptoNotaCredito tiene un metodo getConceptoAnulacion() que busca un concepto cuya descripcion contenga "anulacion", con fallback al primer concepto activo. Este metodo se usa en el servicio BatchNotaCreditoRegistrationService del modulo de Membresias.
Pregunta: Este metodo tambien se usa en el proceso de anulacion de facturas de ventas? Hay otros procesos que dependan de la existencia de un concepto con la descripcion "anulacion"?
Impacto: Afecta la documentacion de integraciones y dependencias del recurso.
8. Nivel de tenancy: EMPRESA y SUCURSAL
Observacion: Ambas tablas (concecre y concedeb) se definen con getDefaultLevels() retornando [LEVEL_EMPRESA, LEVEL_SUCURSAL]. Esto significa que pueden existir en el schema de empresa (compartido) o en schemas de sucursal. Sin embargo, el endpoint utiliza una sola conexion (Database($db, $schema)) sin distincion entre oficial y principal.
Pregunta: En que nivel se gestionan efectivamente los conceptos de notas? Son compartidos a nivel empresa o cada sucursal puede tener sus propios conceptos? El ConfigurableMigration permite configuracion dinamica, pero cual es la configuracion habitual?
Impacto: Afecta la documentacion sobre el comportamiento multi-tenant de este recurso.
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 (5)
- [ ] Preguntas tecnicas respondidas (3)
- [ ] Respuestas validadas con stakeholders
- [ ] Documentacion actualizada con respuestas