Ivan Cesar

Agradeço ao Juliomar e ao Régys pelas respostas, mas eu já tinha seguido esses procedimentos descritos. Sempre instalei os pacotes individualmente, e tenho pastas personalizadas para cada tipo de arquivo gerados pelo compilador (.BPL, .DCP, .DCU, etc..) O instalador usa uma estrutura diferente da minha para os arquivos, e da primeira tentativa de uso dele ( antes da atualização ), ficou perdido um arquivo .DCP nessa estrutura. Após o erro, eu reconfigurei os pacotes para gravarem na minha estrutura, mas como a IDE carregava esse pacote desatualizado, apresentava o erro. Localizei-o e exclui, e tudo se resolveu da forma que está. Muito obrigado mais uma vez.

Pessoal, desculpem se o tópico está repetido, acho que coloquei o outro no local errado mas não consegui exclui-lo depois. O erro é sobre a chamada do método TDFeSSL.ValidarCNPJCertificado, após a atualização em 17/02/2016 (e não em 17/01/2016, como postado anteriormente), como segue no tópico

Após atualização do repositório do ACBr, mais precisamente no dia 17/01/2016 -- ACBrDFeSSL -- [+] Adicionado o método TDFeSSL.ValidarCNPJCertificado(CNPJDocumento: String); Dispara exception se o "CNPJDocumento" não contiver a mesma raiz do CNPJ do Certificado (por: DSA) quando vou instalar os pacotes, é apresentado o erro: Não foi possível localizar o ponto de entrada do procedimento @Acbrdfessl@TDFeSSL@ValidarCNPJCertificado$qqr20System@UnicodeString na biblioteca de vínculo dinâmico ..\ACBr Trunk2\Lib\Delphi\LibD21\ACBr_CTe.bpl. ( se repete em ACBr_NFe e todas as classes que usam esse método ) Conforme pode ser visto na imagem em anexo O erro é apresentado tanto usando tanto o instalador como em instalação individual pela IDE. Já removi todas as referências do ACBr da IDE, limpei o registro, recriei a pasta do SVN, ou seja, mesmo em uma instalação nova e limpa acontece o mesmo. Para poder instalar, em cada classe, comentei a linha onde tem a chamada dessa função. Fica o relato caso mais alguém esteja tendo esse erro.

Passando um xml para o ACBrNFe, usando LoadFromString, faço uma análise no conteúdo carregado pelo componente desse xml, retornando os valores das propriedades do mesmo. Fazendo uma verificação, percebi que após ele carregar o xml, na propriedade Det.Imposto.ICMS.CST sempre é carregado o cst00, mesmo não existindo essa tag no xml passado. Analisando a forma que ele carrega, é usada a função StrToCSTICMS que por sua vez usa a StrToEnumerado, retornando sempre o primeiro valor encontrado em caso de erro ou de não achar nenhum dos passados no array. Como não tem essa tag no xml, esse valor sempre é o cst00. Então quando eu mando analisar se o Det.Imposto.ICMS.CST <> cstVazio sempre retorna True. Notei que existe o cstVazio, mas ele não é referenciado nas funções de conversão, então alterando a assinatura das funções de: function CSTICMSToStr(const t: TpcnCSTIcms): string; begin ... result := EnumeradoToStr(t, ['00', '10' , '20' , '30' , '40' , '41' , '50' , '51' , '60' , '70' , '80' , '81', '90', '10', '90', '41', '90', 'SN'], [cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstPart10 , cstPart90 , cstRep41, cstICMSOutraUF, cstICMSSN]); end; function StrToCSTICMS(var ok: boolean; const s: string): TpcnCSTIcms; begin result := StrToEnumerado(ok, s, ['00', '10', '20', '30', '40', '41', '50', '51', '60', '70', '80', '81', '90', '91', '92'], [cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstICMSOutraUF, cstICMSSN]); end; para function CSTICMSToStr(const t: TpcnCSTIcms): string; begin ... result := EnumeradoToStr(t, ['', '00' , '10' , '20' , '30' , '40' , '41' , '50' , '51' , '60' , '70' , '80' , '81', '90', '10', '90', '41', '90', 'SN'], [cstVazio, cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstPart10 , cstPart90 , cstRep41, cstICMSOutraUF, cstICMSSN]); end; function StrToCSTICMS(var ok: boolean; const s: string): TpcnCSTIcms; begin result := StrToEnumerado(ok, s, ['', '00', '10', '20', '30', '40', '41', '50', '51', '60', '70', '80', '81', '90', '91', '92'], [cstVazio, cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstICMSOutraUF, cstICMSSN]); end; resolve esse problema. O mesmo acontece com outras propriedades tipadas que usam conversões na leitura, como TpcnMotivoDesoneracaoICMS, pois não existe um valor mdiVazio pra esse tipo. Minha dúvida é se esse procedimento não vai afetar em algum outro procedimento usado pela classe. Gostaria de um parecer do pessoal mais experiente, e fica minha sugestão para criar tipos vazios para serem usados nas conversões e caso seja possível, para ser implementado no repositório. Agradeço os retornos.

Na minha humilde opinião, acho que poderia ser usado retorno string nessa propriedade ao invés de um tipo, uma vez que existe a função funChecaCST, pode-se usar a mesma para validar essa string de retorno, ficando assim livre caso sejam atribuídos novos valores, como foi o caso.