# SIHO PMS Master RC4 — Auditoría integral de reportes

## Alcance revisado

Se inventariaron y revisaron los controladores, exportaciones y vistas relacionadas con:

- ingresos diarios;
- ingresos mensuales;
- resumen mensual por turno;
- resumen de estancias;
- reporte por rango;
- ventas por rango;
- cajas y arqueos;
- limpieza;
- compras;
- clientes;
- mantenimiento;
- inventario;
- comprobantes de hospedaje y ventas.

La auditoría fue estática sobre el código fuente. La validación matemática con datos reales requiere importar `database/master/siho_pms_master.sql` en MySQL y ejecutar la matriz operativa.

## Hallazgos críticos corregidos

### 1. Filtros diarios que podían escapar de sus condiciones

El reporte diario y su Excel aplicaban un `OR` sin agrupar. Un pago localizado por `FechaEmision` podía aparecer aunque no cumpliera el método de pago o el estado solicitado.

Se reemplazó la consulta duplicada por `DailyIncomeDetailService` y se agrupó la lógica en una sola fuente.

### 2. Fecha contable inconsistente

Los ingresos de hospedaje se mezclaban entre `FechEntrada`, `FechaEmision` y `FechaPago`. Para el reporte de ingresos se adopta `pago.FechaPago` como fecha del movimiento cobrado.

Los consumos pagados se reportan por `consumo.FechaPago`. Los consumos pendientes no se presentan como ingreso.

### 3. Doble contabilización potencial de consumos

Los reportes diarios y mensuales aceptaban indistintamente `FechConsumo` o `FechaPago`, por lo que un consumo realizado un día y pagado otro podía aparecer en ambos días.

Ahora los reportes financieros utilizan únicamente la fecha de pago.

### 4. Cálculo mensual distinto al arqueo

El reporte mensual tenía fórmulas propias y no incluía de manera uniforme renovaciones, servicios, pago final y penalidad.

Se creó `FinancialReportService`, que reutiliza `CashReconciliationService`. Con esto los resúmenes mensuales toman la misma fuente que el arqueo de caja.

### 5. Tarifas fijas en el reporte de estancias

El reporte personalizado solo reconocía `3 HORAS`, `4 HORAS` y `TODA LA NOCHE`.

Ahora clasifica cualquier tarifa terminada en `HORAS` como estancia corta y el resto de las tarifas activas —noche, día o mes— como estancia larga. Esto permite 5, 8, 10 o 12 horas sin modificar el reporte.

### 6. Ventas por rango con combinación defectuosa

La unión manual entre ventas públicas y consumos podía incrementar índices incorrectamente y producir huecos o duplicados. También utilizaba la fecha de consumo, aunque la venta aún no estuviera pagada.

Se sustituyó por una combinación asociativa estable basada en fecha, producto y precio. Los cargos a habitación se incorporan por la fecha real de pago.

### 7. Recursos de reportes exponían acciones de escritura

Las rutas declaraban los reportes como recursos completos, generando rutas `create`, `store`, `update` y `destroy` innecesarias. El reporte de cajas incluso contenía un método para eliminar cajas.

Todas las rutas de los módulos de reporte quedaron limitadas a `index`. Los reportes son de solo lectura y las exportaciones conservan rutas explícitas protegidas.

### 8. Cortesías con y sin acento

Se unificó el tratamiento de `CORTESIA` y `CORTESÍA` en los cálculos revisados para evitar que una cortesía se contabilice como ingreso por una diferencia ortográfica.

## Servicios agregados

- `app/Services/Reports/FinancialReportService.php`
- `app/Services/Reports/DailyIncomeDetailService.php`

## Fuentes oficiales después de RC4

- Arqueo y conciliación: `CashReconciliationService`.
- Resumen financiero diario/mensual: `FinancialReportService`.
- Detalle diario en pantalla y Excel: `DailyIncomeDetailService`.

## Hallazgos que requieren prueba con MySQL

- Comparar centavo a centavo reporte diario, mensual, PDF y Excel con una caja de prueba cerrada.
- Validar datos históricos donde `FechaPago` pueda estar incompleta por registros heredados.
- Confirmar que los nombres de turno continúan almacenados como `MATUTINO`, `VESPERTINO` y `NOCTURNO` en la tabla `usuario`.
- Revisar el reporte de rango de reservas con datos reales para decidir si debe filtrar por fecha de reserva, entrada o pago según el uso operativo del hotel.
- Validar maquetación PDF/Excel con DomPDF y PhpSpreadsheet después de instalar `vendor`.

## Estado

- Auditoría estática: completada.
- Sintaxis PHP: validada.
- Ejecución Laravel/MySQL: pendiente en entorno temporal.
- Certificación financiera definitiva: pendiente de datos de prueba.
