Italo Giurizzato Junior

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.

Boa tarde, O método Enviar possui 3 parâmetros: function Enviar(ALote: integer; Imprimir: Boolean = True; Sincrono: Boolean = False): Boolean; ALote é o numero do lote que contem uma ou mais notas a serem enviadas. Imprimir, se True faz com que o DANFE seja impresso assim que a SEFAZ retorna o protocolo de autorização, se False não imprime o DANFE. Sincrono, se True realiza o envio no modo síncrono, neste caso o lote só pode conter apenas uma nota, se False o envio é assíncrono e neste caso o lote pode conter até 50 notas. Se cada PDV é autônomo no que diz respeito ao envio da nota para SEFAZ, pressupõe que o lote vai conter apenas uma nota, neste caso o terceiro parâmetro pode valer True. Por outro lado se o envio é centralizado em um servidor, isso faz com que podemos ter um lote com mais de uma nota, neste caso o terceiro parâmetro tem que ser False. Espero ter ajudado.

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 Tiago, Desculpa, mas já foi dito varias vezes em diversos tópicos que o ACBrGNRE ainda não esta pronto para ser compilado no Trunk2. Logo não da para instalar e muito menos usar.

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.

Bom dia Arnaldo, A mensagem de erro é só isso?

Bom dia Maurício, Ao executar pela segunda vez o DistribuicaoDFe, você esta informando o último NSU retornado pela consulta anterior? Se sim não é para constar da lista o resumo da NF-e manifestada e sim somente a NF-e. Para saber do que se trata, se é um resumo de nota ou nota completa ou resumo de evento ou evento completo deve-se ler a propriedade Schema conforme já dito na minha postagem anterior. Exemplo: if ACBrNFe1.retDistDFeInt.docZip.Items.XML <> '' then begin case ACBrNFe1.retDistDFeInt.docZip.Items.schema of tsresNFe: begin (...) end: tsresEvento: begin (....) end; tsprocNFe: begin (...) end; tsprocEventoNFe: begin (...) end; end; end;

Bom dia a todos, Rafael, note que a versão da nota é 3.10 mas a aplicação que gera esse XML ao receber o protocolo de autorização deve incluir no inicio o grupo <nfeProc> Isso esta sendo feito, mas ainda esta colocando a versão antiga. Consequentemente a versão que aparece na TAG nfeProc é 2.00 (errada) e a versão que aparece na TAG infNFe é 3.10 (correta). Medidas que você deve tomar: 1. editar esse XML corrigindo a versão que esta na TAG nfeProc, isso você pode fazer sem nenhum problema, pois não vai invalidar a nota. 2. entrar em contato com o emitente ou com o desenvolvedor dessa aplicação e informar que a versão que aparece na TAG nfeProc esta errada.