Italo Giurizzato Junior

Boa tarde, Já tentou desta forma: with fsindatanfe2 do begin ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.NotasFiscais.LoadFromFile(dmnf.znfeCHAVE_NFE.AsString); ACBrNFe1.NotasFiscais.Items[0].EnviarEmail(Para , edtAssunto.Text , memMsg.Lines , True , nil , nil); ShowMessage('Email Enviado com Sucesso!'); end;

Boa tarde José, Toda rejeição de duplicidade significa que a nota foi enviada novamente. A regra é simples, enviou, ocorreu algum erro, não se deve enviar novamente e sim consultar. É normal você consultar no portal da SEFAZ-Autorizadora e a nota constar e não constar no Portal Nacional. A nota é enviada para a SEFAZ-Autorizadora e esta por sua vez replica para o Portal Nacional caso a nota tenha sido autorizada. A questão é o tempo que demora para que ocorra essa replicação, que pode ser de alguns segundos, minutos ou até horas.

Boa tarde, Favor atualizar os fontes e faça novos testes.

Boa tarde, Eu atualizei os fontes, alterei a minha aplicação para atender as mudanças da NF-e versão 4.00 O meu cliente esta emitindo as notas e os e-mail com o XML e DANFE em PDF estão sendo enviados sem nenhum problema. Você atualizou todos os fontes de todas as pastas? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2? O envio do e-mail não tem nada haver com a versão 4.00 da NF-e e nem com o componente ACBrNFe, pois o envio fica a cargo do componente ACBrMail que é "linkado" ao componente ACBrNFe.

Bom dia Rauber, Favor atualizar os fontes. Essa alteração já fiz no arquivo INI do respectivo provedor.

Bom dia Vanderson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Adilson, Como não existe uma padronização entre os provedores e tem provedor que não consegue manter um padrão perante as cidades atendidas por ele, por exemplo o provedor Abaco que para a cidade de Manaus não pode constar um namespace que aparece no XML das demais cidades, caso contrario o RPS não é aceito. Logo o meu conselho é: Testar.

Anderson, O método Consultar tem como pré-requisito o envio do evento R-2099. O método Consultar não serve para saber se o evento R1000 ou qualquer outro foi processado corretamente ou não.

Bom dia Nelson, Desculpe, não quero ser chato, mas essa postagem é para discutirmos sobre as alterações publicadas na NT 2018/002. Vamos procurar sempre seguir as regras do fórum. Com relação ao DACTE faça as alterações que você juga ser necessárias e faça os testes, funcionando conforme o esperado, criei um novo tópico anexe a unit alterada e descreva a motivação dessa alteração. Desde já muito obrigado pela colaboração.

Bom dia, Sim, consulte novamente, pois no retorno da recepção consta que o lote esta em processamento. Neste caso devemos aguardar mais alguns segundos ou minutos e tentar novamente.

Bom dia Anderson, Você chegou a enviar o evento 2099? Nos XML que você anexou vejo que só foi enviando o evento 1000. Para obter o Numero do Protocolo de Fechamento a ser utilizando no Consultar é preciso enviar o evento de Fechamento, ou seja, o evento 2099.

Bom dia, Para mim tem coisa errada na sua rotina. o trecho abaixo não precisa: //Corri MS := TMemoryStream.Create; try ArqXML := dmnf.znfeCHAVE_NFE.AsString; MS.LoadFromFile(ArqXML); fsindatanfe2.ACBrMail1.AddAttachment(MS, 'XML',adAttachment); finally MS.Free; end; CC := TstringList.Create; Para := edtPara.Text; cc.Text := ''; Pois ao carregar o XML como o LoadFromFile o método EnviarEmail já anexa automaticamente o XML. Outra coisa: fsindatanfe2.ACBrNFe1.NotasFiscais.Items[0].EnviarEmail(Para , edtAssunto.Text , memMsg.Lines , True <==== isso esta correto, pois é o parâmetro que diz que você deseja enviar o PDF do DANFE também. , cc <=== aqui devemos informar a lista de email que desejamos enviar também (CC- Com Cópia) , cc); <=== isso esta errado, pois aqui devemos informar outros anexos, o correto seria informar o valor: Nil Favor se basear no programa exemplo do componente.

Dércio, Os documentos devem ser impressos e acompanhar a carga. Se existe uma previsão do termino do serviço, o caminhão poderá sair com as duas notas e os dois MDF-e. A nota 1 e MDF-e 1 serão apresentados ao posto fiscal ao se locomover para o local do serviço. Já a nota 2 e MDF-e 2 serão apresentados ao posto fiscal quando do seu retorno.

Bom dia Jocemar, No meu entendimento o pessoal do eSocial errou ao discriminar o código 201 como sendo "Lote processado com sucesso", o correto seria, "Lote recebido com sucesso". Ai sim, a recepção do lote foi realizada com sucesso, ou seja, a estrutura do lote bem como dos eventos nele contidos esta correto, mas isso não significa que as informações estejam corretas.

Bom dia Dércio, Também tenho duvidas de qual seria o procedimento correto, mas no meu entendimento seria da seguinte forma: 1. Uma nota de simples remessa é emitida constando as ferramentas, nessa nota devemos informar o local de execução do serviço como sendo o destinatário. 2. Emitir o MDF-e vinculando a nota acima. 3. Chegando no local do serviço o MDF-e deve ser encerrado (o seu cliente deverá fazer isso). 4. Finalizando o serviço uma nova nota de simples remessa deverá ser emitida sendo que agora o destino é a empresa do seu cliente. 5. Um novo MDF-e deve ser emitido com essa nota vinculada. 6. Encerrar esse MDF-e quando as ferramentas chegarem no seu destino. O grande problema que muitos contadores não vão saber lhe orientar de forma correta como proceder, uma vez que o MDF-e não é um documento a ser escriturado ou contabilizado.

Bom dia Walter, Ai é que esta o problema, muitos comente o mesmo erro. Envia a nota o retorno não vem e o usuário envia a nota novamente. Esse procedimento esta errado. A nota é enviada e ocorre um erro, você sabe me dizer se esse erro de timeout (por exemplo) ocorreu no envio ou no retorno? Pois bem, não sabe. O que devemos fazer se ocorrer um erro ao enviar uma nota? Simples, devemos consultar a mesma, se a SEFAZ retornar a mensagem que a nota não consta na base de dados, fica claro que o erro ocorreu no envio, logo devemos enviar novamente. Agora se o erro ocorreu no retorno, ao consultar, a SEFAZ vai retornar o protocolo de autorização, o XML da nota será atualizado e o passo seguinte é imprimir o DANFE. Para resolver o problema de uma vez por todas de Duplicidade com diferença na chave de acesso é muito simples. Veja o fragmento do arquivo INI de uma nota abaixo: [infNFe] versao=4.00 [Identificacao] cNF= <informar aqui o código da Nota Fiscal> natOp=VENDA mod=55 serie=1 nNF=1500 No seu banco de dados deve existir uma tabela que contem os dados da nota, como numero, data de emissão, destinatário, ... entre outras informações. Pois bem, agora vai ter um campo a mais chamado CodNF que é do tipo numérico inteiro. A sua aplicação deve gerar um código aleatório diferente de zero e com no máximo 8 dígitos para cada nota a ser emitida. Esse código deve ser salvo no banco de dados no campo CodNF (conforme exemplo acima). Na rotina que lê as informações do banco de dados para gerar o arquivo INI, devemos ler o campo CodNF e o seu valor atribuir a cNF (em negrito/vermelho). Qual é a motivação para fazer isso? Simples, o valor de cNF é utilizado para compor a chave da nota, se não atribuirmos nada ao campo cNF o Monitor vai considerar ele como zero, isso faz com que um código aleatório seja gerado. Por outro lado se passamos um numero diferente de zero para o cNF, o Monitor vai utilizar esse numero para compor a chave. O que faz gerar o erro de Duplicidade com diferença na chave é exatamente a falta de controle desse numero atribuído a cNF. Se no arquivo ini da nota não tempos o campo cNF se mandarmos o monitor gerar a nota 10 vezes, teremos 10 notas cada uma com uma chave diferente. Por outro lado se passamos o valor de cNF no arquivo ini, podemos gerar quantas vezes desejarmos a nota, a chave sempre será a mesma. Tome muito cuidado, não inventa de atribuir a cNF o numero da nota ou seja o numero atribuído a nNF. Três motivos para não fazer isso: 1. A SEFAZ recomenta que o cNF seja um numero aleatório. 2. Uma nota cujo cNF é igual a nNF a chave se torna fraca, ou seja, passível de pessoas não autorizadas a ter acesso as informações da mesma. 3. O numero da nota (nNF ) é um numero com no máximo 9 dígitos, já o código da nota (cNF) é um numero com no máximo 8 dígitos, logo não tem como atribuir um numero de 9 dígitos a um campo que só aceita no máximo 8. Espero ter ajudado.

Bom dia Mendonça, Desculpe, não tinha notado que você se utiliza do ACBrMonitor, sendo assim favor aguardar uma nova versão.

Boa tarde Rafael, Esses arquivos você recebeu por e-mail? Pois estão muito estranhos, foi preciso editar para remover sujeiras.

Boa tarde Paulo, Muito obrigado pela colaboração, vou fazer a alteração e enviar para o repositório ainda hoje.

Rodrigo, No layout do XML do respectivo provedor não existi nenhuma tag chamada Estado, isso me faz a crer que a mensagem de erro se refira a tag Uf do prestador de serviço. Mas pelo que pude ver esta OK. Favor entrar em contato com o provedor e questioná-los sobre esse erro.

Boa tarde, Favor anexar o XML de pedido de cancelamento para que possamos analisar.

Boa tarde Rodrigo, Favor anexar o XML do RPS, pois o mesmo foi processado com falha.

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Pois segundo o arquivo INI do provedor ele possui os métodos Enviar, Consultar Lote e Cancelar implementados pelo provedor em seu Webservice.

Boa tarde Roger, Primeiro é preciso que seja feito um teste em todos os Estados que você tem cliente. Pois até onde sei até agora o Estado do Ceara não disponibilizou as URLs de Homologação e Produção da versão 4.00 da NFC-e

Boa tarde Walter, Favor postar qual é o comando (com os parâmetros) que esta usando para imprimir o DANFE.