Ir para conteúdo
  • Cadastre-se

Juliano Stringari

Membros
  • Total de ítens

    38
  • Registro em

  • Última visita

Tudo que Juliano Stringari postou

  1. 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.
  2. 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.
  3. 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?
  4. Olá Juliomar, não uso ACBr. É um sistema para nosso cliente aqui em SC.
  5. 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
  6. 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.
  7. 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
  8. Bom dia pessoal, existe ambiente de teste pra Canoinhas? Se existe eu ainda não encontrei qual é a URL. Att.: Juliano
  9. 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.
  10. 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.
  11. 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?
  12. Olá, em anexo segue como ficou a versão final do XML de envio. R4010-Envio.xml
  13. 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
  14. 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.
  15. 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 ?
  16. Bom dia Alexandre, sim atualizei. Estou acompanhando o tópico que você citou.
  17. 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?
  18. 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?
  19. 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.
  20. 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
  21. 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.
  22. 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
  23. 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
  24. Bom dia Italo, com suas dicas agora veio uma resposta do WS Obrigado pelo apoio.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.