Juliano Stringari

Boa tarde pessoal, Eu realmente não soube procurar (cegueta) pois estava no site o tempo todo, a informação que eu procurava. Affffffff Desculpem pelo equívoco. Moderador pode fechar (ou até excluir) o tópico.

Bom dia. Blz, eu me baseei em um dos meus post e eu tinha criado em outro lugar. Obrigado pelo ajuste. Uma outra dúvida, onde vocês se informam sobre as alterações de layout dos arquivos XML de envio e retorno do eSocial? Por que no site https://www.gov.br/esocial/pt-br/documentacao-tecnica/ eu não encontrei ou eu não soube "procurar". Pelo que entendi do erro que estamos recebendo, o layout foi alterado e nossa aplicação não está mais preparada para fazer o parse. Só que eu não encontrei o "novo layout" do XML.

Conforme eu comentei no post, o projeto é em Java. Não usamos nada do ACBr.

Boa tarde pessoal, No projeto em que trabalho (desenvolvido em Java) e utilizado pela Epagri de Florianópolis, nos últimos dias estamos enfrentando um problema na resposta do eSocial ao consultar o lote após processado. Estamos recebendo a seguinte mensagem: Mais alguém está recebendo essa mensagem no ambiente de produção do eSocial? Obrigado pela atenção

O que acabou acontecendo, depois de a Betha empurrar pra prefeitura e a prefeitura empurrar pra Betha, é que a prefeitura "desligou" a validação da assinatura para XML de Cancelamento em ambos os ambientes, HOM e PRD. Até quando vai isso? Boa pergunta. Por que fizeram isso? Outra boa pergunta. Moderador, pode fechar o tópico

Bom dia Juliomar, A nossa aplicação é feita em Java e utilizada pela Epagri de Florianópolis Essa aplicação se comunica com vários provedores e a Betha é um deles.

Bom dia pessoal, Há alguns meses, em produção, o provedor Betha, para a cidade de São Miguel do Oeste - SC, está retornando a mensagem: <Codigo>E180</Codigo> <Mensagem>Pedido de Cancelamento não está assinado.</Mensagem> <Correcao>O pedido de cancelamento deve conter assinatura digital</Correcao> Eu já havia aberto um Tópico aqui em 2018 sobre o assunto e resolvi na época, porém, agora voltou a acontecer. O detalhe é que não estamos conseguindo resolver diretamente com a Betha pois eles dizem que é pra ver com a Prefeitura e a Prefeitura pede pra ver com a Betha. Pasmem! Eu não utilizo o componente ACBrNFSe por isso precisaria de uma ajuda em relação à estrutura do XML se teve alteração ou não, se foi o algoritmo de assinatura. Alguém passando pelo mesmo problema e conseguiu resolver? Obrigado pela atenção

Bom dia Moderador. Pode fechar esse tópico. O problema era que estava usando o ambiente de homologação justamente para testes e esse ambiente não estava ok. Apontando para Produção consegui enviar os Eventos. No fim não precisei mexer nada dos Eventos, apenas atualizar versão de 1.2 para 1.3 no cabeçalho do XML e os Schemas.

Sim, e o que eu tenho aqui eu fiz download desse site https://www.gov.br/esocial/pt-br/documentacao-tecnica/ Vou olhar esses que você mandou. Obrigado.

Sim, eu sei que é sobre o TACBreSocial em delphi mas aqui nesse forum é que consigo encontrar ajuda e já fui ajudado várias vezes. E acredito que tem mais pessoas que não usam o TACBreSocial e conseguem auxílio por aqui pois podem ter passado pelo mesmo problema. Se criei "na pasta" errada, em qual eu posso criar essa dúvida?

Olá Juliomar, não uso ACBr. É um sistema para nosso cliente aqui em SC.

Bom dia pessoal, Estou implementando as alterações no nosso sistema, em Java, para contemplar as atualizações pra versão 1.3 do eSocial, porém, não estou encontrando o XSD com o atributo hrsTrab. Ele se encontra na documentação de leiautes que baixei do site mas não está nos arquivos .xsd que baixei do mesmo site. Alguém passou pelo mesmo problema? Obrigado

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?