Sistema de Inventarios 3DFAB

Operación de inventario de componentes físicos que necesitaba trazabilidad de movimientos, búsqueda rápida, control por ubicación y alertas para reposición.

La gestión manual dificultaba mantener la trazabilidad y conocer el stock disponible, la ubicación de cada componente y el historial de entradas, salidas o traslados. Eso aumentaba el riesgo de descuadres, compras tardías y tiempo perdido buscando piezas o reconstruyendo quién había realizado una operación.

Diseñé y desarrollé el sistema full-stack en Django: modelo de inventario, reglas de stock, movimientos transaccionales, autenticación, códigos QR, alertas, reportes, pruebas y documentación de despliegue.

El sistema debía operar con datos de componentes físicos y mantenerse útil en un entorno local. También debía conservar compatibilidad con reportes PDF/Excel, evitar exponer registros reales en el portafolio y dejar separada la evidencia pública de la operación interna.

Construí módulos para componentes, categorías, ubicaciones, entradas, salidas, traslados, ajustes, uso en órdenes de trabajo, alertas y búsquedas avanzadas. Integré generación de códigos QR, dashboard con indicadores y exportación de inventario, movimientos y valorización a PDF, Excel o CSV. Los flujos protegidos aplican las reglas de stock y registran quién realizó cada operación.

Aplicación Django 5 con templates server-rendered y una UI progresiva mediante HTMX, Alpine.js y Tailwind CSS. Usa SQLite como configuración local; puede cambiar a PostgreSQL mediante DATABASE_URL para producción. Las reglas de inventario viven en modelos, formularios y vistas, mientras QR, reportes y endpoints autenticados se integran al mismo backend.

Centralicé las reglas en el servidor para que las operaciones no dependieran de la interfaz. Usé transacciones atómicas y bloqueo de fila en los movimientos sensibles, validaciones de dominio para evitar salidas sobre el stock y relaciones protegidas para conservar el historial. HTMX/Alpine permite interacciones ágiles sin convertir este sistema administrativo en una SPA innecesariamente compleja.

La aplicación usa autenticación de Django, vistas protegidas con login, permisos por rol, sesiones HttpOnly, protección CSRF, validaciones server-side, rate limiting en el login y contraseñas gestionadas por el hash PBKDF2 de Django. Los movimientos aplicados usan transacciones e idempotencia para reducir inconsistencias. La configuración de cookies seguras, HTTPS, HSTS y otros headers se activa en producción mediante DEBUG=False y variables de entorno; la revisión local conserva advertencias de despliegue porque esos valores no están habilitados por defecto. No se publican secretos, registros, archivos ni rutas operativas.

La suite del proyecto declara 37 pruebas y cubre modelos, stock, movimientos, permisos, CSRF, sesión, API protegida y rate limiting. La ejecución local con salida UTF-8 comenzó correctamente, pero terminó con 7 errores: el login/admin y varios escenarios de autenticación fallaron por una entrada ausente del static manifest, y un caso de creación de componente reveló un manejo de None en una validación de precio. La ejecución inicial de Windows también encontró un problema de codificación por prints con emojis. Por eso no se presenta una suite aprobada ni un benchmark independiente.

La documentación prepara un despliegue con Gunicorn, WhiteNoise y Nginx o Apache con HTTPS, usando PostgreSQL recomendado, variables de entorno, backups y la comprobación check --deploy. En el estado revisado, el proyecto fuente está configurado para desarrollo/local y check --deploy devuelve seis advertencias de endurecimiento; no afirmo un despliegue productivo verificado. El demo público no conecta con la base de datos ni expone el panel operativo.

El resultado funcional es un flujo centralizado para consultar componentes, ubicar existencias, registrar movimientos, detectar stock bajo y generar reportes operativos. El caso entregado reporta que la búsqueda y auditoría podían resolverse en segundos, pero esa cifra no cuenta con benchmark independiente publicado; debe leerse como resultado reportado, no como garantía general.

Evidencia revisada: documentación, modelos, formularios, vistas, pruebas —incluido tests_security.py— y demo Sistema_de_inventarios.webm. La ficha incluye una muestra aislada de reglas de stock y valorización para evidenciar lógica de dominio sin publicar autenticación, APIs, rutas, datos ni configuración operativa. La comprobación actual confirma que manage.py check pasa; la suite de 37 pruebas y check --deploy tienen las limitaciones descritas arriba. No se incluyen base de datos, datos personales, archivos subidos, secretos ni instrucciones operativas sensibles.