Italo Giurizzato Junior

Boa tarde ALA, Qual é o problema da sua aplicação gerar um código aleatório e armazena-lo juntamente com os demais dados da nota? Na rotina que lê as informações do banco de dados e passa para o componente, tem uma linha que lê numero da nota da tabela e passar para nNF, correto? Qual seria a dificuldade de ler o código que obviamente estar armazenado em outro campo e atribuir a cNF?

Boa tarde Josafar, Por favor leia essa noticia: Código Numérico inválido, Chave não Gerada Ela trata sobre a NT, inclusive tem a função que gera o código aleatoriamente conforme a SEFAZ sempre exigiu.

Boa tarde, Como essa questão de imprimir o QR-Code no DANFSE é uma ou outra cidade que tem, não foi implementado. No meu entendimento deveria ser feito um DANFSE especifico com o QR-Code, pois não podemos colocar no padrão, pois por padrão não existe o QR-Code no DANFSE.

Boa tarde Professor, Não existe uma sequencia correta. Provedores que seguem a versão 1 do layout da ABRASF só disponibiliza o serviço de envio de lote no modo assíncrono: botão [Enviar Lote RPS (Enviar)] Já os provedores que seguem a versão 2 do layout da ABRASF a principio disponibilizam os 3 tipos de serviços: envio de lote no modo assíncrono: botão [Enviar Lote RPS (Enviar)], o envio de lote no modo síncrono: botão [Enviar Lote RPS (EnviarSíncrono)] e o GerarNFSe: botão [Enviar um RPS (Gerar)]. O botão [Gerar Lote RPS] apenas gera o lote e salva em disco, não faz mais nada. Pode ser utilizado para os provedores que não tem webservice, neste caso o componente gera o lote de RPS e através do site do provedor você importa o mesmo. Para os provedores que não seguem a ABRASF, a dica é abrir o arquivo INI do mesmo e ver quais são os serviços oferecidos.

Boa tarde Daniel, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Esse XML que você anexou é do RPS. O DANFSE foi feito para imprimir os dados do XML da NFS-e e não do RPS.

Boa tarde Rodrigo, Muito obrigado pela colaboração, ainda hoje vou enviar para o repositório.

Boa tarde Luiz, No meu entendimento você pode sim gerar o BP-e em Contingência com série diferente se tratando do embarcado.

Diogo, Neste caso o que tudo indica é que o webservice responsável por gerar o XML de retorno referente a consulta a situação de uma nota não esta levando ainda em consideração a existência desse novo tipo de evento. Resumindo o problema é na SEFAZ.

Bom dia Alberto, Os schemas da NF-e estão na mesma pasta dos Schemas do CT-e? Os Schemas referente ao DistribuicaoDFe tem o mesmo nome, ou seja, não tem nada que diz que um é da NF-e e outro é do CT-e. O grande problema é com relação a versão, que no caso da NF-e a versão é 1.01 e do CT-e é 1.00 No que ao gerar o XML de DistribuicaoDFe (de envio) esta aparecendo a versão 1.01, logo no retorno diz que a versão esta errada. Para esta aparecendo essa versão na pasta que deveria ter somente os Schemas do CT-e tem também os da NF-e, ou foi trocado somente o schema do DistribuicaoDFe do CT-e pelo da NF-e.

Bom dia Diego, No que se refere ao CT-e consta somente o mês e ano, não consta o dia. Por outro lado no caso do MDF-e que também só constava o mês e ano, agora temos a informação completa. Leia essa noticia: MDF-e versão 3.00a

Diogo, Abra esses 2 XML e compare as datas. No XML refere ao evento note que o evento foi registrado e vinculado em: <dhRegEvento>2019-06-18T08:41:13-03:00</dhRegEvento>, ou seja, no dia 18/06/2019 as 08:41:13 No XML refere a consulta temos: <dhRecbto>2019-06-18T08:41:50-03:00</dhRecbto>, ou seja, no dia 18/06/2019 as 08:41:50 A diferença é questão de segundos, o que pode ter ocorrido é que ao realizar a consulta o serviço de consulta ainda não tinha a informação do cancelamento.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Wesley, Essa linha se encontra em qual Unit?

Bom dia Diogo, Toda nota para ser cancelada primeiro precisa ser autorizada. Logo é normal ao consultar uma nota a SEFAZ retornar que a mesma esta autorizada. No XML de retorno da consulta costuma constar a situação da nota, ou seja, autorizada e caso ela tenha eventos vinculados a ela é retornado também a lista de eventos. Verifique se no XML consta além da informação que ela esta autorizada o evento de cancelamento.

Boa noite Edson, Essa alteração foi sim para o repositório. A sua unit não nenhuma outra alteração, pois as vezes o Tortoise não atualiza a unit caso ela tenha alguma alteração. Renomeia a sua unit e baixe novamente os fontes.

Boa noite Ailton, Por favor leia essa noticia: Código numerico invalido, chave não gerada.

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Boa tarde Joveci, Abra esse XML usando um navegador. Note que foram ADD 4 notas, sendo que a primeira não foi informado a chave. No grupo <tot> a quantidade de notas é 3, logo a nota cuja chave esta em branco não deveria existir.

Boa tarde Diego, Já baixei os Manuais e os Schemas. No Portal por enquanto só foram estabelecidos as datas do MDF-e, do CT-e pelo que me consta ainda não.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Zanutto, Favor anexar o XML que esta ocorrendo erro de validação.

Boa tarde Antônio, Muito obrigado pela correção, já enviei para o repositório.

Anexa o XML para que possamos analisar.

Boa tarde Alberto, Favor anexar os XMLs gerados para que possamos analisar.