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.

Isso mesmo!! Muito Obrigada!

Há um problema que causa essa mensagem mas nos meus testes ocorre apenas em modo debug. Se possível teste como arquivo anexo. Boleto.fr3

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 :

Bom dia. Esse é nome que o Banco do Brasil dá as sua variações, no caso o componente se guia pela carteira e quantidade de dígitos no Convenio. Att.

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. Você poderia também ter um campo status na sua duplicata, de forma a saber se a mesma já foi gerada remessa e ou impressa (ainda que em pdf). Att.

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.

Olá pessoal, eu estava precisando fazer a comunicação com a impressora TSP 700, da marca Star. Até então eu estava usando os comandos do arquivo da Epson, ou seja o modelo "ACBrEscPosEpson", a maioria dos comandos de impressão funciona corretamente porém o comando para cortar o papel, por exemplo, é diferente entre a Epson e a Star e os demais modelos. Para a epson o comando é GS + 'V' e para o modelo star o comando é ESC + 'd'. Pensei na possibilidade de realizar alterações no arquivo "ACBrEscPosEpson" mais achei mais simples e organizado criar um arquivo especifico para os modelos de impressora Star. As alterações ocorreram da seguinte forma, criei um novo arquivo chamado "ACBrEscPosStar" com os métodos e comandos específicos para esse modelo. Na unit: "ACBrPosPrinter", adicionei no enumerador "TACBrPosPrinterModelo" o modelo novo, chamado "ppEscPosStar". Para o método "TACBrPosPrinter.SetModelo" dessa mesma unit adicionei no case a referencia para a nova classe: ppEscPosStar: FPosPrinterClass := TACBrEscPosStar.Create(Self); Modifiquei o arquivo, ACBr_Serial.dpk adicionando essa nova unit: ACBrEscPosStar in '..\..\..\Fontes\ACBrSerial\ACBrEscPosStar.pas' ; Após realizar as alterações compilei novamente o projeto ACBr e configurei meu sistema para esse novo modelo adicionado, após isso a impressão e o corte funcionou normalmente. Eu verifiquei que existe um post bem antigo que fala sobre o corte de papel na impressora Star TSP 100 e TSP 143. Achei mais interessante abrir um post novo. Não sei se o procedimento realizado foi feito da melhor forma, pode ser que exista uma forma melhor de tratar essa comunicação. Para me informar dos comandos que devem ser utilizados na impressora Star , consultei o manual que serve para os modelo Star TSP 700 e Star TSP 800. Segue em anexo os aquivos. ImpressoraStarTSP700.rar

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

obrigado

Boa tarde. Eu ainda não havia visto nada sobre este tipo de remessa, você tem algum documento com o layout? Att.

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

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum. Tópico relacionado abaixo:

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

Infelizmente o cliente é de longe e estou ajudando o mesmo remotamente... Mas se tudo indica que sim vou informar al mesmo para comprar um rolo que informe compatibilidade com a impressora dele nos modelos... Postarei novidades sobre o caso

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"

Tente modificar as configurações do Form Designer. Pela sua descrição parece algo que a opção "Snap to grid" faria.

Bom dia, Obrigada por informar, adicionado para validação. Att.

Só se você informar 0 para o código da nota. Se você já gera e assina o XML antes de enviar para o ACBrMonitorPLUS, pode usar o parâmetro que instrui ele a não recriar o XML. Caso o ACBrMonitorPLUS tenha que regerar o XML e o cNF seja igual ao nNF, por exemplo, vai ter o erro na geração do arquivo.

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

Bom dia Marcos, vamos verificar e padronizar a verificação desse parâmetro, obrigado por reportar.

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

Bom dia Juliano Esses provedores fazem as suas lambanças e nós temos que fazer gambiarras por conta disso. O que custa para eles gerarem no XML a informação em um formato padronizado, ou seja, 4 dígitos para o ano e 2 para o mês? Por favor, entre em contato com o provedor e questione a falta de formatação na informação.

Quer dizer então que caso a nota seja DENEGADA, não preciso passar o item, passo apenas o cabeçalho? Vou colocar então uma regra para ignorar o "RegistroC114New" quando a nota for DENEGADA. Caso o código da situação for '04'. Obrigado!

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

Verdade... Obrigado

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

Bom dia, O problema é na leitura do retorno, seria isso ? Talvez o componente nesse caso leia apenas o nosso numero sem o Digito. Dercide.

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

Obrigado @Italo Jurisato Junior !!

De acordo com o tipo dos parâmetros informados. Para tipos numéricos, vai ser usada a função da unit Math, para string, StrUtils. Se houver a mesma função com mesma assinatura (quantidade e tipagem dos parâmetros) em duas units diferentes, o Delphi vai usar a que for informada por último na cláusula uses.

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

#### TÓPICO RESOLVIDO #### O sistema que estou utilizando foi desenvolvido em Delphi 7 e percebi que uma função "StringToFloatDef" da ACBrUtil não é compativel; fiz uma pequena conversão no código para retirar o ponto decimal de milhar e deu tudo certo. Muito obrigação pela atenção.

Perfeito meu amigo, você elucidou o mistério... Eu tenho um componente ApplicationEvents com o evento OnException implementado com um exemplo que eu peguei da internet com algumas exceções básicas (violação de chave, valor inválido, data inválida, etc), mas não existia um alerta padrão para erros que não se enquadrassem nessa lista de exceções básicas, agora eu coloquei um if excecaobasica1 Then ShowMessage('excecaobasica1') else if excecaobasica2 Then ShowMessage('excecaobasica2') else if excecaobasica3 Then ShowMessage('excecaobasica3') else ... //Se nenhuma das anteriores, exiba um alerta padrão ShowMessage(E.Message); Eu não sabia que ao colocar o ApplicationEvents com o evento OnException implementado o Delphi ignoraria o alerta padrão dele (TApplication.ShowException) e passaria a enxergar somente o OnException do ApplicationEvents. Obrigado novamente

Boa tarde! Origem= CSOSN= vBCSTRet= pST= São campos do grupo [ICMSNNN]

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/

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.

Existe sim, vamos adicionar a nossa lista de tarefas... mas se desejar contribuir poderá implementar essa leitura e anexar o fonte aqui que atualizamos no SVN.