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

Tópicos deste artigo

• Manual do web service
• Portais disponíveis
• Métodos disponíveis
• Tipo de impressão
• Observações gerais
• Observações específicas por cidade
• Emissão pelo ManagerEDoc/ManagerSaas
• Emissão pelo Componente NFSe
• Observações sobre a geração do XML
• Erros comuns
• Campos customizados para a impressão do RPS
• Campos customizados para a impressão da NFSe
   

Manual de integração com o webservice

Download do manual

Portais Disponíveis

• Produção
• Homologação

Métodos disponíveis

• Envio.
  • Assíncrono
  • Não necessita envio sequencial¹
  • Aceita envio de lote de RPS
• Consulta de Lote
• Consulta de NFSe por RPS
• Cancelamento de NFSe

¹Não necessita que as notas sejam enviadas de forma sequencial

Tipo de impressão

• A impressão é feita via link da prefeitura¹

¹ Nossos produtos realizam o download do PDF da NFSe que foi gerado pela própria prefeitura.

Observações gerais

• Por padrão, o acesso aos webservices de Produção é bloqueado para todos os CNPJs.
•  Para realizar as emissões em produção dos municípios deste padrão, é necessário seguir os passos abaixo:
  •   - Realizar o envio de um RPS em ambiente de homologação.
  •   - Enviar um e-mail para o responsável pelo padrão da prefeitura ( contato@tinus.com.br
     ou integracaonfse@tinus.com.br), informando o CNPJ do prestador, o numero do lote utilizado e os XMLs de comunicação para processar em homologação.
  •   - Aguardar resposta do responsável sobre a liberação do WebService em modo de produção.
  •   - Quando é liberado o ambiente de Produção não é mais possível emitir em homologação.
• A inscrição municipal não deve conter máscara.
• Acentuações, caracteres especiais e erros de schema XML causam erro de comunicação com o Webservice (que por sua vez são lançados pelo componente como exceções). Note que o e-comercial (&) não causa esse tipo de problema.
• O processamento das notas para esse padrão ocorre a cada meia hora do relógio, por exemplo, às 12:00, 12:30, 13:00, e assim em diante.
• A comunicação de Consulta Notas Tomadas não está mais disponível para o padrão Tinus desde o dia 18/06/2021
• O cancelamento de NFSe ainda não está disponível; no entanto, encontra-se em fase de implantação, com previsão de conclusão até 30/04/2026.

Observações específicas por cidade

Emissão pelo ManagerEdoc/ManagerSaaS

• Para evitar duplicações e o descarte de notas que já foram AUTORIZADAS será possível sincronizar as notas que retornarem o erro de duplicidade no fluxo de ENVIO. As notas ficarão com a situação ENVIADA, necessitando de um tratamento especial para chegarem a situação final (AUTORIZADA, REJEITADA OU CANCELADA). 
• Caso exista divergências entre a situação da nota na prefeitura (AUTORIZADA) e em nosso produto (ENVIADA) e a mensagem do retorno tenha sido: "Recibo de Prestação de Serviços Já convertido", ou retorne as seguintes mensagens ao tentar resolver ou descartar uma nota:
  • "EXCEPTION,EspdNFSeOperacaoIndisponivelException"
    Não é possível realizar o RESOLVE desta nota pois o RPS informado já foi convertido em uma NFSe. Caso deseje realizar uma tentativa de sincronização, informe o número da nfse através do parâmetro "NumNFSeConsulta", por exemplo: NumNFSeConsulta=1234".
  • "EXCEPTION,EspdManNFSeCheckParamsException"
    Por questão de segurança, não é possível realizar o DESCARTE desta nota pois o RPS informado já foi convertido em uma NFSe. Caso a nota não tenha sido emitida, deve-se informar o parâmetro "forcar=true""

• Siga algum dos passos à seguir:
  • Dados Iguais: Se os dados da nota enviada forem os mesmos da nota que está AUTORIZADA no portal da prefeitura, e deseje sincroniza-la, deve ser utilizado o parâmetro "NumNFSeConsulta" na rota de RESOLVE, como no exemplo abaixo:                  
                                                                                                                                               
     
  • ATENÇÃO: a sincronização será realizada independente de que as informações contidas na nota emitida sejam diferentes da NFSe do portal da prefeitura. Portanto é necessário se certificar que as notas sejam exatamente as mesmas.                                                                                                                                          
  • Dados Diferentes: caso os dados da nota enviada e da AUTORIZADA no portal da prefeitura sejam divergentes e deseje descartar essa nota, deverá utilizar o parâmetro "forcar=true" na rota de DESCARTA, conforme o exemplo abaixo:  
                                                                                                                       
  • ATENÇÃO: Isso fará com que a nota seja descartada.            

• Os demais parâmetros do método RESOLVE, continuam sendo os mesmos já aceitos (handle; numNFSe; e numRPS, serieRPS e tipoRPS ), conforme a documentação.

Emissão pelo Componente NFSe

• Impressão de notas Canceladas: para imprimir a nota com a tarja de cancelamento é necessário utilizar o XML de envio da nota , o XML de retorno da consulta de NFSe por RPS e o Tx2 com o campo customizado DataHoraCancelamento preenchido.

• A Consulta de NFSe ou RPS não retorna nota com status cancelada. 

Observações sobre a geração do XML

• O Código do serviço segue o que está descrito na LC-116.
• O campo código CNAE segue o que foi definido na tabela nacional, entretanto não é um campo obrigatório.
• Caso o campo CodigoCnae for preenchido, o campo CodigoTributacaoMunicipio deve receber o mesmo valor para que a nota seja autorizada

Erros comuns

• "SInvalid Content Type" ou ainda "SInvalidContentType" 
  Esse erro ocorre devido a ausência de liberação do CNPJ do prestador para emissão de RPS no Web service do município em questão.

• "Ocorreu um erro durante a comunicação com o servidor: Não foi possível carregar o XML"
  A possível causa é devido a ausência de assinatura no XML de envio.

  
   

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 empresas optantes do Simples Nacional, o preenchimento do campo RegimeApuracaoTributaria (regApTribSN) é obrigatório:

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

Exemplos de TX2 e XML:

• XML Envio
• XML Retorno
• TX2

Campos Customizados para a impressão do RPS

• NomeFantasiaPrestador=String[80]
• RazaoSocialPrestador=String[80]
• EnderecoPrestador=String[80]
• CodigoMunicipioPrestador=String[10]
• UfPrestador=String[2]
• NumeroEnderecoPrestador=String[7]
• ComplementoEnderecoPrestador=String[20]
• BairroPrestador=String[40]
• CepPrestador=String[8]
• TelefonePrestador=String[20]
• EmailPrestador=String[80]
• OutroDoc=String[40]

Campos Customizados para a impressão da NFSe

• OutroDoc=String[40]
• DataConversaoNFSe=String[40]
• DataHoraCancelamento=String[40]

Soluções Tecnospeed

• Componente NFSe:    Release 8.7.48.X.
• Manager eDoc:    Release 3.0.83.X.