Clayton Alves

Esse tópico pode ser fechado. Correção aplicada na revisão 44204 do svn https://sourceforge.net/p/acbr/code/44204/tree//trunk2/Fontes/ACBrDFe/ACBrNFSeX/Provedores/Coplan.Provider.pas?diff=51af3fbbe88f3d037b5f1a76:44203

Anexo uma correção para ler corretamente o Número da nota (e data de emissão) da resposta enviada pela Coplan. Código está de atualizado conforme arquivo no commit 43995 do svn. Coplan.Provider.pas

Pra não duplicar a resposta, vou apenas adicionar aqui a referência a ela:

@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.

Bom dia, no nosso projeto fazemos uso "pesado" de tipos (classes) e enumerados do ACBr. Ao trocar de pcnConversaoNFe pra ACBrNFe.Conversao nossos fontes começaram a ter muita dependência com tipos definidos na pcnConversaoNFe, apesar de não mais fazermos referência a tela. O problema é que a ACBrNFe.Classes ainda depende da pcnConversaoNFe e isso cria uma imcompatibilidade de tipos forçando a fazer um typecast e nos obrigando novamente a fazer uso ("uses") da pcnConversaoNFe em nosso código.

Eu recomendo, se possível, não migrar ainda de pcnConversaoNFe pra ACBrNFe.Conversao. Discuti sobre isso aqui:

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:

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.

Alguém já tem informações sobre como irá funcionar o recebimento recorrente com Pix automático? Serão disponibilizados novos endpoints nas APIs Pix dos bancos ? Já divulgaram alguma documentação ?

@Daniel Simoes se fosse uma exceção mais específica (algo como ACBrExceptionAlgumaCoisa), até concordaria com você. Mas a exceção em questão é EConvertError, uma exceção genérica e que pode ser levantada em outros lugares no código. Ignorar essa exceção poderia mascarar problemas em outros pontos do código.

Exatamente @Daniel Simoes, como mencionei Porém a IDE do Delphi reporta a exceção e temos que clicar em OK pra continuar, pelo menos 4 vezes.

Em ambiente de testes/homologação (não testei em produção) ao finalizar o recebimento no TEF PayGo o Delphi reporta 4 vezes a exceção: EConvertError '' is not a valid integer value Essa exceção ocorre na unit ACBrBase, classe TACBrInformacao, método GetAsDate, ao executar StrToInt: function TACBrInformacao.GetAsDate : TDateTime; var DataStr, AnoStr: String; begin DataStr := OnlyNumber( Trim(fInfo) ); if (Length(DataStr) = 6) then // DDMMYY, converte para DDMMYYYY begin AnoStr := IntToStr(YearOf(Today)); DataStr := copy(DataStr,1,4) + copy(AnoStr,1,2) + copy(DataStr,5,2); end; try Result := EncodeDate( StrToInt(copy(DataStr,5,4)), // EXCEÇÃO AQUI !!! StrToInt(copy(DataStr,3,2)), StrToInt(copy(DataStr,1,2)) ) ; except Result := 0 ; end; end; A exceção é tratada no bloco try..except então ela não propaga para quem chamou. Mas o fato de ela acontecer pelo menos 4 vezes em uma operação que foi bem sucedida é um pouco chato. Uma solução simples seria: function TACBrInformacao.GetAsDate : TDateTime; var DataStr, AnoStr: String; begin DataStr := OnlyNumber( Trim(fInfo) ); // ********* SUGESTÃO ********* Result := 0; if Trim(DataStr) = '' then exit; // ********* SUGESTÃO ********* if (Length(DataStr) = 6) then // DDMMYY, converte para DDMMYYYY begin AnoStr := IntToStr(YearOf(Today)); DataStr := copy(DataStr,1,4) + copy(AnoStr,1,2) + copy(DataStr,5,2); end; try Result := EncodeDate( StrToInt(copy(DataStr,5,4)), StrToInt(copy(DataStr,3,2)), StrToInt(copy(DataStr,1,2)) ) ; except Result := 0 ; end; end;

Dando um feedback sobre o progresso: Descobri que realmente o QrCode crédito não é um QrCode Pix e sim um QrCode de Carteira Digital do Sicredi.

Realmente, isso eu não havia percebido.

QrCode dinâmico. Sim, o QrCode gerado pela maquininha é bem maior. A questão é: que dados precisam ser enviados para permitir usar o limite de crédito ?