Documentación del Sistema

Appearance

Preguntas sobre Tarjetas ​

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

Preguntas Criticas (Afectan la documentacion de negocio) ​

1. Integridad referencial al eliminar tarjetas ​

Observacion: El endpoint DELETE realiza un soft delete sin verificar si la tarjeta esta referenciada por comprobantes existentes (facturas, notas de credito, notas de debito) a traves del campo id_tarjeta.

Pregunta: Al eliminar una tarjeta que ya fue utilizada en comprobantes, que deberia suceder? Se permite eliminar? Se deberia mostrar un warning? Se deberia bloquear la eliminacion?

Impacto: Afecta la documentacion de reglas de negocio y restricciones de eliminacion. Podria ser necesario agregar un criterio de aceptacion adicional.

2. Relacion entre tarjetas y medios de pago de CRM ​

Observacion: En el modulo CRM (view/mod-crm/medios-pago.php) existe un checkbox "Marcar aqui si se trata de una tarjeta de credito o entidad crediticia". Esto sugiere que existe un concepto separado de "medios de pago" que tambien puede representar tarjetas.

Pregunta: Cual es la relacion entre las tarjetas de ventas y los medios de pago de CRM? Son entidades independientes o deberian estar vinculadas? Un medio de pago de tipo tarjeta deberia referenciar a una tarjeta de ventas?

Impacto: Afecta la documentacion de relaciones entre entidades y potencialmente la arquitectura de integracion entre modulos.

3. Ausencia de campo unico para nombre de tarjeta ​

Observacion: No existe restriccion UNIQUE en la columna nombre de la tabla tarjetas. Esto permite crear multiples tarjetas con el mismo nombre (por ejemplo, dos registros "Visa").

Pregunta: Deberia el nombre de tarjeta ser unico? Es intencional permitir duplicados (por ejemplo, "Visa Credito" y "Visa Debito" ambos llamados simplemente "Visa")?

Impacto: Afecta las reglas de negocio documentadas y potencialmente la validacion de datos.

Preguntas Tecnicas (Afectan la documentacion tecnica) ​

4. Tipo de dato DECIMAL para campo cuenta ​

Observacion: En la migracion, el campo cuenta se define como DECIMAL(10) pero en el DTO se trata como ?int y en el validador como nullable|integer. En PostgreSQL, DECIMAL(10) almacena numeros con hasta 10 digitos sin decimales, pero es un tipo numerico no entero.

Pregunta: Por que se usa DECIMAL en lugar de INTEGER para el campo cuenta? Es porque los numeros de cuenta del plan de cuentas pueden tener formato con decimales? O fue una decision accidental?

Impacto: Afecta la documentacion del esquema de base de datos y la consistencia entre migracion, DTO y validador.

5. getById no filtra por deleted_at ​

Observacion: El metodo Tarjeta.getById() no incluye WHERE deleted_at IS NULL, a diferencia de getAll(). Esto permite obtener tarjetas eliminadas por su ID.

Pregunta: Es intencional? Es necesario para que la facturacion pueda resolver el nombre de tarjetas usadas en comprobantes historicos (emitidos antes de que la tarjeta fuera eliminada)?

Respuesta: No existe deleted_at en casi ningún legacy resource

Impacto: Afecta la documentacion del modelo de datos y el comportamiento de consultas.

6. HTTP Status 200 en lugar de 201 para creacion ​

Observacion: El controller retorna status 200 para la operacion de creacion (POST) en lugar del estandar HTTP 201 Created.

Pregunta: Es intencional o deberia corregirse a 201? El frontend no depende del status code para la logica.

Impacto: Afecta la documentacion de la API y la conformidad con estandares REST.

7. Sidebar activa item de "Clientes" en lugar de "Tarjetas" ​

Observacion: En tarjetas.php, el script de activacion del sidebar activa idMainSideBarClientes en lugar de idMainSideBarTarjetas. Esto hace que al entrar a la vista de tarjetas, el item "Clientes" aparezca como activo en el sidebar.

Pregunta: Es un bug? Deberia activarse idMainSideBarTarjetas para que el item correcto se resalte en el sidebar?

Impacto: Afecta la documentacion de la interfaz de usuario y la experiencia del usuario.

8. Atributo max en lugar de maxlength en input ​

Observacion: El input de nombre en el formulario usa max="100" en lugar de maxlength="100". El atributo max es para inputs numericos (tipo number, range, date), no para inputs de texto. Para limitar la longitud de texto, deberia usarse maxlength.

Pregunta: Es un bug conocido? El campo nombre podria aceptar mas de 100 caracteres en el frontend (aunque el backend lo validaria con max:100)?

Impacto: Afecta la documentacion de validaciones frontend y podria requerir una correccion.

9. Ausencia de indices en la tabla tarjetas ​

Observacion: La migracion no crea indices adicionales mas alla del PRIMARY KEY implicito en id. No hay indice en deleted_at ni en nombre.

Pregunta: Dado el bajo volumen esperado de datos, se considera innecesario? O deberia documentarse como mejora futura?

Impacto: Afecta la documentacion de rendimiento y esquema de base de datos.

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 (3)
  • [ ] Preguntas tecnicas respondidas (6)
  • [ ] Respuestas validadas con stakeholders
  • [ ] Documentacion actualizada con respuestas