Gr@c@

vc tem que verificar no site da administradora do cartão se tem nova cadeia de certificado para instalar

Juazeiro é a cidade de destino do seu manifesto? Existe alguma nota fiscal cujo destinatário seja de Juazeiro?

o link que você disponibilizou requer senha e no portal do MDF-e ainda não foi divulgado. segue o link do Ato Cotepe no CONFAZ http://www.confaz.fazenda.gov.br/legislacao/atos/atos_cotepe/2015/ac005_15 segue o link do Manual do MDF-e Ato Cotepe no CONFAZ (porém, até o momento, ainda não foi disponibilizado nenhum manual MDF-e) www.confaz.fazenda.gov.br/legislacao/manuais Melhor aguardar a publicação do mesmo no portal do MDF-e

{identificador de local de destino da operação } {1-operacao interna TpcnDestinoOperacao = doInterna } {2-Operacao interestadual TpcnDestinoOperacao = doInterestadual } {3-Operação com exterior TpcnDestinoOperacao = doExterior } ao que parece você está setando <idDest> = 1 quando deveria ser 2 - operação interestadual (UF emitentee destinatário são diferentes)

Esse é o jeito que faço, conforme orientação do contabilista. Se você colocar finalidade de devolução para cfop 5949/6949 haverá rejeição 'cfop não pode ser com finalidade devolução'. Acho que não seria obrigatório referenciar a nota. Só referencio porque os fornecedores exigem para controle da garantia. E também coloco na natureza da operação: GARANTIA

NF-e normal, com finalidade normal(não é devolução). Por ser nota de garantia, os próprios fornecedoresexigem que se referencie a chave de acesso da nota de compra.

se for de SP, tem q verificar se tem cadastro no CADESP. E também consultar no Sintegra do estado do destinatário para ver se a inscrição realmente confere com o CNPJ.

Pessoal, já existe tópico antigo e exclusivo para NFe3, onde vocês poderão sanar todas as dúvidas sobre a migração da NFe2 para 3.10. Esse local é para assuntos ref a CT-e.

Alteração com pouquíssimo prazo hábil para desenvolvimento, testes e atualização nos clientes. Dessa vez o SEFAZ se superou.

Você precisa checar se o emitente está liberado para emitir notas em produção. Geralmente, a liberação após o credeciamento inicial é somente para homologação.

25/03/2015 - Atenção: Publicada a versão 1.22 da Nota Técnica NF-e 2013/005, com as novidades abaixo. Alteração em regra de validação: Em função de questionamentos feitos pelas empresas com respeito ao alcance dos efeitos jurídicos de incluir o valor da desoneração de ICMS no valor total da nota, nos termos comandados pelo Ajuste SINIEF 10, de 28 de setembro de 2012, foi alterada a regra de validação W16-10, de forma que, quando o campo vICMSDeson for utilizado, serão aceitas notas tanto no caso de que o valor correspondente à desoneração tenha sido incluído no valor total da nota, quanto quando não tiver sido incluído. Orientação para impressão de DANFE: O conteúdo do campo vICMSDeson, enquanto não for previsto no leiaute do DANFE, deverá ser copiado no campo de Informações Complementares de Interesse do Contribuinte (infCpl) para que a informação conste impressa no DANFE. Caso seja necessária sua impressão no DANFE, outros campos que não forem previstos no leiaute também poderão ser copiados no campo de Informações Complementares de Interesse do Contribuinte (infCpl). Link para a Nota Técnica NF-e 2013/005 v1.22 Assinado por: Coordenação Técnica do ENCAT

Acabei de consultar e está ok. Qual mensagem de erro está retornando para você?

Isaque você perguntou "Graça por você usa "ACBrNFe1.WebServices.Envia" e não "ACBrNFe1.Enviar" ?" Boa pergunta. Lembro que foi orientação de alguém aqui no fórum. Mas vou verificar isso. Mas, com relação a configuração do componente, qual seria a forma mais correta e segura de configurar essas propriedades para evitar o mínimo de erro possível, como esse de não gravar o protocolo? Eu nunca tive problema com envio de nf-e (tirando os problemas do SEFAZ/MG). Os problemas começaram a ocorrer com a versão 3.10 Essa propriedade abaixo confesso que ainda não entendi a finalidade: ACBr1.Configuracoes.Arquivos.Salvar = Se True salva os arquivos XML referente a documentos ou seja serásalvo algum arquivo (xml referente a documentos?) Obrigada pelas orientações.

Fiz uma alteração no meu aplicativo e deu certo. Vejam: No componente ACBrNFe1 existem essas 2 propriedades que, por padrão no componente, são = FALSE. ACBrNFe1.Configuracoes.Arquivos.Salvar ACBrNFe1.Configuracoes.Geral.Salvar Na versão 2.00 eu setava apenas a ACBrNFe1.Configuracoes.Geral.Salvar = TRUE e tudo funcionava corretamente. A outra propriedade está como FALSE direto no componente. Nessa versão 2.00 o xml fica correto com cSTAT = 100 e protocolo Na versão 3.00 mantive a mesma coisa da versão 2.00 porque já que funcionava, passou despercebido. Agora, alterei as 2 propriedades setando para TRUE ACBrNFe1.Configuracoes.Arquivos.Salvar := TRUE ACBrNFe1.Configuracoes.Geral.Salvar := TRUE Enviei uma NFe e o xml ficou correto com cstat = 100 e protocolo Gostaria de saber a diferença entre essas 2 propriedades. No manual do ACBrNFe diz que ACBrNFe1.Configuracoes.Arquivos.Salvar = Se True salva os arquivos XML referente a documentos. ACBrNFe1.Configuracoes.Geral.Salvar = Se True salva os arquivos de envio e retorno da SEFAZ

Tiago Ravache, postei parte do código de envio no arquivo em anexo (tem alguns comentários para faciliar o processo) processoNFe.txt

Ambiente - 1(produção) e 2(homologação) Emitente - MG Schemas atualizados Versao do ACBr atualizada em 20/03/2015 Aplicativo com build e compilado em 20/03/2015 Com a versão 3.10 está ocorrendo algo estranho (em todas as notas enviadas na nova versão, seja em produção ou homologação. Seja em clientes como com a minha empresa também, então descarto a possibilidade de internet, Windows, schema errado): 1-Envio uma NF-e 2-a NF-e é autorizada 3-O Danfe é impresso com chave de acesso e protocolo de autorização 4-Salvo os dados de retorno no banco de dados corretamente 5-Salvo o xml no meu banco de dados e ele fica correto (cstat = 100) 6-o xml e o pdf são enviados por email corretamente (cstat = 100) Mas quando vou olhar o xml na pasta que foi salvo, o xml consta sem protocolo (atag do protocolo está = <ID> e com rejeição 217-NFe não consta na base do sefaz Só que o meu aplicativo não faz nenhuma nova consulta após imprimir e salvar os dados no meu banco de dados (que ficam 100% corretos). Então não sei porque o xml está ficando sem protocolo no final de um processo de autorização. Suponho queo componente ACBrNFe é que esteja realizando essa consulta e tornando o meu xml inválido. Comparando o xml salvo em uma tabela do sql ele está com cstat=100 autorizado. Depois desse salvamento, não faço mais nenhum procedimento no aplicativo. (consultando a nota no portal ela está autorizada com protocolo de autorização) Alguma sugestão?

Também estou com esse mesmo problema na versão 3.10. A nota é enviada, autorizada, imprime com chave de acesso e protocolo de autorização. Porém ao consultar logo após o imprimir para pegar os dados para salvar no banco de dados, retorna 217-NFe não consta na base do sefaz (não me retorna numero de protocolo). Se eu consultar a nota depois de algum tempo, retorna tudo correto. Verifiquei que essas notas tem uma diferença entre horário de recebimento no SEFAZ da UF (no caso MG) e horário de sincromismo com o ambiente nacional (o ambiente nacional está menor em alguns segundos com relação ao ambiente da UF autorizada).

Resolvido na subversion 8596 19/03/2015 Italo, todas as funções testadas com sucesso: -Consulta Status do serviço MDF-e -Envio MDF-e -Consulta MDF-e -Impressão do DAMDFe -Encerramento de MDF-e -Cancelamento de MDF-e -Consulta de MDF-e não encerradas Obs: não foi preciso alterar o ACBr.inc, foi suficiente atualizar e compilar os componentes pelo ACBrInstall.exe, dar build e compilar o projeto. Obrigada Italo

Italo, comentando a linha do UTF funcionou a consulta do status de serviço. A consulta MDF-e encerrados também funcionou com a linha comentada. Essa alteração vai para o SVN valendo para todos ou somente quem tiver problemas deve comentar a linha nos fontes?

Tem um post sobre esse erro do Bad Request no MDF-e mas não foi postada a solução. Fiz tudo o que seria necessário para evitar o erro: -configurações do IE relacionadas a revogação do certificado -firewall do Windows desativado tanto é que a versão anterior do meu aplicativo está funcionando (os schemas são os mesmos desse aplicativo que deixou de funcionar após atualização de ontem e hoje do acbr)

Após descomentar no ACBr.inc a linha que você pediu: BAD REQUEST 400 A cópia do meu ACBr.inc da compilação do dia 10/03 está com a linha comentada (não está na mesma máquina, o backup fica em um pendrive) .

Ítalo, o problema realmente não é no SEFAZ. Mas fiz a alteração que você pediu e também não deu certo. Nada no aplicativo está funcionando, nem mesmo o Status do Serviço. Testei um aplicativo meu compilado em 10/03/2015 e funcionou tudo. Deve ser alguma outra alteração que foi feita no ACBrMDFe. Precisamos ver se alguém que esteja com a versão atualizada do componente está conseguindo realizar as operações em homologação e produção (a produção também não está funcionando com o aplicativo compilado ontem). Tem um detalhe: como tive todo aquele problema de atualização via SVN e tive que instalar o ACBr do zero, pode ser que tenha alguma configuração que eu tenha que fazer nos fontes(mas não me recordo agora). Isso está ocorrendo apenas com o MDF-e. Compilei o aplicativo emissor de ct-e e ele está funcional. No meu backup do ACBr não consta nenhuma unit com o ícone vermelho (todos estão com o ícone de checado verde). Não encontrei nenhuma alteração. Coloquei em outra pasta o aplicativo compilado em 10/03/2015(que funciona), compilei com a nova versão do ACBrMDFe (update feito ontem) e o programa deixou de funcionar, passando a dar o erro de Requisição não enviada. Acabei de atualizar os componentes ACBr (atualização e compilação via ACBrInstall.exe com sucesso). Recompilei meu aplicativo e ainda está dando o mesmo erro de Requisição não enviada. O anterior de 10/03 está funcionando.

Ítalo, desde ontem não estou conseguindo consultar os MDF-e Não Encerrados. Está dando erro Inativo ou inoperante Requisição não enviada 0-A operação foi concluída com êxito Testei das duas formas para ter certeza de que o erro não era devido a alteraçãofeita no componente. ACBrMDFe1.Configuracoes.Geral.RetirarAcentos := False; ACBrMDFe1.Configuracoes.Geral.RetirarAcentos := True; O serviço deve estar indisponível. Assim que conseguir posto o resultado. Obs: consultei através do portal MDF-e no ambiente de produção e o serviço está disponível. Mas pelo endereço de homologação também não consegui consultar.

A solução realmente foi apagar a pasta ACBr, fazer checkout e reinstalar do zero. Mesmo deletando a pasta ACBr e restaurando o meu backup não foi possível corrigir o erro. Somente com o checkout mesmo.

A unit uPrincipal.pas que o componente está trazendo vem com lixo. A unit da versão anterior está correta. Deletei a pasta ACBrInstall e fiz o update e esta unit vem sempre com lixo. A unit uFrameList.pas que está nessa mesma pasta, vem correta. àyÇ ¸çˆ~ ÀH 3× zÇ ¨ñ\†| ÀH „× `zÇ ¸çˆy ÀH )¡× à¡m ¨ñ\†Õ ÀH ˆ§× à¢m ¸çˆä’ ÀH