BigWings

Anexe o XML gerado.

Foi criada uma nova propriedade no componente para controlar a geração das novas tags. Veja o tópico abaixo:

Provavelmente são as quebras de linha no meio de campos e tags. O XML nem mesmo valida pelo validador da SEFAZ-RS:

Aparentemente o XSD fornecido pelo provedor ISSNET não é compreendido pela libxml2.dll. Faça teste configurando a propriedade SSLXmlSignLib do componente como xsMsXML.

O arquivo validou normalmente pelo demo do ACBrNFe e usando a pasta de schemas do ACBr.

Validando pelo demo do ACBrNFe acusou apenas falta de assinatura no XML. Erro Completo: Falha na validação dos dados da nota: 43 1871 - Element '{http://www.portalfiscal.inf.br/nfe}NFe': Missing child element(s). Expected is one of ( {http://www.portalfiscal.inf.br/nfe}infNFeSupl, {http://www.w3.org/2000/09/xmldsig#}Signature ). É preciso assinar antes de validar. E verifique novamente configuração da pasta de Schemas.

Na pasta ACBr\Projetos\ACBrMonitorPLUS\Lazarus você encontra o script de instalação do Inno Setup com a lista de arquivos.

Tente a solução do tópico abaixo:

O que vale é o XML então o que você está dizendo é que as notas deveriam ter sido geradas em contingência mas foram geradas no modo normal, e não foram autorizadas pela SEFAZ. Foi impresso o DANFE NFCe desses XML? Se foi impresso o DANFE de um XML gerado em modo normal sem o protocolo de autorização, ele é inválido e a empresa estaria sujeita a multa pelo fisco. Sendo essa a situação o que precisa ser feito é: - Entrar em contato com o assessor contábil da empresa pra que ele oriente a melhor forma de se resolver. Pode ser preciso: a) Inutilizar as numerações de NFCe que foram emitidas em modo normal mas não tiveram o protocolo de autorização gerado pela SEFAZ e; - Gerar uma NFe para acobertar essas NFCe inutilizadas ou; - Gerar novas NFCe com o mesmo propósito. Qualquer alteração no XML vai causar erro de assinatura, você precisaria gerar e assinar novamente o XML.

Isso provavelmente é uma falha da SEFAZ, afinal se o webservice acatou o envio do evento de cancelamento por substituição, a consulta da mesma deveria retornar como documento cancelado. O melhor a fazer é entrar em contato com eles e reportar o problema.

No arquivo 0-env-lot.xml continua o tpEmis = 1, por isso a rejeição.

Quer dizer que tem algo errado com a tua rotina. Configure o componente para gravar os arquivos de envio e retorno e anexe eles aqui.

O XML que você anexou está com tpEmis = 1 (normal). Dessa forma é feita a crítica da data e hora de emissão. Se a NFCe foi emitida em contingência o correto era estar tpEmis = 9.

Como já diz o trecho da NT que você citou, a rejeição não afeta as NFCe emitidas em contingência off-line. Apenas no modo normal há tolerância máxima de 5 minutos entre a data e hora de emissão e a data e hora de recebimento no webservice. Não deve ser feito nenhum tipo de alteração no XML emitido em contingência. Apenas carregar o arquivo e enviar. Se houver rejeição neste envio, sim, é permitida a correção do campo que causou a rejeição.

Veja o tópico abaixo:

A propriedade não existe mais, ela foi renomeada para "MostraPreview". Mas o seu dfm ainda consta a antiga. Basta abrir o formulário no Delphi, ignorar os erros, e salvar novamente (faça uma alteração qualquer no código para ter certeza que o Delphi vai atualizar o .dfm). Após isso ajustar as novas propriedades de acordo com o desejado.

Faça teste usando o arquivo em anexo. ACBrNFeDANFeESCPOS.pas

Movido.

Esse arquivo é do layout antigo da NFCe. Use o DANFeNFCe4_20.fr3.

Segundo o manual elas devem ser impressas na parte final da NFCe, abaixo do QRCode, identificação da NFCe e área de mensagem fiscal. http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=/xyXbAFZ71k= Está usando ACBr? Se sim, qual componente DANFE está usando?

Se a intenção é apenas baixar o XML você não precisa enviar o evento de confirmação, pode ser apenas ciência.

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.

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.

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