Italo Giurizzato Junior

Bom dia Rafael, É nestes casos que devemos ter uma opção de configuração na aplicação que permite salvar os arquivos soap, ou seja: Configuracoes.WebServices.Salvar := True; Com essa configuração os arquivos de envio e de retorno serão salvos em discos exatamente como são enviados para SEFAZ e o respectivo retorno. Podemos identificar esses arquivos através da palavra soap no nome do XML. Analisando os arquivos de retorno podemos com mais facilidade descobrir o que esta ocorrendo.

Bom dia Murilo, Ao utilizar o método DistribuicaoDFe temos vários tipos de retornos, tais como: resNFe, resEvento, nfeProc e procEventoNFe. Em resNFe temos apenas um resumo da nota e neste resumo temos a data e hora de emissão da nota e para obter essa informação basta ler a propriedade dhEmi da seguinte forma: dhEmissaoNFe := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resNFe.dhEmi; Em resEvento temos apenas um resumo do evento e neste resumo temos a data e hora de emissão do evento e para obter essa informação basta ler a propriedade dhEvento da seguinte forma: dhEmissaoEvemto := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resEvento.dhEvento; Em nfeProc temos a nota completa inclusive com a assinatura e protocolo de autorização e para obter a data e hora de emissão basta ler a propriedade dhEmi da seguinte forma: dhEmissaoNFe := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resNFe.dhEmi; Em procEventoNFe temos o evento completo, ou seja, a solicitação e o retorno da SEFAZ acusando que o mesmo foi registrado e vinculado a nota e para obter a data e hora de emissão do evento basta ler a propriedade dhEvento da seguinte forma: dhEmissaoEvemto := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].procEvento.dhEvento; Dica: abra o fonte pcnRetDistDFeInt.pas para saber quais são as informações disponíveis em cada tipo de retorno.

Bom dia Tony, O componente não gera o XML com base no XSD e sim utiliza este último para validar o XML gerado. Se o XML gerado ao ser confrontado com o Schema (arquivo XSD) o componente para acusando erro de validação. O seu problema é outro, trata-se de uma rejeição. Isso significa que o XML foi gerado, validado e enviado, mas a SEFAZ esta recusando-o. Como as SEFAZ estão passando por um processo de mudanças, pode muito bem ter ocorrido algum problema nas rotinas deles que esta provocando essa rejeição.

Boa tarde ALA, Apesar de constar na NT que a regra NA11-10 só será colocada em pratica a partir de 01/01/2016 pode ser que a SEFAZ tenha habilitado essa regra sem querer querendo. Favor entrar em contato com a SEFAZ.

Boa tarde Marcos, Se você esta usando o método Download, favor dar olhada na estrutura do downloadNFe que consta na Nota Técnica 2012/002 versão 1.02 - página 18. Tudo indica que devemos usar um certificado com o CNPJ da pessoa que deseja realizar o Download da NF-e.

Boa tarde André, O destinatário é o consumidor final da mercadoria vendida, se não for você não pode incluir o grupo <ICMSUFDest> Outra coisa, leia atentamente a coluna observação do campo <indIEDest> que esta na página 20 da Nota Técnica 2013/005 versão 1.22

Boa tarde Gilvan, Os fontes que você esta baixando é do repositório Trunk ou Trunk2? Somente os do Trunk2 estão atualizados com os novos campos.

Boa tarde, A principio o XML esta correto. É preciso agora descobrir se realmente esse destinatário não possui IE.

Boa tarde Cleiver, Para alguns provedores não podemos fazer o ajuste mencionado pelo erro. Estamos estudando algumas alterações que visam corrigir esse problema.

Bom dia a todos, Quando eu salvo no banco de dados uma nova nota, utilizo o Randomize para gerar o cNF e guardo esse numero junto com os demais dados da nota no banco de dados. Randomize; CodigoNFChave := Random(999999999) + 1; // é somado 1 para garantir que esse código nunca seja zero. Na rotina que é lido os dados da nota para alimentar o componente tenho a seguinte linha: Ide.cNF := DM_VEN.NotasCodigoNFChave.AsInteger; Se cNF for alimentado com um valor diferente de zero, o componente se utiliza desse numero para compor a chave, por outro lado se for zero que vai gerar o código de forma aleatória é o próprio componente. Da forma que fiz nuca corro o risco de uma nota ter 2 chaves distintas quando se faz necessário gerar novamente o XML por motivo de rejeição de algum dado informado de forma errada.

Bom se o Micro Empreendedor aparece na nota como destinatário qual é o valor que você esta passando para o campo: indIEDest? Segundo a NT 2013/005 versão 1.22 página 52 diz que devemos atribuir o valor 2 ao campo indIEDest quando se tratar de um contribuinte isento no cadastro de contribuintes do ICMS, ou seja, possui CNPJ mas não possui IE.

Bom dia, Essa pessoa (Micro Empreendedor) é o emitente da nota ou o destinatário?

Bom dia Dércio, Os provedores Betha, BHISS, SJP, 4R, Digifred, FIntelISS, Fiorilli, e SystemPro também requerem que tanto o Lote quanto o RPS sejam assinados. Mas para esses provedores os arquivos INI foram feitos e já encontram-se disponíveis. Alguns colegas do fórum andaram estudando os fontes e fizeram alterações para tentar resolver o problema, alguns conseguiram e enviaram para mim o que fizeram. Algumas alterações vem de encontro com o que estamos trabalhando, outras tivemos que descartar pois o risco de gerar um efeito colateral nos demais componentes era grande.

Bom dia Fabio, Segundo a minha lista esta faltando os provedores: GovBR, Natal, Prodemge, Salvador, Tinus, GovDigital, Link3, Prodata, PVH, e Vitória. Todos esses provedores se eu não estiver errado requerem que tanto o Lote quanto o RPS sejam assinados. O problema é que os componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrNFSe herdam várias propriedades e métodos do ACBrDFe, um deles é o método Assinar. Com exceção do ACBrNFSe os demais componentes devem assinar somente os documentos o Lote não. Ao tentar assinar um lote de um provedor que requer que o RPS seja assinado também, a assinatura não é realizada, provocando um erro de validação ou rejeição por parte do provedor. Estamos trabalhando para resolver esse problema.

Boa tarde, Na pasta: C:\TurboNfe\Schemas estão todos os XSD? Copie para a sua pasta de Schemas todos os arquivos que estão dentro da pasta : ...\Exemplos\ACBrDFe\Schemas\NFe

Boa tarde Maurício, Realmente existe uma incoerência. No meu entendimento se tratando de cancelamento pelo menos este evento ou resumo deste evento deveria ser disponibilizado ao destinatário para que o mesmo saiba que a respectiva nota foi cancelada. A minha sugestão é entrar em contato com a SEFAZ e questiona-los sobre esse assunto.

Boa tarde Lauro, Antes de realizar a manifestação, verifique se a nota já consta no Portal Nacional da NF-e. Se sim, ai sim tenta manifestar, procure certificar-se que realimente a chave informada é exatamente igual ao da nota consulta via site. Se eu entendi direito a primeira nota a ser manifestada o problema não ocorre, ao tentar manifestar a segunda ocorre o problema, correto? Se sim, tente fechar a aplicação e tentar manifestar essa segunda nota, se ela for sem nenhum problema, podemos concluir que é a sua aplicação, que deve esta executanto um segundo ADD e ao tentar enviar o evento ocorre o problema.

Boa noite Daniel, Entrar em contato com a SEFAZ e expor o problema.

Boa noite, Você segui o meu exemplo acima? Antes de executar o exemplo o componente foi configurado para salvar o XML? Configuracoes.Arquivos.Salvar := True;

Pessoal, Parece que o problema na SEFAZ-SP foi resolvido.

Bom dia a todos, Vejam: http://www.nfe.fazenda.gov.br/portal/disponibilidade.aspx?versao=0.00&tipoConteudo=Skeuqr8PQBY=

Arnaldo, Se a postagem acima se refere ao seu XML, isso significa que você esta com os fontes desatualizados, pois o percentual referente a TAG pICMSInter tem que ter apenas duas casas decimais e o motivo do erro é porque esta com 4 casas.

Bom dia Diego, O certificado não esta vencido?

Bom dia, Qual é a UF?

Bom dia Jefferson, Acredito que não, mas vamos estudar o caso.