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!