Particularidades

• Testado no ambiente de homologação.
• Não possui consulta de nfse.
• Método de envio e cancelamento síncrono.
• Por não ter método de consulta, o protocolo de envio é obtido apenas na primeira vez do envio. Caso aja queda de energia, ou o appserver TSS seja interrompido durante a ação de envio nfse, o provedor/município não disponibiliza nenhum método de consulta para que o TSS possa obter novamente o número de protocolo.
• O Provedor/município não trabalha com o conceito de RPS amarrado a número da nota, ou seja, a numeração enviada ao provedor/município  é considerada pelo provedor/município a mesma da nota fiscal. Devido a isso é necessário realizar a manutenção da numeração do RPS no ERP para acompanhar a mesma numeração de nota fiscal disponibilizada no portal da prefeitura.

• O provedor/município não retorna descrição de erro em caso de falha no envio do rps ao WebService. é retornado apenas o código de erro. Como as descrições dos códigos de erro são de responsabilidade do provedor/município, é disponibilizado documentação com as descrições no portal da prefeitura.

• Para que aja comunicação entre TSS e  Web Service provedor/município, é necessário configurar os parâmetros MV_NFSUSER ( usuário do portal da prefeitura )  e MV_NFSPASS ( senha do portal da prefeitura ).
• Provedor/município não disponibiliza arquivo de SCHEMA, ou seja, não há nenhum arquivo .xsd que precise ser copiado para a pasta schema do TSS.
• OBSERVAÇÃO: O ambiente de homologação da prefeitura não aceita as tags <rps_num> e <rps_serie> no xml de envio do método GerarNota. Para o ambiente de produção da prefeitura as tags <rps_num> e <rps_serie> são enviadas normalmente.

• 15/04/2025 
• Na utilização do metodo GetToken  é obrigatorio enviar a inscrição municipal com 9 caracteres, caso contrario não é gerada a autorização.
  •  
  • 
• Devido a RM trabalhar com o xml convertido, neste caso um arquivo json, não existe uma numeração de RPS. Logo o campo SPED051→RPS não é gravado. Para o Protheus o sistema segue o processo normalmente.
  • Primeiro item referente ao RM e o segundo referente ao Protheus
  • 
• O Provedor não trata RPS.
• Foi realizado o ajuste no cancelamento, antes o sitema estava preparado para utilizar o campo SPED051→RPS, porém para o RM não seria possivel o cancelamento (Campo em branco), para o Protheus como a RPS necessariamente tem que ser o mesmo numero da nota, pois o provedor não utilizar RPS não acarretará problemas e caso por algum motivos o numero do RPS utilizado fosse diferente do numero da nota não correriamos o risco de cancelar uma nota existente do cliente.
• Utilizando mais de um item ocorria error.log para a gerançao do valor total da nota, juntamente com a correção do valor do serviço e base de calculo. Todos corrigidos.
• Nos testes realizados nessa issue não tinha ambiente de homologação, as URL produção e homologação eram a mesma.