BigWings

Veja minha resposta no tópico abaixo:

Veja qual componente DANFE está associado ao ACBrNFe, alguns deles são específicos para NFCe.

Como você está informando a propriedade PathSchemas?

Se você recebeu o resumo da NFe, então ela é destinada ao CNPJ informado. Se você recebeu a NFe completa, carregue o XML no componente ACBrNFe e verifique a propriedade ACBrNFe1.NotasFiscais.Items[0].NFe.Dest.CNPJCPF.

Está configurando a versão do componente para o layout 4.00? ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

Não há como fazer o que quer pelo FormatDateTime. Uma forma de fazer seria usando o componente ACBrExtenso. uses ACBrExtenso; [...] function DataPorExtenso(const AData: TDateTime): String; var ACBrExtenso: TACBrExtenso; Y, M, D: Word; begin ACBrExtenso := TACBrExtenso.Create(nil); try ACBrExtenso.StrMoeda := ''; ACBrExtenso.StrMoedas := ''; DecodeDate(AData, Y, M, D); Result := Trim(ACBrExtenso.ValorToTexto(D)) + ' de ' + FormatDateTime('mmmm', AData) + ' de ' + Trim(ACBrExtenso.ValorToTexto(Y)); finally ACBrExtenso.Free; end; end;

Você pode verificar o tipo do documento no retorno do método DistribuicaoDFe. ACBrNFe1.DistribuicaoDFe(cUF, CNPJCPF, UltNSU, ''); case ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.cStat of 138: begin for I := 0 to ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count - 1 do begin case ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[I].schema of schprocNFe: ; // NFe completa schresNFe: ; // resumo da NFe schprocEventoNFe: // evento schresEvento: // resumo de Evento [...]

Apliquei essa correção ontem, inserindo a validação pelo protocolo, para não mostrar mais a mensagem quando a NFCe já está autorizada. Você afirma que mesmo com a correção, continua aparecendo a mensagem de pendente de autorização? Se sim, por favor, informe quando arquivo .fr3 está usando e anexe o XML.

Aqui tem uma forma localizar o número de série do certificado pelo CNPJ, você pode adaptar o método para procurar pelo SubjectName: Note que o SubjectName pode mudar caso seja um novo certificado.

Correto, se você abrir o arquivo ACBrBPeServicos.ini, verá que para SP ele está configurado para direcionar para a SVRS: [BPe_SP_H] Usar=BPe_SVRS_H ;URL-QRCode= URL-ConsultaBPe= Você pode alterar o arquivo com as URLs e salvar o .ini no diretório da aplicação, que ele será usado para carregar as URL. Segue o arquivo já modificado: ACBrBPeServicos.ini Fiz apenas teste de status de serviço, mas percebi que o retorno está com estrutura diferente do esperado pelo componente (e retornado pela SVRS). Provavelmente serão necessários ajustes.

Você pode: - Comparar o digest value da assinatura com o digest value do protocolo: ACBrBPe1.Bilhetes.Clear; ACBrBPe1.Bilhetes.LoadFromFile(OpenDialog1.FileName, False); if ACBrBPe1.Bilhetes[0].BPe.Signature.DigestValue <> ACBrBPe1.Bilhetes[0].BPe.procBPe.digVal then raise Exception.Create('DigestValue do documento não confere com o DigestValue do protocolo'); - Fazer a consulta do BPe para obter o DigestValue do protocolo retornado: ACBrBPe1.Bilhetes.Clear; ACBrBPe1.Bilhetes.LoadFromFile(OpenDialog1.FileName, False); ACBrBPe1.Consultar; if ACBrBPe1.Bilhetes[0].BPe.Signature.DigestValue <> ACBrBPe1.WebServices.Consulta.protBPe.digVal then raise Exception.Create('DigestValue do documento inválido'); Os componente ACBrNFe e ACBrCTe fazem a validação da assinatura, assim como o ACBrBPe. Um DigestValue incorreto incorreria em erro na validação da assinatura, então não vejo o motivo de insistir em validar apenas pelo digest.

Pelo decreto, a alteração é definitiva, ou até que seja emitido novo decreto: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2017/decreto/D9242.htm Enviei ajuste para o repositório, favor atualizar os fontes e testar. Revision: 15862 Author: bigwings Date: terça-feira, 23 de outubro de 2018 16:08:06 Message: 23/10/2018 -- pcnAuxiliar -- [*] Ajuste na função "GetInicioDoHorarioDeVerao" de acordo com as novas regras. https://www.projetoacbr.com.br/forum/topic/47233-erro-na-function-getiniciodohorariodeverao/ Por: BigWings

Veja o tópico abaixo:

Por conta de heranças de classes a propriedade ainda aparece nos componentes DANFE NFCe. Por motivos como esse que está sendo feito um refactoring nas classes de impressão de DANFEs, DACTEs, DAMDFes...

A propriedade se aplica somente a NFe.

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=

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.

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.

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;