Italo Giurizzato Junior

Boa tarde, Você gera o XML e assina com um numero de nota provisório e submete ao validador do componente para saber se os dados estão corretos ou não. Se ocorrer erro na validação o usuário não vai ter que efetuar a correção? Com certeza que sim, então porque você não atribui o numero correto da nota de uma vez? Lembre-se que o numero da nota, ou seja, o campo nNF é usado para compor a chave da NF-e e seu conteúdo é usado para calcular o DisgestValue da assinatura. Eu compreendo o que você fez, o usuário lança varias possíveis vendas e a medida que elas vão se concretizando emiti-se a nota e a numeração tem que ser sequencial. Muito bem, em vez do usuário lançar uma venda, ele lançaria um orçamento que possui uma numeração sequencial, caso este se concretize é gerado a nota com a sua numeração própria. No meu entendimento no que diz respeito a validação esta tem que ser feita na entrada dos dados. Se você validar cada informação digitada as chances do validador do componente acusar algum erro é quase zero.

Boa tarde Diego, Você esta usando os fontes do Trunk ou Trunk2? De qual quer forma, favor olhar a rotina do botão enviar email que lá você o método e seus respectivos parâmetros. Resumindo o método EnviarEmail possui um parâmetro para fazer com que o componente gere o PDF e anexe junto ao XML para ser enviado por e-mail. Agora se você deseja gerar antes de enviar existe o método ImprimirPDF que pode ser executado após o Enviar.

Boa tarde Paulo, Eu em particular acesso os Portais Nacionais da NF-e, CT-e e MDF-e duas vezes ao dia, as 7 da manhã e as 13:30 da tarde, para saber sobre a disponibilidade dos serviços, checar se existem novos Schemas, Manuais e Notas Técnicas. Caso exista eu baixo e leio para saber do que se trata. Se é algo novo, ou seja, uma TAG nova no XML, verifico a possibilidade de implementar sem que ocorra nenhum problema. Para você ter ideia existem varias coisas implementadas nos componentes só aguardando a liberação por parte da SEFAZ. Tudo o que consta nessa NT já foi implementado. Estamos aguardando a liberação do ambiente de homologação para iniciarmos os testes.

Boa tarde icozeira, No momento estou sem ideias e como aqui na empresa ainda utilizo os fontes do Trunk fica difícil rastrear o código do Trunk2. Em casa tenho o Trunk2 instalado, lhe peço um pouco mais de paciência, a noite vou tentar descobrir o que pode esta ocasionando esse erro. Se não me falha a memória o erro 400 significa que o XML não foi gerado de forma correta, o problema pode ser caracteres especiais como por exemplo: &

Bom dia a todos, Não seria o caso de colocar no Library Path do Delphi a pasta que contem as BPL do Fortes?

Bom dia, Inclusive o arquivo INI do provedor? Lembre-se que agora é o arquivo INI do provedor que contem algumas informações para que o componente possa gerar de forma correta o XML a ser enviado para o provedor.

Bom dia Pedro, Acrescentando o que o Juliomar disse: Se você ainda utiliza os fontes do Trunk deve o mais rapido possível migrar para o Trunk2, pois apartir de novembro/2015 as NFC-e emitidas pelo ACBrNFe que esta no Trunk serão rejeitadas pela SEFAZ, pelo simples fato do XML gerado por esse componente estar em desacordo com a nova estrutura do XML. Por outro lado o ACBrNFe que encontra-se no Trunk2 já esta em conformidade com a nova estrutura, logo será aceito pela SEFAZ. Ao migrar para o Trunk2, no que diz respeito ao DANFE para NF-e você terá disponível somente o Fast e Fortes Report, mas nada impeça que você faça as devidas alterações nos fontes do DANFE feito em Rave para funcionar com o ACBrNFe do Trunk2. Mas respondendo a sua pergunta você não vai poder utilizar o mesmo DANFE tamanho A4 que é usado para a NF-e para imprimir o DANFE da NFC-e, pelo simples fato de que esse DANFE não imprime o QR-Code. O DANFE NFC-e não tem a barra de código que representa a chave, mas por outro lado possui a imagem do QR-Code. Espero ter esclarecido as suas duvidas.

Bom dia a todos, Marcio, o componente gera sim a URL do QR-Code conforme consta no manual do DANFE NFC-e, manual este que contem toda a especificação de como deve ser gerado a URL. No que diz respeito a validação da URL por parte da SEFAZ, é que a URL vai constar no XML da NFC-e. Daniel, você lembra das linhas comentadas no método Assinar que são responsáveis por incluir a URL do QR-Code no XML da NFC-e? O QR-Code a principio era gerado e impresso no DANFE da NFC-e, agora alem disso o XML da NFC-e vai passar a ter essa URL. Já temos os novos Schemas que vão fazer uma validação primaria dessa URL e a SEFAZ por sua vez ao receber o XML vai fazer a sua validação que por sinal é mais completa, ou seja, não vai apenas validar se existem os campos que compõe a URL e sim o valor de cada campo. Marcio, em resumo o componente esta preparado para atender as alterações publicadas na NT 2015/001. Volto a lembrar que devemos iniciar os testes em 01/10/2015 para que no dia 03/11/2015 os XMLs das NFC-e já sejam enviados conforme a NT em ambiente de produção.

Bom dia rlind, Se você se refere aos fontes do Trunk a resposta é não. Agora se você esta usando os fontes do Trunk2 a resposta é sim.

Bom dia Leão, Verifique se na sua rotina que alimenta o componente se existe alguma linha onde é atribuído algum valor a propriedade Id. Se sim exclua essa linha, não se deve atribuir nada a propriedade Id, tem que deixar o próprio componente calcular o valor dela.

Luiz, Ao calcular o Digest Value todos os campos são levados em consideração, eu apenas sitei um exemplo.

Bom dia a todos, Luis, no que diz respeito aos novos endereços publicado pela SEFAZ-RS, eu mesmo alterei tanto os fontes do Trunk quando do Trunk2. Essa alteração ocorreu em 01/05/2015, se você tem o abito de atualizar os seus fontes diariamente, as suas aplicações já estão enviando para os novos endereços a 4 meses. Sendo assim se você possui uma aplicação usando os fontes do Trunk ela não vai parar em 01/10/2015 em função dos novos endereços. Mas poderá parar depois dessa data em virtude de novas TAGs que a SEFAZ acrescentou ao XML. Os fontes do Trunk2 já estão preparados para atender essas novas TAGs, por outro lado os fontes do Trunk não estão. Reforço o que o Juliomar já disse, migre o mais rápido possível para o Trunk2.

Luiz, Se você esta alimentando novamente o componente com os dados para poder gerar o XML e assinar através do Validar até ai sem nenhum problema. A questão é se no cadastro de remetente/destinatário foi alterado algum dado, já é o suficiente para que o calculo do Digest Value seja diferente. Por exemplo, no cadastros tinha a seguinte informação: Campo Endereço: Rua Nove de Julho, 540 Campo Numero: <vazio> foi alterado para: Campo Endereço: Rua Nove de Julho Campo Numero: 540 Note que a virgula e o espaço em branco que existia entre o nome do logradouro e numero agora não existe mais, isso já é o suficiente para que o Digest Value seja diferente.

Bom dia Igor, Verifique se você não esta atribuindo o valor 2.00 a propriedade Versao ao alimentar o componente. Algo do tipo: infMDFe.Versao := 2.00; Se sim, exclua essa linha.

Bom dia Rodrigo, Primeiramente é preciso ler com muita atenção a Emenda Constitucional 87 de 2015 uma vez que essa NT visa atender a mesma. Segundo é sempre bom consultar um bom contador.

Bom dia Marcelo, Procure manter os seus fontes atualizados diariamente, pois as vezes a correia é tanta que acabamos não comunicando as pessoas que foi disponibilizado uma alteração. Por favor atualize os fontes e teste novamente.

Bom dia Luciano, Qual é o Report que você esta utilizando para imprimir o DANFSE? A principio se esta aparecendo essa mensagem é porque ela foi gerada pelo provedor e retornada no XML da NFS-e, ou o Report que você esta usando esta imprimindo esse texto, sendo que não deveria.

Bom dia, Isso foi discutido muito e chegamos a conclusão que todos os XMLs referentes a eventos devem ser agrupados na pasta Evento e dentro desta os mesmos são separados em sub-pastas, uma para cada tipo de evento. Exemplo: ...\Evento\CCe <== dentro desta pasta ficam os XMLs referentes aos eventos de CC-e ...\Evento\Cancelamento <== dentro desta pasta ficam os de Cancelamento

Bom dia Luiz, Esse erro só ocorre quando o XML é alterado. O XML pode ser alterado pelo próprio usuário ou pelo componente, coisa que não deveria ocorrer. Faça o seguinte teste, ao carregar o XML atribua o valor False ao segundo parâmentro do LoadFromFile, exemplo: LoadFromFile(<nomearqXML>, False); Esse segundo parâmetro diz ao método que não deve ser gerado o XML novamente.

Bom dia Matheus, É estranho essa rejeição, uma vez que o XML de pedido de consulta esta exatamente igual ao definido na Nota Técnica. Só resta fazer um último teste. Alterar o schema tirando o acento da palavra NÃO e fazer o mesmo na Unit do componente. Desta forma o XML será gerado sem o acento, será validado pois no schema também foi retirado o acento. Se a SEFAZ aceitar isso significa que a Nota Técnica esta errada e o schema também, ou eles acertaram o Web Services e esqueceram de disponibilizar um novo schema e uma NT informando a alteração. Se desejar fazer essas alterações e testar: Unit do componente: pmdfeConsMDFeNaoEnc.pas (...\Fontes\ACBrDFe\ACBrMDFe\PCNMDFe) Schema: consMDFeNaoEncTiposBasico_v1.00 (...\Exemplos\ACBrDFe\ACBrMDFe\Schemas) No schema devemos alterar a linha: <xs:element name="xServ" type="TServ" fixed="CONSULTAR NÃO ENCERRADOS"> Tirar o acento da vogal. Depois dessas alterações não esqueça de compilar a aplicação com a opção Build.

Bom dia Sergio, Dentro da pasta Exemplos existe uma pasta chamada ACBrTEFD.

Bom dia, A minha aplicação permite que o usuário lance diversas notas e depois escolhe a que deseja enviar para a SEFAZ. Quando os dados da nota vão ser gravados no banco de dados o cNF (código da NF conforme manual deve ser um numero aleatório) é gerado e salvo no banco de dados também. Quando o usuário seleciona a nota para Emitir (enviar para SEFAZ) é executado uma rotina que lê os dados do banco de dados e alimenta o componente e é nessa rotina que tenho a seguinte linha: Ide.cNF := DM_VEN.NotasNFChave.AsInteger; O campo NFChave da Tabela Notas é o que contem o numero aleatório gerado no momento da gravação da nota no banco de dados. Depois de alimentar o componente mando executar os métodos Assinar, Validar e Enviar. O Assinar se encarrega de gerar o XML e assinar o mesmo. Desta forma nunca tive problema com rejeição de assinatura diferente do calculado.

Bom dia a todos, No caso da NFS-e até onde sei não existe nenhuma versão nova do XML com uma TAG especifica para informar o Valor Aproximado dos Tributos. Sendo assim, você deve calcular o valor e informa-lo no campo Discriminação do serviço.

Bom dia, Por favor atualize novamente todos os fontes de todas as pastas e teste novamente.

Boa tarde Sergio, Você esta instalando os componentes do Trunk2, muito bem, só tem um problema, não selecione o ACBrGNRE pois este ainda não esta pronto. O ACBrNFSe pode até compilar e instalar mas ainda não esta funcionando, pois existem alguns problemas que precisam ser resolvidos.