nickolasdeluca

Olá novamente, Favor desconsiderar esse tópico, descobri quem fez o problema. Se os mods puderem fechar o tópico, eu agradeço.

Boa tarde, Estamos tentando enviar um CTe, tanto em homologação quanto em produção, no estado de RO e estamos recebendo o seguinte retorno: Element '{http://www.portalfiscal.inf.br/cte}infCTeSupl' is unexpected according to content model of parent element '{http://www.portalfiscal.inf.br/cte}CTe'. Expecting: {http://www.w3.org/2000/09/xmldsig#}Signature. Esse retorno ocorre APENAS ao enviar um CTE para a SEFAZ deste estado específico, em todos os outros autoriza normal. Verifiquei que essa é a tag do qrCode e que faz um tempinho já que foi removida a possibilidade do envio dela ser opcional. Alguém mais tendo esse problema? Anexei o XML do CTE de testes que estamos tentando enviar. 11230946542418000121570000000000011001528128-cte.xml

Servidor do RS aceitando apenas sem hífen. Que piada!

Cara, como você fez para trocar para essa forma SVC-SP? Alterando a UF do webservice para SP? Pergunto isso por que tentei fazer dessa forma e continuo recebendo o retorno em branco.

Tentei enviar pelo estado de MG e de SC hoje, ambos retornando resposta em branco. Alguém conseguindo enviar em algum estado?

Por acaso temos acesso a essa lista para acompanhamento?

Bom dia, alguma novidade sobre isso? Toda vez que atualizamos o nosso repositório interno somos obrigados a aplicar essa correção em cima dos fontes do ACBr. Seria bem interessante se essa solução fosse incorporada ao repositório oficial.

Juliomar, consegue me dar mais detalhes de como fazer essa instalação correta do driver do leitor? No meu caso, estas são as configurações que fiz durante a instalação: E quando tu fala que da pra salvar a senha no componente, podes me dizer qual a propriedade para informar o PIN do token A3? Leandro, infelizmente o cliente é mais teimoso que uma mula...

Infelizmente não, o cliente precisava do certificado então tivemos que devolver, não tenho mais como testar com o certificado... Existe alguma possibilidade de abrirmos a tela do PIN manualmente? no caso, forçar utilizar o PIN antes de iniciar qualquer ação, por exemplo, ao carregar o certificado no componente antes de realizar algum evento?

Boa tarde, alguém com problemas para enviar eventos da NFe através do componente ACBrNFE utilizando certificado A3? estamos enfrentando um caso bizarro aqui onde se não ativar o TimeOutPorThread do ACBrDFeSSL o componente fica travado por horas esperando uma resposta. O erro ocorre na unit ACBrDFeSSL no trecho de código a partir da linha 1405: if TimeOutPorThread then begin EndTime := IncSecond(now,TruncFix(TimeOut/1000)); SendThread := TDFeSendThread.Create( Self, TDFeSSLHttpClassOf(FSSLHttpClass.ClassType), ConteudoXML, AURL, ASoapAction, AMimeType); try while (not SendThread.Done) and (Now <= EndTime) do Sleep(50); finally Result := SendThread.Response; ErrorMsg := SendThread.ExceptMessage; if not SendThread.Done then SendThread.Abort // Isso forçará a Thread terminar, e morrer por si... else SendThread.Free; end; if not EstaVazio(ErrorMsg) then raise EACBrDFeException.Create('Erro na thread de envio: ' + ErrorMsg); if EstaVazio(Result) then raise EACBrDFeException.Create('Timeout - Não foi possível obter a resposta do servidor'); end else begin FHttpSendCriticalSection.Acquire; try Result := FSSLHttpClass.Enviar(ConteudoXML, AURL, ASoapAction, AMimeType, AAuthorizationHeader); finally FHttpSendCriticalSection.Release; end; end; No caso, se ativarmos o TimeOutPorThread através da seguinte configuração: ACBrNFe.Configuracoes.WebServices.TimeOutPorThread := True; o componente, após 5 segundos, retorna um erro de timeout e finalmente pede o PIN do token, após informarmos o PIN, todas as requisições são enviadas normalmente pelo componente. Se não ativarmos tal configuração, o componente fica travado e nunca pede o PIN, porém, só com o PIN ele vai conseguir fazer as requisições... Alguém tem alguma ideia do que pode ser? Isso não acontece em todas as máquinas, na minha por exemplo, funciona normalmente, porém, na máquina de outro colega acontece também. Anexo coloquei um relatório de erros que o componente retorna quando ativamos o TimeOut, caso seja necessário... erro.txt

Realmente Lucas, agora que tu falou, percebi que vi errado... estranho que a SEFAZ ta obrigando a inserção destes campos...

Sobre a latitude e longitude, pelo que eu entendi na nota técnica, os 2 são obrigatórios... especificado como [1,1] Sobre o produto predominante, a gente ta obrigando o usuário a especificar o produto predominante sempre... pelo que eu entendi da nota técnica, ele é obrigatório... especificado como [1,1] O grupo de informações de pagamento não é obrigatório somente se o pagamento for à vista, se for a prazo tu tem que informar... especificado como [0,n], ai tem uma observação dizendo: Informar somente se indPag for à Prazo.

@Italo Jurisato Junior desculpa te incomodar, mas por um acaso a ACBr tem algum webservice que retorne o CEP com a latitude e a longitude? baita sacanagem da SEFAZ fazer a gente fornecer esses dados... Nas APIs que a gente usa, nenhuma delas fornece a latitude e longitude...

Pois é, também foi isso que eu entendi após ler mais sobre no link enviado pelo @BigWings. Já estamos desenvolvendo as modificações nessa NT. Também aproveito para agradecer aos demais que comentaram suas duvidas, sem duvidas serão uteis para responder as nossas dúvidas também.

Ok, vamos utilizar a mesma validação do CTe para o desenvolvimento então, obrigado @BigWings!

Boa tarde pessoal, Estamos implementando as modificações referentes a NT2020_001 v1.03 e me surgiu uma duvida. Sobre o grupo InfLotacao, a nota técnica diz que é para somente informar esse grupo de tags quando o MDFe for de carga lotação, porém, como definir se um MDFe é de carga lotação ou não? isso não ficou bem claro pra mim. Eu li em uma das validações e entendi que o grupo deverá ser gerado quando : 1 - O modal do MDFe for moRodoviario e o tpEmit for igual a teTransportadora. 2 - O tpEmit for igual a teTranspCTeGlobalizado e o MDFe possuir apenas um DFe transportado no grupo infDoc. O meu entendimento está correto? São essas duas regras que hoje classificam um MDFe como carga lotação? Agradeço pela atenção e aguardo ansiosamente pelo retorno.

Farei isto, obrigado!

As vezes, de forma completamente aleatória, ao consultar o status de envio de uma nota fiscal de serviço na prefeitura de Criciúma (A prefeitura usa o ambiente da Betha Sistemas) ocorre uma exceção na IDE (Delphi 10 Seattle): O estranho é que nem os arquivos de envio e retorno do ACBr chegam a ser salvos na pasta para que possamos verificar alguma inconsistência. E também esse erro é completamente aleatório, visto que a próxima nota enviada retorna o status corretamente. Alguém sabe o que pode ser?

Apenas pra finalizar o assunto, funcionou perfeitamente Italo. Muito obrigado!

Boa tarde Italo, desculpa a demora pra responder. Fiz os testes, Infelizmente ainda deu erro no envio. Este foi o retorno do componente: 500 - Inativo ou Inoperante tente novamente. Notei que alguns arquivos foram gerados pelo ACBr e decidi investiga-los. O primeiro arquivo gerado foi o 20190730152717-ANe.xml e este arquivo realmente foi gerado sem o grupo do qrCodMDFe. Notei que o ACBr gerou outro arquivo logo em seguida, 20190730152717-ped-ANe.xml e dentro deste arquivo ainda existe a tag qrCodMDFe. Fiz então a simulação pelo SoapUI com os 2 arquivos, com o primeiro (20190730152717-ANe.xml) o webservice nos retorna o código de declaração, tudo certinho. Já quando eu faço o envio do segundo arquivo (20190730152717-ped-ANe.xml) o webservice retorna esse erro: <faultstring xsi:type="xsd:string">error in msg parsing: XML error parsing SOAP payload on line 8: Mismatched tag</faultstring> Por que o ACBr gerou esse segundo arquivo? imagino que seja ele que o ACBr esteja enviando e por isso gera o erro... Inclui os 2 arquivos gerados pelo componente, obviamente, alterei os dados de acesso na ATM, fora isso está exatamente como foi enviado e feito os testes. Alguma ideia de como resolver essa situação?

Boa tarde, Apenas acrescentando a discussão, essa foi a resposta que o pessoal da ATM nos passou por email... respondemos o email e deixamos claro que não podemos fazer alteração em documento de XML já autorizado... até agora eles não nos responderam e pelo que eu entendi essa é a resposta final deles. Alguém tem alguma sugestão de como devemos proceder?

Agora faz sentido. Por precaução, vou manter a geração do QR Code apenas em homologação até que a ATM nos dê uma solução.

Ótima notícia, porém agora fiquei mais confuso ainda sobre o por que o MDFe não declara com a TAG e o CTe averba normalmente... Talvez a ATM já esteja providenciando as devidas alterações? Estamos aguardando a resposta deles, em contato por telefone eles já afirmaram que a nossa solicitação não foi a única... Qualquer coisa, volto a postar aqui.

Bom dia, após fazer o teste de envio sem a tag ![CDATA] verificamos que realmente deu problema na validação dos dados do XML. Utilizei o link da propria SEFAZ do RS e da erro na validação dos dados da linha 99, que é justamente a tag do qrCodMDFe, voltamos a aplicar a TAG CDATA e funciona perfeitamente. Vamos continuar o contato com o pessoal da ATM, se obtivermos retorno volto a postar aqui. Valeu pessoal!

Farei este teste segunda feira, ai volto aqui a posto o resultado, até!