Documentação Técnica - Padrão BETHA

Esta documentação reúne as regras e os recursos do padrão BETHA utilizados na emissão integrada de NFS-e, com foco em ambientes, autenticação por certificado digital, métodos disponíveis, particularidades municipais, uso no PlugNotas e no Componente, além de orientações sobre XML/RPS/TX2, erros comuns, campos customizados de impressão e pontos que ainda dependem de validação interna. Consulte este manual principalmente se você é:

• Cliente/integrador (dev/tech lead): para entender ambientes, autenticação por certificado, fluxo (DPS → NFS-e), métodos e pontos de atenção.

Tópicos deste artigo

• Manual do web service

• Portais disponíveis

• Métodos disponíveis

• Tipo de impressão

• Observações gerais do padrão

• Autenticação

• Observações específicas por município

• Observações sobre a geração do XML/RPS/TX2

• Erros comuns

• Campos customizados para impressão

• Exemplos de arquivos de integração

Manual do web service

• Manual de integração com o Web Service da BETHA: apresenta o modelo conceitual do padrão, arquitetura de comunicação, uso de certificados digitais, estrutura das mensagens XML e os serviços disponíveis para recepção de lote, consultas e cancelamento.

• Download do manual

Portais disponíveis

• Produção
• Homologação

Métodos disponíveis

Emissão

• Envio sequencial: ( ) Necessita (X) Não necessita 

• Modo: ( ) Síncrono (X) Assíncrono ( ) Ambos ( ) Não informado

• Lote: (X) Aceita lote ( ) Não aceita lote ( ) Não informado

  Observação: No método de "ConsultaLote" utilizado para consulta de protocolo, para a consulta de protocolo de cancelamento, deve ser informado como parâmetro extra do método o valor "ParametrosExtras=TipoConsulta=Cancelamento".

O padrão BETHA trabalha com recepção e processamento de lote de RPS, com retorno de protocolo e processamento posterior. A documentação também informa que o padrão não necessita envio sequencial e aceita lote de RPS.

Consulta

• (X) Consulta de lote

• (X) Consulta por RPS

• (X) Consulta por NFS-e

• (X) Consulta por protocolo

• (X) Consulta por protocolo de cancelamento 

• (X) Consulta notas tomadas

• ( ) Consulta por período

• (X) Consulta de situação de lote

• ( ) Não informado

O manual e o artigo do padrão confirmam consulta de situação de lote, consulta de lote, consulta de NFS-e por RPS, consulta de NFS-e e consulta de notas tomadas. Não há confirmação explícita, no material analisado, de um método destacado separadamente como “consulta por período”.

Cancelamento / Eventos

• (X) Cancelamento via webservices

• (X) Cancelamento administrativo

Tipo de impressão

• (X) Impressão via link da prefeitura
  Os produtos fazem download do PDF gerado pela prefeitura.

• ( ) Impressão via layout Tecnospeed Os produtos geram o PDF, aproximando ao máximo o layout da prefeitura.

Importante: o tipo de impressão depende do que o padrão permite. Não é possível editar livremente o layout além das opções suportadas pelo produto/padrão.

Observações gerais do padrão

• Antes de realizar emissões, é necessário verificar o cadastro do contribuinte no portal da prefeitura, principalmente o preenchimento da Inscrição Municipal. A ausência desses dados pode causar falhas na execução dos métodos disponíveis.

• Os campos ValorDeducoesServico, DescontoCondicionadoServico e DescontoIncondicionadoServico são utilizados apenas no envio e não são usados pelo layout de impressão do padrão.

• O WebService de BETHA não permite o reenvio de RPS rejeitados.

• A função de cancelamento atualmente está disponível e utiliza do fluxo "Assíncrono". 
  Deve ser enviado o cancelamento e consultado seu protocolo para obter o retorno. 
  Para Manager SaaS e PlugNotas, após enviar o cancelamento, deve ser acionado o fluxo de "Resolve" para obter o retorno da consulta de protocolo de cancelamento. 
  ATENÇÃO: O WebService de algumas cidades BETHA ainda está com retorno de cancelamento instável. Elas aceitam o cancelamento pelo webservice normalmente, o cancelamento é efetivado no portal da prefeitura, porém ao consultar o protocolo de cancelamento via webservices, só retorna "Não Processado", nesses casos importante conferir no portal da prefeitura.

Autenticação

O padrão BETHA exige autenticação por certificado digital no web service. 

Componente NFS-e : Configurando a Autenticação pelo Certificado Digital

PlugNotas: Cadastrando Certificados via API e Cadastrando Certificado pela interface

Manager Saas: Como cadastrar, consultar e deletar certificados digitais

Observações específicas por município

As regras acima constam como particularidades municipais do padrão BETHA e devem ser consideradas antes da homologação e da entrada em produção. 

Observações sobre a geração do XML/RPS/TX2

• O código do serviço segue o que está descrito na LC-116.

• O código CNAE não é obrigatório, mas, se informado, será gerado no XML.

• O CNAE segue a tabela nacional com 7 dígitos.

• O Código de Tributação do Município não é utilizado pelo portal nem pelo web service; ainda assim, se informado, será gerado no XML.

• Como o Código de Tributação do Município é proprietário de cada prefeitura, é necessário validar com o município qual codificação deve ser usada.

• Acentuação pode causar rejeição no servidor; por isso, os produtos removem os acentos do RPS.

• Para adicionar o CNAE na impressão da NFS-e, utilizar o campo customizado CodigoCnaes, inclusive em cenários com múltiplos serviços.

• Exemplo: CodigoCnaes=911325,823912 

Novos campos disponibilizados para adequação da Reforma Tributária

Observação: Campos obrigatórios conforme o arquivo de esquema do Padrão estão destacados em negrito.

Ressaltamos que, para manter a funcionalidade em ambos os ambientes de emissão (produção e homologação), essas regras de validação ainda não foram aplicadas em nossas aplicações.

Para maiores informações sobre a forma de preenchimento destes campos novos, acesse nossa documentação do Padrão Unificado de TX2.

Erros comuns

• Lista completa de rejeições: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/6329082658071-Lista-de-Rejei%C3%A7%C3%B5es-do-Padr%C3%A3o-BETHA

Campos customizados para impressão do RPS

• NomeFantasiaPrestador=String[80]

• RazaoSocialPrestador=String[80]

• InscricaoEstadualPrestador=String[40]

• EnderecoPrestador=String[80]

• CodigoMunicipioPrestador=String[10]

• NumeroEnderecoPrestador=String[7]

• ComplementoEnderecoPrestador=String[80]

• BairroPrestador=String[40]

• CepPrestador=String[8]

• UfPrestador=String[2]

• TelefonePrestador=String[20]

• EmailPrestador=String[80]

• CelularPrestador=String[20]

• NomeFantasiaTomador=String[80]

• InscricaoEstadualTomador=String[40]

• CelularTomador=String[20]

• SitePrestador=String[80]

• ValorTributoFederal=string[20]

• ValorTributoEstadual=string[20]

• ValorTributoMunicipal=string[20]

• PorcentagemTributoFederal=string[20]

• PorcentagemTributoEstadual=string[20]

• PorcentagemTributoMunicipal=string[20]

• Pagamento=string[80]

• ValorTTS=string[20]

• ValorTotal=string[20]

Observação: o campo ValorTotal aparecerá na impressão apenas se ValorTTS também estiver preenchido.

Campos customizados para impressão da NFS-e

• InscricaoEstadualPrestador=String[40]

• InscricaoEstadualTomador=String[40]

• CelularPrestador=String[20]

• SitePrestador=String[80]

• NomeFantasiaTomador=String[80]

• CelularTomador=String[20]

• ValorTributoFederal=string[20]

• ValorTributoEstadual=string[20]

• ValorTributoMunicipal=string[20]

• PorcentagemTributoFederal=string[20]

• PorcentagemTributoEstadual=string[20]

• PorcentagemTributoMunicipal=string[20]

• Pagamento=string[80]

• ValorTTS=string[20]

• ValorTotal=string[20]

• CodigoCnaes=string[200]

Observação: o campo ValorTotal aparecerá na impressão apenas se ValorTTS também estiver preenchido.

Impressão da NFS-e – DataSet Parcelas

• Parcela=String[255]

• Vencimento=String[255]

• Valor=String[255]

Exemplos de arquivos de integração