Manual da fase do AUDESP: como rastrear a versão para o arquivo não ser rejeitado

Último dia do prazo de envio, 16h. O operador da prefeitura manda o arquivo ao AUDESP e recebe rejeição. Tenta de novo, mesma mensagem. O sistema interno está certo para quem usa a tela, mas gera o arquivo do jeito que o manual anterior pedia. A resposta curta: o manual da fase é a especificação do arquivo, e a versão que você implementou precisa estar escrita no repositório. Com isso, quando o TCE-SP publica uma revisão, a diferença vira tarefa com prazo, não descoberta no dia do envio.

O exemplo deste guia é um sistema de gestão municipal fictício, o gestao-pm, mantido por uma equipe de três desenvolvedores que atende algumas prefeituras do interior paulista.

Por que o arquivo fica para trás da tela

O AUDESP é o sistema de auditoria eletrônica do Tribunal de Contas do Estado de São Paulo. Os órgãos jurisdicionados enviam informações em arquivos com estrutura definida, organizados em fases, cada uma com documentação própria na página do tribunal. A tela do sistema interno é feita para o usuário. O arquivo é feito para o validador do tribunal. São dois contratos diferentes.

Quando o manual muda, a tela normalmente continua igual: o usuário cadastra o mesmo contrato, a mesma licitação, o mesmo servidor. Nada dispara alarme. A mudança aparece só no arquivo, e só quando ele é validado. Se a equipe não acompanha a documentação, o primeiro aviso é a rejeição.

O outro motivo é cultural. Muita equipe trata o manual como PDF de apoio, consultado quando algo dá errado. Na prática, ele é o leiaute: campos, formatos, obrigatoriedade e regras de validação. Ignorar uma revisão é como ignorar a mudança de versão de uma API da qual seu sistema depende.

A estrutura de cada arquivo e o que o tribunal confere nele são tema de outro guia, sobre o que o AUDESP lê no arquivo enviado. Aqui o foco é o processo: saber qual versão você segue e perceber quando ela mudou.

Como rastrear a fase e a versão do manual

1. Registre a versão implementada: crie um arquivo no repositório com fase, versão ou data do manual e o hash do documento usado.
2. Guarde o manual junto: salve uma cópia do PDF e dos esquemas publicados numa pasta de documentação do projeto, com a data no nome.
3. Verifique periodicamente a página oficial: uma pessoa responsável confere a página de documentação do tribunal em datas definidas e antes de cada período de envio.
4. Compare o hash: se o documento baixado hoje tem hash diferente do registrado, algo mudou e precisa ser lido.
5. Transforme a diferença em tarefa: cada mudança vira item no backlog com prazo anterior ao próximo envio.
6. Valide antes do envio oficial: o arquivo passa por validação local contra o esquema, quando o tribunal publica um, e por um teste com dados de exemplo.

O arquivo de versão no repositório

No gestao-pm, o arquivo audesp/versao-leiaute.json responde à pergunta "que manual este código segue?":

{
  "fase": "IV",
  "documento": "manual da fase publicado na pagina de documentacao do TCE-SP",
  "versao_ou_data_do_manual": "preencha com o que consta na capa do documento",
  "baixado_em": "2026-02-03",
  "sha256_manual": "hash-do-pdf-baixado",
  "pasta_local": "docs/audesp/fase-iv/2026-02-03/",
  "responsavel": "ana.souza",
  "proxima_verificacao": "2026-05-04"
}

Os valores são de exemplo. O importante é que o campo de versão seja copiado do próprio documento, não de memória.

Detectando que o manual mudou

Baixe o documento atual da página oficial e compare o hash com o registrado. No PowerShell:

$registrado = (Get-Content .\audesp\versao-leiaute.json -Raw | ConvertFrom-Json).sha256_manual
$atual = (Get-FileHash .\manual-baixado-hoje.pdf -Algorithm SHA256).Hash.ToLower()

if ($atual -ne $registrado.ToLower()) {
    Write-Output "Manual diferente do registrado. Abrir tarefa de revisao."
} else {
    Write-Output "Manual igual ao registrado."
}

Hash diferente não diz o que mudou, só que mudou. Pode ser uma correção de digitação ou um campo novo obrigatório. Por isso o passo seguinte é ler o histórico de alterações do documento, se houver, ou comparar as seções de leiaute.

Validando contra o esquema antes de enviar

Quando o tribunal publica esquemas de validação, como arquivos XSD para arquivos XML, use-os no seu teste automatizado. Um exemplo em Python com a biblioteca lxml:

import sys
from lxml import etree

def validar(caminho_xsd, caminho_xml):
    schema = etree.XMLSchema(etree.parse(caminho_xsd))
    documento = etree.parse(caminho_xml)
    if schema.validate(documento):
        print("ok:", caminho_xml)
        return True
    for erro in schema.error_log:
        print(f"linha {erro.line}: {erro.message}")
    return False

if __name__ == "__main__":
    if not validar(sys.argv[1], sys.argv[2]):
        sys.exit(1)

Rodando esse script no pipeline com um arquivo gerado a partir de dados de exemplo, a equipe descobre a quebra no pull request, não no último dia do prazo. A validação local não substitui a do tribunal, que pode ter regras de negócio além da estrutura, mas elimina a classe mais boba de rejeição.

Quando a rejeição chega mesmo assim

Leia a mensagem inteira antes de qualquer reenvio. Ela costuma apontar o registro e o campo. Pedir ao operador para "tentar de novo" sem mudar nada só gera outra rejeição e consome tempo do prazo. Registre a mensagem no chamado, reproduza com o mesmo dado no ambiente de teste e corrija o gerador, não o arquivo à mão. Correção manual no arquivo resolve o envio de hoje e garante o mesmo erro no próximo ciclo.

Este texto trata do lado técnico. Dúvida sobre o conteúdo da prestação de contas em si cabe ao responsável contábil do órgão e à orientação do próprio tribunal.

Erros comuns

• Gerar no formato da fase anterior porque a tela não mudou: o arquivo sai coerente para o usuário e inválido para o tribunal.
• Não registrar a versão do manual no código: quando algo quebra, ninguém sabe se o problema é bug ou leiaute desatualizado.
• Usar o envio oficial como primeiro teste: a rejeição aparece com o prazo correndo e sem tempo para corrigir com calma.
• Reenviar sem ler a mensagem: o mesmo erro volta, e a equipe perde horas preciosas do último dia.
• Corrigir o arquivo à mão: o envio passa, mas o gerador continua errado e o problema se repete no ciclo seguinte.
• Depender de uma única pessoa que "acompanha o tribunal": se ela sai de férias perto do prazo, a revisão do manual simplesmente não acontece.

Checklist

• O repositório tem um arquivo com fase, versão do manual, data e hash.
• Uma cópia do manual e dos esquemas está guardada com data no nome.
• Há responsável e data definida para verificar a página oficial.
• Mudança de hash do manual gera tarefa no backlog.
• O pipeline valida um arquivo de exemplo contra o esquema publicado, quando existir.
• O procedimento de rejeição começa pela leitura da mensagem, não pelo reenvio.
• A verificação acontece antes de cada período de envio, não depois.

Abra o código que gera o arquivo do seu sistema: está escrito em algum lugar qual fase e qual versão do manual ele segue, e essa é a mesma versão que está publicada hoje na página do tribunal?