Painel de líderes

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

Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.

bom dia e possivel sim segue um link ai com algumas informacoes

Realizar a manifestação do destinatário apenas com a Ciência e não concluir posteriormente pode sim acarretar em algum tipo de multa... A manifestação do destinatário está "amarrada" ao DistribuiçãoDFe. Porém os objetivos são diferentes... Então a ideia de "só baixar o XML" não funciona muito já que seu cliente se torna obrigado a realizar a manifestação. Aqui eu trato da seguinte maneira: Aplicativo configurado para realizar a manifestação do destinatário automaticamente com a Ciência da operação ao encontrar um novo documento. Usuário realiza o recebimento de mercadorias no sistema: Disparo a Confirmação da operação Desconhecimento ou Operação não realizada fica por conta do usuário. Caso fique notas sem a "conclusão" da manifestação por parte do destinatário, alerto o mesmo através de notificações.

http://www.nfe.fazenda.gov.br/portal/perguntasFrequentes.aspx?tipoConteudo=yjOJMwFOkA0= Se não me engano o prazo geral atual é de 30 dias. Alguns estados como RO tem prazos menores e obrigatoriedade de se enviar a manifestação independentemente de ter havido a ciência.

Há uns 6 anos atrás achei isso: tão verdade...

Boa tarde Luciano, O correto é [infCteSub] chCte= chave do Cte original refCteAnu= chave do Cte Anulação Você colocou chCTe sendo que o correto é chCte.

Ok, deu certo o envio agora, obrigado.

Usando o demo do ACBrNFe o teu XML validou normalmente. Já verificou a versão das DLLs OpenSSL/XmlSec?

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

Sandro, Achei o erro, a url estava começando com bpe sendo que o correto é dfe. Já fiz a correção e estou enviando para o repositório. Favor atualizar novamente e repita os testes

Só para fechar o tópico, após uma semana de busca,descobrir oq estava acontecendo. No meu estado as alterações da nota técnica 2018.005 não são obrigatórias, por esse motivo deixei a opção: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; porém não estava conseguindo transmitir de jeito nenhum. Depois de alguns teste descobri que mesmo não sendo obrigatório as tag icmssubstituto e as demais devem ser preenchidas mesmo que com 0. Então alimentei minhas tags com zero, mas o acbr ignorava a informação e n gerava a tag, assim que eu mudei ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca para fgtSempre as notas passaram. Caso alguém passe pela mesma situação ta ai a resolução do problema. Obrigado ao Felipe que me ajudou

Sim, exclui tudo e atualizei novamente pra ter certeza.

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.

Obrigado pessoal deu certinho abs

Problema Resolvido com a atualização do componente ACBR, Update e reinstalação. Obrigado.

Resolvido! "&" no nome do cliente. Obrigado pela atenção!

ok, atualizei os fontes, e estou iniciando os testes. Obrigado

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

Entendi, muito obrigado! Pode colocar como: RESOLVIDO.

Bom dia Use o comando abaixo, antes de enviar a nota, informe este comando, se ja existir a carta, ela sera reemitida, se nao existir, vc usa o comando para enviar, obs. serve para qualquer evento NFe.EnviarEvento(cIniEvento) Parâmetros: cIniEvento - path do arquivo ini com o nome do arquivo, contendo os eventos a serem enviados conteúdo do arquivo ini. Exemplos: NFe.EnviarEvento("c:\CCe.ini") - Está sendo informando o path do arquivo contendo as informações dos eventos. Exemplo de Resposta: OK: Cancelamento de NF-e homologado [CANCELAMENTO] Versao=1.07 TpAmb=2 VerAplic=SP_NFE_PL_005c CStat=101 XMotivo=Cancelamento de NF-e homologado CUF=35 ChNFe=350XXXXXXXXXXXXXXXXX550010000000220000000229 DhRecbto=2009-03-25T08:50:50 NProt=2009-03-25T08:50:50 tpEvento= xEvento= nSeqEvento= CNPJDest= emailDest= XML=

Bom dia O método está correto, porém a SEFAZ não prevê a Inutilização para NF-e de Produtor Rural, simplesmente você pula a numeração. Pode ver isso na NT de especificação sobre Emissão de NFe com CPF.

A linha em branco foi eliminada sim. Adicionei a propriedade no início do sistema para o DANFE ESCPOS e deu tudo certo. Vlw

Desculpa, não havia visto que já tinha sido respondido, podem desconsiderar, obrigado.

Boa tarde, Milton Lima. Fiz a validação com o ultimo XML que me encaminhou e validou corretamente, veja abaixo: Resultado Nota NFe29190604272032000105550010000270981968174344 XML Válido Verifique se você está utilizando os Shemas da pasta do ACBr e se configurou corretamente no programa exemplo.

Problema resolvido! O erro acontecia por que na pasta do Schemas, só tinha os arquivos de Schemas da versão 4.0, porém debugando, vi que precisava de outros arquivos .xsd, então substitui minha pasta de Schemas pela a do Acbr e deu certo. Mas ainda assim, não estava conseguindo da ciência na nota, pelo o fato de está passando o código da UF da empresa que está solicitando, para o campo: InfEvento.cOrgao Mas com ajude de @Gabriel Franciscon, passei o código 91 e deu certo. Ainda tenho uma dúvida, meu objetivo é apenas baixar o XML do fornecedor, qual das formas eu devo me manifestar: teManifDestCiencia ou teManifDestConfirmacao ? Eu li que essas 3 formas de manifestação são conclusivas: Confirmação da Operação Registro da Operação não Realizada Confirmação da Operação A única que não é: Ciência da Operação, o que acontece se eu declarar todas as notas com esse status? Posso sofrer alguma sanção ? Ou a forma correta é essa mesmo?

Você pagará novo imposto... mas quem controla a numeração do SAT, é o próprio SAT

Se você já está trabalhando com os eventos já existentes, talvez seja mais fácil você implementar os eventos faltantes e enviar os fontes.

Boa tarde! Enquanto aguardamos o teu arquivo, aproveito para alerta-lo sobre o CST do IPI. No XML que você postou a operação é de saída e você colocou código CST de IPI como de entrada. Aproveite e corrija isto também, pois poderá ter alguma complicação mais tarde ou receber um email da SEFAZ, já que agora eles estão solicitando as informações do grupo técnico Teu XML: A partir de 01/04/2010 os contribuintes do IPI deverão utilizar a seguinte Tabela de CST/IPI: SAÍDAS 50 – Saída Tributada 51 – Saída Tributável com Alíquota Zero 52 – Saída Isenta 53 – Saída Não Tributada 54 – Saída Imune 55 – Saída com Suspensão 99 – Outras Saídas ENTRADAS 00 – Entrada com Recuperação de Crédito 01 – Entrada Tributada com Alíquota Zero 02 – Entrada Isenta 03 – Entrada Não Tributada 04 – Entrada Imune 05 – Entrada com Suspensão 49 – Outras Entradas

Você mesmo gera o XML, na sua aplicação ? Ou você usa comandos e o formato INI Se usa o INI, favor anexar o comando e INI enviado, para geração do XML

Boa Noite! Eu passei pelo mesmo problema hoje e consegui Resolver, só que com o Provedor ISSDSF para Campo Grande-MS. O Retorno do WebService era: "Assinatura Digital InvalidaAssinatura Invalida" Alterei a Propriedade: de NFSe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2 para NFSe.Configuracoes.Geral.SSLXmlSignLib := xsMsXml Lembrando que precisei registrar as dll's: msxml5.dll e msxml5r.dll Estas dll's se encontram em: ...\svn\trunk2\DLLs\Capicom\ Aparentemente, houve alguma alteração na forma de assinar pela xsLibXml2 Espero que funcione com você também @conceitho