Italo Giurizzato Junior

Bom dia Emerson, Favor atualizar os fontes, foi implementado a opção de salvar o XML de retorno do Download e DistribuicaoDFe com base na emissão do documento. Basta atribuir o valor True a propriedade: EmissaoPathNFe

Pessoal, Primeiramente muito obrigado, já esta disponível, por favor atualizem os fontes e testem. Se possível, testem o EPEC da NF-e e NFC-e. A alteração que fiz visa gerar o XML de envio do EPEC de tal forma que ele fique em conformidade com os Schemas. No caso do EPEC da NF-e se eu não cometi nenhum erro de sintaxe nos fontes é para funcionar 100%, ou seja, é para ser validado pelo componente e aceito pela SEFAZ. Quanto ao EPEC da NFC-e é para ser validado pelo componente, mas vamos ver se será aceito pela SEFAZ. Fico no aguardo de um retorno dos resultados dos testes.

Bom dia a todos, EPEC da NF-e ==> Nota Técnica 2014/001 versão 1.10 página 7 O campo vST é obrigatório, mas vejam que esse campo é filho do campo P17 que é detEvento. Mas fomos obrigado a mudar, ou seja deixar os campos vNF, vICMS e vST como filhos do campo P26 que é dest. Porque essa alteração? No schema (e110140_v1.00.xsd) esta dessa forma e a validação no Web Service também. Portanto a estrutura apresentada na Nota Técnica não esta em conformidade com o schema e Web Service, no meu entendimento o correto seria o que esta na NT uma vez que os 3 campos sitados não são informações do destinatário. EPEC da NFC-e ==> Nota Técnica 2014/003 versão 1.02 página 7 O campo vST não existe, mas vejam que os campos vNF e vICMS são filhos do campo P17 que é detEvento. O componente esta gerando esses dois campos como filhos do campo P26 que é dest. Temos um problema agora, se usarmos o mesmo schema da NF-e para validar, ocorre erro de validação, acusando a falta do campo vST. Se usarmos o schema (eventoEPEC_v0.01) teremos que mudar a forma que o XML é gerado, ou seja os campos vNF e vICMS temos que colocar como filhos de detEvento, para que ocorra a validação. Fazer essa alteração no componente é simples e podemos fazer. Mas será que a SEFAZ vai validar o XML de EPEC da NFC-e desta forma? Se aceitar ótimo, problema resolvido. E se não aceitar? Bom neste caso a solução será alterar o schema e110140_v1.00.xsd de tal forma que o campo vST seja tratado pelo mesmo como opcional. Eu me comprometo a realizar as alterações, sejam no fonte ou no schema. Preciso de voluntários para realizar os testes. Quem se habilita e qual versão do ACBr vai utilizar (Trunk ou Trunk2) ?

Boa tarde Luiz, Por favor tente debugar, para sabermos exatamente onde esta ocorrendo a violação de acesso.

Boa tarde Emerson, Será preciso fazer uma checagem se deseja salvar na pasta mensal referente a emissão do documento e não na pasta mensal correspondente a data atual.

Bom dia Tiago, No meu entendimento quando o problema é a falta de acesso por parte do emitente, ou seja, a SEFAZ-Autorizadora esta operando normalmente, o emitente tem que enviar o evento EPEC, neste caso terá que se utilizar de uma conexão 3G por exemplo. E quando o problema for sanado as NFC-e deve ser enviadas para SEFAZ. Agora se o problema é na SEFAZ que esta parada, ai sim as notas devem ser represadas no SAT (Estado de São Paulo) e quando a SEFAZ voltar a operar normalmente o SAT envia as notas. Como não tenho nada desenvolvido com a NFC-e / SAT, acredito que se a nota foi enviada pelo SAT não se faz necessário enviar novamente como NFC-e.

Bom dia Korporasi, Conhece aquela frase: faça o que mando e não faça o que faço ? Pois bem segundo o manual da NF-e não devemos usar palavras com vogais acentuadas e cedilha no XML da NF-e, mas no retorno a SEFAZ usa. Desta forma se você tentar abrir o XML de retorno da SEFAZ através de um navegador terá problemas. Você pode abrir o XML usando um bloco de notas e alterar o cedilha por C e as vogais acentuas por não acentuadas, ou na sua aplicação escrever uma rotina que faça isso, depois de todo o processo concluído, a sua aplicação carrega o XML como uma string e faz a alteração e salva novamente.

Bom dia Rafael, Você tem certeza que ao enviar o evento EPEC esta configurando o componente para o modelo moNFCe? Pois se no momento de validar esta acusando a falta do vST significa que algo não esta configurado corretamente. Todos os fontes de todas as pastas estão atualizados? Pois fiz uma alteração visando corrigir esse problema, pois para a NFC-e é usado o schema eventoEPEC e não o envEPEC que é usado pela NF-e. Se esta tudo atualizado, você compilou a sua aplicação com a opção Build?

Bom dia Ally, A minha sugestão é desinstalar os componentes que você tem hoje, deletar a pasta que contem todos os fontes ACBr, criar uma nova e baixar os novos fontes do repositório Trunk2 em vez do Trunk. Os fontes que estão no Trunk vão ser congelados e não terão mais atualizações. Com os fontes do Trunk2 com certeza algumas alterações no seu código serão necessárias, mas nada de perder noites de sono. As alterações que tive que fazer na minha aplicação foram na rotina de configuração do componente, do resto não teve grandes mudanças. Como você esta migrando para a versão 3.10 da NF-e existem algumas alterações a serem feitas na rotina que alimenta o componente com os dados da venda, mas também nada de tão complicado. Se você tiver em mãos a nova estrutura do XML da NF-e versão 3.10 você vai descobrir o que é necessário acrescentar ou alterar para que funcione 100%.

Bom dia Claudio, Entendo o que você disse e concordo plenamente com você, uma vez que o XML, disponibilizado pelo emitente desde que assinado e protocolado pela SEFAZ é um documento com validade jurídica. Sendo assim podemos extrair dele todas as informações que necessitamos para cada etapa do processo. É por isso que sempre coloco o dedo na ferida. Todo Emitente de NF-e tem por obrigação legal disponibilizar o XML assinado e protocolado ao Destinatário assim que a SEFAZ retornar o protocolo de autorização. Estamos aqui falando da NF-e e não podemos esquecer do CT-e que também é preciso ser lançado pelo Tomador do Serviço, portanto o Emitente do CT-e também tem a mesma obrigação legal em disponibilizar o XML ao Tomador do Serviço. Hoje temos para a NF-e o serviço DistrubuicaoDFe disponibilizado pela SEFAZ que permite que o Destinatário baixe o XML completo da NF-e desde que realize a manifestação da mesma. No caso do CT-e ainda não temos este serviço, mas estou apostando que em breve teremos.

Duarte, Quanto ao Thread não sei lhe informar. O Daniel, André tem mais propriedade em responder a sua pergunta.

Bom dia Ramalho, Esse erro esta ocorrendo porque tanto o schema eventoEPEC_v0.01 quanto o tipoBasico_v3.10 possuem o tipo complexo: tcOrgaoIBGE. Se você esta com todos os fontes de todas as pastas atualizados, dentro da pasta ...\Exemplos\ACBrDFe\ACBrNFe\Schemas\ve310 você encontra todos os schemas utilizados tanto para a NF-e quanto para a NFC-e na versão 3.10 São esses esquemas que você deve utilizar.

Bom dia Luiz, Dentro da pasta ....\Fontes\ACBrCTe existe um arquivo TXT para remover as propriedades que não existe. Siga o passo a passo desse arquivo, compile a sua aplicação com a opção Build e teste novamente.

Bom dia Duarte, Em vez de criar uma instância para chamar o método DistribuicaoDFe e outra para o EnvioEvento, porque você não coloca o componente ACBrNFe em um Data Module? No form que será necessário executar algum método do componente basta declarar o DM no uses do respectivo form.

Boa tarde Duarte, Primeiramente, gostaria de chamar a atenção de não utilizar o DistribuicaoDFe para simplesmente obter o XML da NF-e. A Manifestação do Destinatário deve ser feita de forma consciente e que condiz com a realidade e não manifestar tudo como teManifDestCiencia. E se uma determinada nota não tem nada haver com o destinatário, ou melhor, alguém emitiu uma nota por engano contra o seu CNPJ ou emitida de forma fraudulenta. No que diz a exceção levantada, você cria e destrói o componente toda vez que for utilizar? Porque você esta pegando o CNPJ lendo o certificado, você não tem o CNPJ armazenado em uma tabela no banco de dados?

Boa tarde Solivan, Ambas as funções são idênticas. Você tentou fazer no Fast algo semelhante o que foi feito por mim no Quick Report? Na unit ACBrNFeDANFeQRNFCe procure por GetURLQRCode. A chamada agora esta desta forma: sURL := TACBrNFe(FACBrNFe).GetURLQRCode(FNFE.Ide.cUF, ..... );

Boa tarde Jorge, Se você programa em Delphi, lembre-se que existe uma propriedade do DANFE chamada NFeCancelada, se antes de executarmos o Imprimir ou ImprimirPDF atribuirmos o valor True a essa propriedade, o DANFE ou PDF do mesmo vai conter a Tarja: NF-e Cancelada.

Boa tarde Duarte, Você esta abrindo esses arquivos com algum aplicativo? Ou apenas renomeou e anexou na sua postagem? Tirando o fato que no arquivo nomeado como sendo RetornoConsulta_Trunk.xml conter o grupo Header e o RetornoConsulta_Trunk2.xml não ter o resto esta OK. Agora quero saber se foi salvo os XMLs dos resumos das NF-e, os XMLs completos das NF-e e dos eventos? Para que os mesmos sejam gravados em disco a propriedade: Configuracoes.Arquivos.Salvar tem que estar com o valor True.

Bom dia Dangelo, Na empresa que trabalho não precisamos do XML para dar entrada no estoque, ou seja não dependemos dele para esse fim. Ao emitir e enviar o Pedido de Compra para o fornecedor ressaltamos que o mesmo tem por obrigação legal nos enviar por e-mail o XML e o DANFE impresso em papel junto com a mercadoria adquirida. Os XMLs recebidos por e-mail são salvos no servidor separados por pastas mensais. No caso de devolução, por não estarmos obrigados a emitir documento fiscal, ou seja, Nota Fiscal, apenas emitimos uma CRM - Carta Remessa de Mercadoria a titulo de devolução. O que eu quero deixar claro é que: 1. Todo fornecedor é obrigado por lei disponibilizar o XML da NF-e (XML este assinado e com o protocolo de autorização da SEFAZ) para o Destinatário da mercadoria. 2. No meu sistema, se tratando de dar entrada no estoque o almoxarife confronta o DANFE com o Pedido de Compra se tudo estiver OK, basta informar o numero do Pedido e outros dados como data de vencimento das parcelas (por exemplo) para que seja feito o lançamento, desta forma não requer a digitação de item por item comprado.

Bom dia Fabio, Primeiro para que enviar novamente uma nota que já foi enviada? Desculpa não entendi. Segundo, respondendo a sua pergunta: simples, ao gerar novamente o XML o mesmo fica sem o protocolo e se ainda não foi assinado fica sem assinatura também. E ao tentar enviar uma nota que já foi enviada e autorizada, esse segundo envio resulta em uma rejeição acusando duplicidade, portanto o XML não recebe o protocolo de autorização.

Bom dia Otair, O método DistribuicaoDFe pode ser utilizando tanto pelo Emitente da Nota quanto pelo Destinatário. Para ter acesso ao resumo das notas emitidas bem como o XML completo da mesma, o autor da consulta tem que ser o Destinatário. Se o Destinatário vir a realizar a manifestação, o Emitente da nota através do DistribuicaoDFe vai ter como retorno a manifestação realizada pelo Destinatário. Você esta ciente disso?

Bom dia Claudio, Veja este link:

Bom dia Fernando, Não estamos mais disponibilizando o DANFE feito em Quick Report 3, inclusive na nova versão dos componentes apesar de você encontrar o DANFE feito em Quick Report só terá manutenção os que forem feitos em Fortes e Fast Report. Se você quer continuar com o Quick Report aconselho você passar a usar a versão 5.02 do mesmo. Se isso não for possível, será necessário editar o pacote de instalação com o bloco de notas, trocando o nome da DCP do Quick Report 5 pelo do 3.

Bom dia Duarte, Por favor quando postar fragmentos de código, coloque-o em um arquivo TXT e anexe o mesmo, sua postagem vai ficar curta e quem desejar ver a rotina basta baixar o arquivo.

Bom dia Fernando, Acredito que o problema esteja na falta de incluir no Library path o caminho onde esta o Quick Report 5. Na minha maquina inclui a linha abaixo: C:\Arquivos de programas\Borland\Delphi7\Quickrep5 Atenção este path tem que ser incluído antes dos path do ACBr.