BigWings

A diferença na chave está no tipo de emissão que foi alterado de contingência para normal. Também o "xml apos consulta" não tem o protocolo de autorização o que significa que não foi o método de consulta que gerou o mesmo. Verifique se a aplicação não está alterando o tipo de emissão da NFe e gerando novo XML.

O componente já faz a descompactação internamente e disponibiliza o XML na propriedade ACBrNFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[ x ].XML. Também salva o XML em arquivo se configurado pra isso.

Entre em contato com a prefeitura e informe a mensagem de erro.

A mensagem significa que a comunicação com o webservice funcionou. O erro retornado é problema de cadastro na prefeitura que deve estar sem permissão de uso do webservice. Já o erro de validação é alguma incompatibilidade da libxml2.dll com o xsd fornecido por eles. Se tentar validar pelo Notepad++ acusa erro no XSD: Unable to parse schema file. Parsing error at line 262: Element '{http://www.w3.org/2001/XMLSchema}pattern': The value '^20(?:09|[1-9]\d)(?:0[1-9]|1[0-2])$' of the facet 'pattern' is not a valid regular expression.

Experimente configurar a propriedade SSLXmlSignLib como xsMsXML.

Do ponto de vista do emitente, sim. Do ponto de vista do destinatário, em RO ele leva multa. Em outros estados não sei dizer.

O destinatário da NFe deve fazer a manifestação. Se o destinatário é uma PJ em RO ele está obrigado a fazer isso pra todas as NFe. Não significa que o emitente não precise saber as manifestações que foram geradas para as NFe emitidas por ele. Se um destinatário manifestar NFe como "Desconhecimento da operação", o emitente terá que se explicar junto ao fisco. O desconhecimento da operação é o destinatário denunciando o emitente por fraude. Pelo método DistribuicaoDFePorUltNSU você recebe os eventos de manifestação geradas pelos destinatários.

Esse problema é entre a SEFAZ autorizadora (webservice) e a certificadora. Tive esse mesmo problema com um certificado AC SOLUTI na SVRS que ainda estão resolvendo...

Experimente substituir o xsd de schema com o anexo. nfse_v2-04.xsd

Sua instalação do Fortes está desatualizada.

Se está usando Fortes você pode desmarcar a instalação do pacote ACBr_GNREGuiaFR.dpk já que ele é para FastReport. Ou se preferir apenas atualize os fontes novamente, apliquei um ajuste no repositório.

Não pode vender sem imprimir o DANFE da NFCe, em modo normal se houve rejeição você não consegue imprimir o DANFE. Apenas em contingência off-line você tem o prazo de 24 horas.

Se houve rejeição no envio em modo normal o correto é bloquear a venda, fazer a correção, gerar novo XML e enviar novamente, para permitir a impressão do DANFE. NFCe emitida em contingência off-line deve ser transmitida em até 24 horas, após esse prazo o webservice ainda acata a NFCe com o cStat 150 - Autorizado fora do prazo, e a SEFAZ pode vir a cobrar esclarecimentos da empresa pelo atraso.

O objeto pLogoeCliche não existe nos fontes atuais do ACBr. Provavelmente você tem fontes antigos em algum local do disco que está sendo carregado pelo Delphi no momento da compilação. Faça uma busca por ACBrDANFCeFortesFr.dfm em todos os discos, se encontrar esse arquivo, desatualizado, em uma pasta que esteja no library path do Delphi pode causar esse problema.

Pode anexar o XML com o erro?

O que quer dizer com reenviar? A NFCe só é enviada uma vez.

Veja se é o teu caso:

Que saiba uma NFe de ajuste não serve como substituição a uma NFCe já emitida, é considerada uma nova nota fiscal. A não ser que a NFe de ajuste seja a "devolução", com CFOP de entrada, conforme o comentário do Jadielson mais acima. A NFe emitida em substituição a NFCe deve ter CFOP 5929 ou 6929. Cada UF pode permitir ou não a emissão de NFe com CFOP 5929/6929 em substituição a NFCe.

A versão básica do FastReport que vem junto ao Delphi não tem suporte a scripts e causa esse problema. Se instalar a versão completa do FastReport (versão 5.2 ou acima) e FastScript não é opção, você pode tentar usar os arquivos .fr3 identificados como BASIC na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi\Report\Obsoletos. Ou usar a versão em Fortes que é OpenSource.

Até onde sei PR e PA exigem cadastro da software house e/ou aplicativo emissor.

Pode esclarecer melhor? Pra mim é o mesmo campo. E no código do componente é gerado o arquivo TXINFO.TXT com o valor informado para o campo "Receita": function TACBrCargaBal.GetNomeArquivoReceita: String; begin // Urano nao possue arquivo de Receita a parte. EXCETO URANO URF32 case FModelo of modFilizola : Result := 'REC_ASS.TXT'; modToledoMGV5, modToledoMGV6: Result := 'TXINFO.TXT'; modUranoURF32: Result := 'RECEITAS.TXT'; end; end; No momento o componente usa o mesmo código do item como código de receita (informações extras no caso da Toledo).

Informe um valor para a propriedade PosPrinter.EspacoEntreLinhas, algo entre 30 e 60. Quando você deixa 0 nessa propriedade é usado o espaçamento padrão configurado na impressora, o que pode dar diferença de um equipamento pra outro.

Fiz teste em homologação e confirmei que o método DistribuicaoDFePorChaveNFe não retorna o XML completo quando a manifestação é Operação não realizada, retorna apenas o resumo da NFe. Já pelos métodos DistribuicaoDFePorUltNSU ou DistribuicaoDFePorNSU a NFe completa é retornada. Em resumo, é falha no webservice.

O componente apenas envia a solicitação para o webservice e recebe o retorno. Se o webservice ainda está devolvendo apenas o resumo da NFe para NFe com manifestação "Operação não realizada" é problema no ambiente deles. Há muitos relatos de demora no retorno da NFe completa mesmo após a manifestação aqui no fórum. Atenção que para o evento "Desconhecimento da Operação" o XML da NFe completa não é retornado pelo método DistribuicaoDFePorChaveNFe, conforme o manual.

Boa pergunta. Qual o XML de retorno?