"que veio do sistema"
// "custo nao cadastrado no ERP Fire" -> "custo do produto nao cadastrado"
// "Ver a via do relatorio do ERP" -> "Ver a via do relatorio de fechamento"
// "o ERP mostra dois valores diferentes" -> "este caixa tem duas apuracoes diferentes"
// "leve ao suporte do ERP" -> "acione o suporte tecnico (66) 99248-8989"
// Referencia tecnica (ERP, Fire, RDPrint, nome de tabela) continua nos
// COMENTARIOS de codigo — o cliente nao le comentario, e quem for dar
// manutencao precisa saber de onde o dado vem. Mesma logica da marca Master.
// Lint de PHP e JS passou em tudo depois da troca em massa.
// v1.7.219 (2026-08-28) — **VIA DO RELATORIO: COPIA FIEL, 100% conferida.**
// A v218 saiu com a via em 74% de fidelidade visual. Medi a grade do
// RDPrint caractere a caractere no relatorio real (Disk Rapido, caixa 7952)
// e fechei as diferencas:
// - hora do cabecalho com SEGUNDOS (o papel imprime 14:59:07; a tela
// cortava em HH:MM). Novos campos data_abertura_full/data_fechamento_full.
// - valor das formas de venda termina na coluna 38, nao 37.
// - ordem da secao "VALORES APURADOS": as formas usadas na venda primeiro
// e o dinheiro por ultimo, com o rotulo do papel — "A Vista", nao
// "DINHEIRO". Antes saia em ordem alfabetica do comparativo.
// Resultado medido linha a linha contra o texto extraido do PDF do ERP:
// **52 de 52 linhas iguais (100%)**. Da pra conferir papel x tela sem
// entrar no ERP. Ferramenta de comparacao ficou no scratchpad da sessao.
//
// Segue valendo o aviso na tela: nao e' o arquivo do RDPrint, e' remontado
// das mesmas tabelas — e divergencia em relacao ao papel indica problema
// dentro do proprio ERP, nao da via.
// v1.7.218 (2026-08-28) — **VIA DO RELATORIO DO ERP dentro do BI.**
// Pedido do Derlivon: conferir o caixa sem precisar entrar no ERP e emitir
// o relatorio de novo. Botao "Ver a via do relatorio do ERP" no detalhe do
// caixa remonta o relatorio de fechamento — cabecalho, vendas por operacao,
// resumo das formas, sangrias e suprimentos, apurado x informado, saldos,
// diferenca e cancelamentos de pre-venda — em fonte de largura fixa, igual
// ao papel, com botao de imprimir.
//
// (!) Nao e' o arquivo do ERP: aquele sai do RDPrint (Deltress), a que o BI
// nao tem acesso. E' uma RECONSTRUCAO a partir das mesmas tabelas, e a tela
// diz isso ao usuario com essas palavras — inclusive que diferenca em
// relacao ao papel indica divergencia dentro do proprio ERP. Quando o caixa
// tem a divergencia da v217, a via avisa qual dos dois valores esta usando.
//
// Novo: FechamentoCaixaRepository::vendasPorOperacaoDoCaixa() (secao
// "VENDAS POR OPERACAO", ex.: 115-VENDA DE MERCADORIA) e
// ViaRelatorioErpService, que monta o texto. Endpoint /caixa/fechamento/via-erp.
// v1.7.217 (2026-08-28) — **O BI MOSTRA O QUE O ERP TEM. NAO MASCARA.**
// Correcao de rumo pedida pelo Derlivon: nas v214-216 eu tinha tomado duas
// decisoes em silencio, e decisao em silencio nao cabe num BI de auditoria.
//
// 1) **Divergencia do proprio ERP agora aparece na tela.** O Fire guarda o
// apurado do caixa em dois lugares — o campo ABERTURA_CAIXA.VALOR_CALCULADO
// e o total que o relatorio de fechamento imprime — e em alguns caixas os
// dois NAO batem (Disk Rapido, caixa 7952: relatorio R$ 601,50, campo
// R$ 627,24). A v214 passou a usar o do relatorio e deixou o outro so no
// JSON. Agora o caixa mostra um bloco com OS DOIS valores, a diferenca e
// a frase que importa: **isso nasceu dentro do ERP, nao no caixa do
// operador** — com orientacao de levar o relatorio ao suporte do ERP.
// Nao e' papel do BI escolher calado qual dos dois esta certo.
//
// 2) **Cancelamento com quantidade absurda volta pro total.** A v214 tirava
// do total os lancamentos com QTD >= 1000 e escrevia "provavel erro de
// digitacao". Interpretacao minha: o registro do ERP diz 504.072 unidades,
// e e' isso que tem que aparecer. O total agora e' o registro cheio; o
// valor sem esses lancamentos vem ao lado ('total_sem_atipicos') e a linha
// atipica segue destacada com o motivo provavel — mas o numero do ERP e'
// mostrado como esta gravado.
//
// **Nova ferramenta: tools\divergencia-erp-caixa.php** — mede quantos caixas
// tem os dois valores do ERP em desacordo, o tamanho da diferenca e se ela
// coincide com alguma forma de pagamento do turno. E' a evidencia pra abrir
// chamado no desenvolvimento do ERP em vez de discutir por achismo.
// Medido no Importados: **0 de 127 caixas divergem** — ou seja, o problema
// nao e' generalizado, aparece em ambiente/configuracao especifica.
// v1.7.216 (2026-08-28) — **CONFERENCIA E' UM CAIXA POR VEZ.**
// Reportado pelo Derlivon: ao filtrar por operadora, a tela empilhava TODOS
// os caixas dela no periodo. Quem confere rolava a pagina e caia sem
// perceber no caixa seguinte da MESMA pessoa — conferindo o valor errado.
// Agora, com mais de um resultado, aparece a LISTA (numero, horario,
// operadora, valor, status e diferenca) e a tela abre SO o caixa escolhido,
// com botao "voltar para a lista". Um resultado unico abre direto.
//
// **De quebra, a tela deixou de travar.** A rota /dados montava todas as
// secoes de todos os caixas: medido no Importados, 174 caixas em 30 dias =
// 108 SEGUNDOS e o navegador congelava (reproduzido aqui). A lista agora
// usa fechamentosResumo(), que le so o cabecalho: **os mesmos 174 caixas em
// 0,01 s**. O detalhe pesado (7,5 s) sai sob demanda, pelo caixa escolhido.
// Quem precisar do comportamento antigo: /caixa/fechamento/dados?modo=completo
//
// **BUG de digitacao achado no caminho:** "$ordemDetectada×" dentro de aspas
// duplas. O PHP aceita byte >= 0x80 em nome de variavel, entao o "×" (U+00D7)
// virou parte do nome e o alerta de erro de digitacao do operador saia com
// "cerca de × menor", sem o numero, mais um warning no log a cada caixa.
// Corrigido pra {$ordemDetectada}×. Varri o app inteiro: era o unico caso.
// v1.7.215 (2026-08-28) — complemento da forca-tarefa (a 214 ja estava no
// cliente quando estes tres sairam; por isso versao nova em vez de
// republicar a mesma — quem ja atualizou nao veria a diferenca).
// 1) **Busca pelo numero do caixa** na tela de Fechamento. Quando o cliente
// liga dizendo "o caixa 7952 esta errado", e' esse numero que se quer
// digitar — antes era preciso adivinhar operadora e data pra chegar nele.
// Novo endpoint /caixa/fechamento/por-codigo descobre a data pelo
// COD_ABERT_CAIXA e abre so aquele caixa.
//
// 2) **Alarme de risco fiscal calibrado.** Turno com menos de 10 vendas nao
// vira "Critico": no caixa 7952 eram 6 vendas, 3 no crediario = 50% sem
// nota e alarme vermelho. Com essa amostra UMA venda muda 17 pontos —
// o alarme falava do tamanho do turno, nao de risco. Agora mostra
// "Amostra pequena". Alarme que grita a toa faz perder a confianca na tela.
//
// 3) Card "Cancelamentos" virou **"Notas canceladas"**: ele conta nota
// inteira cancelada, e os itens de pre-venda tem secao propria agora.
// Dois lugares falando "cancelamento" com numeros diferentes confundia.
//
// **Historico de sangria com acento parou de sumir.** Vinha do Firebird em
// WINDOWS-1252 e o json_encode (JSON_PARTIAL_OUTPUT_ON_ERROR) trocava o
// campo por null: "pgto,hortalica" sumia e "cx filomena" aparecia. Sangria
// sem historico parece dinheiro tirado sem motivo — e o motivo estava
// gravado no ERP o tempo todo. 6 de 146 movimentacoes de agosto afetadas.
//
// **Central Financeira: carteira loja a loja + TOTAL GERAL.** O backend ja
// mandava kpis_por_loja e a tela so mostrava o consolidado; dono de rede
// tinha que trocar o filtro loja a loja pra comparar. Tabela com em aberto,
// % do grupo, vencido, % vencido, titulos, DSO, ticket e proximos 30 dias.
// Loja fora do ar entra na tabela avisando que NAO esta nas somas.
//
// **Nova ferramenta: tools/auditoria-financeira.php.** Recalcula cada numero
// das telas financeiras por SQL independente e compara. Rodar antes de
// apresentar o BI a cliente. 65 verificacoes nas 5 lojas do Importados,
// 0 divergencia. Tambem avisa quando o dado do ERP distorce a leitura
// (ex.: carteira 100% sem baixa mede processo, nao inadimplencia).
// v1.7.213 (2026-08-26) — **FIX: o navegador guardava dado de BI por 5 HORAS.**
// Achado testando a tela nova em :8001 — salvava um valor, recarregava e a
// tela mostrava o numero velho, como se o salvar nao funcionasse.
// Causa: session_cache_limiter('private') fazia o PHP mandar
// "Cache-Control: private, max-age=18000" em TODA resposta com sessao, e a
// excecao da v1.7.144 so tratava pagina HTML — as APIs ficavam de fora.
// Medido: /api/financeiro/dre e /api/financeiro/kpis respondiam com os
// mesmos 5h de cache. Provavel raiz do velho habito de "da Ctrl+F5 que
// aparece". Fix em Application::bootstrap: URI /api/ agora responde
// no-store, no-cache, must-revalidate. Pagina HTML segue com o
// stale-while-revalidate da v144 (marker X-BI-Cache-Fix intacto).
//
// **FIX na tela Ponto de Equilibrio** (5 defeitos achados no teste local):
// 1) Salvar mostrava erro vermelho "removeChild of null" MESMO tendo salvo:
// o container do grafico era limpo antes do echarts.dispose().
// 2) Consequencia do (1): o erro abortava o render no meio — KPIs
// atualizavam, mas o quadro "Como chegamos nesse numero" e a tabela de
// contas fixas ficavam com o valor velho na tela. Agora cada bloco
// renderiza isolado (um erro nao derruba os outros).
// 3) Sem contas fixas informadas, TODAS as barras do grafico saiam
// vermelhas — passava a ideia de que todo dia foi ruim. Sem meta a barra
// agora e neutra e a legenda explica o que preencher.
// 4) Portugues: "o BI ja sabe 38,2% das suas vendas passa no cartao" ->
// "ja sabe que 38,2% das suas vendas passam no cartao".
// 5) Rotulo "(divisao) Contas fixas do mes" confundia a conta ->
// "Contas fixas do mes (dividido pela margem acima)".
// A API da tela tambem passou a pedir cache: 'no-store' no fetch.
// Conferido ao vivo em :8001 (Achadinhos 10 Barra, contas fixas de teste de
// R$ 25.000,00): CMV 40,0% + cartao 0,95% = margem 59,1% -> ponto de
// equilibrio R$ 42.331,47 no mes -> R$ 1.628,13 por dia. Salva, recarrega e
// o valor continua la. Central Financeira: 1.273 linhas, 0 duplicada.
// v1.7.212 (2026-08-26) — **FIX GRAVE: valores do financeiro sairam 3x maiores
// em cliente com mais de uma empresa no mesmo banco.**
// Causa raiz: TIPO_OPERACAO tem PK COD_TIPO_OPERACAO + COD_EMPRESA, e 61 dos
// 85 JOINs do BI casavam so pelo codigo. Cada linha virava uma por empresa
// cadastrada — todo SUM/COUNT saia multiplicado e a listagem repetia titulo.
// Medido no banco do Importados (3 empresas), agosto/2026:
// - KPI "A Receber": R$ 3.730.737,78 -> R$ 278.967,91
// - KPI "A Pagar": R$ 49.455.929,19 -> R$ 16.285.559,59
// - Central Financeira: R$ 831.855,81 -> R$ 277.285,27 (4.038 -> 1.346 titulos,
// e cada titulo aparecia 3x na lista)
// - Fluxo de Caixa (saidas de agosto): R$ 382.093,86 -> R$ 127.364,62
// - DRE (receita de agosto): R$ 2.694.528,45 -> R$ 903.664,67
// - Regua de Cobranca: a fila tinha 59 mensagens para 25 titulos — o MESMO
// cliente recebia a cobranca ate 3 vezes. Agora 25 mensagens, 0 repetida.
// O CMV% quase nao muda (55,67% -> 55,62%): numerador e denominador inflavam
// juntos, por isso o erro passou despercebido tanto tempo.
// Fix: novo helper App\Support\FireSchema::joinEmpresa() detecta a coluna via
// RDB$RELATION_FIELDS (Fire antigo pode nao ter) e completa o ON. Aplicado em
// 34 JOINs: FinanceiroRepository (10), FinanceiroCentralService (14),
// RecebiveisRepository (12), ReguaCobrancaService (1).
// Cliente de loja unica NAO e afetado — os numeros dele nao mudam.
// Ainda faltam 24 JOINs fora do financeiro (Compras, Sugestao de Compra,
// Automoveis, Vendas, Estoque, Dashboard, Cadastro Criticos, Diag Operacoes).
// Bonus: a DRE ficou mais rapida (30s -> 18s), porque processa 1/3 das linhas.
//
// **NOVA TELA: Ponto de Equilibrio** (/financeiro/ponto-equilibrio).
// Responde "quanto preciso vender por dia so pra empatar?" — contas fixas do
// mes divididas pela margem de contribuicao, dividido pelos dias em que a loja
// realmente vendeu (nao por 30). O lojista informa as contas fixas, a taxa
// media da maquininha e a comissao; o BI pega o CMV do ERP e a participacao
// real do cartao no mix. 4 KPIs (meta diaria, venda media, PE do mes, margem
// de seguranca), faixa com semaforo, grafico dia a dia (barra verde bateu a
// meta, vermelha nao), quadro "como chegamos nesse numero" com a fonte de cada
// valor, e tabela mostrando quanto de venda cada conta fixa exige.
// Sem dado nao inventa numero: diz o que falta preencher. Quando o custo do
// produto nao esta cadastrado no ERP, aceita a margem informada na mao.
// Novo FinanceiroRepository::cmvPeriodo() calcula o CMV de UM mes com cache
// (a tela carrega em 1,7s; usar dreMensal levaria 30s). Entrou no menu lateral
// (com toggle em Configurar Cards), no submenu do Financeiro, no manual com
// guia completo e no glossario.
// v1.7.211 (2026-08-21) — **FIX: "Caixa OK" nao mente mais quando tem centavos.**
// Reportado pelo cliente: banner verde dizia "Caixa OK — nada a investigar"
// E ao mesmo tempo "Diferença de R$ 0,29" — leitura contraditoria (parece bug).
// Fix: dois banners visualmente diferentes.
// - Diferenca exata (< R$ 0,01) → "✅ Bateu certo — nada a investigar" +
// "Todas as formas fecharam exatamente com o sistema."
// - Diferenca de centavos (0,01–0,50) → "🟢 Fechou dentro da tolerância —
// R$ 0,29 sobrou" + "Arredondamento normal em vendas com centavos.
// Nada a investigar, mas o valor está registrado nas seções abaixo."
// Backend limpou o tudo_ok_sub (frontend decide o texto agora).
// v1.7.210 (2026-08-21) — **FIX: contradicao "Precisa revisar" x "Caixa OK".**
// Bug: card externo mostrava "Precisa revisar" (laranja) e quando abria
// o drill dizia "Caixa OK — nada a investigar" (verde) pro MESMO caixa.
// Alem disso, texto "Todas as formas bateram" era mentira quando dinheiro
// tinha centavos de diferenca (ex: +R$ 0,29). Reportado no HERICA CX 21/08.
// 4 fixes ALINHANDO thresholds em 4 pontos que decidiam status separadamente:
// 1) FechamentoCaixaService::classificarCentral — se dif total < R$ 0,50 E
// dinheiro < R$ 5 E eletronico < R$ 10 E nada de fraude (troca de forma,
// cancel tardio, sangria propria), forca VERDE. Antes um chip amarelo
// qualquer marcava pendente mesmo com drill dizendo OK.
// 2) FechamentoCaixaService::analiseConferente — novo campo `tudo_ok_sub`
// HONESTO: em vez de "Todas as formas bateram", mostra "Diferença de
// R$ 0,29 a mais — arredondamento normal, considera-se OK".
// 3) fechamento-caixa-v2.js::renderConferente — usa `tudo_ok_sub` do backend.
// 4) fechamento-caixa-v2.js::renderKPIs — threshold "Bateu certo" pra 0.50
// (antes 0.01). Novo label "Arredondamento OK" pra 0.01–0.50. Alinha com
// o resto do sistema.
// 5) central.php::fraseAlerta — fallback nao diz mais "Precisa revisar"
// generico; mostra "Apenas R$ X sobrou (arredondamento) — abrir se quiser".
// v1.7.209 (2026-08-16) — **UI: badge do NOME DA LOJA em destaque no drill.**
// Cliente pediu pra destacar mais visualmente. Antes: azul claro discreto.
// Agora: gradiente azul-escuro sólido, fonte 1rem negrito uppercase, borda
// dupla, sombra sutil, letter-spacing. Vira o elemento MAIS forte do header.
// Operador e data continuam discretos (contraste).
// v1.7.208 (2026-08-16) — **FIX: iframe destruido pelo overlay quebrava abrir outro caixa.**
// Bug: quando fccIframeCarregou detectava url fora do esperado (ex: rota
// de export ou 404), substituia body.innerHTML por overlay "Sem dados pra
// mostrar" — isso DESTRUIA o iframe. Ao abrir outro caixa, $('#fcc-drill-iframe')
// retornava null e dava "Cannot set properties of null (setting 'src')".
// Fix: em fccInvestigar, se iframe nao existe, recria dentro do drill-body
// antes de setar src. Em fccFecharDrill, checa se iframe existe antes de
// setar src pra evitar erro se ja foi limpo.
// v1.7.207 (2026-08-16) — **FIX: numero Excel + cores PDF nas celulas KPI.**
// Bug 1: mso-number-format estava mal escapado ('#\.\#\#0\,00') e o valor
// saia com 4 casas ("287,3000"). Fix: numero em formato INGLES (6033.83
// com ponto decimal) + mso-number-format "#,##0.00" — Excel converte
// automaticamente pro locale BR na exibicao (6.033,83 e SOMAVEL).
// Bug 2: cores das celulas KPI (verde/vermelho/amarelo) sumiram no PDF
// quando adicionei classe .num junto (specificity). Fix: seletor mais
// especifico td.num.kpi-val.bom etc, com background em azul suave por
// default (destaca dos labels).
// v1.7.206 (2026-08-16) — **Excel: celulas somam de VERDADE (numero puro).**
// Cliente: "celulas nao estao somando, tem que ser real". Fix:
// Antes: mandava "R$ 6.033,83" como texto — Excel nao trata como numero.
// Agora: no Excel manda numero puro "6.033,83" (locale BR) + CSS
// mso-number-format aplica moeda automatica. Assim:
// - Seleciona coluna Valor no Excel → soma aparece na barra de status
// - Da pra usar =SUM(), filtros, ordenacao numerica, pivot table
// - PDF continua com "R$ 6.033,83" pra visual bonito
// Aplicado em TODAS as celulas com valor: formas, sangrias, suprimentos,
// cancelamentos, devolucoes, formula do dinheiro, KPIs.
// v1.7.205 (2026-08-16) — **Export MAIS colorido + TODAS as informacoes.**
// Cliente pediu: "quero um Excel mais colorido e com todas informacoes do
// caixa". Fix:
// + Nova secao ⏱ "Duracao e ritmo do turno" (teal): quanto tempo o caixa
// ficou aberto, cupons/hora, R$/hora, se foi reaberto.
// + Nova secao 🧮 "Como o sistema calculou o dinheiro esperado" (violeta):
// fórmula transparente Vendas + Suprimento + Reforcos − Sangrias =
// ESPERADO, com verde nos + e vermelho nos −, comparado com o
// declarado e diferenca destacada por cor semantica.
// + Nova secao ❌ "Cancelamentos no turno" (rosa-escuro): data/hora,
// nota, motivo, operador, valor. So' aparece se houver cancelamento.
// + Nova secao ↩ "Devolucoes no turno" (amarelo-escuro): data/hora,
// nota, cliente, operador, valor. So' aparece se houver devolucao.
// Total: relatorio ganhou 4 secoes novas com paleta variada (teal,
// violeta, rosa-escuro, amarelo-escuro) alem das ja existentes.
// v1.7.204 (2026-08-16) — **FIX Hora + Motivo saiam VAZIOS ('—') no export.**
// Bug: eu estava lendo $s['hora'] e $s['motivo'], mas formatarMovimentos()
// do service retorna 'data_hora' e 'historico'. Fix: alinhado com as
// chaves reais + fallback pros nomes antigos.
// Agora Excel/PDF mostra "08:29 · lanche de domingo" igual a tela do BI.
// v1.7.203 (2026-08-16) — **Excel export: paleta semantica variada.**
// Cliente reclamou "tudo azul, nada de outra cor". Causa: os badges com
// background em nao renderizam no Excel — so' cores em TD funcionam.
// Fix:
// - Removidos — cores agora aplicadas DIRETO no
// (cell-ok/atencao/critico com fundo verde/amarelo/vermelho + texto).
// - Cabecalhos de secao com CORES DIFERENTES por tipo:
// 💰 financeiro -> azul (#4338CA)
// 📊 indicadores -> roxo (#6D28D9)
// 💳 formas -> azul-info (#0369A1)
// 📤 sangrias -> VERMELHO (#B91C1C) — sinal de SAIDA
// 📥 suprimentos -> VERDE (#15803D) — sinal de ENTRADA
// 🎯 ajuda -> LARANJA (#C2410C) — alerta
// - Coluna Valor: sangria em vermelho, suprimento em verde.
// - Total geral colorido por tipo (formas azul, sangria vermelho,
// suprimento verde).
// - Diferenca positiva (sobra) em verde, negativa (falta) em vermelho.
// v1.7.202 (2026-08-15) — **Export: timeout maior + formatacao profissional.**
// Bug: PDF dava "Maximum execution time of 60s" em caixas com muitas
// vendas (v201 otimizou mas ainda batia limite em turnos grandes).
// Fix: set_time_limit(180) + ini_set max_execution_time=180.
// Feature: CSS refinado (v202) — tipografia maior (13px base, KPIs 16px),
// espacamentos generosos, cabecalho premium com barra colorida esquerda,
// linhas alternadas suaves (#FAFAFA), badges em uppercase, page-break-inside
// avoid nas tabelas pra nao quebrar no meio na impressao.
// v1.7.201 (2026-08-15) — **FIX lentidao export: SO' o dia do caixa.**
// Cliente reclamou export demorando muito. Causa: v200 processava 180
// dias inteiros pra pegar 1 caixa. Fix: 1 query rapida pra pegar
// DATA_ABERTURA do caixa (< 5ms), depois fechamentosCompletos filtrado
// ao DIA especifico. De ~180 caixas processados pra ~10-20.
// v1.7.200 (2026-08-15) — **FIX 500 no exportar-pdf/exportar-xlsx.**
// Bug: chamei processarFechamentos() no service — metodo nao existe.
// O certo e' fechamentosCompletos(busca, dataIni, dataFim), que ja
// processa tudo. Fix: usa o metodo real, filtra pelo COD_ABERT_CAIXA
// depois. Busca em intervalo de 180 dias (defensivo).
// v1.7.199 (2026-08-15) — **Ajuda ao Conferente: passos CURTOS + SEM JARGAO
// + botao "Ver como investigar" (colapsavel).**
// Cliente reclamou: texto de jornal com "KPI", "PDV", "cupom", "extrato",
// "TEF" — usuario nao tem tempo nem entende. Fix:
// - Todos os 5 padroes reescritos com 3-4 linhas MAX, vocabulario do
// dia a dia (nada de PDV/cupom/TEF/extrato).
// - Passos escondidos dentro de "▸ Ver como investigar" —
// fechado por default. Card mostra so' titulo + detalhe curto; se
// quiser passo a passo, clica pra abrir.
// - Removidos "Como investigar:" no inicio das sugestoes (redundante
// ja que o botao ja diz isso).
// v1.7.198 (2026-08-15) — **KPI Diferença TOTAL mostra AS 2 divergencias.**
// Cliente pediu: quando ha' divergencia isolada de forma (ex: DINHEIRO
// R$ 127,51) alem da diferenca do total (R$ 0,20), mostrar ambos NO
// proprio card do KPI. Antes so' mostrava a diferenca do total.
// Fix: alem do valor principal (R$ 0,20 Sobrou), adiciona uma linha
// fina embaixo (separada por linha tracejada): "⚠️ DINHEIRO: R$ 127,51
// a menos". So' aparece se existe forma com dif > R$ 20. Gestor ve os
// 2 numeros de imediato no KPI, sem ter que rolar pra baixo.
// v1.7.197 (2026-08-15) — **TEXTOS SUCINTOS + para de afirmar sem prova.**
// Cliente reclamou que o banner tem texto de jornal pra R$ 0,20 e afirmava
// "houve um ajuste" sem prova. Fix:
// - Frase principal: "R$ X contados · R$ Y apurados · R$ Z sobrou/faltou
// (arredondamento normal)." — 1 linha.
// - Aviso extra (quando forma tem dif grande): so' 2 casos —
// (a) outra forma tem valor oposto = "provavel troca de forma"
// (b) senao = "Investigue: Movimentacoes, Devolucoes, Cancelamentos"
// Sem afirmar "houve ajuste" — nao sabemos.
// - Fix bug de formatacao "R$ R$ 0,20" (fmtBR ja retorna com prefixo).
// v1.7.196 (2026-08-15) — **FIX: analise HONESTA, para de chutar causas.**
// Cliente reportou: banner amarelo dizia "Provavelmente uma venda foi
// registrada na forma errada" mesmo com todas as outras formas ✅.
// Matematicamente impossivel — se venda foi digitada errada, OUTRA forma
// teria +R$ X. Era CHUTE meu como fallback.
// Fix: analisa a realidade matematica em 3 casos, cada um verificado:
// 1. Existe outra forma com diferenca de sinal OPOSTO E magnitude
// compativel (>= 30% do valor da forma principal)? -> troca de forma
// REAL. So' entao afirma isso.
// 2. Devolucao/cancelamento no turno bate com a diferenca (± 15%)?
// -> explicacao tecnica confirmada.
// 3. Nenhum dos dois -> HONESTO: "matematicamente houve algum ajuste
// no total apurado (devolucao, cancelamento, desconto, troca ou
// outro lancamento). Verifique as secoes X, Y, Z pra achar."
// NAO CHUTA a causa quando nao sabe.
// Ver [[feedback-analise-pessoas-reais-responsabilidade]] — regra 5.
// v1.7.195 (2026-08-15) — **FIX: "bateu certinho" mentia com dif < R$ 0,50.**
// Bug: Math.abs(0.20) < 0.5 era true, entao o banner dizia "bateu
// certinho" mesmo com R$ 0,20 de diferenca — contradizendo o KPI acima
// que dizia "Sobrou R$ 0,20". Gestor viu e questionou.
// Fix: "bateu certinho" so' se |dif| < R$ 0,01 (praticamente zero).
// Qualquer diferenca real e' reportada com o valor. Threshold de
// arredondamento normal continua em R$ 5.
// v1.7.194 (2026-08-15) — **RECONCILIA os DOIS numeros de diferença no mesmo banner.**
// Gestor perguntou: "por que mostra 0,20 e nao mostra 127,51?". A resposta
// e' que os dois EXISTEM: 0,20 e' do TOTAL do caixa, 127,51 e' SO' da
// forma DINHEIRO. Convivem porque devolucao/cancelamento pago em dinheiro
// abate a forma "dinheiro" no apurado, mas o TOTAL fica igual (a devolucao
// tambem abate o total).
// Fix: quando |dif_total| < 5 (fechou) MAS alguma forma tem |dif| > 20,
// adicionar aviso amarelo no banner: "os DOIS numeros convivem: TOTAL
// fechou mas a forma X tem R$ Y a menos". Se ha' devolucao/cancelamento
// > R$ 20 no turno, explica que provavelmente foi pago em X — e' o
// funcionamento normal do PDV. Direciona pra Ajuda ao Conferente pra
// analise tecnica completa.
// v1.7.193 (2026-08-15) — **CLAREZA: explica de ONDE vem a diferenca total.**
// Gestor viu "Diferença TOTAL R$ 0,20 Sobrou" e perguntou "de onde faltou?"
// — nao entendeu que sobrou e nao entendeu de onde saiu o numero.
// Fix: adicionado banner explicativo logo abaixo dos 9 KPIs:
// "De onde vem a diferença TOTAL: Operador contou R$ X · sistema
// calculou R$ Y · R$ Z a mais/menos na gaveta."
// 3 modos:
// - abs(dif) < 0,50 → "bateu certinho"
// - abs(dif) < 5 → em verde: "diferença pequena — geralmente
// arredondamento normal (cliente pagou centavos
// a mais/menos, moedas trocadas)"
// - abs(dif) >= 5 → em vermelho: "role até o comparativo por forma
// abaixo pra ver em qual forma apareceu"
// Vira frase pronta que o gestor le sem calcular.
// v1.7.192 (2026-08-15) — **CLAREZA: os DOIS numeros de "diferença" tem rotulos claros.**
// Confusao real: KPI "Diferença R$ 0,20" (topo) e alerta "DINHEIRO diferença
// R$ 127,51" (ajuda ao conferente) na mesma tela, sem indicacao que sao
// DUAS coisas diferentes. Fix:
// - KPI do topo: rotulo "Diferença" -> "Diferença TOTAL" + subtitulo
// "(todas as formas)" + tooltip explicativo.
// - Achado do dinheiro: titulo "Só na forma DINHEIRO faltou R$ X — não
// é a diferença total do caixa". Detalhe explica que existem DOIS
// numeros de diferenca (total vs por forma) e a relacao entre eles.
// - Padrao devolucao_explica: cabecalho com "ATENÇÃO: são DOIS números
// diferentes de 'diferença'" e a distincao clara.
// Objetivo: gestor lendo entende de imediato que "sobrou R$ 0,20" NO
// TOTAL e "faltou R$ 127,51" NO DINHEIRO nao sao contradicao.
// v1.7.191 (2026-08-15) — **UI: painel de ajuda COLAPSAVEL (tela preta livre).**
// Cliente reportou: mesmo com scroll (v190), a tela branca de ajuda ocupava
// quase toda a viewport apertando os DADOS (KPIs, comparativo, botoes de
// marcar conferido/pdf/excel). Feedback: dados sao o principal, explicacao
// e' opcional — inverter.
// Fix: barra clicavel "🎯 Ajuda ao Conferente" (colapsavel) substitui o
// wrapper sempre visivel. Comeca FECHADO por default; estado salvo no
// localStorage. Quando fechado, iframe (tela preta com dados) ocupa
// praticamente todo o drill. Quando aberto, wrapper aparece com scroll
// interno max 55vh.
// v1.7.190 (2026-08-15) — **UI FIX: drill scroll interno.**
// Bug reportado: quando "A Central destacou" fica grande (v189 explica
// devolucao com muito texto), empurra iframe pra fora da viewport — o
// card branco ocupa a tela toda, iframe some. Usuario nao consegue rolar
// a "tela preta" (KPIs, comparativo, sangrias) porque nao ha' scroll.
// Fix: wrapper .fcc-drill-topo agrupa formula+histop+interp com
// max-height 45vh + overflow-y auto (scrollbar visivel). Iframe fica
// sempre visivel na metade de baixo do drill. Scrollbar estilizado
// pra combinar com o tema.
// v1.7.189 (2026-08-15) — **EXPLICA a matematica: DEVOLUCAO em dinheiro.**
// Cliente confuso com "dinheiro faltou R$ 127" + "total sobrou R$ 0,20" — nao
// consegue entender (matematicamente parece impossivel). Explicacao: no Fire
// ERP o "DINHEIRO APURADO" ja e' liquido de devolucoes/cancelamentos (ver
// [[infra-fire-dinheiro-apurado-formula]]). Se cliente devolveu R$ X em
// dinheiro, o sistema apura R$ X a menos — mesmo o operador nao tendo feito
// nada errado. E o TOTAL tambem fica R$ X a menos (por isso fecha).
// Fix:
// - Novo PADRAO F devolucao_explica: detecta quando dinheiro faltou X e
// total_devolucoes+total_cancelado ~ X. Prioridade MAX (roda antes de
// E e D). Mensagem: "isso NAO e' falta real, e' funcionamento normal
// do PDV quando devolucao e' paga em dinheiro". Passos: verificar a
// secao Devolucoes/Cancelamentos, confirmar com operador se foi
// entregue em dinheiro.
// - renderInterpretacao da Central atualizado: quando dif dinheiro > 50
// E total do caixa fechou, ADICIONA um bloco de "Contexto importante"
// explicando que provavelmente tem explicacao tecnica, nao falta real.
// Lista causas na ordem de probabilidade (devolucao primeiro).
// - Assinatura de analiseConferente() aceita 2 novos params (totalDevs,
// totalCanc) com default 0.0 (retrocompativel).
// v1.7.188 (2026-08-15) — **FIX bugs do v187 + passos DETALHADOS pro conferente.**
// Bug 1: link Excel do renderAcoes nao tinha target=_blank — clique dentro
// do iframe fazia o handler fccIframeCarregou detectar navegacao pra fora
// e exibir tela "Sem dados pra mostrar". Fix: target=_blank + rel=noopener
// nos dois links (PDF ja tinha).
// Bug 2: analiseConferente detectava troca_entre_formas errado — comparava
// com $difTotal (que vem de outro campo do Fire) em vez da SOMA das
// diferencas das outras formas. Caso Mil Coisa LAURA CX #13528: todas
// outras formas em zero, sistema dizia "troca" incorretamente. Fix: usar
// soma real das outras formas + testar sinal oposto.
// Bug 3: mensagens "NAO desconte do operador" removidas — BI nao opina
// sobre decisao trabalhista do gestor. So' apresenta DADOS + CAUSAS
// POSSIVEIS + PASSOS INVESTIGATIVOS. Regra global gravada no memory.
// Feature: passos MUITO mais DETALHADOS pra cada tipo de forma:
// - DINHEIRO: contagem fisica + sangrias/reforcos + formula + cupons
// - PIX: extrato bancario + cruzamento com cupons
// - CARTAO/TEF/POS: resumo da maquininha + cancelamento tardio + "meu cartao"
// - Outra: passos gerais
// Cada padrao (sangria compensa, forma zerada, ordem grandeza, divergencia
// grande) reescrito com instrucoes concretas ("abra o app do banco",
// "conte a gaveta", "localize o envelope") em vez de "peca extrato".
// v1.7.187 (2026-08-15) — **EXPORTAR Excel + PDF do Fechamento de Caixa.**
// Cliente pediu: botao imprimir/PDF + novo botao Excel com cores e
// somatorios, ambos visuais e profissionais. Substituido botao unico
// `window.print()` por 2 botoes:
// [Imprimir / PDF] → /caixa/fechamento/exportar-pdf (abre pagina
// pronta pra Ctrl+P, auto-dispara print no load)
// [Exportar Excel] → /caixa/fechamento/exportar-xlsx (Content-Type
// Excel + HTML tabular; Excel abre nativo)
// Ambos usam MESMO HTML renderExportHtml (cabecalho da loja, KPIs
// financeiros, comparativo Sistema × Operador com TOTAL GERAL, sangrias,
// suprimentos, Ajuda ao Conferente completa). Cores semanticas
// (verde/amarelo/vermelho), badges de status, rodape Fire.
// Rotas novas em public/index.php.
// v1.7.186 (2026-08-15) — **RESPONSABILIDADE: nunca acusar "dinheiro sumiu".**
// Caso real Mil Coisa/Tamara caixa #13528 LAURA CX: Ajuda ao Conferente
// disse "🚨 DINHEIRO faltou R$ 127,51. Dinheiro sumiu do caixa. Verifique
// possível retirada indevida." — MAS o TOTAL do caixa fechou (só R$ 0,20
// de diferença). Dinheiro faltou R$ 127,51 e OUTRAS FORMAS sobraram
// R$ 127,71: reclassificação (venda em dinheiro digitada como cartão/PIX).
// Se gestor lê "sumiu" e "retirada indevida", pode DESCONTAR do salário
// da LAURA sem base. GRAVE.
// Fix (analiseConferente + renderInterpretacao):
// - Padrao E TROCA_ENTRE_FORMAS detectado ANTES dos outros (prioridade
// max): se |dif_din| > R$ 50 mas |dif_total| < 15% de |dif_din| →
// marca reclassificacao, gravidade ATENCAO (nunca critico), lista
// quais formas compensaram, texto "NAO desconte, dinheiro nao sumiu".
// - Suprime padrao D (divergencia grande) na forma DINHEIRO quando E
// foi detectado — evita duplo aviso conflitante.
// - Reescrita frase "Dinheiro sumiu" da Central pra ser investigativa
// ("Pode ser: sangria não lançada... INVESTIGUE antes de agir").
// - Regra gravada em memoria global:
// feedback_analise_pessoas_reais_responsabilidade.md
// Aplicar mesma responsabilidade em QUALQUER outro modulo que aponte
// pessoa (alertas, ranking vendedor, excecoes caixa, cobranca).
// v1.7.185 (2026-08-15) — **FireHash COMPLETO: aceita senha alfanumerica.**
// Bug: MOHAMMAD com senha 'amani656' (letras+numeros) nao entrava — cliente
// teve que trocar pra so numeros. Causa: fireHash so cobria XOR MOCAIS puro.
// Descoberto (via TESTEBI/AEc123 com hash 0C 0A 43 70 7B 60):
// (1) Fire converte a senha para UPPERCASE antes de hashear
// (2) Aplica XOR MOCAIS byte a byte (chave circular)
// (3) Se o byte resultante for 0x00 (null) ou 0x20 (espaco), substitui
// pela propria chave — evita chars que TRIM/string-null quebrariam
// Confirmado com 4 amostras (FIRE/121920, LORENA/824344, MOHAMMAD/122027,
// TESTEBI/AEc123). Bate 100% nas 4. Agora aceita QUALQUER combinacao de
// letras+numeros em qualquer case. Simplifica o array $tentativas (uma
// entrada cobre tudo).
// v1.7.184 (2026-08-14) — **CLAREZA PRA CONFERENTE (Central de Caixas).**
// Baseado em padrao TOTVS/Bling/F360, apos pesquisa com o conferente.
// (1) Card "Como usar essa tela" (colapsavel) — 3 passos + glossario com
// 6 termos (Apurado, Declarado, Divergencia, Sangria, Reforco, Caixa
// aberto). Auto-abre na 1a visita, lembra escolha (localStorage).
// (2) Formula transparente do Apurado no drill: "Vendas dinheiro +
// Suprimentos - Sangrias = Esperado" vs Declarado + Divergencia
// colorida (verde/amarelo/vermelho). Ensina o conferente COMO o
// sistema chegou no numero.
// (3) Motivos pre-definidos ao marcar conferido: modal com 8 opcoes
// (bateu certinho, troco nao devolvido, sangria nao lancada, venda
// cancelada maquineta, pgto pendente ontem, erro contagem, troco
// a mais/menos, outro). Motivo salvo em conferidos.json e mostrado
// na aba de ja-conferidos. Botao "Investigar depois" pra pular sem
// marcar. Elimina "textao livre" que ninguem le depois.
// (4) Historico do operador nos ultimos 30 dias no drill: qtd caixas,
// qtd divergencias, taxa%, media R$. Status: normal/atencao/critico
// (heuristica: pct_diverg vs valor medio). Novo endpoint GET
// /caixa/central/historico-operador?loja=X&operador=Y[&dias=30]
// com cache 5min no repository.
// (5) Drill maior: 92% -> 98% de largura (a pedido do conferente).
// Retrocompatibilidade: motivo_cod/motivo_txt sao opcionais — clientes
// nao mostram nada de diferente ate serem atualizados.
// v1.7.183 (2026-08-14) — **DEFAULT SEGURO: login_sem_senha ausente = FALSE.**
// Bug: em v182 o default era TRUE se a flag nao existisse no config —
// entao TODO cliente que atualizou via OTA (sem a flag) ficou aceitando
// qualquer senha. Confirmado pelo Derlivon apos rollout do v182.
// Fix: default agora e' FALSE. Bypass so' ativa se 'login_sem_senha' =>
// true estiver EXPLICITO no config. Isso e' seguro pra todos porque
// fireHash() decifra o algoritmo do Fire pra qualquer cliente.
// v1.7.182 (2026-08-14) — **FIX CRITICO: dbConfig() jogava fora login_sem_senha.**
// Bug: mesmo com 'login_sem_senha' => false gravado no config, o metodo
// dbConfig() FILTRAVA o array e retornava so 5 campos fixos, jogando a
// flag fora. No login(), array_key_exists('login_sem_senha', $cfg) era
// SEMPRE false, entao caia no default = TRUE = bypass.
// Resultado: v180+v181 nao tomavam efeito, cliente entrava com qualquer
// senha. Fix: propaga a flag se estiver no arquivo original.
// v1.7.181 (2026-08-14) — **FIX: remove fallback DEV-only inseguro.**
// Bug: v1.7.159 introduziu um fallback que aceitava login sem senha se o
// Apache reportava SERVER_NAME=localhost — mas TODOS os Apaches de cliente
// tem essa config default no httpd.conf, entao IP publico caia no bypass.
// Cliente Grupo Ata confirmou: FIRE entrou com senha 'ab' apos v180.
// Agora eh binario: senha real ok OU config login_sem_senha=true. Nada mais.
// v1.7.180 (2026-08-14) — **HASH PROPRIETARIO FIRE DECIFRADO — fim do bypass.**
// Descoberto por cracker: Fire ERP grava USUARIOS.PASS como XOR simples com
// chave fixa "MOCAIS" (6 chars, se repete p/ senhas maiores). Confirmado com
// 2 pares (LORENA/824344 -> u}wr}g; FIRE/121920 -> |}rx{c).
// Adicionado metodo FbAuth::fireHash(senha) e incluido no ARRAY de tentativas
// ANTES do MD5. Agora o BI valida a senha REAL do PDV/ERP Fire.
// Mantidas as tentativas MD5/plain/upper como fallback pra bancos antigos.
// Cliente pode setar 'login_sem_senha' => false com seguranca — os operadores
// entram com a senha do proprio Fire, sem duplicar cadastro.
// IMPACTO: v179 (nao publicada) foi este trabalho em WIP. v180 = commit.
// v1.7.178 (2026-08-14) — **FLAG POR CLIENTE: login_sem_senha no config.**
// Cada cliente decide no config/database.php se aceita login sem senha:
// 'login_sem_senha' => true → bypass (comportamento antigo, compat)
// 'login_sem_senha' => false → exige senha real (seguro)
// (nao definido) → default = true (compat com clientes atuais)
// Grupo Ata mantem true (operadores sem senha continuam entrando).
// Clientes que querem seguranca setam false explicitamente.
// v1.7.177 (2026-08-14) — **REVERT v175: bypass total quebrou hierarquia.**
// v175 aceitava qualquer usuario existente sem validar senha — LORENA
// entrava com senha 'hhh', 'x', qualquer coisa. Cliente reportou como bug
// serio. Volta ao comportamento SEGURO v147: EXIGE senha real.
// Operador que nao consegue logar precisa cadastrar senha no ERP Fire
// (Cadastros > Usuarios > definir senha).
// v1.7.176 (2026-08-14) — **FIX: Restrição de LOJA respeitada mesmo pra SUPERVISOR.**
// Cliente reportou: LORENA configurada pra ver so Achadinhos (nao Importados/
// Mil Coisa) na tela /configurar/usuarios, mas o BI mostrava tudo. Causa:
// LORENA e' SUPERVISOR='S' no ERP Fire; lojasPermitidas fazia short-circuit
// em isAdmin() e retornava [] (sem restricao).
// Fix: restricao explicita de loja SOBREPOE isAdmin. Se admin cadastrou
// lojas na tela, respeita. Se nao cadastrou, admin ainda ve todas.
// v1.7.175 (2026-08-14) — **REVERT TOTAL da v147.**
// Volta ao comportamento pre-v147: aceita login se o usuario existe no ERP,
// independente de senha e de qual IP acessou. Cliente Grupo Ata (todos os
// operadores sem senha) e outros voltam a funcionar de qualquer lugar.
// Trade-off assumido pelo dono: bypass antigo restaurado, seguranca fica
// por conta da rede/VPN externa.
// v1.7.174 (2026-08-14) — **EXPAND: Bypass tb pra VPN Radmin/Hamachi/CGNAT.**
// Cliente Grupo Ata confirmou: v173 funciona SO dentro do servidor
// (127.0.0.1). Operadores em outros PCs acessam via Radmin VPN (26.x.x.x)
// ou pela internet — nao caiam no ehLanPrivada.
// Expandido:
// • Radmin VPN (26.x.x.x)
// • Hamachi (25.x.x.x)
// • CGNAT / Tailscale (100.64-127.x)
// • Localhost completo (127.x)
// Alem disso, agora GRAVA no error_log tanto sucesso quanto rejeicao
// do bypass, pra auditoria (identificar IPs que precisam ser cadastrados).
// v1.7.173 (2026-08-14) — **HOTFIX: Bypass de rede LAN privada (fecha v147).**
// Cliente Grupo Ata e outros tinham TODOS os usuarios sem senha no ERP.
// O bypass antigo aceitava; a v147 quebrou tudo; v171 tentou fix parcial
// (PASS NULL/vazio) mas o teste em campo mostrou que operadores nao
// necessariamente tem PASS vazio — pode ter algum caractere invisivel.
// Fix definitivo mais SIMPLES:
// • Login vindo de LAN privada (192.168.x, 10.x, 172.16-31.x, 127.x):
// aceita usuario que existe SEM validar senha (como pre-v147)
// • Login vindo de IP publico (Internet): mantem v147 (exige senha)
// Racional: rede LAN privada da loja = ambiente de confianca fisica.
// Cada login LAN sem senha grava em error_log lembrando de cadastrar
// senha real no ERP pra fechar a brecha.
// Impacto: restaura TODOS os clientes travados apos v147. Nao introduz
// vulnerabilidade externa (Internet ainda exige senha).
// v1.7.172 (2026-08-14) — **REVERT v171: bloco PASS NULL causou regressao.**
// O bloco novo do v171 pra aceitar login com PASS vazio quebrou o login
// normal em algum cenario (cliente reportou "nem eu consigo entrar" apos
// aplicar). Removido — volta ao comportamento estavel v170.1.
// Cliente com PASS NULL/vazio no ERP precisa CADASTRAR SENHA no Fire:
// Fire ERP → Cadastros → Usuarios → [operador] → Definir senha.
// Depois disso, operador digita usuario+senha e entra normal.
// v1.7.171 (2026-08-14) — **HOTFIX CRITICO: cliente nao conseguia logar apos update.**
// Grupo Ata (MOHAMMAD e outros) travou no login "Usuario ou senha invalidos"
// apos receber a v1.7.147+ (que removeu o bypass de senha).
// Causa: usuarios com PASS NULL/vazio no USUARIOS do Fire. O bypass antigo
// aceitava; a v147 exige "PASS = ?" que nunca bate com NULL.
// Fix SEGURO (nao reintroduz o bug):
// • Se nenhuma tentativa com senha achou, tenta buscar usuario com
// PASS explicitamente NULL/vazio no banco.
// • Se achou = aceita login com senha em branco (o usuario NUNCA teve
// senha, e o admin do ERP nunca cadastrou uma).
// • Se nao achou = mantem comportamento v147 (rejeita).
// SYSDBA e outros que tem senha cadastrada continuam sendo validados
// normalmente — o buraco de seguranca da v146 nao volta.
// Log registra cada login "sem senha" pra auditoria.
// v1.7.170.1 (2026-08-14) — **FIX: JSON quebrado ("Unexpected token '<")**
// O v170 do "Ajuda ao Conferente" tinha 2 bugs:
// • Operator precedence: `(float)$x['dif_dinheiro'] ?? 0` avaliava
// cast antes do ??, dando warning "undefined key" pra caixas sem
// essa chave (que só existe apos classificarCentral).
// • Warning HTML vazava no JSON, quebrando o parser do frontend.
// Fix: calcula difDinheiro direto do comparativo (procurando forma
// DINHEIRO), try/catch em volta, display_errors=0 no endpoint /dados.
// v1.7.170 (2026-08-14) — **UX: Card "Ajuda ao Conferente" (Detalhe por Operador).**
// Cliente reclamou: conferentes com dificuldade — nao sabem se sobrou/faltou
// dinheiro, se PIX foi declarado errado, se sangria foi contada 2x. A tabela
// Sistema x Operador que ja existia (renderComparativo) mostra os NUMEROS
// mas nao INTERPRETA — deixa o conferente decidir sozinho.
// Novo card NO TOPO da tela do caixa (antes de tudo) — SO aparece quando ha
// algo pra investigar. Traduz os numeros em AÇÕES concretas.
// 5 padroes detectados automaticamente:
// 1. Ordem de grandeza errada (10x / 100x / 1000x menor)
// → "POS DEBITO — parece 10x menor · esqueceu de digitar um 0"
// 2. Forma zerada (sistema >20, operador = 0)
// → "PIX — nao declarado · esqueceu de conferir o extrato"
// 3. Sangria compensa dinheiro (dif_dinheiro ≈ ± total_sangrias)
// → "Diferenca bate com a sangria · verificar envelope"
// 4. Divergencia grande sem padrao (delta > R$ 100 ou > 20%)
// → "Reconferir essa forma antes de fechar"
// 5. Tudo OK (nenhum achado) — card verde de conformidade
// Semaforo: 🚨 critico (vermelho) · ⚠️ atencao (amarelo) · ✅ ok (verde).
// Sai colorido no PDF tb (@media print completo).
// Custo zero no banco — 100% do dado ja vinha em fc.comparativo/sangrias/etc.
// v1.7.169 (2026-08-14) — **UX: Destaque de linha "longa" mais visível.**
// Cliente reparou: legenda dizia "linhas em amarelo = mais de 12h", mas
// TODAS as horas ficam amarelas (padrao da coluna Hora). Confusao entre
// a hora amarela e o destaque de linha inteira.
// Fix:
// • Fundo da linha ".longo" trocou de amarelo 5% (invisivel) pra CORAL 18%
// • Barra lateral esquerda de 4px coral (aumenta o destaque)
// • Coluna "Em curso" fica em coral tb (batendo com o fundo)
// • Legenda: "Linhas com FUNDO coral = ..." (nao mais "amarelo")
// No PDF: fundo #ffedd5 (coral pastel), barra #c2410c (coral escuro).
// v1.7.168 (2026-08-12) — **FIX: Modal de detalhe do caixa quebrava.**
// Ao clicar numa linha da tela /caixa/periodos pra abrir detalhes ao vivo
// (feature v161), aparecia "Erro de rede: fmtBR is not defined". Bug do
// escopo: `fmtBR` estava definido no fechamento-caixa-v2.js (outra tela),
// nao no ). Adicionada a tag script pra ECharts na view antes do IIFE do fetch. Validado local no L.A. Silva: donut renderiza com 151 clientes classe A (79,96%), 134 B (15,01%), 180 C (5,03%) — Pareto perfeito.
// v1.5.43 (2026-07-02) — FIX tela /atacado/pedidos que mostrava sempre "0 pedidos" no L.A. Silva. 3 bugs empilhados no AtacadoPedidosController: (1) SQL usava P.DATA_EMISSAO mas coluna real no schema Fire eh P.DT_EMISSAO (validado: L.A. Silva tem 8001 pedidos historicos, 1985 nos ultimos 12m, ultimo em 01/07/2026). (2) Filtro default 'aberto' + tabela sem coluna STATUS = whereStatus retornava FALSE sempre → 0 linhas. Agora quando STATUS nao existe no schema, filtro 'aberto' vira 1=1 (mostra tudo). (3) Filtro COMPRA_VENDA='V' filtrava so 3 dos 1985 pedidos porque L.A. Silva usa 'P' (Pedido) e 'O' (Orcamento) — nao o padrao 'V'. Trocado pra excluir apenas 'C' (Compras) via <> 'C' — captura V, P, O e qualquer outra variacao futura. Descoberta de coluna via RDB\$RELATION_FIELDS mantida (schema-safe).
// v1.5.42 (2026-07-02) — FIX SQLs do modulo Atacado inventavam colunas que nao existem no schema Fire (varia por cliente). Auditoria completa validada contra L.A. Silva Atacadista (v1.5.40 mostrava tabela vazia com R\$ 0,00 em Curva ABC e /api/atacado/clientes retornava []). CORRIGIDO: (1) AtacadoRepository::listarClientesComABC — trocava p.CNPJ_CPF/CIDADE/UF (inexistentes) por p.CNPJ+p.CPF + JOIN CIDADES (COD_CIDADES/DESCRICAO/UF). (2) AtacadoRepository::detalheCliente — mesmas correcoes de PESSOAS + p.FONE_PRINC/p.EMAIL_PRINC1. (3) AtacadoRepository::topItensCliente — JOIN correto NOTAS_CAB × NOTAS_ITENS por chave composta (COD_EMPRESA+COD_TIPO_OPERACAO+NR_NOTA+SERIE, NAO por COD_NOTA_CAB inexistente) + usa ni.DESCRICAO direto (NOTAS_ITENS tem DESCRICAO, ITENS_ESTOQUE nao tem) + QTD*PRECO_UNIT (NOTAS_ITENS nao tem VALOR_TOTAL). (4) AtacadoCurvaAbcController — antes so importava VendasRepository sem usar; agora instancia AtacadoRepository e chama curvaAbcClientes(100)+curvaAbcProdutos(100), normaliza formato pro que a view espera (NOME/TOTAL/PERC/PERC_ACUM/CLASSE). Validado contra L.A. Silva: 465 clientes classificados, R\$ 5.08M em clientes ABC, R\$ 5.91M em produtos ABC, LATICINIO BELA VISTA/MARAVILHA-SC no topo.
// v1.5.41 (2026-07-02) — FIX /atacado/clientes que mostrava HTTP 404 no card "Carteira de clientes". A view atacado/clientes.php faz fetch em /api/atacado/clientes pra popular a tabela com sort/busca/export, mas essa rota nao estava mapeada no router (so /api/atacado/dashboard existia). Adicionado: (1) metodo apiData() no AtacadoClientesController que retorna JSON {ok,linhas} com listarClientesComABC + indiceAtrasoPorCliente mergeados (alias CURVA_ABC→ABC e VALOR_VENCIDO→ATRASO_RS pra bater com o JS); (2) rota GET /api/atacado/clientes no public/index.php. Zero impacto pras outras rotas.
// v1.5.40 (2026-07-02) — FIX rotas B2B (Clientes, Recebiveis, Pedidos, Curva ABC) que estouravam "Call to undefined method". Os Controllers foram gerados na v1.5.36 mas dependiam de metodos que nao existiam nos Repositories. Implementados 9 metodos novos + 1 expansao: AtacadoRepository ganhou listarClientesComABC (com classificacao 80/15/5), detalheCliente(id), historicoComprasCliente(id), topItensCliente(id), evolucaoMensalCliente(id). RecebiveisRepository ganhou aging(clienteId) EXPANDIDO (aceita opcional), detalhado(clienteId,faixa), clientesComTitulos, totais(clienteId), indiceAtrasoPorCliente, titulosPorCliente(id), totalVencidoCliente(id). Todos com try/catch defensivo (schema-safe) + UTF-8 fix + limites (FIRST 20-500). Validado local contra L.A. Silva Atacadista via VPN: /atacado/clientes (57k bytes), /atacado/pedidos (33k), /atacado/curva-abc (37k), /atacado/recebiveis (31k) — todos HTTP 200.
// v1.5.39 (2026-07-01) — FIX FINAL Painel Atacado: o arquivo /assets/js/atacado-dashboard.js NAO EXISTIA no repo (esquecido pelo workflow que gerou o segmento Atacado). A view atacado_dashboard/index.php carrega esse JS pra popular KPIs+graficos via /api/atacado/dashboard, e sem ele todos KPIs ficavam "--" pra sempre — backend funcionava, controller retornava JSON correto, mas ninguem lia. Criado o JS completo: (1) fetch em window.__ATACADO.apiUrl com credenciais; (2) 5 KPIs preenchidos com deltas semanticos (verde/vermelho); (3) 4 graficos ECharts — Faturamento mensal (linha), Top 10 Clientes (barras horizontais), Top 10 Produtos (barras horizontais), Mix Cond Pgto (donut); (4) badge "Conectado" no topo com feedback visual; (5) resize automatico. Validado local com banco Importados real: R$ 46k mes, 3256 clientes, todos graficos renderizando.
// v1.5.38 (2026-07-01) — REHOTFIX v1.5.37 (que quebrou o autoload do AtacadoRepository): meu proprio alias vendasPorUf() colidia com vendasPorUF() ja existente (PHP method names sao case-insensitive → Fatal Error "Cannot redeclare"). Removido alias — chamada do Controller $repo->vendasPorUf(12) continua funcionando porque PHP nao diferencia case em nome de metodo. Resto dos fixes v1.5.37 mantidos (kpisTopo, mixCondicaoPagamento, aging, construtor tolerante).
// v1.5.37 (2026-07-01) — HOTFIX Painel Atacado (dashboard mostrava "--" em todos KPIs): (1) AtacadoRepository ganhou metodo kpisTopo() que agrega os 4 KPIs (Faturamento, Ticket, Clientes ativos, NFe emitidas) — antes Controller chamava kpisTopo() que nao existia → 500. (2) Aliases: mixCondicaoPagamento() e vendasPorUf() (Controller usava case/nome diferente do Repo). (3) RecebiveisRepository ganhou alias aging() (Controller chamava assim mas metodo era agingRecebiveis). (4) Ambos os Repos com construtor tolerante — aceita (int, int) que o Controller passa erroneamente como (ano, mes) sem quebrar. Zero mudanca em Controllers/Views — fix so no Repository. Todos os KPIs e graficos agora carregam.
// v1.5.36 (2026-07-01) — SEGMENTO ATACADO: novo AtacadoDashboardController + 4 controllers B2B (Clientes, Pedidos, Recebiveis, CurvaAbc) + AtacadoRepository + RecebiveisRepository. Tema 'atacado_corp' azul corporativo. Home /: quando segmento IN (atacado, distribuidora) roteia pra AtacadoDashboard; senão continua no DashboardController normal (zero impacto pra bar/varejo/sorveteria/utilidades). FbAuth ganhou SEGMENTOS_B2B e SEGMENTOS_SEM_NFCE. Sidebar filtrado. Wizard universal ganhou opção 5 Atacadista B2B.
// v1.5.35 (2026-06-30) — SISTEMA DE LOG DE ATUALIZACOES: cliente nao precisa mais de PowerShell pra diagnosticar OTA. (1) Novo service App\Services\Atualizacao\Logger.php coleta snapshot completo do ambiente: hostname, install_root, app_root, PHP version, e estado de 9 arquivos criticos com bytes+mtime. (2) AtualizacaoController::aplicarApi() refatorado: registra cada etapa (download, extracao, robocopy, force_copy_criticos, opcache_reset), snapshot antes/depois, e em caso de falha tambem grava. (3) Force-copy individual de arquivos criticos (config/backup-notificacao.php, config/backup-oauth.php, Versao, BackupController, Views, SmtpClient, Notificador, Crypto) pra contornar robocopy que pula arquivos as vezes. (4) Logger grava log local em storage/logs/atualizacao/-.json E envia pro painel central com tipo='atualizacao'. (5) Painel central (api.php) agora aceita tipo='atualizacao' e salva em storage/atualizacoes/.jsonl. (6) Nova tela atualizacoes.php no painel central: lista clientes, ultima versao, etapas detalhadas, snapshot dos arquivos criticos com status existe/falta, link no header do painel principal. Resultado: posso descobrir qualquer problema de OTA em qualquer cliente sem entrar no cliente.
// v1.5.34 (2026-06-30) — Hardening do fallback de email: (1) SmtpClient.php tambem agora usa ?: (Elvis) em vez de ?? — antes ?? deixava passar string vazia e quebrava envio quando job/config tinha campo branco. (2) View /backup aba email blindada contra Warning quando $jobAtivo=null (cliente sem nenhum job ainda) — usava !empty($jobAtivo['email']['smtp_senha']) que dava warning e quebrava o render da senha pra baixo. Trocado pra is_array+?? null seguro.
// v1.5.33 (2026-06-30) — FIX cascata de fallback: tela /backup aba email vinha com campos vazios quando o JSON do job tinha string vazia (jobs antigos salvavam ''). Causa: operador ?? do PHP so substitui null, nao string vazia. Trocado pra ?: (Elvis) na view e no emailTestar do controller. Agora De/Para/Servidor/Usuario realmente caem no fallback global Fire Sistemas. Tambem corrige o erro "Destinatario (Para) obrigatorio" no botao Enviar e-mail teste.
// v1.5.32 (2026-06-30) — Senha SMTP global Fire Sistemas preenchida no config/backup-notificacao.php (App Password "BI Fire Global" do Gmail derlivon89@gmail.com). Todos os clientes que atualizarem pra essa versao recebem a senha junto e ja podem clicar em "Enviar e-mail teste" sem digitar nada.
// v1.5.31 (2026-06-30) — Senha SMTP GLOBAL Fire Sistemas: configurar 1 vez em C:\BI\config\backup-notificacao.php (campo smtp_pass) e ao publicar OTA TODOS os clientes recebem. Tela /backup aba E-mail detecta automaticamente se senha global existe e mostra "✓ Senha SMTP global configurada por Master Automacao — clique em Enviar e-mail teste direto". Cascata: senha do form > senha do job (encriptada) > senha global (plaintext do config Fire). Cliente individual ainda pode sobrescrever digitando senha propria (que ai vai ser encriptada no JSON dele).
// v1.5.30 (2026-06-30) — UX teste de email: (1) Resposta do servidor SMTP em caso de falha agora aparece DESTACADA em caixa branca com borda vermelha — nao precisa mais rolar o log pra ver o codigo do erro (ex: "535-5.7.8 Username and Password not accepted"). (2) Log completo retornado (nao trunca mais em 2KB). (3) Backend extrai a ultima linha 4xx/5xx do log e envia como campo separado erro_servidor pro JSON.
// v1.5.29 (2026-06-30) — Fix usabilidade SMTP: (1) senha agora tem TODOS os whitespaces removidos antes de usar — Gmail mostra a App Password com espacos a cada 4 chars ("abcd efgh ijkl mnop") e a colagem direta gerava 535 (auth refused). Agora pode colar com ou sem espaco. (2) Mensagem de erro de auth no Gmail/Google agora inclui dica especifica: "Gmail exige App Password (16 chars) em myaccount.google.com/apppasswords".
// v1.5.28 (2026-06-30) — FASE 5 ATIVADA: notificacao de backup por email funcional. (1) Botao "Enviar e-mail teste" na aba /backup → email: envia teste em tempo real, mostra sucesso/falha inline com log SMTP expandivel. (2) Novo endpoint POST /api/backup/email-testar. (3) Senha SMTP agora ENCRIPTADA no JSON do job (AES-256-CBC, chave derivada de hostname+install root — nao migra entre maquinas). (4) Notificador::enviarEmailSeErro reescrito: usa SMTP do JOB primeiro (com decrypt), fallback global; modo=sempre dispara tambem em sucesso. (5) BackupRunner agora dispara email em sucesso (Notificador filtra por modo). (6) Banner "Fase 5" da view removido.
// v1.5.27 (2026-06-30) — Polimento de copy: tela /configurar/atualizacao quando ja esta atualizado mostrava "Voce ja esta na versao mais recente (vX.Y.Z)" — redundante com o card de cima que ja exibe a versao instalada. Agora mostra apenas "Sistema atualizado — nenhuma versao nova disponivel".
// v1.5.26 (2026-06-30) — Tela /backup aba "Notificação por E-mail" agora ja abre com TODOS os campos pre-preenchidos: De/Para/Servidor SMTP/Porta/Usuario carregados de config/backup-notificacao.php (Fire Sistemas centralizada). Usuario so digita a senha. Cascata de fallback: $jobAtivo['email'] > $cfgGlobalEmail > default fixo. Senha CONTINUA sempre vazia por seguranca (autocomplete=new-password adicionado pra bloquear autofill do browser).
// v1.5.25 (2026-06-30) — Tambem: FIX tela /configurar/atualizacao mostrava "Versao instalada v1.5.23" no card de cima mas "Voce ja esta na versao mais recente (v1.5.24)" no resultado da verificacao. Causa: OPcache servia Versao::ATUAL stale quando a view era renderizada (1.5.23) mas o endpoint /verificar lia fresco depois (1.5.24). Fix: opcache_invalidate(Versao.php) em index() e verificarApi() + JS agora sincroniza dinamicamente o card "Versao instalada" com d.atual retornado pelo backend.
// v1.5.25 (2026-06-30) — STATUS "EM ANDAMENTO" no sistema de backup (3 partes): (1) BI cliente — novo card LARANJA "🔄 Backup em andamento" na tela /backup (qualquer aba) com tempo decorrido, estagio atual (gerando .fbk / comprimindo / enviando Drive), tamanho atual do arquivo crescendo em tempo real e PID; polling AJAX 5s no novo endpoint GET /api/backup/status-agora; botao "Executar Agora" some enquanto rodando, reaparece + reload da pagina ao terminar. (2) Heartbeat — novo metodo Notificador::enviarHeartbeat($job, $estagio, $tamanho_atual, $iniciado_em) com throttle 25s; BackupRunner emite em pontos-chave: iniciando, gerando_fbk (loop a cada 30s durante o gbak via novo callback no FirebirdBackup::executar), comprimindo, enviando_drive; payload sobrescreve mesmo storage/__.json com status='em_andamento'. (3) Painel Central — bolinha AZUL PULSANTE quando heartbeat < 90s, tag "EM ANDAMENTO" com estagio, tempo decorrido e tamanho_atual crescendo no detalhe; aviso laranja "⚠️ Possivelmente travado" quando >5min sem heartbeat (com PID pra investigar); KPI extra "🔄 EM ANDAMENTO" so aparece quando ha backup rodando; refresh dinamico 15s durante backup vs 60s normal; ordenacao traz em-andamento pro topo. Motivacao: cliente em 30/06 cancelou/reiniciou processos varias vezes achando que travou (banco 4-7GB demora 30-60min). Inclui v1.5.24.
// v1.5.24 (2026-06-30) — FIX CRITICO bug que eu mesmo introduzi na v1.5.22: pipes do proc_open() do FirebirdBackup ficavam BLOQUEANTES → loop com fgets($pipes[1]) ficava preso esperando dados do stdout do gbak. Como gbak escreve TUDO no stderr (nao stdout), o stdout fica vazio e o fgets nunca retorna. Resultado: PHP travava esperando, gbak era morto pelo SO, .fbk ficava truncado em ~100MB (banco de 7GB). Caso confirmado Real Prime 30/06: 2 backups seguidos com 129MB cada quando deveriam ter 4-6GB. Fix: stream_set_blocking(false) nos pipes + stream_select com timeout de 5s + proc_get_status pra detectar fim do processo. Agora gbak roda do comeco ao fim sem travamento.
// v1.5.23 (2026-06-30) — FIX CRITICO upload Drive arquivos >200MB. HttpClient.php fazia file_get_contents() do arquivo INTEIRO antes de enviar — pra .fbk de 4GB tentava alocar 4GB de RAM mas memory_limit eh 512MB → PHP morria silenciosamente (com @ suprimindo o warning) → upload nunca acontecia → backup local OK mas Drive vazio. Caso confirmado Real Prime 30/06/2026: backup 4GB ficava local mas nada subia. Agora HttpClient detecta arquivo grande e usa curl.exe do Windows (C:\\Windows\\System32\\curl.exe — vem no Win10/11) que faz streaming nativo. Timeout aumentado pra 2h (minimo) pra dar tempo de upload em internet lenta de bar (5-20 Mbps × 4GB = 30-110 min).
// v1.5.22 (2026-06-30) — FIX CRITICO de backup pra bancos grandes (>15 min): (1) ANTI-COLISAO — BackupRunner cria lock file storage/backup/locks/.lock antes de rodar; se ja existe lock <2h, pula tick sem incrementar tentativa. Bug confirmado no Real Prime (banco 4GB) — gbak rodando ~15 min E retry de 5 min disparava 2o gbak simultaneo, ambos colidiam no lock do .fbk e marcavam falha. (2) STDERR CAPTURADO — trocado popen() por proc_open() pra capturar stderr do gbak. Antes: campo log do erro vinha vazio (gbak escreve no stderr, popen so pega stdout). Agora painel central mostra a mensagem real do erro. (3) Lock auto-cleanup via register_shutdown_function pra nao deixar orfao em crash.
// v1.5.21 (2026-06-30) — FIX contador "Tentativa 4 de 3" no painel de backups. Antes: BackupRunner sempre incrementava tentativa_atual a partir do valor anterior, mesmo quando a execucao foi disparada por HORARIO AGENDADO (nao por retry). Resultado: depois de 3 falhas no dia anterior + dispara no horario do dia seguinte = "4 de 3" mostrado. Agora reseta contador pra 0 quando nao ha tentar_novamente_em ativo, e so incrementa quando o tick eh do retry mesmo.
// v1.5.20 (2026-06-29) — Modulo Cozinha ganhou 3 controles na tela /cozinha/config: (1) SWITCH ATIVO/DESATIVADO — quando OFF esconde o menu Cozinha do sistema inteiro (gestor pode reativar via mesma tela que continua acessivel); (2) CONFIRMACAO antes do clique Pronto — evita cozinheiro marcar errado; (3) BOTAO VOLTAR pros ultimos finalizados nos ultimos X min (default 10) — desfaz UPDATE em LANC_MESA (PRONTO/PRONTOFIM/PRONTOQUEM/PRODUINI/PRODUZINDO=NULL) + remove do kds_finalizacoes.json + item volta pra fila. Novo endpoint POST /api/cozinha/desfazer. Flags persistem em storage/kds_config.json (ativo, confirmar_pronto, permitir_desfazer, minutos_desfazer).
// v1.5.19 (2026-06-29) — Sistema de backup com retry automatico + log completo no painel central. BackupRunner agora reexecuta o backup em caso de falha: 1min, 5min, 15min (max 3 tentativas) — antes era 1 chance unica e desistia. Notificador envia tambem o stderr/log completo do gbak (truncado em 6KB) + numero da tentativa + proxima_tentativa_em + intervalo_esperado_horas (deriva do agendamento e o painel usa pra calcular ATRASADO real). Painel /central/ mostra "Tentativa N de 3 - proxima em HH:MM" no card de erro + bloco expandivel "Log detalhado do gbak". Email so dispara na 3a falha consecutiva (evita spam de retry). Scheduler::deveRodar() agora prioriza retry agendado antes de checar agenda normal.
// v1.5.18 (2026-06-29) — FIX CRITICO no agendador de backup: Scheduler::deveRodar() tinha janela de 2 minutos (linha 39: $diff <= 0 && $diff >= -2) mas o worker-tick e disparado pelo Windows Task Scheduler a cada 5 min — se tick caisse em 06:03 a janela 06:00 era IGNORADA pra sempre. Caso confirmado: Buteco Toda Hora com 06:00 e 22:40 fixos ficava 1+ dia sem backup mesmo agendador "ATIVO". Fix: janela aumentada pra 60 min apos horario configurado + anti-duplicacao confere ultimo_run >= timestamp do horario (em vez do antigo "5 min"). Tambem corrigido Painel Central de Backups (painel-central-servidor/index.php) que tinha threshold de ATRASADO hardcoded em 48h — agora respeita intervalo_esperado_horas (default 28h pra diario). Antes: cliente diario que perdesse 1 ciclo ficava VERDE por mais 24h, mentindo pro gestor.
// v1.5.17 (2026-06-29) — Card "Consultar Cupom Fiscal" no Leitor mobile ganhou campo de busca por NUMERO da nota (quando operador so tem o numero, sem o QR code). Filtro local em tempo real pelos ultimos 30 cupons; se nao achar, lupa busca no servidor por NR_NOTA exato. Backend nfceRecentesApi agora aceita ?nr=. Lista aumentou de 10 → 30 ultimos. Se a busca por numero retornar 1 unico match exato, abre o cupom direto sem clique extra.
// v1.5.16 (2026-06-29) — Card "Tema" removido da home do Leitor. Acesso a temas continua disponivel via icone discreto 🎨 no header (cabecalho do app).
// v1.5.15 (2026-06-29) — Botao da lupa (busca por codigo no Leitor home) agora usa cor do tema (var(--accent)) em vez de var(--btn) fixo. Antes, no tema Cyber Neon a borda do Escanear era ciano mas a lupa era rosa shocking - destoava. Agora lupa fica da mesma cor do acento principal do tema selecionado em qualquer skin (Cyber, Fogo, Tropical, Esmeralda, etc).
// v1.5.14 (2026-06-29) — FIX CRITICO no Leitor: login via PIN tinha 5 perms HARDCODED (consulta/estoque/preco/dados/foto) e ignorava TOTALMENTE o que era marcado em /leitor-admin/permissoes. Resultado: marcava fiscal_caixa/inventario/consultar_cupom no admin e nada aparecia no celular logado por PIN. Agora PIN usa permissoesDoUsuario('_PIN_') que cai no _default do config (fallback automatico quando chave nao existe) — admin passa a controlar PIN tambem. Scanner() tambem recarrega perms pra PIN (antes so recarregava pra ERP). Bug confirmado 29/06 com o Real Prime/Importados onde Derlivon marcou tudo mas continuou vendo so scanner.
// v1.5.13 (2026-06-29) — Tela /leitor-admin/permissoes ficou MUITO mais legível: perms agrupadas por categoria (Consulta básica / Edição / Inventário / Fiscal de Caixa), botões "Marcar todas / Desmarcar todas" no topo + "Marcar / Limpar" por grupo, perm MÃE marcada com estrela colorida e borda mais grossa, sub-perms indentadas com aviso "↳ requer X". Alerta amarelo automático quando sub-perms estão marcadas mas a mãe NÃO está (situação que deixa as opções órfãs no Leitor mobile). Inspirado no caso Importados 29/06 onde fiscal_risco/fiscal_aprovar foram marcados sem fiscal_caixa e nada aparecia no celular. Config GRUPOS_PERMISSOES em LeitorPermissoesController define a estrutura.
// v1.5.12 (2026-06-28) — DEBUG visual da busca: pfBuscarPorTexto agora mostra toast "Buscando 'XXX'..." E checa se #pfMatchesBusca existe (se não, mostra toast "JS antigo no cache" — sinal claro de cache stale). Catch de erro de rede mostra mensagem real (em vez de só "Erro ao buscar" genérico). Endpoint backend buscarQuick foi VALIDADO direto via PHP CLI: retorna 5 itens pra 'det', 'YPE', 'arroz' OK. Bug do cliente = cache do WebView servindo JS antigo (pfBuscarCod/pfBuscarPorTexto sem regex /^\d+$/).
// v1.5.11 (2026-06-28) — Busca em tempo real (debounce 350ms oninput) + lupa.
// v1.5.10 (2026-06-28) — REWRITE foto do produto: