Sistema de Inventarios 3DFAB

01Contexto

3DFAB trabaja con componentes físicos y materiales de fabricación. El inventario agrupa la información de cada pieza con su categoría, ubicación principal, cantidad disponible y umbral de reposición. Las órdenes de trabajo relacionan los materiales utilizados con un trabajo concreto.

Desarrollé todo el sistema y se encuentra actualmente operativo. No se dispone de un número confirmado de usuarios ni de mediciones de uso real; la ejecución descrita aquí corresponde a un laboratorio local.

02Problema

Consultar una cantidad aislada no explica dónde está el componente ni qué operación la cambió. El problema del dominio es reunir catálogo, ubicación, movimientos y consumo en trabajos, además de señalar existencias que necesitan reposición.

La consistencia requiere distinguir un movimiento pendiente de uno aplicado y comprobar las operaciones repetidas o simultáneas. Un historial disponible no demuestra, por sí solo, que todo saldo físico tenga una apertura documentada.

03Mi rol

Diseñé y desarrollé la solución completa en Django: modelos y relaciones, formularios, vistas, reglas de existencias, interfaz, QR, alertas, reportes, pruebas y documentación. La atribución procede de mi confirmación, no de inferir responsabilidades a partir de Git.

Esta revisión del caso de estudio inspecciona y prueba una copia del producto. No incorpora reparaciones funcionales al repositorio fuente.

04Restricciones

La validación debía funcionar en local sin tocar datos ni servicios del taller. Se excluyeron credenciales, base de datos existente, archivos subidos y registros; únicamente se copiaron código, documentación y archivos de configuración necesarios.

No hay lockfile de Python y algunas dependencias no tienen versión exacta. Se reutilizó el entorno instalado, registrando sus versiones, sin actualizar paquetes para conseguir pruebas aprobadas. PostgreSQL, correo externo, lectores físicos y recuperación de respaldos quedan fuera de la ejecución.

05Solución

El catálogo reúne componentes, categorías, ubicaciones, fotografías y especificaciones. Las búsquedas combinan nombre, código, categoría, ubicación y estado de stock; las listas usan paginación y relaciones precargadas.

Los movimientos permiten entrada, salida, traslado y ajuste por conteo. El consumo en órdenes de trabajo genera salidas. Las señales crean alertas y códigos QR; los reportes producen PDF, Excel y CSV. El QR contiene una instantánea informativa del componente y no prueba un flujo integrado de escaneo móvil. Los indicadores se calculan al consultar la página, sin acreditar actualización continua.

06Arquitectura y modelo de datos

Monolito Django 5: autenticación y sesiones → vistas y formularios → modelos de dominio → persistencia. Las páginas se renderizan en el servidor, con HTMX para consultas y Alpine.js para interacción. Tailwind y Chart.js se cargan desde servicios externos en las plantillas revisadas.

El modelo incluye categorías, ubicaciones, componentes, historial de movimientos, órdenes, uso de componentes y alertas. QR e imágenes se almacenan como archivos, fuera de las transacciones de la base de datos.

SQLite es el motor predeterminado. DATABASE_URL contempla PostgreSQL, con paquetes adicionales descritos en la guía y ausentes del manifiesto principal. No se ejecutó ese motor. La presencia de select_for_update() no aporta bloqueo de fila en SQLite.

07Flujo principal de inventario

Recorrido comprobado mediante el cliente HTTP de Django, con CSRF activo: iniciar una sesión de prueba, crear un componente sin existencias, registrar una entrada de diez unidades, aplicar el movimiento y consultar su ficha y respuesta de stock. Se verificaron cantidad persistida, estado aplicado y usuario asignado por el servidor.

La prueba de dominio recorrió salida, reposición, traslado y ajuste: comprobó saldos, cambio de ubicación y creación/resolución de alertas. El navegador confirmó inicio de sesión y presentación del catálogo sintético. Son recorridos locales, no evidencia de operación continua ni pruebas de un lector físico.

08Concurrencia e integridad de existencias

La aplicación del movimiento agrupa actualización de stock y estado del historial en una transacción. Una salida superior al saldo se rechazó sin cambios. Al simular un fallo después de escribir el stock, se revirtieron saldo, movimiento y alerta; una nueva lectura permitió reintentar correctamente.

Dos retiradas solapadas sobre diez unidades usaron hilos y conexiones reales a SQLite, sincronizados durante la lectura: una se aplicó, la otra recibió un error de bloqueo; quedaron dos unidades y un movimiento aplicado. Esto demuestra contención, no un manejo satisfactorio de concurrencia ni un resultado trasladable a PostgreSQL.

Las pruebas detectaron repetición de efectos con objetos desactualizados y al volver a guardar consumos de órdenes. También comprobaron que un saldo inicial introducido directamente no genera un movimiento de apertura. Por ello, idempotencia completa y conciliación exhaustiva permanecen pendientes de refuerzo.

09Decisiones de arquitectura

Django concentra formularios, ORM, autenticación y administración en una aplicación mantenible. HTMX permite enriquecer consultas sin duplicar toda la interfaz en un cliente separado; es una decisión coherente con el producto, no una comparación de rendimiento entre frameworks.

Las transacciones atómicas limitan escrituras parciales de movimientos. El bloqueo solicitado por el ORM depende del motor: PostgreSQL contempla bloqueo de fila, SQLite no implementa esa operación. Cambiar de motor requiere pruebas propias.

Las señales automatizan QR y alertas. El QR se guarda sin disparar otra cadena de señales, pero un fallo de archivo conserva el componente sin etiqueta y no establece recuperación automática.

La documentación describe correcciones previas en QR, stock, formularios y consultas. No se encontraron ADR numerados que respalden las referencias anteriores de la ficha.

10Seguridad y control de acceso

Implementado: autenticación Django, contraseñas PBKDF2, cookies de sesión HttpOnly, middleware CSRF y controles de configuración para HTTPS. Comprobado localmente: redirección de visitantes sin sesión, rechazo de POST sin CSRF y acceso con una cuenta sintética.

La separación por rol de la interfaz general no quedó aprobada. La existencia de grupos y permisos en la administración no equivale a su aplicación en cada vista. El inventario es compartido y no se presenta como aislamiento entre clientes.

El rate limiting existe y una prueba con caché limpia observó el bloqueo esperado; los casos originales comparten estado de caché y una ejecución adicional varió entre ventanas del limitador. No se acredita resistencia global a abuso. La configuración local conserva cinco advertencias de despliegue; producción no fue auditada. No se publican rutas operativas, secretos ni registros del taller.

11Pruebas y alcance de validación

Se ejecutaron módulos reales en una copia aislada: Python 3.12.10, Django 5.0.1 y SQLite en archivo, sin copiar el entorno operativo. El arranque local, las migraciones, el análisis sintáctico y la comprobación de dependencias se completaron. No existe una tarea dedicada de lint ni de tipos en el proyecto.

La primera ejecución original dio 30 aprobados y 7 errores. Tras collectstatic, sin cambiar aserciones ni código, quedaron 32 aprobados, 4 fallos y 1 error. Los cuatro fallos corresponden al limitador y su presentación; el error combina un cliente sin enforcement CSRF con validación de precio ausente.

Las 15 comprobaciones adicionales terminaron con 9 aprobadas y 6 fallidas. La tabla separa lo comprobado de los incumplimientos: reproducir un defecto no lo convierte en una garantía aprobada. No se midió cobertura, carga máxima ni latencia productiva.

12Despliegue y entorno

Operativo en el taller 3DFAB. La guía plantea Gunicorn y WhiteNoise, proxy Nginx/Apache, HTTPS, PostgreSQL y respaldos. Son instrucciones de despliegue, no evidencia de que esa topología describa la instancia actual.

Se arrancó únicamente el servidor de desarrollo en loopback sobre la base sintética. Se generaron los estáticos exigidos por la configuración y se verificó el acceso desde el navegador. No se inspeccionaron infraestructura productiva, correo, restauraciones, disponibilidad ni dispositivos del taller.

13Resultado y estado actual

El resultado entregado es una aplicación que reúne consulta de piezas, ubicación, movimientos, alertas y reportes. Desarrollé la totalidad del sistema y se encuentra en operación activa. La ejecución respalda el recorrido básico de inventario y aporta límites concretos para priorizar mejoras.

No hay evidencia suficiente para cuantificar ahorro, rapidez de búsqueda, reducción de errores o disponibilidad. Tampoco se afirma equivalencia absoluta entre stock físico e historial. El valor demostrado es centralizar el trabajo y hacer visibles sus reglas y estados.

14Evidencia y límites

Implementado: modelos, formularios, vistas, señales y exportaciones inspeccionados. Comprobado localmente: suite original, comprobaciones adicionales, arranque, recorrido HTTP y presentación en navegador. Simulado: fallo al guardar el movimiento y fallo de generación de QR. Alcance: desarrollo propio y estado operativo. No comprobado: entorno productivo, PostgreSQL, lectura física de QR, correo y restauración.

La revisión incluyó los cambios locales de configuración numérica y dashboard. Las copias se contrastaron mediante SHA-256; el repositorio fuente se conservó intacto. El registro saneado y el entorno reproducible permanecen internos; esta página explica método y resultados sin ofrecer descargas.

15Calidad de software y UX de taller

El catálogo y los formularios reúnen las operaciones del taller; mensajes, estados pendientes y alertas facilitan interpretar qué quedó registrado. La búsqueda y la paginación limitan el volumen presentado; select_related reduce consultas repetidas en listados.

Calidad de software significa comprobar las reglas de inventario y sus fallos, no sumar pruebas aprobadas. La revisión añade escenarios de reenvío, concurrencia, rollback y exportaciones que el recorrido feliz no cubría.

La UX del producto depende de recursos externos para estilos e interacción; no se acredita funcionamiento completo sin red. Esta ficha ofrece índice, navegación entre proyectos, diagrama legible y código ajustable en móvil. No se presenta una puntuación de accesibilidad ni un benchmark.

16Muestra de código y prueba de ingeniería

Adaptación pública y autocontenida de una regla de salida: validar cantidad, rechazar sobregiro y calcular si se alcanza el umbral. Requiere Python 3 y solo su biblioteca estándar. Se ejecutaron exactamente los dos bloques concatenados. No importa código reservado ni sustituye las transacciones reales del sistema.

1
def plan_dispatch(stock, quantity, minimum):
2
    """Regla pura de stock: sin base de datos, red ni código reservado."""
3
    values = (stock, quantity, minimum)
4
    if any(type(value) is not int for value in values):
5
        raise ValueError("Se requieren valores enteros")
6
    if stock < 0 or minimum < 0 or quantity <= 0:
7
        raise ValueError("Stock o cantidad no válidos")
8
    if quantity > stock:
9
        raise ValueError("Stock insuficiente")
10
    remaining = stock - quantity
11
    return remaining, remaining <= minimum

1
import unittest
2
3
class StockRuleTest(unittest.TestCase):
4
    def test_dispatch_and_threshold(self):
5
        self.assertEqual(plan_dispatch(10, 8, 3), (2, True))
6
7
    def test_threshold_boundary(self):
8
        self.assertEqual(plan_dispatch(10, 7, 3), (3, True))
9
10
    def test_above_threshold(self):
11
        self.assertEqual(plan_dispatch(10, 2, 3), (8, False))
12
13
    def test_exact_stock(self):
14
        self.assertEqual(plan_dispatch(10, 10, 0), (0, True))
15
16
    def test_reject_invalid_inputs(self):
17
        for values in [(10, 11, 3), (10, 0, 3), (-1, 1, 0),
18
                       (10, 1, -1), (10, True, 3), (10, 1.5, 3)]:
19
            with self.subTest(values=values):
20
                with self.assertRaises(ValueError):
21
                    plan_dispatch(*values)
22
23
unittest.main()

5 pruebas aprobadas; el caso de entradas inválidas incluye 6 subcasos. Comprueba exclusivamente esta regla pura: no demuestra concurrencia, permisos, persistencia ni operación productiva.