Olá
Estamos com a rejeição “E172 - Arquivo enviado com erro na assinatura.” desde o dia 21/11
Na prefeitura de São José do Rio Preto/SP.
Certificado A1 está OK, na validade
Chave da NFS-e: NFS_3A1684FFDD844E1B9B2ACE7493C7C9C3
Podem verificar por favor se há algo na API
obrigado
Estou com o mesmo problema para São José do Rio Preto.
Certificado A1 Válido porém recebemos o mesmo erro.
ID NFs em Produção: nfs_3a168f55dea44f03acfdb5ec26fdbe7d
Boa tarde, @evandro e @brunobric1.
Verificamos que o município de São José do Rio Preto (SP) migrou recentemente para uma nova versão da GissOnline. Vale ressaltar que outros municípios que adotaram essa mesma versão continuam operando normalmente em nossa API, o que indica que o problema pode ser algo isolado a esse município em específico.
Recomendamos que entre em contato com o suporte da prefeitura para verificar se há alguma inconsistência ou problema relacionado a essa mudança.
Segue o comunicado da prefeitura:
Fonte: https://sjrp.ginfes.com.br/
Submetemos o arquivo XML no site de validação do ITI (https://validar.iti.gov.br/), gerando algumas inconsistências no resultado. O relatório de validação retornou o seguinte:
Conforme imagem em anexo!
Obrigado!
Verifique a assinatura no site de validação da Receita Federal também e nos informe o resultado:
https://servicos.receita.fazenda.gov.br/servicos/assinadoc/ValidadorAssinaturas.app/valida.aspx
No site informado retorna:
A assinatura digital do documento fornecido é válida.
O site de validação do ITI está apresentando resultados incorretos, indicando falsos negativos. Realizamos testes com diversos XMLs autorizados, incluindo outros documentos fiscais como NF-e e NFC-e, e todos foram classificados como inválidos pelo sistema.
Recebemos uma informação extraoficial indicando que a Prefeitura de São José do Rio Preto (SP) pode ter prorrogado a migração para a nova versão do GissOnline devido a diversos relatos de problemas e instabilidades. Há a possibilidade de que o município ainda esteja aceitando emissões pela versão anterior do sistema.
Poderiam entrar em contato diretamente com o suporte da prefeitura e confirmar se essa informação procede?
Vou entrar em contato e retorno aqui assim que me responderem.
Obrigado por enquanto.
Bom dia, @arimateia,
Estive em contato hoje por telefone com a Giss (11 2175-1145). A princípio, eles informaram que não têm conhecimento de nenhum problema relacionado ao município(São José do Rio Preto - SP). No entanto, solicitaram que, para análise, enviemos o XML de envio completo e o XML de retorno com o erro.
Poderia me orientar sobre como obter essas informações para que eu possa encaminhá-las para análise?
Ok, estou enviando para suporte assim que retornar mantenho vocês informados aqui.
Olá @arimateia segue retorno do pessoal da Giss sobre o caso:
Informamos que a Gissonline a partir de 01/11/2024 irá aceitar a assinatura digital nos arquivos XML seguindo as seguintes regras de acordo com cada método disponibilizado para uso no WSDL Assim como estabelecido no modelo ABRASF o algoritmo de assinatura a ser utilizado deve ser o rsa-sha1.
· RecepcionarLoteRps
Para este arquivo, é requisitado no mínimo duas assinaturas digitais (este valor e variavel de acordo com a quantidade de RPS dentro do lote) sendo:
Assinatura do RPS que deve estar presente no elemento DeclaracaoPrestacaoServico
Assinatura do LOTE que deve estar presente no elemento EnviarLoteRpsEnvio
OBS: Vale ressaltar que os id’s de referencia (Reference URI) devem ser indicados nos arquivos conforme padrões estabelecidos no XSD xmldsig. OBS: A informação de que deve haver no mínimo duas assinaturas digitais, se deve ao fato de aceitarmos de 1 a 50 recibos provisórios num mesmo arquivo, logo em um arquivo contendo um lote de 50 RPS, este lote deve conter 50 assinaturas (uma em cada RPS) + 1 assinatura (Assinatura do lote como um todo), lembrando que o Lote deve ser assinado por ultimo para evitar problemas de quebra de assinatura digital. Os métodos CancelarNfse, ConsultarLoteRps, ConsultarNfsePorRps e ConsultarNfsePorFaixa, possuem uma única assinatura, e assim como o método RecepcionarLoteRps, esta assinatura deve seguir as regras descritas no schema XSD, assim como os id’s de referencia (Reference URI) devem ser indicados
Olá @arimateia conseguiu verificar sobre a assinatura geral no lote? Pretendemos migrar nossos clientes para iniciar o ano de 2025 já na NuvemFiscal, fico no aguardo!
Bom dia, @brunobric1.
Essa mensagem retornada pelo suporte da Giss não parece ter relação alguma com o arquivo XML enviado, pois o mesmo contém as duas assinaturas (RPS e lote) com seus devidos id’s de referência.
Enviei para você agora (via mensagem privada) o XML do elemento EnviarLoteRpsEnvio que foi enviado dentro do envelope SOAP. A existência e validade das duas assinaturas pode ser verificada através do Validador da Receita Federal.
Favor questionar novamente o suporte da prefeitura.
Combinado, vou entrar em contato novamente enviado o XML com as duas assinaturas.
Entrei em contato novamente hoje e depois de uma hora de ligação entre espera e atendimento por fim, abriram um chamado 508047 assim que retornarem eu informo por aqui! Obrigado por enquanto.
Pessoal,
Recebi o retorno sobre o caso: embora a Prefeitura de São José do Rio Preto tenha migrado o painel do usuário final para a nova versão, a emissão via Webservice continua no modelo antigo, sem previsão para migração para a nova versão.
@arimateia , pode verificar, por favor, e ajustar o processamento da NuvemFiscal para a versão anterior?
A única observação foi uma mudança no cancelamento. Vou anexar os arquivos fornecidos pela EICON para análise.
Cancelamento via WebService - Diferenças Ginfes e GissOnline V2 8.pdf
Exemplo_Cancelamento_WS 13.xml
cancelamento.zip (360,5,KB)
