Relatório e verificação

Esta página trata do ângulo técnico. O passo a passo para quem recebe o PDF e o significado de cada seção estão em Como conferir um relatório.

Como o relatório é gerado

O relatório é produzido por uma função do servidor (generateAccountabilityReport), nunca pelo aparelho. Ela só atende conta Premium, verificado no servidor; o período pedido vai de um a doze meses.

sequenceDiagram
    participant M as Membro
    participant F as Função
    participant B as Banco
    participant S as Arquivos
    M->>F: pede
    F->>B: confere acesso
    F->>B: carrega registros
    F->>S: hash dos anexos
    F->>F: monta o PDF
    F->>B: grava reportIssues
    F-->>M: PDF e código

O registro gravado em reportIssues tem o SHA-256 do PDF, o código, o plano, a conta de quem emitiu, o período e a data de emissão. Ele não guarda o PDF, nem o título do plano, nem nomes. Esse registro é fechado ao cliente: só as funções do servidor o leem e escrevem.

Como o servidor reconhece um relatório

A função verifyReport não exige login. Recebe o SHA-256 de um arquivo e responde se existe um relatório emitido com aquela impressão digital. Se existe, devolve apenas o código, o período e a data de emissão; nunca a conta, o plano ou nomes. A página iunto.app/verificar calcula o SHA-256 no navegador: o PDF não é enviado ao servidor, só os 64 caracteres do hash (G-28).

O que o hash cobre

O hash cobre os bytes do PDF. Um PDF alterado em qualquer ponto, mesmo sem mudança visível, tem outro hash e não é reconhecido. O hash não cobre a verdade do que o PDF diz: o relatório reproduz o que o servidor tinha registrado na emissão, e os limites desses registros são os descritos em Trilha de auditoria e em Limites conhecidos. Também não prova que nada aconteceu depois da emissão: um relatório mais novo pode trazer alterações posteriores.

Como reportIssues é escrito pelo servidor do operador, o selo prova que o Iunto emitiu aquele arquivo. Ele não é um carimbo de tempo de terceiro.

Relatório de quem saiu do plano

Quem saiu ou foi removido ainda emite o relatório do período em que participou, até o mês da saída. O servidor decide a origem dos dados assim:

flowchart TD
    A["Pedido de relatório"] --> B{"A conta é membro<br/>do plano hoje?"}
    B -->|sim| C["Lê os documentos vivos<br/>do plano"]
    B -->|não| D{"A trilha mostra que<br/>participou do plano?"}
    D -->|não| E["Recusa"]
    D -->|sim| F["Monta tudo só da trilha,<br/>até o mês da saída"]

No segundo caminho, nenhum documento vivo é lido: o plano, as notas, os pagamentos e os comentários são reconstruídos a partir da trilha, como estavam na saída (G-29). Não se usa o estado de hoje porque ele pode ter sido alterado depois da saída. O cabeçalho do PDF traz “Saída do emissor” e “Fonte dos dados”. A conversa e os acertos são lidos dos documentos, porque são imutáveis.