Italo Giurizzato Junior

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

Bom dia Joveci, O MDF-e pode relacionar NFe ou CTe, se o tipo de emitente for transportador só vai acrescentar no XML os CT-e informados. Por outro lado se você informar que o tipo de emitente é transportador de carga própria o componente só vai acrescentar no XML as NF-e informadas.

Boa tarde a todos, Com certeza os schemas estavam desatualizados.

Como lhe disse, não sei se a versão Free do ACBrMonitor contempla o BP-e, já para quem é assinante do SAC tenho certeza que contempla. E quem vai assinar, validar, enviar, etc é o ACBrMonitor. No Manual do ACBrMonitor você encontra todos os métodos implementados para o BP-e, inclusive o layout do arquivo INI que a sua aplicação tem que gerar. Não estou entendendo qual é a dificuldade.

Boa tarde Antônio, Se a propriedade de configuração: Configuracoes.Arquivos.IniServicos estiver vazia ao compilar a sua aplicação o arquivo ACBrNFeServicos.Res será incorporado ao EXE da sua aplicação. Desta forma você não precisa distribuir junto com a sua aplicação o arquivo ACBrNFeServicos.ini

Boa tarde, O ACBrMonitor Plus, para quem é assinante do SAC tenho certeza absoluta que tem o BP-e. Sendo assim vale apena assinar e poder semanalmente baixar a versão mais recente do ACBrMonitor Plus. O que a sua aplicação vai ter que fazer é simplesmente gerar um arquivo TXT segundo o nosso layout e usar os métodos disponíveis para o BP-e implementados no ACBrMonitor Plus. Ele pega esse arquivo TXT (que tem o formado de um arquivo INI) lê todas as informações, gera o XML, Assina, Valida, envia para a SEFAZ, aguarda o retorno, se tudo estiver correto, acrescenta ao XML o protocolo de autorização, por fim imprimir o DABPE. Em uma pasta que você configura no Monitor será salvo um arquivo TXT também no formato INI com as informações do retorno, desta forma você pode atualizar o seu banco de dados.

Boa tarde Adilson, Vamos ver se eu entendi: Se imprimir logo após o envio a impressão sai correta, se carregar o XML da nota para poder imprimir sai errado. É isso que esta ocorrendo?

Fabio, Na maquina que esta emitindo as notas, além de atualizar a aplicação atualizou também os arquivos INI?

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

Detalhe importante: Executando o DistribuicaoDFePorUltNSU você tem a lista de resumos das notas, de posse dessa lista é possível saber se existe alguma empresa emitindo nota contra o seu CNPJ sem você ter comprado nada dessa empresa. Lembre-se também que devemos capturar o valor de UltNSU ao executar o DistribuicaoDFePorUltNSU, pois na próxima execução deveremos usar o numero capturado na execução anterior na próxima execução.

Boa tarde New Standard, Antes de executar o método DistribuicaoDFePorChaveNFe a nota foi previamente Manifestada? Por favor leia esse artigo: Como obter o XML do Fornecedor

Boa tarde, Ao obter o retorno você tem o numero da nota? Se sim, é possível usar o método ConsultarNFSe.

Marcos, Tente fazer um teste com o programa exemplo do componente.

Boa tarde Fabio, Esse problema começou depois que você atualizou os fontes dos componentes?

Boa tarde Romano, Favor atualizar os fontes e iniciar os testes com o programa exemplo. Note que fiz alterações nos arquivos: Cidades.ini e Coplan.ini

Marcos, Acabei de fazer um teste usando o programa exemplo do componente ACBrGNRE com ele configurado para a versão 2.00 A versão gerada no cabeçalho é 2.00 Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada? Detalhe não alterei o nome de nenhum Schema. O teste foi realizado com tudo o que esta no repositório.

Boa tarde Lucimauro, Sim, mas a mudança é pequena, foi acrescentado uma tag que vai conter a string do QR-Code. Algo semelhante o que já ocorre com a NFC-e. Logo o DAMDFE vai ser alterado também, pois além do código de barras ele vai passar a ter também o QR-Code.

Boa tarde Marcos, Favor anexar os XMLs gerados que apresenta a versão do cabeçalho errada.

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.

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.

Boa tarde Júlio, Se você for de Pelotas, sugiro que você abra os XMLs: 844-rec.xml (retorno do envio), 01746519201946-con-lot.xml (consulta ao lote) e 01746519201946-lista-nfse.xml (retorno da consulta), através de um navegador, imprima e mostre pessoalmente para essa analista. Não esqueça de imprimir um Print da tela do site que mostra que a respectiva nota foi processada com sucesso. Caso não seja possível conversar com ela pessoalmente, envie esses arquivos por e-mail. Deixe claro que até uma certa data esta funcionando sem nenhum problema, depois começou a apresentar essa mensagem ao consultar o lote.

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.

Boa tarde Marcelo, Somando os valores dos componentes: 17,59 + 0,57 + 1,17 + 0,00 resulta em 19,28 De onde você tirou o valor 36,82 informado em vBP ?