helio

NFC-e esta autorizada mais não consigo fazer consulta, sempre recebo o retonor CSTAT 999, alguem com o mesmo problema.... Webservice de MT.

Chegamos ao ponto.... Primeiro concordo com vc q o código q eu propus não funcionaria com o codigo atual do ACBr.. Mais não posso corrigir um erro com outro erro? A lógica do código q enviei esta certa, Leitor.rCampo deveria ser capaz de procurar primeiro elementos do nó atual para depois procura em nós filhos... o código atual continua errado ou melhor sujeito a falhas, primeiro o xml pode chegar ao TLeitor sem esta na sequencia(imagino q o SEFAZ procura por tag e não por sequencias), digamos q código esteja na sequencia, e se ele não foi gerado pelo ACBr, foi carregado de uma arquivo externo, e se o mesmo estiver com quebras de linhas ou espaçamentos entre tags? isso nao funcinaria MDFe.rodo.veicTracao.UF := copy(Leitor.Grupo, (Pos('</tpCar>', Leitor.Grupo)+12), 2)? É simples destacar um erro sem apresentar uma possível solução, pra mim neste caso não é necessário querer reinventar a roda, o TLeitor do ACBr deveria internamente usar algum lib para leitura XML! seria até mais rapido pois com uma lib para esse fim tudo estaria em nó elemento e atributo? Por hora pra mim q carrega o xml(xml valido) gerado em outro lugar, é remover toda quebra de linha e espaçamentos e manter a sequencia do manual!!!

Hj nao tem como! Mas por favor explique o motivo do if? Logico se puder.... Qual motivo tenho q checar se exist a tag <prop> para adicionar uf do <veictracao>? Porfavor faca referencia no manual de integracao!

Veja... if pos('<prop>', Leitor.Grupo) = 0 then MDFe.rodo.veicTracao.UF := Leitor.rCampo(tcStr, 'UF') esse trecho diz q seu nao tenho a tag <prop> eu posso pega a uf, e se tiver d onde vem a uf do veiculo? Independente do modo q opera o acbr?

Boa tarde, Mesmo <veicTracao> sendo de nível 1 e <prop> sendo de nível 2 mesmo assim elas são entidades diferente.... veja o contexto, imagine um carro(veicTracao) que foi registrado em SP, e o proprietário(prop) tem seu rg de MG.... por que o carro tem q ter a mesma UF de registro do proprietário? na minha humilde opinião cada um tem e deve ter sua UF de registro nacional ou de licenciamento.... agora se o acbr faz alguma restrição ele esta fazendo de modo errado....

Discordo pois veicTracao e prop são entidades diferentes, um nao depende do outro para ter o atributo UF e o manual nao faz nenhuma restrição a única restrição é Proprietários do veículo só preenchido quando o veículo não pertencer à empresa emitente do MDF-e.... lógico estou falando da versao 3.00....

No tópico abaixo foi discutido o erro sobre a UF do veiculo de tração, a meu ver independente de existir ou nao o proprietário do veiculo deve existir a UF do veiculo pois é onde o veiculo foi registrado.... O ACBr faz esta verificação desnecessária na unit "pmdfeMDFeR" linha 240 if pos('<prop>', Leitor.Grupo) = 0 then MDFe.rodo.veicTracao.UF := Leitor.rCampo(tcStr, 'UF') else MDFe.rodo.veicTracao.UF := copy(Leitor.Grupo, (Pos('</tpCar>', Leitor.Grupo)+12), 2); o topico e este abaixo Segue abaixo uma alteração...... pmdfeMDFeR.pas

Tive o mesmo problema.... o acbr não trata devidamente o cabeçalho de resposta de envio.... na unit ACBrCTeWebService.pas linha 929 fiz uma correção para que ele trate o cabeçalho 'retEnviOS'. em anexo a correção ACBrCTeWebServices.pas

Quando vc faz referencia para ACBrDANFCeFortesFrA4 e ACBrDANFCeFortesFr no mesmo projeto, elas adicionam o resource na sessão initialization, veja: {$ifdef FPC} initialization {$I ACBrNFeDANFCeFortes.lrs} {$endif} Assim dará o erro interno de resouce duplicado... a alternativa do Anderson foi para resolver o problema por hora... pois a solução seria seria ter um recurso para cada unit/class