Criar minha reserva

Relatórios e auditoria

Todo número remonta a quem, o quê e quando.

Vendas brutas, custo e margem nunca misturam moedas em um único total enganoso. E toda edição de um preço, de uma regra de disponibilidade ou de uma atribuição de imposto registra exatamente o que mudou, de que valor para que valor, por quem.

  • Por moeda, sempre Vendas brutas, custo e margem nunca misturam moedas em um único total enganoso
  • 8 tipos de entidade Regras de preço, exceções e regras dinâmicas, regras e exceções de disponibilidade, atribuições, exceções e categorias de impostos: todos registram cada mudança
  • Número constante de consultas O relatório executa o mesmo número de consultas, tenha o período 3 pedidos ou 3 milhões

Quatro peças de responsabilidade.

Cada uma responde a uma pergunta diferente: quanto vendemos, o que perdemos, consigo exportar isso, e quem mexeu no quê.

01

Vendas, detalhadas com honestidade

Pedidos, ingressos vendidos, vendas brutas, custo e margem, por moeda, com um gráfico de tendência e uma divisão por canal e produto principal, nunca um único número misturado que esconde o que realmente aconteceu.

02

Cancelamentos, mantidos à parte da receita

Pedidos cancelados, expirados e reembolsados têm sua própria seção, para que uma reserva que nunca chegou a cobrar nada nunca seja confundida com uma venda que se perdeu depois de acontecer.

03

Uma exportação em CSV que transmite

Exportações no nível de pedido escrevem diretamente na resposta em blocos, à medida que avançam, para que um ano inteiro de pedidos seja exportado da mesma forma que um único dia, sem nunca carregar tudo na memória de uma vez.

04

Uma trilha de auditoria para cada mudança comercial

Toda edição de uma regra de preço, uma exceção de preço, uma regra dinâmica, uma regra ou exceção de disponibilidade, ou uma atribuição de imposto registra o valor antigo, o valor novo, quem fez a mudança e quando.

Como um relatório se mantém preciso e rápido ao mesmo tempo

Cinco passos por trás de cada execução de relatório e de cada mudança registrada.

  1. 1

    Todo número filtra por status pago e data do recibo

    O relatório só conta pedidos que de fato chegaram a pago, usando a data em que o recibo foi atribuído, não quando o carrinho foi criado.

  2. 2

    A agregação acontece no banco de dados, não em um laço

    Somas, contagens e agrupamentos rodam como consultas SQL agregadas únicas. O número de consultas que o relatório executa depende de quantas moedas estão envolvidas, nunca de quantos pedidos existem.

  3. 3

    Cancelamentos são calculados a partir do registro de eventos

    Como o status de um pedido é um único valor atual, cancelamentos e reembolsos são lidos a partir do histórico completo de eventos de status, e mantidos como sua própria seção separada.

  4. 4

    Uma mudança é comparada e registrada

    Editar uma regra de preço, uma exceção de disponibilidade ou uma atribuição de imposto registra exatamente quais campos mudaram, de que valor para que valor, junto com quem fez e quando.

  5. 5

    A exportação transmite em blocos

    Um download em CSV lê os pedidos correspondentes 500 de cada vez, escrevendo cada bloco diretamente na resposta à medida que avança, para que o tamanho do arquivo nunca dependa de quanta memória está disponível.

O que o relatório de vendas realmente retorna

Um resumo por moeda de pedidos, vendas brutas, custo e margem, junto com uma seção de cancelamentos e reembolsos claramente separada da receita real.

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 Relatório resolvido

Um pedido nunca chega de fato a "reembolsado" como status

Um reembolso aparece como uma propriedade da transação de pagamento, não como o status do próprio pedido, porque um pedido pode ser parcialmente reembolsado, totalmente reembolsado, ou reembolsado depois de ter sido cancelado por um motivo sem relação. Tratar isso como um único status no nível do pedido forçaria a escolher um único rótulo para situações genuinamente diferentes, então o relatório lê os reembolsos a partir da transação e do histórico de eventos, e mantém essa seção visivelmente separada da receita real.

Perguntas frequentes

Não por padrão. Todo número central, vendas brutas, custo, margem, é agrupado e exibido por moeda. Um total combinado opcional em uma moeda de referência está disponível separadamente, sempre identificado como estimativa, e qualquer moeda sem uma taxa de câmbio confiável fica excluída em vez de ser estimada.

Não. Cancelamentos, expirações e reembolsos ficam em sua própria seção, inteiramente separada das vendas brutas, para que uma reserva que nunca foi paga de verdade nunca seja confundida com dinheiro que entrou e depois saiu.

Ele não fica mais lento conforme o número de pedidos cresce. Todo número vem de uma consulta agregada no banco de dados, não de um laço sobre linhas, então o número de consultas executadas permanece o mesmo, cubra o período três pedidos ou três milhões.

Os campos específicos que mudaram, seu valor antigo, seu valor novo, quem fez a mudança e exatamente quando, cobrindo regras de preço e exceções, regras de preço dinâmico, regras e exceções de disponibilidade, atribuições e exceções de impostos, e categorias de impostos.

Não. A exportação transmite os pedidos em blocos de 500 diretamente na resposta à medida que os lê, então exportar um ano inteiro funciona da mesma forma que exportar um único dia.

Mais reservas. Mais canais. A mesma calma.

A Tiqory mantém disponibilidade, preços, pagamentos e acesso a trabalhar juntos enquanto a sua operação cresce. Conte-nos para onde vai; mostramos como chegar lá sem recomeçar.