-- ---------------------------------------------------------------------------
-- Quantas comandas são abandonadas, e quanto havia nelas (D52, ação 3).
--
--   docker compose exec -T mysql mysql -uroot -proot franquiabv_dev \
--     --default-character-set=utf8mb4 < scripts/medir-comandas-abandonadas.sql
--
-- O `--default-character-set=utf8mb4` NAO E ENFEITE, e a falta dele custou
-- 17 dias de cegueira. O cliente mysql deste contêiner negocia
-- `character_set_client = latin1` (medido em 14/09/2026); sem a opção, os
-- bytes UTF-8 deste arquivo são remendados na entrada, e comparação com
-- literal acentuado casa ZERO linhas -- sem erro e sem aviso. O terceiro
-- bloco vivia disso; ver a nota dentro dele.
--
-- POR QUE ESTE ARQUIVO EXISTE. As ações 1 e 2 do D52 são código: a rotina passou
-- a dizer qual dos dois casos é, e a abertura deixou de criar comanda duplicada.
-- A ação 3 — decidir o que fazer com as abandonadas — **não é código**. É uma
-- decisão de operação, e uma decisão sem número é palpite.
--
-- ATENÇÃO À LEITURA. `valor_total` numa comanda aberta acompanha a soma dos
-- itens — foi verificado. Então o valor abaixo é **o que estava na comanda
-- quando ela foi abandonada**, e NÃO é receita perdida comprovada: item
-- selecionado não é serviço prestado, e uma comanda pode ter sido aberta por
-- engano com item já escolhido. É o teto do que estava em aberto, e o piso de
-- quanto vale investigar.
--
-- HISTÓRICO x DAQUI PARA A FRENTE. Até 28/08/2026 a rotina gravava a mesma frase
-- em todos os cancelamentos, então o histórico precisa ser reclassificado pela
-- mesma pergunta que a rotina passou a fazer — existe venda finalizada do mesmo
-- cliente no mesmo dia? É o que a primeira consulta faz. A segunda usa a frase
-- nova, e só enxerga o que foi cancelado depois da mudança.
-- ---------------------------------------------------------------------------

SELECT '--- HISTÓRICO, reclassificado pela mesma pergunta da rotina ---' AS '';

SELECT
    YEAR(f.data_criacao) AS ano,
    SUM(NOT eh_fantasma)  AS abandonadas,
    SUM(eh_fantasma)      AS duplicadas,
    ROUND(SUM(CASE WHEN NOT eh_fantasma THEN f.valor_total ELSE 0 END), 2) AS valor_abandonado
FROM (
    SELECT v.id, v.cliente, v.data_criacao, v.valor_total,
           EXISTS (SELECT 1 FROM vendas v2
                    WHERE v2.cliente = v.cliente
                      AND v2.status = 1
                      AND DATE(v2.data_criacao) = DATE(v.data_criacao)
                      AND v2.id <> v.id) AS eh_fantasma
      FROM vendas v
     WHERE v.status = 0
       -- FORA A FAIXA DE FIXTURE (D167). Este roteiro roda na CÓPIA
       -- anonimizada, e ela tem linha de fixture dentro: em 11/09/2026 eram
       -- 6 vendas com id >= 90000000, uma a mais do que as 5 medidas dois dias
       -- antes. Hoje nenhuma delas casa com o `cancelado_motivo` abaixo, então
       -- o filtro não muda número nenhum -- ele existe para a PRÓXIMA fixture,
       -- que ninguém vai lembrar de conferir.
       AND v.id < 90000000
       AND v.cancelado_motivo LIKE 'Comanda%cancelamento autom%'
       -- Só as que tinham serviço lançado: comanda vazia abandonada não
       -- representa atendimento nenhum, e contá-la infla o número.
       AND EXISTS (SELECT 1 FROM vendas_produtos vp WHERE vp.venda = v.id)
) f
GROUP BY 1
ORDER BY 1;

SELECT '' AS '';
SELECT '--- POR UNIDADE, últimos 12 meses, só abandonadas ---' AS '';

SELECT
    uni.nome AS unidade,
    COUNT(*) AS comandas,
    ROUND(SUM(v.valor_total), 2) AS valor
FROM vendas v
JOIN usuarios usu ON usu.id = v.usuario
JOIN unidades uni ON uni.id = usu.unidade
WHERE v.status = 0
  AND v.id < 90000000                 -- fora a faixa de fixture (D167)
  AND v.cancelado_motivo LIKE 'Comanda%cancelamento autom%'
  -- O `MAX(data_criacao)` tambem sai da faixa: a fixture grava em 2026, e uma
  -- venda de fixture com data futura moveria a janela de 12 meses inteira.
  AND v.data_criacao > DATE_SUB(
        (SELECT MAX(data_criacao) FROM vendas WHERE id < 90000000), INTERVAL 12 MONTH)
  AND EXISTS (SELECT 1 FROM vendas_produtos vp WHERE vp.venda = v.id)
  AND NOT EXISTS (SELECT 1 FROM vendas v2
                   WHERE v2.cliente = v.cliente AND v2.status = 1
                     AND DATE(v2.data_criacao) = DATE(v.data_criacao) AND v2.id <> v.id)
GROUP BY uni.id, uni.nome
ORDER BY comandas DESC
LIMIT 15;

SELECT '' AS '';
SELECT '--- DAQUI PARA A FRENTE: o que a rotina já classificou sozinha ---' AS '';

-- ESTE BLOCO VINHA VAZIO POR DEFEITO DELE, e a nota que estava aqui dizia
-- que vazio era o esperado: "quando parar de vir vazio, a classificação
-- está no ar". O único indicador que diria "a classificação subiu" estava
-- preso em "não subiu", e o comentário ensinava o leitor a não desconfiar.
--
-- A causa era o `IN` com literal acentuado contra um cliente em latin1.
-- Medido em 14/09/2026 na cópia local: o `IN` acentuado devolvia 0, e o
-- mesmo filtro em ASCII devolve 43. Agora o predicado é ASCII, igual ao
-- dos blocos 1 e 2 -- que sempre funcionaram por serem ASCII puro --, e
-- vazio aqui voltou a significar vazio.
SELECT
    -- prefixo ASCII de proposito: o acento so aparece depois de `duplicada`
    CASE WHEN cancelado_motivo LIKE 'Comanda duplicada%' THEN 'duplicada (fantasma)'
         ELSE 'abandonada' END AS tipo,
    COUNT(*) AS comandas,
    ROUND(SUM(valor_total), 2) AS valor
FROM vendas
WHERE cancelado_motivo LIKE 'Comanda duplicada:%cancelamento autom%'
   OR cancelado_motivo LIKE 'Comanda aberta h%mais de dois dias e nunca paga%'
GROUP BY 1;