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.

Muitos usuários quando configuram o ACBrMail do pacote ACBrTCP para enviar emails utilizando uma conta do GMail, encontram dificuldades, devido a erros de configurações ou ainda a restrições de segurança da conta, por meio do Google. Neste tópico, vou demonstrar como habilitar na conta do Google o envio de Emails, ou melhor, o acesso a uma conta do google por meio de "Aplicativos Menos Seguros". - Para verificar se sua conta do Google permite o login, e consequentemente o envio de emails por estes apps, acesse sua conta do google através do link, ou como no print abaixo.: - Clique em Segurança, e vá até a sessão: Acesso a app menos seguro No meu caso a opção já está habilitada. Pronto, agora você pode configurar o ACBrMail para usar o Gmail, com os parâmetros abaixo: ACBrMail1.From := '[email protected]'; // Coloque seu endereço do GMail ACBrMail1.FromName := 'Celso Marigo Junior'; // Nome para exibição ACBrMail1.Host := 'smtp.gmail.com'; // SMTP do Gmail ACBrMail1.Username := '[email protected]'; // O usuário é o próprio email ACBrMail1.Password := '*********'; // Nunca coloque a sua senha em fórums ACBrMail1.Port := '587'; ACBrMail1.SetTLS := True; ACBrMail1.SetSSL := False; Abaixo Gif demonstrando o envio com os parâmetros acima utilizando o ACBrMonitorPLUS recomento do excelente ScreenToGif (Google it!), para gravação de gifs de telas.

Bom dia. Obrigada @Leonardo Fabro da Rocha Att.

Bom dia. Veja este tópico. Att.

Bom dia. Veja que este tópico é relativo ao Santander, logo é sim necessário criar um novo. Att.

Bom dia, Aparentemente resolvido

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.

não é difícil. o que ocorre é que o processo de montagem do xml tem que obedecer a sequencia de ítens obrigatórios. a mensagem diz que niExpRisco não é esperado e que no lugar dele seja informado dtIniCondicao. ou schema errado ou montagem da sequencia incorreta, levando em consideração as regras de "esse vai", "esse nao vai" de acordo com os dados do empregador / estabelecimento.

Está na minha lista de afazeres.

BLZ Já estou implementando aqui valeu a todos pelo

Boa tarde, angelica adriana alves. Qual a mensagem de erro? Pouca informação para que possamos tentar te ajudar.

Boa tarde José, Estava tendo o retorno abaixo Segui tua orientação de retirar a acentuação, e foi solucionado a rejeição. Muito obrigado.

Depois de muita pesquisa, chegamos a conclusão que para emissão de NFC-e aqui no Ceará, é necessário gerar o XML para o Integrador Fiscal. Infelizmente os webservices estão bloqueados.

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

Bom dia, eu (ainda não tive a chance de trabalhar com datasnap, mas) ACHO que o caminho seria o app enviar apenas o comando de impressão dizendo qual NFe imprimir, e o "servidor datasnap" mandaria o DANFe pra impressora... Att Ricardo

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

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

Favor evite copiar textos grandes no corpo da mensagem. Use a opção de anexar arquivos.

Bom dia, Antonio Carlos L. Veja o artigo abaixo: https://www.portalmei.org/microempreendedor-individual-nota-fiscal/

Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr. Obrigado pela contribuição!

Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr. Obrigado pela contribuição!

Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr. Obrigado pela contribuição!

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

Edson, Se informar o CPF com 14 dígitos, o XML de pedido de evento vai ser gerado com a tag CNPJ e não a tag CPF, pelo que me recordo. Se possível, favor anexar o XML de pedido de cancelamento mais o de retorno com a rejeição, quando informado o CPF com 11 dígitos. E depois o XML de pedido de cancelamento com o CPF informado com 14 dígitos que não foi rejeitado.

Bom dia Daniel, Você concorda que isso gera um efeito colateral com os demais provedores? Será que a melhor saída não seria: rllPrestNome.Caption := IfThen(RazaoSocial <> '', RazaoSocial, fpDANFSe.RazaoSocial); if rllPrestNome.Caption = '' then rllPrestNome.Caption := IfThen(NomeFantasia <> '', NomeFantasia, fpDANFSe.RazaoSocial); Tente desta forma e anexe a unit alterada para que possamos analisar.

Bom dia, essa tela de Dialog não faz parte do componente e sim do demo que utiliza o componente. Utilizando o ACBrMonitor, poderá implementar algo parecido na sua aplicação, informando esta mensagem quando utilizar o comando EnviarNFe e atualizar a mensagem baseado no retorno obtido pelo ACBrMonitor...

Bom dia Cintia. Já tive esse "problema" uma vez, não exatamente com tecidos, mas a orientação que mais de um contador me envio é de que, se vc não transforma a matéria prima, ela permanece com o mesmo NCM, exemplo, compro arroz cru, e vendo marmita, dai tenho o processo de cozimento do mesmo, e a "unidade" de venda dele já não é mais a mesma, diferente se eu tivesse comprado o arroz, tirado a casca do mesmo, e vendido.

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

Veja se assim fica mais claro...