O caminho de uma cidade — e onde você entra

1. 1
   Conseguir a documentação fora desta ferramenta

   WSDL, XSD, manual e exemplos de XML vêm da prefeitura ou do integrador. A IA ajuda a procurar e converte o que você trouxer, mas não substitui a fonte: confirme na origem.

2. 2
   Modelar a ferramenta faz

   Converter a documentação, gerar os mapeamentos JSON — um por operação: autorizar, consultar, cancelar — e registrar a cidade.

3. 3
   Provar você conduz

   Validar, testar o modelo no motor e testar a comunicação com a prefeitura. São três execuções separadas, na ordem do mais barato para o mais caro.

4. 4
   Configurar e homologar fora desta ferramenta

   Aplicar o modelo no Portal Faktura e rodar os cenários de homologação com a prefeitura. Só então a cidade vai a produção.

Cada execução termina mostrando o que vem depois — você não precisa decorar esta trilha.

Vocabulário mínimo

Integrador

A empresa de tecnologia por trás do sistema da prefeitura (Betha, ISSNet, SpeedGov…). Uma cidade tem um; um integrador atende muitas cidades.

Modelo / mapeamento

O JSON que diz como montar o XML da nota, como enviá-lo e como ler a resposta. É o produto do trabalho aqui.

RPS / DPS

O pedido de nota que o sistema envia à prefeitura. Ela responde autorizando e devolvendo o número da NFS-e.

XML e DANFSe

O XML é a nota em si, com validade fiscal. O DANFSe é o PDF, a versão que o cliente lê.

ABRASF e Nacional

Os dois padrões de NFS-e. ABRASF varia de cidade para cidade; o Nacional é o padrão único do governo federal, usado por quem aderiu ao Emissor Nacional.

Homologação

A fase de testes com a prefeitura, antes de emitir nota de cliente real.

Portal Faktura

Onde o Motor de Notas lê o modelo. É lá que a alteração passa a valer.

Regras de ouro

• Sem documentação não existe modelo. Prioridade das fontes: XSD, depois WSDL, depois manual técnico, depois exemplos de XML. Sem nada disso, o modelo seria chute — e a IA vai pedir que você envie o arquivo à mão.
• XML de nota real vale ouro. Se você tem uma nota autorizada daquela cidade, anexe: ela mostra os campos que a prefeitura realmente usa e permite comparar o XML gerado com o verdadeiro.
• O repositório pode estar diferente do Portal. O Portal não exporta mapeamento — alguém pode ter editado lá sem trazer de volta. Confira antes de pedir um diagnóstico.
• "Sem erro" não é "valor certo". Nos testes, dado ausente costuma virar campo vazio em silêncio. Confira os valores, não só a ausência de erro.
• Nunca marque uma cidade como homologada com cenário obrigatório faltando. Homologação incompleta em produção atinge cliente real.

Antes de pedir um modelo novo, tenha em mãos

• A documentação técnica do integrador: WSDL, XSD, manual e exemplos de XML de envio e de resposta.
• As URLs dos webservices — de homologação e de produção.
• Como a prefeitura autentica: certificado A1, usuário e senha, ou token.
• Um contato técnico na prefeitura ou no integrador, para o que a documentação não responder.

Não tem nada disso? Comece por Pesquisar integrador da cidade — é exatamente para isso que ela serve. O que não der para baixar, você envia pela área de anexos do formulário.

Administracao de acessos

Aqui voce decide quem pode usar cada agente. Para liberar alguem, informe o e-mail que a pessoa usa no Elleven.

Quem tem acesso hoje

Ninguem cadastrado ainda.

Versao do agente

Aqui voce confere se o agente esta rodando a versao mais recente e, quando houver novidade, aplica a atualizacao.

Publicacao do dia

Leva para o GitLab o que foi feito hoje (so Models/, docs/, Data/ e tests/): cria a issue com o relatorio por operador, a branch e o MR. Aprovar e fazer o merge e no GitLab. Depois do merge, clique em "Atualizar com a master".

Execução