# Farmacia FASSID v1.2.0 ## Actualizar una instalación v1.0 o v1.1 1. Respalda la base, `.env` y `storage`. Conserva la APP_KEY original: las vistas previas de Excel usan cifrado. 2. Copia el contenido del nuevo backend a la carpeta instalada, sobrescribiendo código y `vendor`, sin borrar tu `.env` ni datos. Ejecuta `ACTUALIZAR.bat`. No uses `migrate:fresh` ni reinstales sobre otra base. Los puertos se mantienen: 8016 y 5184. 3. Reemplaza el frontend conservando su `.env`. Usa `INICIAR.bat` para probar. Para hosting, compila con `COMPILAR.bat` y sube todo el contenido de `dist`, incluida la carpeta `denominaciones`. La migración añade secuencia de códigos, registro de abonos, solicitudes de impresión y campos de desglose del cierre. Conserva usuarios, productos, compras, ventas, pagos acumulados y turnos. GD y ZIP siguen siendo necesarias para Excel. En Linux, con respaldo y archivos nuevos: `php artisan optimize:clear`, `php artisan migrate --seed --force` y opcionalmente `php artisan config:cache`. El DocumentRoot del backend sigue siendo exclusivamente `public`. HTTPS es necesario para acceso remoto y generación de UUID desde el navegador. ## Ficha propia de cada producto Pulsa el nombre del producto o su acción Ver detalle. Se abre una página con sus datos, presentaciones, stock y pestañas de ventas, compras y lotes. - Ventas vigentes: número de ventas distintas y unidades base vendidas, excluyendo anuladas. Una venta no se cuenta varias veces si utilizó más de un lote. - Compras: compras distintas y unidades base recibidas; se puede abrir su detalle y acceder al proveedor. - Lotes: cantidades físicas, estado y vencimiento por lote. El vencimiento no se traslada a la ficha general. - El historial de ventas incluye estado vigente/anulada y el bruto del producto antes del descuento global de la venta. No se presenta ese bruto como ingreso neto por producto. - Administración y regencia ven compras. El cajero ve el acumulado de ventas general y el historial de sus propias ventas; no ve compras ni costos de compra en la ficha. ## Ficha y estado de cuenta del proveedor Desde Proveedores abre su nombre. La ficha muestra cantidad de compras, total comprado, total pagado, saldo y última compra. La tabla distingue compras pagadas, parcialmente pagadas y sin pagar. El filtro Pendientes incluye las parcialmente pagadas. Administración puede abonar el saldo desde esta vista o desde Compras. Se exige referencia. El sistema valida que el abono no supere la deuda y conserva cada nuevo pago inicial/abono. Las confirmaciones enviadas por el nuevo frontend incluyen identificador para evitar duplicar un abono al reintentar. Los pagos de versiones anteriores se conservan como **acumulado previo** por compra. No existía antes una tabla con cada abono; la actualización no inventa sus fechas ni cantidades de pagos individuales. La auditoría previa se conserva para consulta. Los nuevos pagos sí muestran fecha, usuario, referencia y monto. Un pago a proveedor no produce automáticamente un egreso del turno de caja; registra el egreso si realmente sale efectivo de ese turno. ## Cierre y conteo de caja El resumen muestra fondo inicial, ventas en efectivo, transferencias, QR, tarjetas, otros ingresos de efectivo, egresos, efectivo esperado, contado y diferencia. `Efectivo esperado = fondo inicial + ventas en efectivo + otros ingresos de efectivo − egresos de efectivo`. Transferencias, QR y tarjetas se muestran separados y no se suman a la cantidad de billetes/monedas que debe haber en el cajón. El total cobrado en ventas sí incluye los medios de pago registrados para ventas vigentes. Al cerrar indica cuántas piezas tienes de cada denominación. El sistema usa las imágenes adjuntas de billetes de Bs 200/100/50/20/10 y monedas de Bs 5/2/1 y 50/20/10 centavos. Calcula cada subtotal y la suma en centavos; no identifica ni cuenta piezas a partir de una cámara. Se permite registrar una diferencia real de efectivo, que queda guardada. El cierre conserva una instantánea del desglose y cantidades por denominación, consultable en Mi caja → Historial → Ver desglose. Las peticiones de cierre del nuevo frontend llevan identificador para reintentar sin cerrar otro turno. Los cierres anteriores conservan sus importes, pero no pueden mostrar un conteo por denominación que nunca se registró. **QR sigue sin conexión bancaria en esta entrega.** La columna existe para el desglose; en la operación actual queda en cero. No se habilita QR manual ni se simulan cobros. BNB/SIP se conectarán después de recibir la documentación. Tarjetas y transferencias siguen siendo registros manuales con referencia, conforme a v1. ## Original y copia del comprobante El botón Imprimir / guardar PDF registra una solicitud de impresión en el servidor. La primera solicitud de una venta nueva emite original. Las siguientes muestran **COPIA / REIMPRESIÓN** y el número de solicitud. Un reintento de la misma petición no incrementa el contador. Las ventas que ya existían al actualizar se consideran emitidas y sus nuevas impresiones salen como copia. La v1 no registraba impresiones, por lo que no es posible reconstruir cuántas veces se imprimieron antes. El navegador no confirma si el papel salió físicamente: cancelar el diálogo también deja registrada la solicitud; la siguiente será copia. La impresión directa desde el menú del navegador se marca como copia y no se registra como una nueva solicitud mediante API. Los archivos PDF ya descargados se imprimen fuera del control del sistema. ## Código automático En el alta individual de Productos, deja vacío Código de barras / código interno. Se genera un prefijo de cuatro letras del nombre en minúsculas, sin tildes, más guion y ocho dígitos: `amox-00000001`. La secuencia es **global para las altas automáticas**, no se reinicia por nombre. Dos medicamentos con prefijo diferente usan números sucesivos. Los nombres de menos de cuatro letras se completan con `x`; si no contienen letras, se usa `prod`. Los códigos que ya existían no se cambian. El contador se bloquea dentro de la transacción y se comprueba que el código no exista, sin distinguir mayúsculas para los códigos generados. Si encuentra una coincidencia con un código manual, salta ese número. Los códigos no se liberan al desactivar productos. Se mantiene el índice único en la base. El formulario nuevo utiliza un identificador de petición para evitar crear otro producto en un reintento de la misma alta. Al editar, dejar el código vacío conserva el que ya tenía; no lo regenera. Si escribes un código manual, se respeta y debe ser único. La importación de Excel mantiene el contrato de su plantilla: exige códigos de texto para identificar las filas y omitir existentes. No se cambió ese formato en v1.2. ## Buscar con TAB en POS Escribe un código, nombre o principio activo y pulsa TAB. La búsqueda se ejecuta y TAB continúa su cambio de foco normal; no añade unidades automáticamente. Enter conserva el comportamiento anterior: busca y puede agregar un código exacto. Buscar con TAB no registra una venta ni cambia el inventario.