StockiFy

Qué Problema Resuelve

Dolor específico que ataca

StockiFy ataca el problema real del negocio chico: no tener control confiable del inventario y la operación. No alcanza con un listado de productos: hace falta stock actualizado por movimientos, historial, entidades y caja.

Situación previa sin la solución

• Stock llevado “a ojo” o en Excel, con errores y datos desactualizados.
• Ventas sin trazabilidad real: no queda claro qué se vendió, cuándo, a quién y bajo qué condiciones.
• Compras cargadas tarde o mal, sin impacto automático en stock.
• Importaciones sucias (CSV con delimitadores raros, encoding roto, números con símbolos) que rompen la base.

Impacto real de implementarlo

• Stock actualizado por operación (venta/compra) con menor margen de error.
• Orden administrativo: clientes, proveedores, empleados y medios de pago correctamente modelados.
• Lectura rápida del negocio (dashboard, métricas, balance de caja).
• Escalabilidad operativa: múltiples inventarios por usuario, con estructura consistente.

Explicación Técnica

Stack detallado

• Backend: PHP (arquitectura modular con Controllers/Models/Services) + Composer.
• Base de datos: MySQL con PDO y prepared statements.
• Frontend: HTML/CSS + JavaScript vanilla modular, organizado por dominios.
• Integraciones:
• Google OAuth (login con Google).
• PHPMailer para correos transaccionales (OTP y seguridad de cuenta).
• Servicio de tipo de cambio (dólar) consumido por API externa con cache local.
• Configuración: variables sensibles por .env (dotenv).
• Autenticación: sesiones PHP + helpers de usuario actual.

Arquitectura general

StockiFy está armado como un monolito web modular con un MVC práctico: páginas y UI en public/, lógica de negocio en src/ y endpoints JSON en public/api/.

Organización de carpetas

• public/: páginas del producto + assets + endpoints api/.
• src/: Controllers / Models / Services / core (DB) / helpers.
• vendor/: dependencias Composer.

Principales módulos

• Auth / User: login tradicional + Google OAuth + OTP (acciones sensibles).
• Inventarios: múltiples “bases” por usuario, con preferencias por inventario.
• Tabla dinámica de productos: CRUD + administración de columnas.
• Importación CSV: detección de delimitador, normalización UTF-8, sanitización de headers, limpieza de numéricos, import masivo.
• Ventas: ventas + ítems, cliente/empleado/medio de pago, totales, vuelto, comisión, comprobante.
• Compras: compras + ítems, proveedor, impacto en stock.
• Entidades: clientes, proveedores, empleados y medios de pago (CRUD).
• Analytics: dashboard, métricas y balance de caja.
• Notificaciones: avisos por usuario/inventario.

Gestión de datos

El núcleo técnico está en el soporte de multi-inventario y una estrategia de tablas de productos por inventario, combinada con metadata (columnas y preferencias) para mantener flexibilidad sin perder operatividad.

Seguridad

• PDO + prepared statements para reducir riesgo de inyección SQL.
• Sesiones PHP para control de autenticación y contexto.
• OTP con expiración para cambios sensibles (mail/contraseña).
• Sanitización de nombres de columnas/tablas (clave si se trabaja con estructura dinámica).

Decisiones técnicas relevantes

• Tablas dinámicas por inventario: prioriza flexibilidad real por rubro/negocio, con control estricto de sanitización.
• Frontend vanilla modular: menos dependencia, más control del producto y performance predecible.
• Integraciones pragmáticas: Google OAuth, mail transaccional y tipo de cambio local con cache.

Arquitectura del Sistema

Tipo de arquitectura

Monolito web modular con un MVC práctico: Views (páginas y UI), Controllers (casos de uso), Models (acceso a datos) y Services (integraciones).

Separación de capas

• UI: páginas PHP + módulos JS que consumen endpoints.
• API: endpoints en public/api/* que validan request, sesión y devuelven JSON.
• Negocio: Controllers orquestan reglas y llaman Models.
• Datos: Models ejecutan queries/transacciones vía PDO.
• Integraciones: Services encapsulan mail, OAuth y tipo de cambio.

Interacción entre componentes (diagrama textual)

• UI (JS) → fetch('/api/...')
• Endpoint (public/api/x/y.php) → instancia Controller
• Controller → valida sesión → llama Model/Service
• Model → DB (PDO) → queries/transacciones
• Response → JSON → UI renderiza/actualiza

Features (Funcionalidades)

Core (negocio)

• Multi-inventario por usuario (crear/seleccionar/administrar).
• Gestión de productos: alta/edición/borrado, con estructura flexible por inventario.
• Ventas: ventas con ítems, totales, vuelto, comisión, notas y comprobante.
• Compras: compras con ítems y proveedor, impacto directo sobre stock.
• Stock actualizado por movimiento (venta/compra) y consistencia operativa.

Entidades administrativas

• Clientes (CRUD).
• Proveedores (CRUD).
• Empleados (CRUD).
• Medios de pago (CRUD).

Analítica y operación

• Dashboard con métricas y balance de caja.
• Historiales/records por operaciones.
• Notificaciones por usuario/inventario.

Plataforma / técnica

• Login tradicional + Google OAuth.
• OTP para acciones sensibles (cambio de email/contraseña).
• Importación masiva CSV con normalización de delimitador, encoding y limpieza de campos.
• Configuración por .env y dependencias vía Composer.

Estado del Desarrollo