Pesquisar na Comunidade

Contextualizando Prezados, devido nossa aplicação ser em 3 camadas, a parte de assinatura do XML fica em uma aplicação externa em outra linguagem de programação, e no que diz respeito a parte de ENVIO basta mencionar o excelente trabalho que o projeto fez com a WinCrypt. obs: se você não sabe o porque de fazermos assim, segue o tópico EXCELENTE do Daniel O Problema Essa semana obtivemos um certificado A3 da Perto (SmartCard) e ele está pedindo PIN no servidor, e no DEBUG descobri que não era na nossa rotina de assinatura mas sim no momento do envio pela ACBr. A Causa Na unit "ACBrNFeNotasFiscais.pas", na linha 252, onde temos: TACBrNFe(TNotasFiscais(Collection).ACBrNFe).SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); 1º Ele acaba inicializando todo contexto e enviando o PIN para o SmartCard (ou Token) previamente, antes da assinatura e antes do envio. 2º Quando o evento "OnAntesDeAssinar" é disparado nosso código externo realiza a assinatura do XML nessa biblioteca externa. 3º (Não tenho certeza) É provável que ao adquirir o contexto do certificado A3 nessa aplicação nossa, e enviar o PIN tem removido o contexto da ACBR ou algo semelhante, isso já vai um pouco além do que conheço do assunto. 4º Quando o código volta para a ACBR realizar o Envio, a janela de PIN aparece. 5º Quando debugando eu faço um Jump para a próxima linha pulando a linha 252 conforme destacada acima, tudo funciona normalmente, porque não houve um contexto anteriormente adquirido acima, então no momento do envio o código para obter a chave privada funciona como se fosse executado a primeira vez. Obs: CertFreeCertificateContext também é chamado em nossa aplicação depois da assinatura do XML ser concluída, e o Store dos certificados é fechada. Possíveis Soluções Aqui que venho pedir ajuda ao pessoal responsável pelo projeto para não fazer alterações desnecessária ou que não serão aceitas. De imediato pensei em para as pessoas que assinam os XMLs em aplicações externas fica a responsabilidade da validação do CNPJ e o certificado, assim adicionando uma verificação se o evento OnAntesDeAssinar está "Assigned" antes linha 252 e resolvendo esse problema. Ou então a rotina que verifica se o CNPJ é o mesmo do certificado não realizar o envio do PIN quando o tipo for A3 por exemplo // Talvez adicionar um parametro padrão como TDFeWinCrypt.CarregarCertificado; Para TDFeWinCrypt.CarregarCertificado(const EnviarPinSeExistir: Boolean = True); E aqui seguindo a lógica de enviar o parâmetro falso para o CNPJ, até chegar na unit que verifica se os dois CNPJ são os mesmos. function TDFeSSLCryptClass.GetCertCNPJ: String; begin CarregarCertificadoSeVazio(False); Result := FpDadosCertificado.CNPJ; end; Desculpe se ficou muito extenso.

Arquivo: ACBrDFe/ACBrNFe/ACBrNFeNotasFiscais.pas Linhas: 525 e 528 Alterar de GravaLog('Validar: 208-CNPJ Emitente'); AdicionaErro('208-Rejeição: CNPJ do emitente inválido'); Para GravaLog('Validar: 208-CNPJ destinatário'); AdicionaErro('208-Rejeição: CNPJ do destinatário inválido'); Respectivamente Motivo: A validação está ocorrendo em cima do CNPJ do destinatário e não do emitente como a mensagem diz. if (Length(Trim(OnlyNumber(NFe.Dest.CNPJCPF))) >= 14) and not ValidarCNPJ(NFe.Dest.CNPJCPF) then

Boa Tarde Pessoal, Alguém sabe por que no fonte ACBrNFeNotasFiscais.pas foi removida a propriedade write da propriedade NFe? Era: property NFe: TNFe read FNFe write FNFe; Ficou no trunk2: property NFe: TNFe read FNFe; Eu utilizava assim: NFe := TNFe.create; //Populava ACBrNFe1.NotasFiscais.Add; ACBrNFe1.NotasFiscais[countNFe].NFe := NFe; [Error] Nfe.pas(7348): E2129 Cannot assign to a read-only property Qual a recomendação? por enquanto voltei o write no set da propriedade. property NFe: TNFe read FNFe write FNFe; Abraços,