Gr@c@

Tenho tido esse problema de consumo indevido (mas é raro) em um cliente de São Paulo. Percebi que ocorre quando, após enviar uma NFe, o usuário tenta consultar a NFe novamente pela chave de acesso Ou seja, quando ele consulta uma NFe logo após tê-la enviado e impresso o Danfe (isso num prazo menor que 5 minutos). Após orientar o cliente a evitar essa consulta em seguida (pois realmente não é necessário, já que ele tem o xml e o danfe gravados em disco), o erro parou de ocorrer. Parece que o SEFAZ de SP está achando q é um loop do sistema (enviar e consultar novamente) quando na verdade não é.

Liguei no plantão do SEFAZ/MG e me disseram que está funcional e que o erro está no meu aplicativo. Em todo caso, enviei email ao Fale Conosco de MG constando a chave de acesso da nota que cancelei. Assim que tiver o retorno, posto aqui.

Consigo consultar a NF-e no site de MG e o evento de cancelamento está lá com protocolo.

Não tem nada. Completamente vazio.

O conteudo do arquivo está ficando assim: A página XML não pode ser exibida Não é possível exibir a entrada XML usando a folha de estilos . Corrija o erro e clique no botão Atualizar ou tente novamente mais tarde. -------------------------------------------------------------------------------- O documento XML deve ter um elemento de nível superior. Erro ao processar o recurso 'file://servidor/f/DESENVOLVIMENTO/ATIV...

Estou em MG ambiente de homologação.

Colocando Library Path na ordem sugerida e compilando o PCN2 antes de dar build nos demais componentes, parece que deu certo.

Também estou com o mesmo erro de Access Violation ao consultar uma NFe que foi cancelada por evento

Ok, vou rever tudo.

Uma observação: pode ser que o erro não esteja na revisao 4310, pois eu estava ainda com a revisão 3896.

Quanto aos arquivos inc eu só tenho na pasta C:\Arquivos de Programas\Borland\Delphi7\Lib\ACBr\Fontes\ACBrComum Sempre que faço update do ACBr via SVN sigo esse processo: 1-Abro o Delphi7 2-Open em C:\Arquivos de programas\Borland\Delphi7\LIB\ACBr\Pacotes -Synapse.dpk -> build -ACBrCapicom.dpk -> build -ACBrOpenSSL.dpk -> build -ACBrComum.dpk -> build =====> aqui ocorreram os erros -ACBrDiversos.dpk -> build -ACBr_SPED.dpk -> build -ACBR_Serial.dpk -> build -ACBRNFe2\PCN2.dpk -> build -ACBRNFe2\ACBrNFe2.dpk -> build =====> aqui ocorreram os erros -ACBRNFe2\ACBrNFeDANFERV.dpk -> build =====> aqui ocorreram os erros -ACBRNFe2\ACBrCTe.dpk -> build =====> aqui ocorreram os erros -ACBRNFe2\ACBrCTeDACTeQRPkg.dpk -> build No caso, é melhor compilar o ACBRNFe2\PCN2.dpk antes de dar build nos demais componentes? Como seria a ordem correta de atualização dos componentes no meu Delphi7? E a ordem dentro da Library Path pode interferir em algo?

Não, somente o Delphi 7. E não instalei nenhum componente novo, ou seja, o meu Delphi 7 está exatamente como estava na ultima vez que fiz o update do ACBr. Será que o dpk não foi alterado em uma nova versão do Delphi? O problema é que agora não consigo compilar nenhum dos meus projetos, pois diz não encontrar os bpls dos componentes de NFe e CTe.

Pessoal, eu fiz o update hoje do componente e também estou tendo o mesmo erro do nosso colega centuryinf. Além disso, não consigo fazer o build do ACBrComum.dpk e em consequencia, tenho erro em todos os demais componentes (ACBrNFe,ACBrCTe). O que foi que mudou?

Este erro está ocorrendo ao dar build no ACBrComum.dpk e está intereferindo nos demais componentes do ACBr (ACBrNFe,ACBrCTe...) Fiz o update hoje(12/11/2012)

Bom dia Só uma confirmação por favor: o CT-e em Fortes Report está sendo atualizado como o CT-e em QuickReport?

A intenção aqui é fazer aplicativo para 32 e 64 bits, onde estaria incluso pelo menos NF-e, CT-e e SPED. A maioria dos micros agora vem com Windows7 64bits e já tivemos problemas com o aplicativo ECF + dll do fabricante. Lembra como foi rápida a transição do 16bits para 32bits e como as pessoas torciam o nariz para aplicativos 16bits?

Segue resposta do SEFAZ recebida em 04/10/2012 A legislação pertinente está disposta no Art. 96 da parte geral do RICMS/02, inciso XI, alíneas a, b e c, acessado através do link http://www.fazenda.gov.br/confaz/confaz ... 009_07.htm . Citamos ainda o Art. 58-B do CONVÊNIO/SINIEF 06/89 (link http://www.fazenda.gov.br/confaz/ ): Fica permitida a utilização de carta de correção, para regularização de erro ocorrido na emissão de documentos fiscais relativos à prestação de serviço de transporte, desde que o erro não esteja relacionado com: I - as variáveis que determinam o valor do imposto tais como: base de cálculo, alíquota, diferença de preço, quantidade, valor da prestação; II - a correção de dados cadastrais que implique mudança do emitente, tomador, remetente ou do destinatário; III - a data de emissão ou de saída. Conforme parecer da superintendência responsável, informamos que em Minas Gerais a Carta de Correção Eletrônica (CC-e) ainda não foi instituída para sanar erros em campos específicos do CT-e, somente da NF-e. Assim, a carta de correção em papel poderá ser utilizada para corrigir o CT-e nas situações previstas na legislação. Havendo dúvida sobre a aplicabilidade da Carta de Correção em situações específicas, sugerimos dirigir-se ao plantão fiscal da AF de sua circunscrição (endereços no link http://www.fazenda.mg.gov.br/secretaria/enderecos/ ) para obter esclarecimentos relativos ao seu caso, portando o documento a ser corrigido e um documento de identificação da sua responsabilidade legal perante a empresa e/ou a operação/prestação. Considerando somente o atendimento por e-mail que você acabou de receber, clique abaixo de acordo com sua opinião: Ótimo | Bom | Regular | Ruim Qualquer outra informação ou esclarecimento sobre dispositivos da legislação tributária, que não se revista das características e dos requisitos próprios de consulta (RPTA/MG, artigo 37, aprovada pelo Decreto nº 44.747 de 03 de março de 2008), será prestado verbalmente ao interessado pela Administração Fazendária do município de circunscrição do contribuinte, conforme disposto no art. 48 do diploma legal citado. *As dúvidas esclarecidas por esta mensagem têm caráter de orientação não gerando o efeito decorrente da consulta formal. Atenciosamente, FALE CONOSCO - SEF Diretoria de Gestão do Atendimento ao Público Superintendência de Arrecadação e Informações Fiscais Tel.: 155 para todo o Estado de Minas Gerais; (31) 3303-7995 para outros estados e países. ESTA É UMA MENSAGEM AUTOMÁTICA, POR FAVOR, NÃO RESPONDA ESTE E-MAIL. Contatos futuros http://www4.fazenda.mg.gov.br/faleconoscoservico/

Obrigada Elton. O Delphi Conference será dia 23/10 e seria bom se o pessoal que já tem o Delphi XE2 postasse aqui problemas ou mesmo dúvidas para levarmos no dia.

Obrigada Italo Enviei um email para o SEFAZ/MG mas até agora nenhum retorno, mas assim que tiver a resposta posto aqui.

Os componentes do ACBr já estão aptos para serem usados em Delphi 64 bits?

Alguns tomadores de serviço de MG estão exigindo carta de correção eletronica para CT-e. Esse evento já está disponivel para transportadoras de MG? Os schemas da cc-e não constam junto com os schemas de ct-e. Os schemas serão os mesmos usados para NF-e?

Nota Técnica 2012/005 Divulga novas Regras de Validação para Recepção de CT-e no Ambiente de Homologação Se Tipo do Ambiente for igual 2 (homologação) e existir remetente, o campo razão social (xNome) deve ser informado com a literal: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL” Se Tipo do Ambiente for igual 2 (homologação) e existir expedidor, o campo razão social (xNome) deve ser informado com a literal: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL” Se Tipo do Ambiente for igual 2 (homologação) e existir recebedor, o campo razão social (xNome) deve ser informado com a literal: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL” Se Tipo do Ambiente for igual 2 (homologação) e existir destinatario, o campo razão social (xNome) deve ser informado com a literal: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL”

Acho que o nosso colega quer é separar os arquivos de envio e retorno do arquivo xml final (*-nfe.xml) Eu também estou enfrentando esse tipo de problema. Em meu aplicativo coloquei para mover os arquivos para uma outra pasta, mas dependendo de como o Windows 7 foi instalado, em algumas máquinas ele não permite fazer isso. Então, na pasta fica tudo misturado: os arquivos xml válidos(*.-nfe.xml) e aqueles arquivos (tipo env-*.xml, *-sit.xml). Isso gera transtorno quando temos que enviar os arquivos para a contabilidade.

Pessoal, como será a solução correta dessa questão? Já estamos gerando mes 07 e ainda persiste o erro. As alterações feitas pelo nosso colega rvaccari não foram aprovadas?

O componente já atende os padrões de Uberlandia/MG?