Painel de líderes

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.

Visulizar Arquivo Consulta SAT - WebService Este aplicativo utiliza o Componente ACBrSATWS do Projeto ACBr, permite realizar consultas em lote de CFe transmitidos via SAT para SEFAZ SP. Este componente utiliza recursos do WebService disponibilizado pela SEFAZ, pode ser útil para recuperar XMLs de CFe de um determinado período. Autor José M. S. Junior Enviado 18-06-2019 Categoria Utilitários - PRO  

Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf

Veja como está carregando o XML para o componente NotasFiscais.LoadFromFile(<xml>, True) <--- com True pode dar o erro Experimente colocar NotasFiscais.LoadFromFile(xml) que já passa False como parâmetro

Pessoal boa tarde O @Rafael Dias, desenvolveu uma classe e demo da lib acima para HARBOUR, a qual estou testando e fazendo ajustes para xHARBOUR, o empenho que ele dispôs nesse projeto, é algo imensurável em termos de dedicação e conhecimento. Com isso, acredito que esta classe , deva alavancar a adesão e migração de muitos assinantes FREE para SAC, pois o uso da DLL, trará muitas vantagens para todos, com maior controle dos seus aplicativos, sombreamento de suas aplicações e quiçá , independência em relação ao MONITOR, sem contar a economia, da não necessidade de assinaturas de DLL's de terceiros por CNPJ. Logo devo repassar ao Rafael os testes e os ajustes que fiz, a fim de atender também ao xHARBOUR, que passará pelo crivo dos seus conhecimentos para análise e demais ajustes que se fizerem necessários. Estarei envolvendo usuários em geral dos grupos/fóruns de HARBOUR, xHARBOUR e FIVEWIN, assinantes ou não do ACBR no intuito da difusão desta facilidade e de agregar colaboradores. Obs: Está a caminho as demais classes de HARBOUR/xHARBOUR para ACBREMAIL, NFE e etc...

Bom dia @ALA A questão deste procedimento é justamente garantir uma segurança maior a informação gerada. Já ocorreram muitas fraudes devido a este erro. Só que quando acontecem todos gritam e ninguém quer assumir a responsabilidade. Inclusive já culparam até a SEFAZ dizendo que os servidores da SEFAZ foram invadidos, outros disseram que os servidores de email foram invadidos e por ai se vai a imaginação fértil do povo. (Inclusive há vídeos aonde a SEFAZ explica a situação. Isto já é antigo, mas muitos tem dificuldades de entender o risco e ficam insistindo, até então que a SEFAZ se posiciona criando a rejeição. Se você ver os números não permitidos vai perceber que eles tentaram imaginar o que alguns colocariam e não duvido que se tivessem acesso ao teu texto antes tentassem bloquear códigos de possíveis composição de data Mas tirando a brincadeira de lado o caso é sério. Muitas empresas foram fraudadas, (como está citado nos links acima, que nossos colegas postaram sobre boletos falsos), pois já tiveram casos de que com posse da chave da nota, acessam o portal nacional e com informação de uma nota por exemplo a crédito (duplicatas, boletos) enviaram no do email do cliente (que está no xml) um novo boleto oferecendo descontos vantajosos se o pagamento fosse antecipado, algo assim e no boleto ou no email informavam dados da nota, data e as vezes até produtos fazendo com que isto desse credibilidade ao golpe. Muitos por sua vez vê a vantagem, nem se importam com o email recebido e pagam, depois a empresa não recebeu e as vezes acionam na justiça o cliente que terá que pagar novamente a dívida. Isto é muito sério e no google está cheio de relatos assim. Aqui no forum, há um relato de alguém que diz que o fraudador chegou a ligar para eles (empresa que desenvolve) e por telefone ia falando as notas que estavam sendo emitidas, os produtos e valores e ainda oferecendo serviço de proteção contra esta "fragilidade de segurança" e o rapaz da software house, pensando em vulnerabilidade do servidor de empresa, firewall, invasão de email etc, sendo que o fraudulento apenas tinha condição de criar as chaves (como ele criaria) e consultar na sefaz. Simples assim. Então não brinque com isto, se alguém pegar duas notas suas e entender que você usa a data para compor o código aleatorio (cNF) ficará o mesmo caso de usar o numero da nota para cNF, ou seja não resolve nada. Todos que sabem como se compõe uma chave logo conseguirá compor a proxima. O cara faz uma tentativa de um novo número com a mesma data, digamos que deu não encontrada ele acrescenta a próxima data e vai na tentativa novamente até dar o próximo erro, sendo necessário outra vez acrescentar a nota data. Quanto aos teus questionamento: - Sim seria bom vc gerar um número aleatório e guardar no banco de dados. (este é o ideal) - Quando vc diz "Nunca mais consigo gerar a chave". Em ultimo caso, se você tentar enviar novamente o mesmo numero de nota com chave diferente ele vai te retornar a informação de duplicação e vem o retorno da chave que está registrada na sefaz. E isto só é possível com o uso do certificado e emitindo a nota, logo outros não saberão, mas o emitente tem sim a condição de saber, não estará perdido para sempre - Porém se mesmo assim você tem pouco domínio em gerar um código randômico e grava-lo no banco, você pode criar uma rotina sua para gerar este código aonde só você saiba como ele é composto. Exemplo: 2 ultimos dígitos do cpf/cnpj do cliente; 2 últimos dig. do minuto da emissao ou do orçamento; 2 ult. dig. do número da nota; 1 dig. da forma de pagto, 1 do prim. digito do valor da nota. Algo assim: você teria o código de 8 dígitos em mãos, uma vez que sabe a fórmula que usou para criar uma função: gerateucodigoaleatorio() e estaria dificultando para alguém que não sabe o código. Se for criar invente uma, isto é apenas um exemplo Portanto tem N formas de fazer, porém fuja do óbvio.

Eu utilizo cobrança Cecred, agora Ailos, e não tenho problema nenhum na leitura do retorno. Não entendi a tua necessidade. Dercide.

Bom dia Jorge, Que legal sua animação e contribuir com esse novo projeto, parabéns. Att.

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

Bom dia Júlio. O erro ocorre no momento de gerar, assinar ou enviar? Já tentou debugar até onde ele chega para poder chegar a uma conclusão do que seja. Infelizmente esse erro pode ser N problemas. Sugiro que debugue a aplicação para chegar mais a fundo do erro.

Bom dia, Também estou começando a desenvolver o módulo de NF-e em um ambiente WEB, com Java rodando por trás. Já utilizo o ACBR em aplicações DELPHI. Se precisarem de algum "BETA", coloco a minha empresa a disposição. Obrigado.

@Henrique Sandri Zimermam Falta conteúdo nessa requisição de cancelamento. Veja um exemplo de como deve ser feito. <?xml version="1.0" encoding="UTF-8"?> <CFeCanc> <infCFe chCanc="CFe35181008723218000186599000040340003836020508"> <ide> <CNPJ>16716114000172</CNPJ> <signAC>SGR-SAT SISTEMA DE GESTAO E RETAGUARDA DO SAT</signAC> <numeroCaixa>001</numeroCaixa> </ide> <emit/> <dest/> <total/> </infCFe> </CFeCanc>

Segue o tópico ref a esse assunto

Obrigado meu amigo

Isso depende de cada Estado, mas, especialmente quando são indústrias. Muito cuidado, existe substituição tributária para frente e para trás, cada uma delas utiliza uma cst, para frente cst 010 e para trás, 060. É bem tranquilo isso.

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

boa noite.. Guilherme..tudo bem.. Converse com o Seu contador, ou com o Contador do Seu cliente, que ele vai lhe passar o que precisa fazer.. e ai..depois que voce tiver gerando xml, e precisar de ajuda,, ai nos avise.

Já foi enviada uma correção. Atualize novamente os fontes.

Consegui Agnaldo, obrigado pela ajuda!

Boa tarde Camilo, Pergunte para esse cliente se o contador possui o certificado dessa empresa. Se sim, é bem provável que o contador esteja realizando a manifestação para poder obter o XML e com isso fazer a escrita fiscal e contábil da empresa.

Resolvido Pessoal obrigado, Na verdade o dono anterior realizou o Bloqueio do aparelho e deveria realizar a DESATIVAÇÃO pela SEFAZ. Após desbloquear o aparelho com as credenciais dele e realizar a desativação consegui resetar o SAT e parametrizar com meus dados. Mas ao consultar rede ainda consta a falha na porta 80 da bematech porém não atrapalha o uso. Como está com Desativação Solicitada você precisa bloquear o aparelho pelo Activation Software, depois de bloqueado você consegue resetar (segurando o reset por 20 segundos) e assim, após isso, você insere seus dados nele após resetar

Obrigado Sérgio. O problema estava no número de série do SAT conforme você citou. Estávamos colocando o número de série do SAT com o dígito verificador, conforme o cadastro na SEFAZ. Excluímos os 2 últimos dígitos do número de série correspondentes aos dígitos verificadores aí a transmissão funcionou normalmente. Muito obrigado pela ajuda.

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.

Enviei o arquivo errado, segue em anexo o correto. ACBrDFeXsLibXml2.pas

O Manual diz que o número atribuído a cNF tem que ser um numero aleatório, e não um número que possa ser descoberto por terceiros, o que seria o seu caso. A finalidade é evitar fraudes e uso indevido por terceiros mal intencionados. Pode ser que o SEFAZ não rejeite a chave de acesso por enquanto, mas acredito que possa ser futuramente passível de rejeição por estar usando um número fixo e previsível.

Obrigado @Italo Jurisato Junior

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 tarde, Em breve faremos o lançamento, estamos quase lá :) Att.

Amigo, esses arquivos foram do erro que deu após o problema do retorno. Não estou localizando os arquivos do primeiro erro. Como já voltei a versão do ACBr anterior pois preciso emitir as notas, na segunda faço novo teste e te envio, ok? Mais uma vez obrigado.

Olá Giovane, tudo bem haha Galera, desculpem-me, mas encontrei onde ocorre o processo corretamente. No ACBrDFeSSL há uma alteração no método AdicionarSignatureElement em que passou a atribuir corretamente a assinatura no XML. Com isso o arquivo .ini deve ficar apenas com o valor Pedido no DocElemento. No meu caso, como ainda não atualizei os fontes, permaneço com a instrução "Pedido></CancelarNfseEnvio", mas ao atualizar deve ficar apenas como Pedido. Todos os casos que fique de registro para, caso alguém mais passe por este problema, possa encontrar a solução. Abraço * Tópico pode ser fechado

Marcelo, O que diz a rejeição? "436 Rejeição: Valor da soma dos componentes não corresponde ao valor total do bilhete". A somatória é 19,28 já o valor total do bilhete é 36,82. Logo a somatória tem que ser 36,82, não devemos considerar o desconto.

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

Não encontrei nada falando sobre isso. Enviei a pergunta para a receita e estou aguardando resposta. Quando obtiver a resposta posto aqui para qualquer outra pessoa que também tiver a dúvida saiba.

Que bom que resolveu

Como você não mencionou a mensagem exata de erro que está dando, vou dar outra sugestão; Limpar o componente antes de criar um evento. (Se tiver uma nota fiscal carregada no ACBr e você tentar criar um evento, terá a mensagem abaixo) Por tanto, certifique-se de limpar as notas fiscais e eventos que estão previamente carregados no ACBr. with ACBrNFe1 do begin NotasFiscais.Clear; EventoNFe.Evento.Clear; with EventoNFe.Evento.New do begin InfEvento.cOrgao := 91; //91 - Ambiente Nacional. No caso de evento de manifestação, sempre será 91 InfEvento.chNFe := ''; //Chave de acesso da NFe InfEvento.CNPJ := ''; //CNPJ da empresa que está emitindo o evento (o mesmo do certificado digital) InfEvento.dhEvento := now; //Data do evento InfEvento.tpEvento := ''; //teManifDestCiencia, teManifDestConfirmacao, teManifDestOperNaoRealizada, teManifDestDesconhecimento InfEvento.detEvento.xJust := ''; //Justificativa, caso seja desconhecimento ou op não realizada end; EnviarEvento(IdLote); end;

Bom dia Daniel, Eu achava que a classe de resposta somente era preenchida ao enviar uma venda ou cancelamento. Não sabia que ela pegava o retorno da consulta também. Vou implementar essas mudanças. Vou analisar o log do SAT pra ver se acho alguma ocorrência de venda em que o SAT estava em processamento, talvez nesse momento pode ter acontecido da venda ser reenviada e quando o SAT volta em operação, acaba enviando as duas vendas. E vou sugerir colocar uma alimentação externa, para evitar mau funcionamento. Obrigado pela valiosa ajuda.

Pode ser que o código do componente precise de ajustes para essa balança. Creio que o melhor é você averiguar a fundo. Pesquise no fórum sobre o assunto.

Depois de apanhar durante algumas horas, resolvi com o procedimento acima, valeu!

Consegui resolver o problema mudei as configurações da função para fgtSomenteProducao, e fiz atualização dos Schemas da NF-e http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=/fwLvLUSmU8=, é as notas passaram.

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

Olá Claudio. Primeiramente, muito obrigado pela contribuição. Gostei muito de você ter separado o exemplo em uma outra aba, em vista de tantas informações necessárias. Infelizmente, seu exemplo substituiu os geradores de relatório do Fortes report pelo Fast Report e inclui componentes de terceiros (TVirtualTable) que não poderia ser utilizados por quem tem uma licença Professional do Delphi. Sendo assim, não podemos enviar o código ao SVN nesse estado. Se você ou algum outro usuário tiver o interesse em corrigir esses pontos acima, teremos o prazer de fazer a atualização no código. Mesmo que não possa, mais uma vez, obrigado pela intenção em ajudar. Talvez outros usuários que tenham esses componentes ainda possam achar esse tópico e exemplo úteis.

Bom dia Eduardo, Favor anexar a unit alterada para que possamos analisar.

A URL da mensagem de erro é da versão 3.10: Verifique a configuração do componente e a versão do XML gerado.

A Nota Técnica que implementou a emissão de NFe para Pessoa Física "NT 2018.001 (Emitente Pessoa Física)" diz isso na página 19: 12. Serviço: Evento de Manifestação do Destinatário (item 4.9 do MOC) O Evento de Manifestação do Destinatário é gerado pelo destinatário da NF-e e atualmente não consegue ser realizado por destinatário pessoa física (CPF). Esta NT trata do emitente pessoa física, portanto não prevê alterações relacionadas com o destinatário.

Boa tarde. Não tinha me atentado a isso. Agora deu certo. Muito obrigado, @Daniel Simoes!

Boa tarde Ítalo. Verdade, arrumei uma solução para um único provedor. Vou fazer isso sim e retorno. Valeu mais uma vez.

Resolvido, muito obrigado por toda a ajuda e tempo dispensados para resolver meu problema, utilizando outra máquina também com Windows 10 64bits funcionou, portanto o problema é com a máquina que uso para trabalhar, algo está bloqueando o acesso ao Ambiente Nacional ou pior, tem algo na minha máquina que o Ambiente Virtual detectou e negou meu acesso. Como faz muito tempo que uso essa máquina, e não somente eu utilizo, vou fazer backup de tudo e formatar. Mais uma vez, obrigado a todos !

Era um no CSC apenas !

Não existe um opção no SGR-SAT que faça a desassociação com a software house. Isso só irá acontecer quando uma outra software house associar a assinatura com o equipamento SAT desse seu cliente.

Resolveu, era isso mesmo, coloquei a impressora padrão no windows a de A4 e resolveu. Será que não tem uma forma de configurar isso no fortes mesmo para não precisar alterar o windows?