Italo Giurizzato Junior

Boa tarde Mazuka, Verifique se o componente não esta configurado para a versão ve300. Se sim, tai o erro. Tem que configura para a versão ve310.

Boa tarde Azevedo, Qual é o motivo de gerar o TXT usando o ACBrNFe para depois ser importado pelo programa gratuito da SEFAZ e por fim ser emitido? Porque você não utiliza o ACBrNFe para tudo?

Boa tarde Cleiton, Na minha aplicação eu utilizo o RoundTo( valor, -2) isso faz com que o valor seja arredondado para 2 casas decimais. Nunca tive rejeição por diferença de centavos.

Boa tarde, O UltNSU do DistribuicaoDFe começou do zero portanto se você esta alterando de ConsNFeDest para DistribuicaoDFe deve começar do zero novamente e não utilizar o último NSU que você obteve ao usar pela ultima vez o ConsNFeDest.

Boa tarde Dércio, Te aconselho utilizar uma outra maquina para usar os fontes do Trunk2.

Boa tarde ALA, Essa história de reversão de cancelamento foi cogitada se não me falha a memória no grupo G19 entre as empresas piloto da NF-e assim que foi lançado a versão 2.00 da NF-e, isso por volta de 2010. Não houve um consenso entre as empresas, umas queriam e outras diziam que seria muito difícil gerenciar de forma eficiente essa possibilidade no sistema. Como você pode ver se passaram 5 anos e ainda nada foi resolvido. O que você tem que fazer agora é apresentar essa resposta da SEFAZ a este cliente que solicitou algo que não existe.

Boa tarde Filippe, Com certeza no texto da carta de correção esta sendo informado algum carácter invalido.

Boa tarde Rômulo, Desculpe pelo puxão de orelha, mas esse assunto já foi tratado no fórum e a resposta é: Não se deve alterar o XML da NF-e depois que a mesma recebe o protocolo de Autorização. Se a nota for cancelada devemos enviar ao destinatário o XML chamado *-procEventoNFe.xml este contem o pedido e o protocolo de cancelamento. Se você desejar imprimir novamente o DANFE com a tarja de cancelado basta atribuir o valor True a uma propriedade do DANFE chamada NFeCancelada.

Diego, Aparentemente o seu XML esta correto. A sua rotina acima que não concordo, pois se o tipo de emissão se não for normal o ambiente é homologação esta errado isso. Uma coisa é o ambiente ser de Homologação ou de Produção, outra coisa é o tipo de emissão ser Normal ou Contingência FSDA ou SVC-RS ou SVC-SP. Posso enviar um CT-e para o ambiente de homologação cujo tipo de emissão é normal sem nenhum problema e por outro lado posso enviar um CT-e para o ambiente de produção cujo tipo de emissão é SVC-SP. Com certeza antes do envio algo esta sendo alterado e ficando incompatível. As rotinas que alimentam o componente e de envio estão na mesma Unit? Se sim, você acrescentou em uses: pcnConversao e pcteConversaoCTe ?

Boa tarde Dimas, Você gera o XML salva em disco, depois carrega ele para poder assinar, validar e enviar, é isso? Se sim, porque você simplesmente alimenta o componente com os dados e manda assinar, validar, enviar ...?

Boa tarde André, Com toda certeza ele deve baixar através do site da SEFAZ, pois não existe no momento outra forma.

Boa tarde Diego, Post como anexo o XML que foi rejeitado.

Boa tarde Daniel, Isso se pegarmos os dados do XML mais a assinatura e protocolo e gerar novamente o XML, caso contrario não. Temos também outras situações, por exemplo a inutilização de numeração, onde temos 3 XMLs, o de envio, de retorno e de compartilhamento. O de envio não temos problemas, pois é executado o "TGerador.wCampo", mas o de retorno e o de compartilhamento que é apenas uma montagem dos dois anteriores não temos essa filtragem e consequentemente vai aparecer esses caracteres "inválidos".

Boa tarde Carlos, Muito obrigado pelo retorno. Descomentei o código o EnviarEmailEvento, por favor atualize novamente os fontes e realize novos testes. A mesma função foi implementada também no componente ACBrCTe e o código foi descomentado.

Bom dia Luciano, Não vejo problemas em incluir ela novamente.

Thiago, Desculpe o puxão de orelha, mas já foi dito em diversas postagens que o ACBrNFSe no Trunk2 não esta pronto, logo ele não vai funcionar.

Bom dia Diego, Esta errado o que você esta fazendo. A sua rotina esta checando a posição 35 da chave caso ela seja diferente "1" você esta configurando como homologação e isso não significa que o ambiente seja homologação. Posso enviar um CTe para o SVC em produção também.

Bom dia Fábio, Hoje fiz uma proposta de alteração visando exatamente isso. A propriedade XML contem apenas o XML assinado, a ideia é criar uma propriedade chamada XML_ProcCTe que vai conter o XML completo, ou seja, assinado e protocolado.

Bom dia Carlos, Foi eu que escrevi e comentei pois na maquina que fiz a implementação não tenho o trunk2 instalado, logo não tenho sequer condições de compilar para saber se existe erros de sintaxe. Por favor descomente e compile e utilize o EnviarEmailEvento. Fico no aguardo de um retorno.

Bom dia, Não, a propriedade Salvar de WebServices tem por finalidade fazer com que o componente salve ou não os arquivos de envio e de retorno com as TAGs de envelopamento, note que ao atribuir o valor True a essa propriedade começa a ser salvo arquivos com a palavra soap no nome.

Boa tarde Fabio, Vou lhe ficar devendo não conheço o Fast Report, por favor aguarde alguém que tenha conhecimento e possa fazer a correção e disponibilizar.

Boa tarde Luciano, Nos fontes do Trunk o componente trocava o cedilha por "C" e vogais acentuas por não acentuadas antes de salvar em disco. Nos fontes do Trunk2 não foi incluída a função que faz esse serviço nas rotinas que obtêm o retorno da SEFAZ.

Boa tarde Dalpiaze, A sua preocupação é valida, mas até hoje foram rara as vezes que a SEFAZ fez uma alteração no tamanho de uma TAG. Precisamos passar um pente fino no código a fim de garantir que o XML esteja pronto e disponível uma determinada propriedade independente se o mesmo será salvo em disco ou não. Se você analisar as Units ACBrNFeWebServices, ACBrCTeWebServies e ACBrMDFeWebServices vai notar que existem muitas semelhanças em varias procedures e functions. Vamos focar em apenas um deles até conseguir um resultado confiável, ai sim vamos aplicar a mesma solução nos demais.

Boa tarde Serginho, Pelo que me recordo o componente não se utiliza do relógio da maquina. Você quem deve informar a data / hora. Você pode utilizar a função Now do Delphi para pegar a informação e depois adicionar ou diminuir a quantidade de horas desejada.

ALA, As funcionalidades implementadas nos componentes são baseadas em Manuais e Notas Técnicas publicadas pelo ENCAT / SEFAZ. Nunca vi nada sobre: reverter o cancelamento de uma nota. No seu primeiro poste você afirma que: "Existe uma opção na receita chamada 'Reversão de Nota fiscal cancelada', ...." Post em anexo o documento que trata sobre esse assunto ou o link.