Italo Giurizzato Junior

ALA, Se o CT-e for Globalizado além da tag indGlobalizado ter o valor 1 se faz necessário informar a observação.

Gilbas, Você esta usando os schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe ? Todos os XSD estão com uma bolinha verde no ícone? Você costuma atualizar todas as pastas?

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

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.

Boa tarde ALA, Sim se o CT-e for Globalizado.

Boa tarde Gilbas, Note que erro de validação e não rejeição, sendo assim o erro esta ocorrendo antes do envio. É bem provável que os schemas estejam desatualizados.

Boa tarde Sandro, Favor atualizar os fontes, essas novas URLs já foram atualizadas no componente.

Boa tarde Joveci, Favor anexar o XML.

Boa tarde Lucimauro, Ainda não pois a SEFAZ só vai exigir o DAMDFe com o QR-Code a partir de outubro/2019.

Bom dia Gibas, Esse erro esta ocorrendo antes do envio? Ou é o retorno da SEFAZ?

Bom dia Cicero, Favor atualizar todos os fontes de todas as pastas novamente. Reinstale a suíte através do ACBrInstall_Trunk com a opção Apagar arquivos antigos marcada.

Bom dia ALA, Basta atribuir a observação no campo xObs conforma exemplo abaixo: infCTeNorm.infGlobalizado.xObs := sObservacao;

Bom dia Hugo, O numero da nota tem que ser um numero sequencial. Se o numero da venda é sequencial, não vejo problemas. Se o seu cliente tiver mais de um PDV, a sugestão (inclusive da SEFAZ) é cada PDV usar uma série. O PDV 1 vai emitir as notas com serie 1, o PDV 2 vai emitir as notas com serie 2 e assim por diante. Espero ter ajudado.

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, Por ser um evento novo e no momento só disponível para a NFC-e, com certeza a página da SEFAZ não foi alterada para mostrar esse novo evento de cancelamento.

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?

Leonardo, É a sua aplicação que gera o XML do MDF-e e depois o Monitor faz o resto? É a sua aplicação que pega o XML do MDF-e assinado e acrescenta o protocolo de autorização? Se sim, esta montando de forma errada. A tag correta é <mdfeProc> e não <MdfeProc>. Se você editar esse XML corrigindo tanto a tag de abertura quanto a de fechamento (final do arquivo) você vai ver que vai funcionar 100%.

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.