Pesquisar na Comunidade

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

Boa Tarde! Estou implementando o cancelamento por substituição, estou tendo o retorno 135 (evento vinculado e registrado) tudo conforme o esperado, porem ao verificar status retorna com status 100, então fui verificar os eventos retornados nesta consulta e encontrei um erro ao converter. TpcnTpEventoString : array[0..54] of String =('-99999', '110110', '110111', '210200', '210210', '210220', '210240', '110112', '110113', '110114', '110160', '310620', '510620', '110140', '610600', '610501', '610550', '610601', '610611', '990900', '111500', '111501', '111502', '111503', '411500', '411501', '411502', '411503', '610500', '990910', '000000', '610610', '610110', '110170', '310610', '110115', '310611', '610614', '610510', '610514', '610554', '610615', '790700', '240130', '240131', '240140', '240150', '240160', '240170', '440130', '440140', '440150', '440160', '110112', '110116'); Vejam que na terceira linha, segunda coluna (posição 7 no array), temos o '110112' e na penúltima linha, terceira coluna (posição 53 do array), também temos o '110112' Agora vejam o TpcnTpEvento: TpcnTpEvento = (teNaoMapeado, teCCe, teCancelamento, teManifDestConfirmacao, teManifDestCiencia, teManifDestDesconhecimento, teManifDestOperNaoRealizada, teEncerramento, teEPEC, teInclusaoCondutor, teMultiModal, teRegistroPassagem, teRegistroPassagemBRId, teEPECNFe, teRegistroCTe, teRegistroPassagemNFeCancelado, teRegistroPassagemNFeRFID, teCTeCancelado, teMDFeCancelado, teVistoriaSuframa, tePedProrrog1, tePedProrrog2, teCanPedProrrog1, teCanPedProrrog2, teEventoFiscoPP1, teEventoFiscoPP2, teEventoFiscoCPP1, teEventoFiscoCPP2, teRegistroPassagemNFe, teConfInternalizacao, teCTeAutorizado, teMDFeAutorizado, tePrestDesacordo, teGTV, teMDFeAutorizado2, teNaoEmbarque, teMDFeCancelado2,teMDFeAutorizadoComCTe, teRegPasNfeProMDFe, teRegPasNfeProMDFeCte, teRegPasAutMDFeComCte, teCancelamentoMDFeAutComCTe, teAverbacaoExportacao, teAutCteComplementar, teCancCteComplementar,teCTeSubstituicao,teCTeAnulacao,teLiberacaoEPEC,teLiberacaoPrazoCanc, teAutorizadoRedespacho,teautorizadoRedespIntermed,teAutorizadoSubcontratacao, teautorizadoServMultimodal, teCancSubst, teAlteracaoPoltrona); A posição 7 é teEncerramento, e é assim que o ACBr identifica o retorno da verificação de status, fica como Encerramento ao invés de teCancSubst. É identificado pela linha 193 (infEvento.tpEvento := StrToTpEvento(ok,Leitor.rCampo(tcStr, 'tpEvento'));) do arquivo pcnRetEnvEventoNFe no método TRetEventoNFe.LerXml O objetivo é setar a NFC-e como cancelada (cStat 101) mas pelo geito não vou conseguir fazer isso, já que no evento retorna 135 e no status 100. Estou testando no Sefaz/PR. Alguem de outra UF tem o mesmo problema (retornar 100 ao invés do 101 depois de autorizado o cancelamento por substituição). ?? P.S. Procurei na NT mas não encontrei nenhuma alteração na verificação de status.

Olá pessoa, estou tendo um problema com a tag tpEvento na Carta de Correção Eletrônica. Estou usando, a muito tempo, no campo tpEvento o valor 110111, dentro do XML o ID da carta começa com 110111xxxx porem, quando o componente salva o XML ele o faz com o ID inicial 110110xxx. Debugando, na unit pcnEventoNFe >> TInfEvento.getTipoEvento ele usa a conversão TpEventoToStr(FTpEvento) onde FTpEvento é o enumerator teCCe que convertido passa para 110110. Alguém pode me ajudar? O que estou fazendo de errado? grato.

Boa tarde|! Gostaria de saber se alguém já realizou teste do novo Evento Prestação do Serviço em Desacordo? E se sim, se tiverem a Rejeição 297: Assinatura difere do calculado? Estamos realizando o teste aqui e não consegui entender o motivo desta rejeição, estamos utilizando o componente ACBrCTe para o envio desde evento. Seque em anexos os xml que envolve o Evento: Xml gerado da NF-e no mesmo período: 333170000426982_v03.10-procNFe.xml Xml gerado do CT-e no mesmo período: 131170001241261_v03.00-procCTe.xml Xml gerado do Evento Prestação do Serviço em Desacordo: 1-ped-eve.xml1-ped-eve.xml Xml de resposta do Webservice: 1-eve.xml Se puderem oferecer alguma dica lhes agradeço. Aproveito a oportunidade para agradecer os apoio que sempre recebi aqui desde grande grupo, e também para parabenizar o excelentes trabalho de toda equipe envolvida no projeto. Sem para o momento, Antecipo agradecimentos,

Bom dia,Alguém aqui conseguiu emitir o evento de prorrogação?Conforme a NT a entrada em Homologação foi dia 26/10, e estou enfrentando a rejeição: 491 - tpEvento informado inválido, alguém com o problema parecido? Estou encaminhando o evento para o WS de recepção de eventos do RS.

Srs. uma situação bem "incomum", e preciso de ajuda. Meu cliente precisa encaminhar Carta de Correção para Notas emitidas em 2009. Apesar de ter duvidado no inicio, li em alguns tópicos que não existe restrição de tempo para emissão da CCe (me corrijam se estiver errado). O fato é que ao enviar notas retorna para mim o erro 494 (Rejeicao: Chave de Acesso inexistente para o tpEvento que exige a existencia da NF-e ), mesmo que ao consultar a mesma chave da nfe a mesma consta como autorizada no SEFAZ. Habilitei o log (salvar arquivos de envio e resposta), e tenho os três arquivos de requisição, e pelo que vi os arquivos estão enviando o evento e chave corretamente. Mais alguma dica? Já passaram por situação parecida? 1-ped-cce.xml 1-cce.xml 350909646004220001805500100000000100000000191101101-procEventoNFe.xml