Product_title
Title Particularidades Image https://jiratdncdncontent.blob.core.windows.net/tdn/icons/documento.png

• 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.