Construir mi booking

Reportes y Auditoría

Cada número se rastrea hasta quién, qué y cuándo.

Ventas brutas, coste y margen nunca mezclan monedas en un total engañoso. Y cada edición a un precio, una regla de disponibilidad o una asignación de impuesto registra exactamente qué cambió, de qué valor a cuál, y quién lo hizo.

  • Por moneda, siempre Ventas brutas, coste y margen nunca mezclan monedas en un total engañoso
  • 8 tipos de entidad Reglas de precio, excepciones y reglas dinámicas, reglas y excepciones de disponibilidad, asignaciones, excepciones y categorías de impuesto registran cada cambio
  • Número de consultas constante El reporte corre el mismo número de consultas sin importar si el rango tiene 3 pedidos o 3 millones

Cuatro piezas de rendición de cuentas.

Cada una responde una pregunta distinta: cuánto vendimos, qué perdimos, puedo sacarlo, y quién tocó qué.

01

Ventas, desglosadas honestamente

Pedidos, tickets vendidos, ventas brutas, coste y margen, por moneda, con un gráfico de tendencia y un desglose por canal y producto top, nunca una sola cifra mezclada que esconda lo que realmente pasó.

02

Cancelaciones, separadas de los ingresos

Los pedidos cancelados, expirados y reembolsados tienen su propia sección, así que una reserva que nunca cobró nada jamás se confunde con una venta que se perdió después del hecho.

03

Una exportación CSV que transmite

Las exportaciones a nivel de pedido escriben directamente a la respuesta en fragmentos a medida que avanzan, así que un año completo de pedidos se exporta igual que un solo día, sin cargarlo nunca todo en memoria a la vez.

04

Un rastro de auditoría para cada cambio comercial

Cada edición a una regla de precio, una excepción de precio, una regla dinámica, una regla o excepción de disponibilidad, o una asignación de impuesto registra el valor anterior, el valor nuevo, quién hizo el cambio y cuándo.

Así se mantiene un reporte preciso y rápido a la vez

Cinco prácticas detrás de cada ejecución de reporte y cada cambio registrado.

  1. 1

    Cada cifra filtra por estado pagado y fecha de recibo

    El reporte solo cuenta pedidos que realmente llegaron a pagado, usando la fecha en que se asignó el recibo, no cuándo se creó el carrito por primera vez.

  2. 2

    La agregación ocurre en la base de datos, no en un bucle

    Sumas, conteos y agrupaciones corren como consultas SQL agregadas únicas. El número de consultas que corre el reporte depende de cuántas monedas están involucradas, nunca de cuántos pedidos hay.

  3. 3

    Las cancelaciones se calculan desde el historial de eventos

    Como el estado de un pedido es un solo valor actual, las cancelaciones y reembolsos se leen en cambio del historial completo de eventos de estado, y se mantienen como su propia sección separada.

  4. 4

    Un cambio se compara y se registra

    Editar una regla de precio, una excepción de disponibilidad o una asignación de impuesto escribe exactamente qué campos cambiaron, de qué valor a cuál, junto con quién lo hizo y cuándo.

  5. 5

    La exportación transmite en fragmentos

    Una descarga CSV lee pedidos coincidentes de 500 en 500, escribiendo cada fragmento directamente en la respuesta a medida que avanza, así que el tamaño del archivo nunca depende de cuánta memoria hay disponible.

Lo que realmente devuelve el reporte de ventas

Un resumen por moneda de pedidos, ventas brutas, coste y margen, junto con una sección de cancelaciones y reembolsos mantenida visiblemente separada de los ingresos reales.

GET /admin/reports/sales
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
{
  "currency": "EUR",
  "summary": {
    "orders_count": 128,
    "tickets_count": 341,
    "gross_sales": 15230.5,
    "cost_total": 6100,
    "net_total": 9130.5
  },
  "cancellations_and_refunds": {
    "cancelled_count": 4,
    "expired_count": 9,
    "refunded_count": 2,
    "refunded_amount": 184
  }
}
200 Reporte resuelto

Un pedido nunca llega realmente a tener "reembolsado" como estado

Un reembolso aparece como una propiedad de la transacción de pago, no como el estado propio del pedido, porque un pedido puede reembolsarse parcial o totalmente, o reembolsarse después de cancelarse por un motivo sin relación. Tratarlo como un solo estado a nivel de pedido obligaría a elegir una única etiqueta para situaciones que en realidad son distintas, así que el reporte lee los reembolsos desde la transacción y el historial de eventos, y mantiene esa sección visiblemente separada de los ingresos reales.

Preguntas frecuentes

No por defecto. Cada cifra principal, ventas brutas, coste, margen, se agrupa y se muestra por moneda. Un total combinado opcional en una moneda de referencia está disponible por separado, siempre marcado como estimación, y cualquier moneda sin una tasa de cambio confiable queda excluida en lugar de adivinarse.

No. Cancelaciones, expiraciones y reembolsos viven en su propia sección, completamente separada de las ventas brutas, así que una reserva que en realidad nunca se pagó nunca se confunde con dinero que entró y luego volvió a salir.

No escala con la cantidad de pedidos. Cada cifra viene de una consulta agregada en la base de datos, no de un bucle sobre filas, así que el número de consultas que corre se mantiene igual sin importar si el rango cubre tres pedidos o tres millones.

Los campos específicos que cambiaron, su valor anterior, su valor nuevo, quién hizo el cambio y exactamente cuándo, cubriendo reglas y excepciones de precio, reglas de precio dinámico, reglas y excepciones de disponibilidad, asignaciones y excepciones de impuesto, y categorías de impuesto.

No. La exportación transmite pedidos en fragmentos de 500 directamente a la respuesta a medida que los lee, así que exportar un año completo funciona igual que exportar un solo día.

Más reservas. Más canales. La misma calma.

Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.