Monitoramento: visão geral, mensagens, processos e relatórios

Histórico de versões

• 2.12.3

  O conteúdo dos relatórios fica pronto mais rápido depois de uma carga grande: a preparação grava só o que mudou em cada mensagem e soma os totais em lotes maiores. Os números, a conciliação e a evidência não mudam.

  09/11/2026 · updated

• 2.12.2

  A preparação do conteúdo dos relatórios anda mais devagar enquanto há leitura ou processamento em curso e volta ao ritmo normal quando o atraso passa de 2 horas. As abas Negócio e o construtor de relatórios avisam quantas mensagens ainda estão fora dos números, e o aviso ignora as que nunca entrariam: mensagem de teste, expurgada ou em quarentena.

  09/11/2026 · updated

• 2.12.1

  Contagens de mensagens em empresas grandes: a lista de empresas (Empresas, no admin), a lista de Relatórios, o alerta de taxa de erro, o relatório técnico por integração (e o MCP) e o bloco Operação do painel do sócio passam a contar pelo consolidado por hora, com as horas mais recentes contadas na hora. Antes contavam uma a uma todas as mensagens (nas listas, todas as guardadas), e com uma empresa do tamanho da JAU o banco interrompia a leitura. As listas, o alerta e o relatório técnico contam o mesmo de antes: só as mensagens guardadas (o que a retenção já apagou não entra). Se alguma hora sair aproximada, os números aparecem com "≈" e uma dica (no alerta, também no Slack, com a linha inteira no idioma da empresa, e no e-mail). Nas listas, cada empresa é contada à parte: a que não couber no tempo mostra "—" e as outras seguem; zero erro aparece como 0. No painel do sócio, as contagens e a série incluem o que a retenção já apagou (a tela avisa), e a latência sai das 5 mil mensagens guardadas mais recentes do período (com mais do que isso, "≈").

  31/10/2026 · updated

• 2.12.0

  Empresa nova já nasce com os relatórios lendo a consolidada por hora (visão executiva, técnico, gráfico por hora e scorecard rápidos desde o primeiro dia), sem passo manual: na criação pela tela de empresas e no preparo da célula nova. As empresas que existiam lendo direto passam à consolidada no release, depois da conferência de que os números são iguais aos da leitura direta.

  28/10/2026 · updated

• 2.11.5

  Correção: a consolidação dos relatórios deixou de falhar com "invalid input syntax for type integer" em algumas horas (o tempo de cada passo saía com meio milissegundo). As horas afetadas são reconstruídas no próximo ciclo.

  15/10/2026 · updated

• 2.11.4

  A preparação do conteúdo dos relatórios cede a vez a uma leitura em andamento no mesmo ambiente (as mensagens desse ambiente andam devagar; os outros ambientes seguem normalmente), aumenta o ritmo quando a fila acumula, respeita o prazo do ciclo e lê as mensagens em partes menores. Os relatórios continuam corretos durante a espera (a mensagem ainda não preparada é lida na hora).

  15/10/2026 · updated

• 2.11.3

  Correção no rótulo "Consolidado por hora · atualizado há…": ele mostrava a idade da última linha reconstruída, que só anda quando chega mensagem, então uma empresa sem tráfego dizia "há 1 hora" com a consolidada a 5 minutos. Agora mostra a idade real da marca do consolidador (quanto a consolidada está atrás) e, quando está em dia e nada foi reconstruído depois dela, diz "em dia, sem mensagens novas". Nenhum número dos relatórios mudou.

  15/10/2026 · updated

• 2.11.2

  Correção na consolidada dos relatórios: uma mudança feita nos primeiros minutos de vida de uma mensagem, seguida de outra escrita nela sem relação com os relatórios (por exemplo, arquivar a falha), podia deixar a hora com o número antigo até a conferência noturna. Agora a hora é refeita no ciclo seguinte.

  15/10/2026 · updated

• 2.11.1

  Menos escrita no banco a cada lote de mensagens: a consolidada dos relatórios passa a anotar cada hora que precisa ser refeita uma vez por operação, e não uma vez por mensagem (um lote de 470 mensagens anotava 470 vezes a mesma hora). Nenhum número muda; o banco grava menos e os lotes ficam mais leves.

  14/10/2026 · updated

• 2.11.0

  Os relatórios podem ler uma tabela consolidada por hora em vez de somar todas as mensagens a cada abertura (a escolha é por empresa, a leitura direta continua sendo o padrão): a visão executiva, o técnico e o gráfico por hora do monitor abrem em fração de segundo mesmo com centenas de milhares de mensagens. Quando a empresa usa a consolidada, a tela mostra "Consolidado por hora · atualizado há…"; as horas ainda não reconstruídas e as últimas horas são lidas na hora. Se a leitura na hora passaria de 50 mil mensagens, as horas que não couberem vêm da consolidada e a tela avisa "Números aproximados" com a lista delas (o resumo da IA não é gerado nesse estado). O tempo até o envio (p50, p95, p99) passa a ser o limite superior da faixa (erro de até uma faixa) e o prazo de entrega da política de SLA só aceita valores que a consolidada mede com exatidão (qualquer minuto até 60, múltiplos de 15 até 24 h e de 6 h até 7 dias). Correção: a visão geral e o scorecard de parceiros deixam de contar mensagem de teste, como os KPIs e o SLA já faziam.

  14/10/2026 · updated

• 2.10.4

  Correção de desempenho: o envelhecimento das pendências (faixas do relatório técnico, a lista "precisa de você" e a página de saúde operacional do /admin) deixou de calcular o desfecho de todas as mensagens da empresa e passou a olhar só as pendentes, por um índice próprio. Os números são os mesmos, calculados na hora; a página de saúde operacional recebe a contagem por empresa já somada.

  14/10/2026 · updated

• 2.10.3

  Desempenho: o alerta de taxa de erro por empresa e as contagens que chegam só com a empresa passaram a usar o índice por ambiente (a empresa é convertida nos ambientes dela). Os números são os mesmos.

  14/10/2026 · updated

• 2.10.2

  Correção: os cartões do /monitor e dos relatórios (contagem por desfecho das últimas 24 h) deixaram de estourar o tempo no volume da rodada noturna: a contagem usa um índice de cobertura e deixou de chamar uma função por mensagem. Os números são os mesmos.

  14/10/2026 · updated

• 2.10.1

  Correção: seleção em massa com snapshot do servidor estável (PR #1007); prints dos tutoriais mostram a mensagem do erro (PR #1006). Release #1008.

  23/09/2026 · updated

• 2.10.0

  Resposta do destino na própria linha, com altura constante e o motivo real do erro. Cartão de total passa a obedecer os filtros. Coluna que declara filtro passa a filtrar — idade, tentativas e próxima tentativa existiam na tela e nunca filtraram nada. Filtros deixam de vir de lista paralela e derivam do mesmo array do cabeçalho. Itens #582, #534, #604, #605.

  19/09/2026 · updated

• 2.9.1

  Fix (reportado pelo Bruno 27/08): seleção em massa vazava entre contextos — selecionar mensagens na empresa A e navegar pra B (monitor, relatório ou tabela por integração do EDI Hub) mantinha as anteriores contando na barra, e o Reprocessar em massa agiria nesses ids invisíveis. Raiz: o bulk-selection-store é global de módulo e sobrevive à navegação client-side; nada o limpava. Fix: prune(validIds) no store — a seleção nunca contém id fora do dataset da tela atual — aplicado no MessageTable (monitor/reports), MessagesTable (por integração) e nas barras de integrações/empresas do admin (mesmo vazamento latente). Filtrar/paginar dentro da mesma tela preserva a seleção; poda sem assinar o store nas tabelas (sem re-render por checkbox). +5 testes. Bônus: pre-push não aborta mais sob sh -e quando db:drift falha sem token.

  28/08/2026 · updated

• 2.9.0

  Monitor: busca typeahead por nome de empresa no TenantListView (paridade com /reports). Com 18+ empresas, achar uma sem rolar. KPIs seguem refletindo saúde geral; só a lista filtra. i18n PT/EN/ES.

  11/06/2026 · updated

• 2.8.0

  Pass E do polish iterativo — último do plano. (1) Empty states informativos: MessageTable distingue tenant sem mensagens (sugere verificar integrações) vs filtros restritivos demais (mostra total disponível + botão "Limpar todos os filtros"). (2) Saved views Monitor: migration monitor_saved_views (user_id, tenant_id, name UNIQUE, query_string) com RLS per-user. Endpoints GET/POST/DELETE. Componente SavedViewsDropdown com 2 botões (Salvar visão + Visões N), input inline pra nome, dropdown com delete + apply. Cliente salva combo de filtros frequentes ("Travadas Walmart") e reaplica com 1 click. 19 chaves i18n × 3 idiomas. Fim do plano de 5 passes (A-E). PR #68.

  18/05/2026 · updated

• 2.7.0

  Pass D do polish iterativo — 3 features pra /relatorios. (1) Período customizado: toggle 7d/30d/90d/Custom no header com datepicker inline. URL state ?period=X&from=Y&to=Z. computeStats aceita endDate opcional pra comparativo no período custom. (2) Export da lista filtrada: botão "Exportar esta lista" no MessagesDrilldownList gera CSV client-side com 7 colunas business + filename mensagens_<filter>_<date>.csv. (3) P95/P99 nos cards: ComparativeStats ganha timeToSuccessP95Sec/P99Sec calculados via sort + percentile. Card "Tempo médio até sucesso" mostra tooltip "P95: 12s · P99: 45s" embaixo do P50. Diferencial enterprise — outliers visíveis sem drill-down. PR #67.

  18/05/2026 · updated

• 2.6.0

  Pass C do polish iterativo — produtividade Monitor. (1) URL stateful filters: todos os filtros da MessageTable (q, status[], direction, from/to, advanced, colfilters) escrevem na URL via router.replace. Compartilhar URL com filtros, bookmark, back/forward, reload preserva. (2) Quick reprocess inline: novo ícone RotateCw na primeira coluna visível apenas pra mensagens em error/dead_letter. Estados idle/loading/success(check verde 1.5s + router.refresh)/error(alert vermelho 4s). Padrão Boomi/MuleSoft — economiza ~3 cliques por mensagem em triagem. Endpoint /api/edi-hub/reprocess-message rate-limited 30/min. PR #66.

  18/05/2026 · updated

• 2.5.0

  Pass B do polish iterativo — drill-down de /relatorios. (1) ComparativeCards do topo viram <Link href="?filter=X#messages"> clicáveis. Card ativo ganha ring-2 + bg primary/5 + border primary/50. URL #messages anchor scrolla suave. (2) Novo componente MessagesDrilldownList no fim do report com 7 colunas business (Recebido em, Documento, Tipo, Origem, Destino, Status humanizado sem código, Tempo até sucesso). Status traduzido: Recebida/Em processamento/Concluída/Travada/Em retry. (3) Paginação 50 default + botão "Ver mais N". Empty state + limpar filtro. Ícone Eye em cada row → /monitor/empresa/[id]?q=docnum. (4) Page lê searchParams.filter (whitelist all/success/stuck/errors) e propaga. 20 chaves i18n novas × 3 idiomas. PR #65.

  18/05/2026 · updated

• 2.4.0

  Pass A do polish iterativo. (1) Monitor: nova ordem default de 12 colunas (Recebida em → Documento → Tipo → Origem → Destino → Direção → Integração → Status → Latência → Idade → Tentativas → Próxima). (2) Rename "Colunas técnicas" → "Expandir Detalhes" nos 3 idiomas. (3) Expandido adiciona 5 colunas contextuais: Status Origem (após Origem), Status Destino (após Destino), Formato, Mapping (lookup id→nome), Versão (mapping_version). (4) Processos: nova ordem (Iniciado em → Último evento → Documento → Parceiro → Status → Etapas). Page /monitor/empresa/[id] passa mappings query nova pra montar lookup. PR #64.

  18/05/2026 · updated

• 2.3.0

  Fase 2 finalizada — 3 últimos buracos da proposta original entregues. (M) ProcessingFunnel mostra 4 estágios do pipeline: Recebidas → Mapeadas → Enviadas → Sucesso. Cada estágio com count + conversion rate vs anterior (verde ≥90% / amarelo 70-89% / vermelho <70%) + drop-off entre estágios visível. Diagnostica gargalo: se 1000 → 950 → 200, o problema está na entrega. (N) AgingByIntegration complementa o AgingBuckets global com tabela por integração — 1 row por integração com 5 buckets coloridos + total. Ordenação default: Critical DESC → Stale → Aging — integrações mais urgentes em cima. (O) Toggle Diária/Semanal/Mensal no VolumeChart — usuário escolhe granularidade conforme análise (diário pra debug, semanal pra renovação, mensal pra ROI). Bucket key por granularidade (date/ISO week start/YYYY-MM). PR #60.

  18/05/2026 · updated

• 2.2.0

  Reports completion — 4 buracos fechados da proposta original. (L) Sidebar agora tem item "Processos" entre Monitor e Relatórios pros 3 perfis (super admin/support/dashboard). /processos/[id] virou página própria (era re-export de /monitor/flows/[id]) com link voltar contextual pra /processos e 15 chaves i18n no novo namespace processosDetail. (K) Novo WeeklyTrendChart — taxa de sucesso week-over-week nas últimas 12 semanas com linha referência verde em 95% (gráfico vendável pra renovação). Tooltip mostra X% (sent/total) + Semana de dd/mm. (I) Novo ErrorsByCategory — pie/donut com as 7 categorias do classifier heurístico (Auth/Schema/Mapping/Transport/Timeout/Business/Unknown). Cores escalonadas por severity, click numa fatia abre /monitor filtrado por error_category. MessageTable ganha filtro de ?error_category= via useSearchParams. Empty states distintos (sem erros vs nenhum classificado ainda) com nota sobre cobertura prospectiva. Novo namespace i18n errorCategories (8 labels × 3 idiomas). (J) Novo ExportButtons no header de /relatorios — Imprimir/PDF (window.print + CSS print stylesheet que esconde sidebar/nav, A4-friendly, break-inside avoid em cards) + Exportar CSV (blob client-side com 4 seções: volume diário, erros por categoria, top 20 partners, erros por tipo). Zero dependência nova. PR #59.

  18/05/2026 · updated

• 2.1.0

  Fase 2 parte 2 do refactor Monitor/Reports — 4 features UX que dependiam da foundation. (E) 4 cards comparativos no topo de /relatorios com Δ% vs período anterior (30d atual vs 30d anteriores) — Documentos no período, Taxa de sucesso, Tempo médio até sucesso (P50), Mensagens travadas. Cor semântica invertida por direção (mais é bom vs menos é bom). (F) Nova rota /processos com linguagem business — mesmo dado de /monitor/flows (document_flows) mas vocabulário PT/EN/ES: "Document Flows" → "Processos de negócio", "Stages" → "Etapas", "Orphan" → "Fora do fluxo". (G) Drill-down: click numa fatia de "Erros por Tipo" ou barra de "Erros por Parceiro" no /relatorios abre /monitor/empresa/[id]?q=X filtrado. MessageTable lê useSearchParams e pré-popula busca. (H) AutoRefresh 30s em /monitor — router.refresh() sem full reload, pause/play, React 19 purity-safe. PR #58.

  18/05/2026 · updated

• 2.0.0

  Fase 2 parte 1 do refactor Monitor/Reports — foundation no DB + 2 features que consomem. (A) Migration: messages.updated_at + trigger (corrige bug silencioso da Fase 1 onde "Idade no status" sempre renderizava — porque coluna não existia em public.messages). View v_message_aging com aging_bucket categórico (fresh/recent/aging/stale/critical) + flag needs_attention. View v_integration_health com last_success_at, last_error_at, contadores 24h/7d. Tabela error_categories com 7 root causes (auth/schema/mapping/transport/timeout/business/unknown) + label e ação recomendada em PT/EN/ES. Coluna messages.error_category FK. (B) Classifier heurístico em src/lib/edi-hub/error-classifier.ts com 30 testes. Helper markMessageError() integrado em process-message.ts (5 sites) e retry-orchestrator.ts. (C) Tile "Integrações silenciosas" no /monitor — fluxo recente mas sem dado nas últimas 24h. (D) Aging buckets em /relatorios — barra horizontal stacked + grid de 5 tiles, diferencial visual vs MuleSoft/Boomi. PR #57.

  18/05/2026 · updated

• 1.0.0

  Fase 1 do refactor Monitor/Reports — separação de audiências (técnico vs business) em 5 sub-tarefas. (1) ForecastChart removido + SlaRiskTable renomeada pra OperationalRiskTable — sem promessa de SLA contratual que o produto não cumpre. (2) Colunas MessageTable renomeadas: Doc→Documento, Remetente→Origem, Destinatário→Destino, Data/Hora→Recebido em. Toggle "Colunas técnicas" esconde Status origem/destino/Formato por padrão. (3) 3 colunas observáveis novas: Idade no status (cor escalonada cinza/amarelo/vermelho), Tentativas, Próxima tentativa. (4) Tile "Precisam de atenção" no /monitor agregando mensagens em erro >1h sem retry + per-card badge. Recurring Errors movido de /reports → /monitor. (5) ExplainableCard com botão "O que isso mostra" expansível em cada seção de /relatorios (sugestão Bruno) — explicação em PT/EN/ES por gráfico. PR #56.

  18/05/2026 · updated