Unit ACBrNFe.Classes com dependência de pcnConvercaoNFe

[Zer0]

O tipo da propriedade  TPag (TpcnFormaPagamento) de TpagCollectionItem presente em ACBrNFe.Classes ainda está referenciando a unit pcnConversaoNFe. Como estamos fazendo alterações no projeto para usar ACBrNFe.Conversao está havendo conflito.

[Zer0]

Outras propriedades da classe TPagCollectionItem também estão fazendo referência para tipos que estão em pcnConversaoNFe ao invés de ACBrNFe.Conversao

[Juliomar Marchetti]

use a pesquisa do delphi e olhe nos fontes as declarações 

mas houve mudanças hoje no código que notei

[Zer0]

15 hours ago, Juliomar Marchetti said:

use a pesquisa do delphi e olhe nos fontes as declarações 

mas houve mudanças hoje no código que notei

Testei na versão mais recente, mas ainda assim classes de  ACBrNFe.Classes  continua fazendo referência para tipos em pcnConversaoNFe.

[Juliomar Marchetti]

2 horas atrás, Zer0 disse:

Testei na versão mais recente, mas ainda assim classes de  ACBrNFe.Classes  continua fazendo referência para tipos em pcnConversaoNFe.

Eu vi algum lugar aqui no fórum que foi recriado uma unit diferente para centralizar todas. 
confere no showlog e creio que vá precisar declarar ela pra suar

[Gildenor]

11 minutos atrás, Juliomar Marchetti disse:

Eu vi algum lugar aqui no fórum que foi recriado uma unit diferente para centralizar todas. 
confere no showlog e creio que vá precisar declarar ela pra suar

 

[Zer0]

Cheguei a ler este tópico. E atualizei o nosso fonte de acordo. No entanto o problema de conflito persiste. Vou tentar explicar com um exemplo.

...
uses
  ACBRNFe.Classes;

procedure FazAlgumaCoisa;
var
  Pag: TPagCollectionItem;
begin
	...	
	Pag.tpag := fpDinheiro; // O tipo esperado aqui por TPagCollectionItem é o que está em pcnConversaoNfe.TpcnFormaPagamento ao invés de ser ACBrNFe.Conversao.TpcnFormaPagamento
end;

Como estamos atualizando os nossos fontes para fazer uso de ACBrNFe.Conversao,  no exemplo dado, fpDinheiro seria do tipo que está em ACBrNFe.Conversao, mas TPagCollectionItem.TPag ainda faz referencia para o tipo antigo. Desta forma, o Delphi reclama que os tipos são diferentes. 

Consegui contornar o problema declarando na mesma unit tanto pcnConversaoNFe quanto ACBrNFe.Conversao. E no ponto onde ocorria o problema coloquei 

Quote

Pag.tpag := pcnConversaoNFe.fpDinheiro;

Como está em processo de refatoração ainda. Acredito que logo irá ser alterado as referências de pcnConversao para ACBrNFe.Conversao na unit ACBrNFe.Classes.

[Juliomar Marchetti]

dúvida tu não tá com todos os componentes do delphi nesse form ou datamodule?

[Zer0]

45 minutes ago, Juliomar Marchetti said:

dúvida tu não tá com todos os componentes do delphi nesse form ou datamodule?

Não é Form nem Datamodule, é uma unit comum de código. As dependências dela com o código ACBr são: ACBrNFe.Classes, ACBrUtil.Math, ACBrDFe.Conversao, pcnConversaoNFe.

[Clayton Alves]

Reproduzi o problema aqui:

Mensagem de erro:

[dcc32 Error] Unit1.pas(31): E2010 Incompatible types: 'pcnConversaoNFe.TpcnFormaPagamento' and 'ACBrNFe.Conversao.TpcnFormaPagamento'

Código para teste:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
  TForm1 = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

uses
  ACBrNFe.Conversao, ACBrNFe.Classes;

procedure FazAlgumaCoisa;
var
  Pag: TPagCollectionItem;
begin
  Pag.tpag := fpDinheiro;
  // O tipo esperado aqui por TPagCollectionItem é o que está em pcnConversaoNfe.TpcnFormaPagamento ao invés de ser ACBrNFe.Conversao.TpcnFormaPagamento
end;

end.

 

 

[Clayton Alves]

Essas últimas modificações no ACBr para eliminar as pcn* estão impactando negativamente nossa base de código.

O problema é a unit ACBrNFe.Classes depender da unit pcnConversaoNFe quando na verdade deveria depender da ACBrNFe.Conversao.

A partir do momento que começamos a adotar ACBrNFe.Conversao no lugar da pcnConversaoNFe, somos obrigados a realizar
typecasts para os tipos em pcnConversaoNFe pois a maioria do código do ACBr (ex: unit ACBrNFe, ACBrNFeWebServices, etc)
ainda depende de pcnConversaoNFe.

Eu recomendo fortemente que NÃO atualizem ainda seus projetos para as units ACBrDFe.Conversao e ACBrNFe.Conversao.

No nosso caso foi mais fácil criar um fork do ACBr corrigindo as dependências do que introduzir typecasts em todo o projeto.

Fork: https://github.com/ellotecnologia/ACBr/commit/071a31841d1fa7219444931afa3eb4febfa14787

Tópico relacionado: 

 

Editado 11 Novembro, 2025 por Clayton Alves

[Juliomar Marchetti]

Que coisa mais estranha

to com o svn atualizado e rodando na empresa e não estou tendo esses erros.

mas é que uso o ACBr e si se modificações

[Clayton Alves]

12 hours ago, Juliomar Marchetti said:

Que coisa mais estranha

to com o svn atualizado e rodando na empresa e não estou tendo esses erros.

mas é que uso o ACBr e si se modificações

@Juliomar Marchetti, se puder faz um teste aí, projetinho simples, console.

Adiciono na seção "uses" somente as duas units: ACBrNFe.Classes, ACBrNFe.Conversao

program Project1;

{$APPTYPE CONSOLE}

uses
  ACBrNFe.Classes, ACBrNFe.Conversao;

var
  Pag: TPagCollectionItem;
begin
  Pag.tpag := fpDinheiro; // Incompatible types: 'ACBrNFe.Classes.TpcnFormaPagamento' and 'Project1.TpcnFormaPagamento'
end.

Se tentar compilar irá ver o erro "Incompatible types".

Isso acontece pq a propriedade TPagCollectionItem.tpag, que é do tipo TpcnFormaPagamento, é na verdade pcnConversaoNFe.TpcnFormaPagamento. Como eu não adicionei pcnConversaoNFe ao projeto, ele usa a definição do enumerado fpDinheiro que ele encontra em ACBrNFe.Conversao.

Uma solução menos drástica que um fork, seria adicionar também a pcnConversaoNFe, posteriormente a ACBrNFe.Conversao. Nesse caso o projeto compila "de boas":

program Project1;

{$APPTYPE CONSOLE}

uses
  ACBrNFe.Classes, ACBrNFe.Conversao, pcnConversaoNFe;

var
  Pag: TPagCollectionItem;
begin
  Pag.tpag := fpDinheiro;
end.

A ordem das units é importante pois o Delphi dá preferência para a última unit encontrada.

Mas fazendo isso a unit ACBrNFe.Conversao se torna redundante e pode até ser removida, o que volta no ponto que comentei: melhor nem adicionar a unit ACBrNFe.Conversao como dependência dos projetos enquanto essa migração não for totalmente concluída.

[Juliomar Marchetti]

então aponta a unit que vai usar já que tem todos os componentes na mesma DM quem sabe

NomeUnit.OTipoQueUsar

[EMBarbosa]

Em 12/11/2025 at 08:43, Clayton Alves disse:

A ordem das units é importante pois o Delphi dá preferência para a última unit encontrada.

Mas fazendo isso a unit ACBrNFe.Conversao se torna redundante e pode até ser removida, o que volta no ponto que comentei: melhor nem adicionar a unit ACBrNFe.Conversao como dependência dos projetos enquanto essa migração não for totalmente concluída.

Precisamos fazer aqui na pcnConversaoNFe, o mesmo que fizemos com a ACBrDFe.Conversao. Ou seja, fazer os tipos da pcnConversaoNFe apontar para os tipos da ACBrNFe.Conversao.

Por conta do evento do Dia do ACBr e dos esforços para a Reforma Tributária, não conseguimos terminar isso antes.

Vamos verificar, mas toda ajuda é bem vinda.