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.

Boa tarde Juliano No seu sistema, basta deixar o campo "cNF" recebendo "0" dessa forma o componente irá gerar um numero aleatório diferente do número da NF de forma automática, dessa forma já não terá mais esse erro... Ou utilize a função (GerarCodigoDFe) no campo cNF, citada no tópico acima....

Bom dia, Obrigada pela contribuição, adicionada para análise; Att

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17276. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

De acordo com as novas regras da SEFAZ, o campo cNF não pode ter o mesmo valor do campo nNF. Veja o tópico mais completo explicado pelo @Italo Jurisato Junior :

Eita acabei de entrar em contato com a SEFAZ de TO, depois de mil anos tentando falar kkk (acho que acabei me equivocando um pouco) Venho informar que o CDF não está sendo mais utilizado, tendo em vista a obrigatoriedade da utilização da Nota Fiscal de Consumidor Eletrônica pelas empresas usuárias de ECF, conforme previsto na Portaria Sefaz nº 510/2018.

Bom dia. Obrigada por contribuir, está adicionado a fila de análise. Att.

Bom dia. Se desejar pode implementar e submeter para análise. Att.

Boa noite! Nota Técnica 2018/001 - Emitente Pessoa Física (CPF) Com Inscrição Estadual. Pág. 3 - Item --> 02.1. Sobre a Chave de Acesso da NF-e - Será reservada uma faixa do campo Série da NF-e, como forma de identificação do Emitente pessoa física (CPF); Pág. 6 e 7 - Item - 03.2 Quadro resumo sobre as Faixas de Série Série: 910-919 Processo de emissão: Site Sefaz - Chave de acesso: CPF do Emitente Série: 920-969 Processo de emissão: Aplicativo da Empresa (Próprio) - Chave de acesso: CPF do Emitente Sua chave: Observe a série (920) logo 00077853687168 é CPF portanto considerar apenas os 11 dígitos, os 3 zeros a esquerda é apenas para a chave permanecer com total de 44 dígitos. 51190700077853687168559200000000101000000109

Encontrei relatos de outros usuários, utilizando o modelo Toledo Prix 3 Plus e 4 due com ACBrBal. Porém para confirmar, seria interessante realizar os testes ou verificar no manual juntamente com as implementadas. Segue os tópicos relacionados:

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Fiz algumas alterações em outras units que parecem seguir o mesmo padrão. Subi as alterações para o SVN na Revisão 17270. Pelo que vi está tudo certo. Queira por favor atualizar, reinstalar, testar e reportar qualquer problema. Mais uma vez obrigado.

Na impressão da NF-e, nos dados dos produtos / serviços, de acordo com a quantidade de registros as linha são coloridas com cores alternadas. porém o campo estava sendo pintado ultrapassando a largura máxima do "detail". segue o print do erro: Para correção desse problema realizei algumas modificações nos arquivos (ACBrNFeDANFeRLRetrato.pas, ACBrNFeDANFeRLRetrato.dfm), segue imagem: Não sei se já foi feito alguma correção nesse sentido, mas estou anexando os arquivos com minhas alterações. Obrigado. ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.pas

Obrigado pela contribuição... Porém creio que essa nova classe, poderia descender de TACBrEscPosEpson, e com isso você faria a sobreescrita apenas dos métodos que são diferentes, economizando Centenas de linhas de código repetido... Veja um exemplo, na Unit ACBrEscCustomPos.pas

Felipe boa tarde. Para dar um feedback, como a maquina que programo é do trabalho tem restrições administrativas que impediam de carregar os pacotes. Ao rodar como administrador, os pacotes foram carregados com êxito. Grato pela ajuda.

funcionou, mais recomendo apagar todos os certificados e realizar os procedimentos. muito obrigado. att

Nilton, Enviei um novo arquivo INI do provedor para o repositório. Favor atualizar e faça novos testes com esse novo.

Boa tarde. Obrigada pela contribuição. Att.

Boa tarde. Basta informar este valor na propriedade Modalidade. Att.

Boa tarde, Rafael Sartori. Aqui eu utilizo sem problemas SKYTEF e Pay&GO (NTK).

Boa tarde Se voce utiliza OpenSSL deixe comentado apenas: {.$DEFINE DFE_SEM_OPENSSL} Na instalação do Monitor pode verificar as dlls que precisa no diretório raiz ACBrMonitor...

Boa tarde, d2mpavan. Verifique a tag DataBaixa no titulo.

Por enquanto só podemos se basear na quantidade de caracteres definida no MOC, de 60 caracteres (página 179). Att Ricardo

Bom dia. Note, que o campo finNFe ( Finalidade da NF-e ), está sendo utilizado como " NF-e complementar ", porém não foi referenciada a NF-e que a mesma está sendo complementada. Você deve adicionar a NF-e que será complementada no campo "NFref"

Aparentemente não é possível a emissão de NFe complementar referenciando uma nota de produtor rural (grupo NFP). A regra de validação menciona apenas NF-e, NFC-e ou NF modelo 01.

Bom dia. Que bom que resolveu, mas seria interessante você dizer a solução também. Att.

Você pode verificar se todos os dados da mensagem foi enviada corretamente? Talvez tenha faltado alguma linha ou character? Eu verifiquei o código que é na verdade na sua maior parte da Synapse. Me parece que a verificação para o retorno 250 está OK. Veja: function TSMTPSend.MailData(const Value: Tstrings): Boolean; (...) FSock.SendString('.' + CRLF); Result := ReadResult div 100 = 2; end;

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

Bom dia Marcos, Se para a NF-e devemos informar a sigla da UF e no CT-e o código IBGE da UF, com certeza o comando da NF-e deve estar realizando a conversão de sigla para código e quanto ao CT-e essa conversão não esta sendo feita. Vou passar esse problema para o pessoal que cuida do ACBrMonitor, pois devemos deixar padronizado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17274. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado. Essa terceira eu não enviei ao SVN ainda. Gostaríamos de analisar melhor. Não consegui localizar nenhum XML nesse formato que você informou. Poderia anexar algum para análise?

Tem que ver a legislação do seu estado. MG é permitido, desde que informe os dados do cartão (adm,bandeira)

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17273. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde, vc já verificou a propriedade "DetRastros" ? 06/06/2019 -- ACBrNFeDANFEClass -- [+] Inclusão da propriedade "DetRastros" para configurar impressão individualizada das tags do detalhamento específico "rastro" no DANFE. Att Ricardo

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

Tinha uma dúvida, mas acabei lendo outra resposta neste tópico que me ajudou, Gostaria de ter excluido este post mas não tenho essa opção. Obrigado 35190724755982000190580010000000191042629938-mdfe.xml

Bom dia! Experimente ir em configuração. Opção DFe - Impressão - NFC-e Aonde aparece Margens: Inferior - Superior - Direita - Esquerda - Largura [ ] <<-- Experimente aqui colocar tamanhos entre 280 a 300 e vai ajustando. Veja se muda alguma coisa.

Pelo o que vi alguns bancos retornam o nosso numero com o digito, e outros não. Eu particularmente utilizo o Sicredi, e não tenho problemas na leitura, pois quando leio o nosso numero eu calculo o digito verificardor, e formato o nosso numero conforme ele foi gerado e enviado na remessa, pois muitas vezes a formatação de envio não é mesma do retorno. Não vejo necessidade de alteração, pois ai todos que utilizam terão que revisar os códigos. Dercide.

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

Reverte para os valores do SVN que vai compilar como é compilado

Boa noite! A resposta está neste mesmo tópico. Por acreditar ser o que você precisa e o tópico ser antigo, estou fechando ele. Caso não resolva, abra novo tópico com nova dúvida.

Boa noite, segue a alteração sugerida, basicamente alterei para aceitar definir no componente cópias = 0, quando estiver setada copias = 0 não fará a verificação deste trecho if RLPrinter.Copies <> AConfig.NumCopias then, pois é exatamente neste if onde ocorre o problema. ACBrDANFCeFortesFr.pas ACBrDFeReport.pas ACBrDFeReportFortes.pas

Boa noite Senhores! Solução encontrada, eu estava utilizando na estação cliente uma versão desatualizada da dll "Midas", peguei a versão correta para o Delphi 10.2 Berlin, realizei a copia para os diretórios do windows, fiz o registro e o aplicativo funcionou normalmente.

Boa tarde Vi a alteração que você fez, desta forma não vai mais ter inconsistência e propriedade "ACBrMDFe1.WebServices.Consulta.Protocolo" sempre vai retornar o protocolo atual considerando o evento atual ou no caso de não haver evento retorna o protocolo de autorização. Ainda não testei, mas acredito que vai funcionar Por mim pode fechar o tópico Muito Obrigado

Bom dia, Obrigada pela contribuição, adicionada para validação. Att.

Ola Tiago, encontrei um blog que aparentemente me ajudou! Ate então não tive problemas depois q segui os passos, vou te passar o link. https://nstecnologia.com.br/blog/problema-ao-localizar-certificados-icp-brasil-v5/

Tópico fechado por falta de retorno do usuário

De acordo com o que foi me informado por um consultor tributário: pRedBCEfet = pRedBC(Nota Entrada) vBCEfet = vProd( Valor Total do Item que está sendo vendido) * (1 - pRedBCEfet ) pICMSEfet = pICMSST(Nota Entrada) vICMSEfet = vBCEfet * pICMSEfet Agora não sei se isto se aplica para todas as UF's que estão exigindo este grupo!

Tentou reinstalar os certificados, de acordo com o seu navegador ? https://www.iti.gov.br/navegadores

Estamos em um consenso, @Larry. Agora, esperamos que seja isto mesmo. Estamos tratando logo no processo de entrada de notas no sistema, quando trata-se de CST 010, 030, 070, por exemplo, já realizamos a divisão pela quantidade e armazenamos sempre o valor unitário da última entrada por produto. Assim, quando demos saída com CST 060 ou CSOSN 500, já temos os valores bonitinhos armazenados, daí é só puxar e multiplicar pela quantidade. É isso. Até mais.

Boa tarde Liliane, O idCSRT é um numero sequencial: 001, 002, .... Por outro lado o CSRT - Código de Segurança do Responsável Técnico que eles chamam de forma errada de token, será fornecido pelo Fisco, conforme consta na Nota Técnica. Nesse primeiro momento você não precisa se preocupar, pois o grupo <infRespTec> é opcional, podendo ser obrigatório se a UF do emitente do CT-e assim desejar. Se isso vir a ocorrer, que acredito que venha, os campos idCSRT e hashCSRT são opcionais e depende de uma implementação futura, ou seja, primeiro o Fisco tem que estar pronto para fornecer o CSRT do Responsável Técnico, caso contrario não tem como incluir essas informações no XML. Quero chamar a atenção referente a palavra token, pois ela nos remete ao certificado digital A3 em formato de pen-drive, chamado pelas certificadoras de token. O token que a Nota Técnica se refere neste caso é o CSRT, ou seja, trata-se de um código alfanumérico que será fornecido pelo Fisco. Quando for publicado a Nota Técnica sobre o idCSRT e CSRT bem como o calculo do hashCSRT, com certeza vamos fazer uma alteração no componente visando atender essa NT.