Juliano Stringari

Bom dia Italo, descobri o problema. Eu estava enviando na URL um arquivo (form-data) na verdade tem que ser como texto (raw). No Postman funcionou e obtive o retorno do webservice. Pode fechar o tópico.

Boa tarde pessoal, estou implementando (no nosso sistema) a comunicação com Canoinhas, agora com IPM padrão Abrasf 2.04, antes era Pública. Estou usando o Postman para fazer os primeiros testes e o retorno é simplesmente: nada A URL utilizada é a https://canoinhas.atende.net/?pg=services&service=WNENotaFiscalEletronicaNfe& confirmada por um Analista (via email) email esse que peguei via site da Prefeitura. Também fiz a validação do XML pelo site https://tributacao.smarapd.com.br/abrasf/loginWeb.jsp?execobj=ABRASFValidaXml e está OK. Se eu "forçar" o envio de login ou senha errado (no POST) o retorno é: <?xml version="1.0" encoding="ISO-8859-1"?> <retorno> <msg>Acesso Negado!</msg> <sis>EST</sis> <code>401</code> </retorno> Alguém passou pelo mesmo problema ou algo parecido? Att.: Juliano

Bom dia pessoal, existe ambiente de teste pra Canoinhas? Se existe eu ainda não encontrei qual é a URL. Att.: Juliano

Olá Geizon, consegui resolver usando outro algoritmo de assinatura de outro projeto. A rotina que já usava para o Sitip não funcionou mais. Não sei lhe dizer exatamente o que era o problema pois não conheço as "nuances" dos algoritmos de assinatura. Moderador, esse tópico pode ser fechado.

Olá Breno, eu faço tudo em java, não uso o Acbr. Desculpe, sempre esqueço de mencionar isso nos posts. Estou usando a mesma classe já utilizada para o Reinf "antigo", ou seja, versão 1.05.01. Não fui eu quem construiu essa classe que faz a assinatura (ela existe há muito tempo) e também não tenho conhecimento para tal. Acredito que quem a construiu "pegou" de algum lugar. Pelo que pesquisei até agora, na net, com esse erro, notei que alguns devs trocaram a forma de assinatura. Encontrei muitos relatos nesse forum https://portalspedbrasil.com.br/forum/assinatura-do-evento-invalida-api-rest/ Obrigado pelo retorno.

Bom dia pessoal, Ao consultar o protocolo de envio do Lote para qualquer evento assíncrono do Reinf, na versão 2.1.2, estou recebendo esse retorno: Estou usando a mesma lógica de assinatura já implementada para os Eventos antigos do reinf, que ainda eram síncronos (e tb para o R2099, o único assíncrono na ocasião). Abaixo o trecho da documentação da versão 1.05.01 Porém da documentação da versão 2.1.2 eu não achei algo semelhante, por isso, estou aplicando a mesma lógica, ou seja, assinando o evento a partir da tag <nome_do_evento> e a tag <Signature> logo abaixo do fechamento da tag <nome_do_evento>. O arquivo XML está sendo validado contra seu respectivo XSD e está correto e o WebService continua devolvendo o erro mencionado acima. Alguém passou por algo semelhante e conseguiu resolver?

Olá, em anexo segue como ficou a versão final do XML de envio. R4010-Envio.xml

Pessoal, descobri o problema. A URL do wsdl estava errada (não tinha atentado para esse detalhe) e o atributo id estava com o "i" minúsculo. Tem que ser "Id" com "i" maiúsculo. Agora enviou e retornou o XML onde menciona que o lote está em processamento. Mesmo assim obrigado pela atenção de todos. Tópico pode ser fechado

Olá Renato, Que componente você fala? Eu trabalho num sistema em Java que já faz envio/recebimento de arquivos XML para eSocial e Reinf. Estou, agora, implementando o envio dos eventos 4000 do Reinf. Postei o arquivo XMl de Envio e o XMl de retorno nesse tópico pra, de repente, alguém ver se já passou por isso com essa mesma estrutura que estou enviando. Se o XML que postei aqui está correto e mesmo assim ele está sendo barrado, só se a forma de envio que estou usando está incorreta. Mas pelo que entendi está sedo enviado e recebido pelo Webservice.

O que estou estranhando é que na tag inicial o xmlns tá vindo com identificação da versão 1.5.1, não deveria vir 2.1.2 ?

Bom dia Alexandre, sim atualizei. Estou acompanhando o tópico que você citou.

Bom dia pessoal, Abaixo segue os arquivos de envio do evento R-4010 e o arquivo de retorno para ambiente de Produção Restrita do Reinf. O Arquivo XML de envio está sendo validado contra o arquivo XSD do Evento correspondente, está certo, mas mesmo assim ainda retorna erro do Reinf Já entramos em contato, via Fale Conosco com a Receita, isso já há 4 dias e sem resposta. Alguém está com esse mesmo retorno mesmo o XML estando com a estrutura correta?

Olá Alexandre, sobre o meu problema eu descobri a causa. Problema de 'BIOS" aqui rsrs. Agora transmitiu o R-4010 porém veio esse retorno: Eu achei um tópico aqui, somente para Administradores, onde é comentado sobre esse retorno e, na ocasião, o post era de 09/05/2023. Observei que a resposta veio identificada com versão v1_05_01, ou seja, a Produção Restrita ainda não está contemplando a última versão?

Obrigado

Olá Alexandre, eu tenho todos os arquivos baixados hoje do site do Sped. Eu mesmo construo os XML e faço o parse com o XSD. Eu desenvolvo para uma empresa em SC que faz uso do eSocial e Reinf, não uso o ACBR. Mas já me ajudaram muito por aqui.

Boa tarde pessoal. Vocês conseguem postar aqui um XML de exemplo do Evento R-4010? Mesmo eu montando o arquivo seguindo o XSD ele não é validado. Segue XML que gerei: O erro de parse do XML é: O arquivo .XSD utilizado está em anexo. Obrigado pela atenção. evtRetPFReinf.xsd

Olá Italo, abrimos tickets diretamente no Fórum Oficial da Prefeitura e já resolveram algumas questões. Essa ainda não mas já finalizei o desenvolvimento do que precisávamos e testei diretamente em produção pois o cliente já estava sem emitir nota há dias. Obrigado pela ajuda e pode encerrar o tópico.

Boa tarde, Conforme trecho do XSD versão 2.04 da Abrasf, abaixo: <xsd:element name="CancelarNfseResposta"> <xsd:complexType> <xsd:choice> <xsd:element name="RetCancelamento" type="tcRetCancelamento" minOccurs="1" maxOccurs="1" /> <xsd:element ref="ListaMensagemRetorno" minOccurs="1" maxOccurs="1" /> </xsd:choice> </xsd:complexType> </xsd:element> a resposta do enviar um XML de Cancelamento é um Choice, ou seja, ou retorna um elemento ou outro elemento, dentro do elemento "pai"; Porém, no ambiente de testes está retornando um elemento dentro do outro, abaixo: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:CancelarNfseResponse xmlns:ns1="https://testechapecoabrasf.meumunicipio.online/ws"> <CancelarNfseResult><?xml version="1.0" encoding="UTF-8"?> <CancelarNfseResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <RetCancelamento> <ListaMensagemRetorno> <MensagemRetorno> <Codigo>E78</Codigo> <Mensagem>Número da NFS-e inexistente na base de dados para o prestador do serviço pesquisado. - CODE: 1</Mensagem> <Correcao>Informe corretamente o número da NFS-e.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </RetCancelamento> </CancelarNfseResposta> </CancelarNfseResult> </ns1:CancelarNfseResponse> </soapenv:Body> </soapenv:Envelope> Alguém passou por isso? Ainda não pude executar um cancelamento no ambiente de produção, mas quem já cancelou nesse ambiente, tem um exemplo de retorno de XML para cancelamento? Obrigado pela atenção Juliano

Pessoal, estou tentando enviar o XML de Recepção de Lote para Abrasf pelo SOAPUI e está retornando a seguinte mensagem: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Call to a member function release() on null</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Abaixo segue o XML que estou enviando <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="https://testechapecoabrasf.meumunicipio.online/ws"> <soapenv:Header/> <soapenv:Body> <ws:RecepcionarLoteRps> <xml> <![CDATA[<?xml version="1.0" encoding="UTF-8"?> <ns2:EnviarLoteRpsEnvio xmlns:ns2="http://www.abrasf.org.br/nfse.xsd" xmlns="http://www.w3.org/2000/09/xmldsig#"> <ns2:LoteRps versao="2.04"> <ns2:NumeroLote>655028</ns2:NumeroLote> <ns2:Prestador> <ns2:CpfCnpj> <ns2:Cnpj>83052191000405</ns2:Cnpj> </ns2:CpfCnpj> <ns2:InscricaoMunicipal>6342</ns2:InscricaoMunicipal> </ns2:Prestador> <ns2:QuantidadeRps>1</ns2:QuantidadeRps> <ns2:ListaRps> <ns2:Rps> <ns2:InfDeclaracaoPrestacaoServico Id="Rps42042020000000000417738305219100040508022023"> <ns2:Rps> <ns2:IdentificacaoRps> <ns2:Numero>41773</ns2:Numero> <ns2:Serie>1</ns2:Serie> <ns2:Tipo>1</ns2:Tipo> </ns2:IdentificacaoRps> <ns2:DataEmissao>2023-02-08</ns2:DataEmissao> <ns2:Status>1</ns2:Status> </ns2:Rps> <ns2:Competencia>2023-02-08</ns2:Competencia> <ns2:Servico> <ns2:Valores> <ns2:ValorServicos>555.00</ns2:ValorServicos> <ns2:ValorPis>0.00</ns2:ValorPis> <ns2:ValorCofins>0.00</ns2:ValorCofins> <ns2:ValorInss>0.00</ns2:ValorInss> <ns2:ValorIr>0.00</ns2:ValorIr> <ns2:ValorCsll>0.00</ns2:ValorCsll> <ns2:ValorIss>22.20</ns2:ValorIss> <ns2:Aliquota>4.00</ns2:Aliquota> <ns2:DescontoIncondicionado>0</ns2:DescontoIncondicionado> </ns2:Valores> <ns2:IssRetido>2</ns2:IssRetido> <ns2:ItemListaServico>1705</ns2:ItemListaServico> <ns2:Discriminacao>ASSISTENCIA TECNICA E EXTENSAO RURAL AO MUNICIPIO</ns2:Discriminacao> <ns2:CodigoMunicipio>4204202</ns2:CodigoMunicipio> <ns2:ExigibilidadeISS>1</ns2:ExigibilidadeISS> <ns2:MunicipioIncidencia>4204202</ns2:MunicipioIncidencia> </ns2:Servico> <ns2:Prestador> <ns2:CpfCnpj> <ns2:Cnpj>83052191000405</ns2:Cnpj> </ns2:CpfCnpj> <ns2:InscricaoMunicipal>6342</ns2:InscricaoMunicipal> </ns2:Prestador> <ns2:TomadorServico> <ns2:IdentificacaoTomador> <ns2:CpfCnpj> <ns2:Cpf>03295413908</ns2:Cpf> </ns2:CpfCnpj> </ns2:IdentificacaoTomador> <ns2:RazaoSocial>GILCIMAR BORGERT</ns2:RazaoSocial> <ns2:Endereco> <ns2:Endereco>RUA LAURO LINHARES</ns2:Endereco> <ns2:Numero>689</ns2:Numero> <ns2:Complemento>AP 306 BL B3</ns2:Complemento> <ns2:Bairro>TRINDADE</ns2:Bairro> <ns2:CodigoMunicipio>4205407</ns2:CodigoMunicipio> <ns2:Uf>SC</ns2:Uf> <ns2:Cep>88036001</ns2:Cep> </ns2:Endereco> <ns2:Contato> <Telefone xmlns="" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#">48984072511</Telefone> <Email xmlns="" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#">[email protected]</Email> </ns2:Contato> </ns2:TomadorServico> <ns2:OptanteSimplesNacional>2</ns2:OptanteSimplesNacional> <ns2:IncentivoFiscal>2</ns2:IncentivoFiscal> </ns2:InfDeclaracaoPrestacaoServico> </ns2:Rps> </ns2:ListaRps> </ns2:LoteRps> </ns2:EnviarLoteRpsEnvio>]]> </xml> </ws:RecepcionarLoteRps> </soapenv:Body> </soapenv:Envelope> Segui a mesma lógica de envio para o serviço de Consultar Lote e para esse, em questão, funcionou. Não estou encontrando a causa do problema. Pelo menos não com essa mensagem de retorno. Att.: Juliano

Bom dia Italo, com suas dicas agora veio uma resposta do WS Obrigado pelo apoio.

Tentei isso também mas retorna outra mensagem de erro. O que não estou entendendo é que na URL do wsdl o serviço tem o nome de ConsultarNfsePorRps e no arquivo XSD está assim <!-- Consulta de NFS-e por RPS - ConsultarNfsePorRps --> <xsd:element name="ConsultarNfseRpsEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="IdentificacaoRps" type="tcIdentificacaoRps" minOccurs="1" maxOccurs="1" /> <xsd:element name="Prestador" type="tcIdentificacaoPessoaEmpresa" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> No SoapUI o xml "default" é <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="https://testechapecoabrasf.meumunicipio.online/ws"> <soapenv:Header/> <soapenv:Body> <ws:ConsultarNfsePorRps> <xml>?</xml> </ws:ConsultarNfsePorRps> </soapenv:Body> </soapenv:Envelope> Então na tag <xml> eu coloquei o XML completo que coloquei no post inicial, porém o erro retornado é: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Too few arguments to function App\Abrasf\AbrasfService::ConsultarNfsePorRps(), 0 passed in /var/www/sites/apis/abrasf/vendor/laminas/laminas-soap/src/Server/DocumentLiteralWrapper.php on line 108 and exactly 1 expected</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Olá Italo, com java. Já implementei o Pública baseado no Betha mas esse agora tá complicado.

Olá, me desculpem estar criando esse tópico aqui mas li vários outros tópicos sobre essa mudança e não achei um cenário igual ao que estou enfrentando atualmente. Estou usando o SoapUI para simular o envio de XML para a URL da Abrasf no ambiente de teste. Baixei os arquivos XSD (para montar o XML do serviço ConsultarNfseRpsEnvio) a partir de um link compartilhado aqui em um dos fóruns pois não encontrei no site da Prefeitura de Chapecó. Informei o XML que está na imagem e ao enviar retornou a msg de versão errada. Alguém passou pelo mesmo problema? Os arquivos XMLs disponibilizados no site da Prefeitura de Chapecó também não funcionam. Não estou sabendo como "criar" os XMLs para envio. Att.: Juliano

Boa tarde pessoal. Estou enfrentando um problema ao enviar XML para a Publica de Chapecó - SC com mais de um serviço. O WS está retornando o erro: Falha: no lote 576002 Código->E000 Descrição->Problemas ao processar arquivo. Correção->Entre em contato com suporte ao sistema. Quando envio um XML com apenas um serviço o retorno é de sucesso. O nosso sistema é em Java e as classes são criadas a partir dos XSDs (para criar o XML de envio) e do WSDL para comunicação com o WS. Li em posts anteriores que tem gente que está criando uma NF para cada serviço. Será que terei que fazer o mesmo? Obrigado pela ajuda