BigWings

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.

Acho que não compreendi a pergunta... O que precisa corrigir é o campo tpEmis.

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

Veja minha resposta no tópico abaixo, é o mesmo caso:

Correção enviada, rev. 16903.

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.

Acho que não porque a tag CNPJ será gerada então a CPF não seria necessária. A validação do tamanho do CNPJ 0 ou 14 dá a entender que qualquer uma das tags a seguir seriam válidas: <CNPJ/> <CNPJ></CPNJ> <CNPJ>99999999999999</CNPJ> <CPF>99999999999</CPF>

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.

Aparentemente, é possível sim. Vendo o XML anexado que foi autorizado, o ACBr gera a tag CNPJ no grupo de Entrega, mas sem conteúdo. E isso é aceito pelo layout, o campo CNPJ é obrigatório mas o tamanho pode ser 0 ou 14. Já o CPF caso informado deve ser gerado com 11 caracteres. Acho que pode ser modificado para verificar pelo campo xLgr que é realmente de informação obrigatória no grupo.

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

Boa tarde, Já leu o guia prático? Essa dúvida você pode tirar facilmente por ele. http://sped.rfb.gov.br/arquivo/download/2734 Respondendo a pergunta, as notas fiscais de prestação de serviço são informadas no registro A100 e registros filhos.

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?

O QRCode é validado pelo webservice, se tivesse algum problema com ele a NFCe não seria autorizada. Se algumas NFCe consultam e outras não é preciso saber o que está diferente entre eles, mas sem dúvida é problema na página de consulta da SEFAZ-ES.

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.

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.