# Depósito Elías — Fase 0 Base Laravel 12 con interfaz Blade en español inspirada visualmente en TailAdmin, implementada con Bootstrap 5. No incluye Productos, Inventario ni facturación electrónica. ## Instalación 1. `composer install` 2. Copiar `.env.example` a `.env` y configurar MariaDB. 3. `php artisan key:generate` 4. `php artisan migrate --seed` 5. `php artisan storage:link` 6. `php artisan serve` Acceso inicial: `admin@depositoelias.local` / `ChangeMe123!`. Cambiar la contraseña inmediatamente. ## Migraciones y rutas Se crean `roles`, `permissions`, `role_user`, `permission_role`, `settings` y `activity_logs`. Los usuarios admiten estado, último acceso y eliminación lógica. `/login` es pública; `/dashboard` y `/users` requieren autenticación y los usuarios requieren `users.view`. Logout usa POST y CSRF. ## Decisiones - Código/base de datos en inglés e interfaz en español. - MariaDB mediante driver `mysql` y zona horaria `America/Guayaquil`. - RBAC nativo, sin dependencia externa. - Facturación electrónica reservada para `app/Services/ElectronicBilling/` en una fase futura. ## Prueba manual Iniciar sesión, comprobar el panel, crear/editar un usuario, asignarle un rol, cerrar sesión y confirmar que `/dashboard` redirige al login. ## Fase 1 — Catálogos y productos La migración `2026_08_16_010000_create_catalogs_and_products_tables.php` añade categorías, marcas, unidades, presentaciones y productos. Todos los catálogos tienen código único, estado y eliminación lógica. Los productos incluyen SKU, descripción, relaciones de catálogo, contenido, unidad, código de barras, retornabilidad, fotografía, stock mínimo y observaciones. Rutas principales: `/products` y `/catalogs/{categories|brands|units|presentations}`. Las fotografías se validan como JPG, PNG o WebP de máximo 4 MB y se guardan en el disco público de Laravel; ejecutar `php artisan storage:link` para mostrarlas. Después de actualizar desde Fase 0: `php artisan migrate`, `php artisan db:seed` y `php artisan storage:link`. ## Fase 2 — Compras e inventario Se añadieron proveedores, compras y detalles, lotes independientes y movimientos de kardex. Las compras se guardan en `DRAFT`; solamente la acción de recepción genera lotes. `ReceivePurchaseService` usa transacción y bloqueo pesimista, comprueba nuevamente el estado y registra un movimiento `PURCHASE` por lote. Las cantidades y valores usan `DECIMAL(15,4)` y los cálculos monetarios backend utilizan BCMath. Rutas: `/suppliers`, `/purchases`, `/inventory/batches` y `/inventory/kardex`. Los documentos se almacenan en el disco privado. Una recepción ya ejecutada no puede repetirse por la validación del estado bajo bloqueo. ## Fase 3 — Clientes y crédito Los datos se separan en `clients` (perfil comercial y ubicación), `client_billing_profiles` (identidad tributaria) y `client_credit_profiles` (habilitación, límite, plazo y observaciones). Se incluyen tipos de negocio configurables y coordenadas con siete decimales. No se guarda un campo genérico de deuda. `CreditAvailabilityService` está preparado para recibir el saldo calculado por cuentas por cobrar y devolver límite, exposición y crédito disponible usando BCMath. En la Fase 6 se conectará con obligaciones, vencimientos y pagos. Rutas de gestión: `/clients`. ## Fase 4 — Pedidos, reservas y rentabilidad Se añadieron `orders`, `order_items`, `order_item_allocations` y `order_status_histories`. Un borrador no modifica inventario. La pantalla de confirmación propone FIFO pero muestra todos los lotes disponibles para que un usuario autorizado cambie la distribución. `ConfirmOrderService` bloquea pedido y lotes en orden estable, valida nuevamente el disponible, exige que las asignaciones coincidan con cada cantidad, guarda costos reales, reserva stock y registra movimientos `RESERVATION`. `CancelOrderService` libera reservas mediante `RESERVATION_RELEASE` sin disminuir stock físico. La utilidad se calcula desde el costo de cada asignación. Rutas: `/orders`. ## Fase 5 — Entregas y evidencias Se añadieron órdenes de entrega e historial logístico con dirección, coordenadas, repartidor, vehículo, programación y datos opcionales del receptor. La fotografía y las observaciones son obligatorias al completar y se almacenan en el disco privado. `CompleteDeliveryService` bloquea entrega, pedido y lotes; valida reservas, disminuye stock físico y reservado, genera movimientos `SALE` y cambia pedido y entrega a `DELIVERED` en una sola transacción. Una entrega fallida cambia el estado logístico, conserva la reserva y no reduce inventario. Rutas: `/deliveries`. ## Fase 6 — Pagos y cuentas por cobrar Cada pedido confirmado crea una obligación en `receivables`; los comprobantes se guardan en `payments` y cada abono queda relacionado mediante `payment_applications`. Los pagos pueden ser parciales y nunca pueden superar el saldo. Se conservan monto original, pagado, saldo, emisión, vencimiento y estado, sin campos agregados de deuda en clientes. `RegisterPaymentService` bloquea pedido y obligación, aplica el monto con BCMath y actualiza `UNPAID`, `PARTIALLY_PAID` o `PAID` independientemente del estado logístico. Los comprobantes se almacenan de forma privada. El planificador marca cartera vencida diariamente a las 00:05. Rutas: `/payments`, `/receivables` y `/clients/{client}/statement`. ## Fase 7 — Caja diaria Las sesiones registran usuario, apertura, saldo inicial, cierre, esperado, contado, diferencia y estado. `open_user_id` único impide más de una caja abierta por usuario y se libera al cerrar, sin borrar el historial. Los movimientos distinguen entradas y salidas y conservan usuario y referencia polimórfica. Los pagos `CASH` exigen una caja abierta y crean un movimiento automático en la misma transacción. Los movimientos manuales admiten ingresos, gastos y ajustes autorizados. El cierre bloquea la sesión, calcula valores con BCMath y deja la caja inmutable. Ruta: `/cash`. ## Fase 8 — Dashboard y reportes El dashboard incluye ventas, pedidos, utilidad, cobros, cartera, vencidos, inventario valorizado y entregas, gráfica de 30 días, stock bajo, pedidos pendientes y últimos pagos. Los reportes disponibles son ventas, compras, inventario, kardex, rentabilidad, cartera, pagos, caja y entregas, con rango de fechas e impresión desde navegador. La arquitectura queda preparada para exportadores PDF/Excel posteriores. ## Fase 9 — Reservada, no implementada No existe comunicación con SRI, código de facturación electrónica ni dependencia hacia la librería adquirida. El sidebar muestra un módulo deshabilitado “Facturación electrónica — Próximamente”. La integración futura debe residir en `app/Services/ElectronicBilling/` y no modificar el núcleo de pedidos, pagos o inventario. ## Fase 10 — Auditoría, seguridad, pruebas y backups `ActivityObserver` registra creación, actualización y eliminación de entidades sensibles, valores anteriores/posteriores, usuario, IP, user agent y fecha; contraseñas y tokens se excluyen. El sistema añade CSP y cabeceras defensivas, rate limit nominal para login, permisos granulares y archivos privados. `php artisan system:backup` genera un `.sql.gz` mediante `mysqldump` usando `MYSQL_PWD`, sin exponer la contraseña en argumentos. Configure `DB_DUMP_BINARY`; el scheduler ejecuta un respaldo semanal. Se recomienda copiar `storage/app/private/backups` a almacenamiento externo cifrado y probar restauraciones periódicamente. Antes de producción: usar PHP 8.3+, `APP_ENV=production`, `APP_DEBUG=false`, HTTPS, credenciales propias, cron para `schedule:run`, worker supervisado, backup externo, rotación de logs, `php artisan optimize` y ejecución completa de `php artisan test`. ### Verificación final realizada - Migración completa y seed sobre SQLite: correcta. - Rollback completo de todas las migraciones: correcto. - Registro de 59 rutas: correcto. - Compilación de vistas Blade: correcta. - Validación sintáctica PHP: correcta. - `composer audit --locked --no-dev`: sin avisos de seguridad conocidos. - Pest/PHPUnit no se ejecutó localmente porque XAMPP proporciona PHP 8.2.4 y Pest 4 requiere PHP 8.3+. Ejecutar `composer install && php artisan test` en PHP 8.3 o superior.