Italo Giurizzato Junior

Boa tarde Matheus, Muito obrigado pela colaboração, já esta disponível no SVN. Com relação aos arquivos que você postou, poderia configurar o componente: Configuracoes.WebServices.Salvar := True; Para salvar os XMLs de envio e de retorno com as TAGs de envelopamento. Esses arquivos possuem a palavra soap no nome e nos ajuda bastante na detecção de erros.

Boa tarde Leão, Não sei qual é o software que você esta usando para visualizar o XML, mas não existe nenhum linha em branco em lugar nenhum desse XML. Ele só não esta assinado e protocolado e contem o valor 1 informado de forma errada a TAG qMDFe conforme eu já relatei em uma outra postagem sua.

Boa tarde Renan, No meu entendimento esta errado e acredito que as empresas que atuarem dessa forma brevemente serão autuadas.

Bom dia Paulo, Pela mensagem de erro, você esta usando o Fortes Report, correto? Eu não trabalho com o Fortes, logo se eu testar com o seu XML com certeza não terei esse problema. A mensagem diz que ocorreu um erro pois não existe a propriedade ModDate. Esse tipo erro aparece quando a versão do seu Report não é a mesma que foi utilizada para fazer o DANFE. Tinhas esse tipo de problema com o Quick Report, inclusive escrevi um passo a passo (Property_Does Not Exist.txt) para resolver, ele esta disponível na pasta: ...\Fontes\ACBrDFe\ACBrNFe\DANFE\NFe\Quick Abra o arquivo: Property_Does Not Exist.txt e veja como é o passo a passo e tente adapta-lo para o Fortes Report. Se funcionar, ou seja, resolver o problema ficaríamos gratos se você disponibilizar o passo a passo que criou.

Bom dia Leão, É bem provável que o seu MDF-e esteja sendo rejeitado pelo simples fato de você estar atribuindo o valor UM ao campo qMDFe. O campo qMDFe que fica no grupo <tot> não significa a quantidade de MDF-e que você esta emitindo e sim a quantidade de MDF-e que foi relacionado nesse MDF-e que você gerou. Um MDF-e pode conter uma lista de CT-e no caso de uma transportadora, ou uma lista de NF-e no caso de transporte próprio ou uma lista de MDF-e quando se tratar de transporte Multimodal. Quando o MDF-e possui uma lista de CT-e devemos informar em qCTe a quantidade de CT-e que constam nessa lista. Quando o MDF-e possui uma lista de NF-e devemos informar em qNFe a quantidade de NF-e que constam nessa lista. Quando o MDF-e possui uma lista de MDF-e devemos informar em qMDFe a quantidade de MDF-e que constam nessa lista. Sendo assim somente um desses campos terá um valor maior do que zero os demais são sempre zero. Logo o XML que você postou esta errado, pois aparece: <qNFe>3</qNFe> <qMDFe>1</qMDFe> Sendo que deve aparecer somente: <qNFe>3</qNFe> Faça as devidas correções e teste novamente.

Bom dia Leão, Qual linha em branco?

Bom dia Matthias, Obrigado pelos arquivos, vou analisar e assim que possível disponibilizar as correções necessárias. ***** Favor atualizar os fontes e testar novamente.

Rafael, O Firewall da empresa esta impedindo que eu faça o download do 4shared. Envie os arquivos por e-mail.

Boa tarde Cantu, Na verdade você esta utilizando o método DistribuicaoDFe e não o Download, correto? Você esta passando como terceiro parâmetro o último NSU retornado pela última execução do método? Esta passando uma string vazia como quarto parâmetro? Já tentou realizar o teste em ambiente de produção?

Boa tarde Fabio, Mas esse XML original foi gerado por quem?

Boa tarde Igor, Qual XML foi excluído? No EPEC você tem que informar como Data/Hora de emissão a mesma Data/Hora informada em dhEmi que esta no XML da NF-e?

Boa tarde Paulo, Se mesmo compilando com a opção Build o problema continua, a minha suspeita cai sobre alguma DCU antiga perdida em alguma pasta que o Delphi tem acesso. Sugiro você procurar por todas as DCU e verifique se alguma delas não esta em algum lugar errado.

Bom dia Rômulo, Seguindo as orientações do Daniel, por favor atualize todos os fontes de todas as pastas e refaça os testes.

Bom dia Sandro, Esse XML que você anexou não possui o protocolo de autorização, ele esta apenas assinado. Você deve carrega-lo com o método LoadFromFile e depois executar o Consultar, desta forma o XML será atualizado, ou seja, vai receber o protocolo de autorização, caso o mesmo tenha sido autorizado pela SEFAZ.

Bom dia Pedro, Você pode sim utilizar a mesma série e consequentemente a mesma sequencia de numeração sem nenhum problema, visto que a NF-e é um modelo de documento fiscal e a NFC-e é outro modelo. Uma mesma Empresa pode dependendo da situação emitir a NF-e ou a NFC-e, consequentemente em algum momento será emitido a NF-e serie 1 numero 1500 e em outro a NFC-e serie 1 numero 1500. Repito isso não tem problema nenhum pois são modelos de documentos fiscais diferentes. Modelo da NF-e é 55 e da NFC-e é 65.

Bom dia Rafael, O componente possui 3 propriedades que determina se os XMLs serão salvos em disco ou não. Configuracoes.Geral.Salvar := [True|False] => defini se os XMLs de envio/retorno serão salvos em disco ou não. Configuracoes.WebServices.Salvar := [True|False] => defini se os XMLs de envio/retorno (completos com as TAGs de envelope) serão salvos em disco ou não. Configuracoes.Arquivos.Salvar := [True|False] => defini se os XMLs de validade jurídica serão salvos em disco ou não.

Bom dia Leão, Os espaços em brancos que encontrei no seu XML são normais e estão previstos, não encontrou nenhum que invalidasse o seu XML.

Bom dia Fabio, O método consultar é para quando você já tem o XML assinado e só necessita do protocolo de autorização. Se o emitente perdeu o XML existem 2 soluções: 1. Se o XML em questão foi enviado por e-mail para o destinatário, basta entrar em contato com o mesmo e pedir que lhe envie por e-mail, simples assim. 2. Gerar e assinar o XML com os mesmos dados da primeira vez, tomando o cuidado da chave ser exatamente igual, depois executar o método consultar para obter o protocolo de autorização.

Bom dia Robinho, Qual problema?

Bom dia, O Daniel adicionou uma nova propriedade para identificar o tipo de soap a ser enviado ao Web Services e eu fiz uma alteração no ACBNFSe visando utilizar essa nova propriedade. Favor atualizar todos os fontes de todas as pastas e refaça os testes.

Bom dia Marcelo, Obrigado, vou analisar, assim que descobrir alguma coisa vou fazer as correções e disponibiliza-las.

Bom dia Paulo, Só há necessidade de instalar novamente quando alguma propriedade nova é acrescentada, caso contrario não. É interessante toda vez que existe uma atualização dos fontes, compilar a aplicação com a opção Build.

Beleza, como nem todos os provedores seguem o mesmo tipo de envio para o Web Service, com certeza teremos que fazer algumas alterações nas classes do ACBrDFe para que o ACBrNFSe possa funcionar.

Boa tarde Fabio, O Consultar não gera XML do CT-e ele apenas realiza uma consulta. O que ele faz é se você carregar o componente com o CT-e, após a consulta o mesmo será atualizado. Por exemplo, o XML do CT-e esta assinado mas não contem o protocolo de autorização. Você carrega o XML com o LoadFromFile e depois executa o Consultar. O XML do CT-e será atualizado, ou seja, vai ficar assinado e com o protocolo de autorização (caso a SEFAZ tenha autorizado).

Boa tarde Murilo, A mensagem de erro é clara: '' violates pattern constraint of '[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}'.The element '{http://www.portalfiscal.inf.br/nfe}cExportador' with value '' failed to parse. Diz que o elemento cExportador contem uma string vazia, sendo assim você deve alimentar esse campo na sua rotina que alimenta o componente com os dados da nota. Te aconselho ter em mãos a estrutura completa do XML para saber quais são os campos obrigatórios e opcionais na hora de alimentar o componente. Você encontra a estrutura completa e atualizada do XML da NF-e na Nota Técnica 2013/005 versão 1.22