BigWings

O que está mudando é o dígito referente ao tipo de emissao. 1 para normal e 9 para contingência. Nesse caso específico você precisa alterar novamente o tipo de emissão para normal, gerar novamente o XML e usar o método ACBrNFe.Consultar para atualizar o XML com o protocolo de autorização. Leia o manual de contingência off-line da NFCe, ele determina o que fazer caso haja erro na transmissão de uma NFCe em modo normal, de forma que a chave não venha a ser alterada por alteração do tipo de emissão. http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=YbZEjEHCuHQ=

Como a chave foi alterada? No processo normal de emissão em contingência a chave deve ser mantida ao transmitir o XML após a saída da contingência.

Não foram geradas chaves das NFe no XML: O motivo é falta de informar a cidade de descarregamento relacionada à NFe. Veja o exemplo do manual: [DESC001] cMunDescarga=3518701 xMunDescarga=GUARUJA ; Utilize tags abaixo para Adicionar NFes Relacionadas [infNFe001001] chNFe= SegCodBarra= indReentrega=

Aguardar a nota técnica com a implementação e prazos de entrada em homologação e produção.

Séries 890 a 899 são reservadas para a NFe avulsa, emitida pelo fisco.

Veja como está pasando a tag cUnid: O retorno da validação do schema diz que cUnid deve ter valor 01 ou 02, como está sendo passado um valor inválido está sendo gerado "00" no XML: Preenchimento do campo segundo o manual:

Apenas complementando a resposta do Italo, como os grupos infCTe e infNFe são filhos do grupo infMunDescarga, e este pode ter até 100 ocorrências, em teoria o limite máximo de documentos que podem ser informados num mesmo MDFe é de 100 municípios x 4000 documentos por município = 400.000 documentos. Lembrando que também há limite do tamanho total do XML de 1024KB.

Esse erro não deveria acontecer com cryOpenSSL. Ele ocorre quando se usa cryWinCrypt ou cryCapicom e informa um número de série de certificado digital não instalado no Windows.

Está correto se está usando o webservice do Amazonas, ja que o fuso é 1h a menos. Deve-se comparar a data e hora e fuso horário de emissão do XML com a data e hora e fuso horário do recebimento no webservice.

Uma coisa é validar a assinatura, outra é querer gerar novamente o DigestValue. Validar a assinatura é possível, basta você configurar o componente como o Italo recomendou, no que se refere as configurações SSLLib do componente.

Nativa do Delphi não conheço, mas se já usa ACBr estude o método ACBrNFe.Enviar. Quando o parâmetro Zipado é True o ACBr faz a compactação do XML e posteriormente converte em base64.

Na minha opinião, se o vendedor está emitindo o MDFe, ele está se responsabilizando pelo frete, e se está usando um veículo de terceiro, mesmo que seja do próprio destinatário da mercadoria, pelas novas regras o veículo deve ter o RNTRC. A solução para isso seria a não emissão do MDFe. Se o destinatário está buscando a mercadoria na sede do vendedor, caracteriza-se como uma operação interna, não interestadual, e sem frete. É possível emitir a NFe com endereço de outro estado e a tag idDest = doInterna, CFOP iniciando com 5. Se o destinatário está levando a mercadoria para outro estado é inteiramente por conta dele. Claro que isso é apenas palpite meu, envolve conversar com o contador, SEFAZ, fiscais...

Esse arquivo é idêntico ao do repositório.

Fiz teste com o demo, também tive o AV aqui com a mensagem de ERRO com esse método, com um token A3. Percebi que se tentasse acessar as informações do certificado, como data de vencimento, depois disso o teste passava a retornar como presente. Incluí a chamada ao CarregarCertificadoSeNecessario e passou a funcionar: procedure TForm1.Button6Click(Sender: TObject); begin if ACBrNFe1.SSL.SSLCryptClass is TDFeWinCrypt then begin try ACBrNFe1.SSL.CarregarCertificadoSeNecessario; GetCertIsHardware(TDFeWinCrypt(ACBrNFe1.SSL.SSLCryptClass).Certificado); ShowMessage('PRESENTE'); except ShowMessage('ERRO'); end; end; end;

Nesse caso é configuração incorreta. Sugiro que abra um novo tópico e detalhe melhor o problema.

O retorno apenas indica que não foi possível acessar a impressora. Pode ser configuração incorreta, problema com o driver da porta serial virtual... Você consegue imprimir normalmente apesar do erro?

Se o XML não foi gravado no momento da emissão ou autorização da nota, a única forma de "baixar" o XML é gerar novamente o XML com exatamente os mesmos dados da venda e mesmo cNF, assinar e usar o método ACBrNFe.Consultar para atualizar o XML com o protocolo de autorização. A alternativa é entrar em contato com a SEFAZ estadual e solicitar o arquivo armazenado por eles. Vou fechar o tópico por ter se desviado do assunto, caso ainda tenha dúvidas, crie um novo tópico.

Como já dito, não existe o método DistribuicaoDFe para NFCe. Para NFe você pode configurar o componente assim: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve400; A versão 3.10 já foi desativada.

Provavelmente não, não faço idéia do que você está querendo fazer.

Não existe essa seção no ACBrNFeServicos.ini. Até porque não existe ambiente nacional para NFCe. Até onde sei, os únicos serviços ativos onde se usa o ambiente nacional são os eventos de manifestação do destinatário e o método DistribuicaoDFe. Se estiver usando esses serviços, certifique-se que o componente está configurado para o modelo NFe.

A SEFAZ não disponibiliza o XML da NFCe via webservice. O emitente é o responsável legal pelo armazenamento dos arquivos XML.

A tag pDevol é em relação à quantidade devolvida: NT 2013.005 v1.22:

Não é o ACBr que está rejeitando informar com 9 dígitos, mas o próprio schema do MDFe que tem esse limite. Veja que o campo RNTRC deve ter sempre 8 dígitos de acordo com o layout: A consulta na ANTT retorna 9 dígitos para qualquer RNTRC, sempre preenchendo com zeros a esquerda. Não há nada a fazer do lado do ACBr, se o RNTRC está habilitado e está tendo rejeição deve entrar em contato com a ANTT para saber o motivo.

Que saiba nenhum estado que aderiu à NFCe exige homologação. Alguns exigem o cadastramento da empresa desenvolvedora e/ou software, como PR e PA. Essa situação pode mudar em breve, já que CTe e MDFe incluiram grupos para identificar a empresa desenvolvedora e responsável técnico, a ser informados a critério da UF. A NFe deve seguir o mesmo caminho. https://cdn.sefin.ro.gov.br/portalnfce/9ac05befca7d6499e3abec9bdfef2b68.pdf