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 ?

Alguns aplicativos de Banco permitem que o cliente faça o pagamento utilizando o Limite de Crédito disponibilizado pelo banco. No nosso sistema a geração do QrCode Pix Sicredi utilizando o ACBr está funcionando normal. Porém se o cliente do estabelecimento tenta fazer a leitura do QrCode para pagar utilizando o Limite de Crédito, o aplicativo do banco diz que o QrCode é inválido. Para contornar o problema, o operador do caixa gerou o QrCode por uma "Maquininha" POS e o aplicativo do cliente leu sem problemas. Minha dúvida é: Será que preciso configurar algo no ACBr antes de solicitar a geração do QrCode na API do Sicredi de modo que o QrCode para recebimento utilizando limite de crédito seja válido ? Ou Será que é algum problema no aplicativo do banco do Cliente do estabelecimento ? Segue imagem do QrCode gerado pelo nosso sistema: Texto do QrCode gerado pelo nosso sistema: 00020126860014br.gov.bcb.pix2564pix-qrcode.sicredi.com.br/qr/v2/2e55525d8fad4a9d993b2f28bcecdd335204000053039865802BR5903PIX6006Cidade62070503***63047202 A seguir o QrCode gerado pela maquininha: E esse pela maquininha: 00020101021226580010BR.COM.ELO0104516102150000000920335150308APT69FFD0401P52045411530398654041.005802BR5912J C DA SILVA6005Sinop6108785533086213050931568442980560010BR.COM.ELO011004101737530203C0003020104066844290801363044480

Aparentemente como zip vai OK. ACBrTEFAPIElginComum.zip

A implementação do TEF Elgin possui alguns vazamentos de memória. A unit corrigida pode ser obtida nesse link. Não anexei a unit pois o fórum está me retornando erro quando eu tento anexar:

@Daniel Simoes @WINDEL Por acaso vocês tiveram retorno da Setis sobre esta questão da imagem no Pinpad ?

@Cleber Ferreira sim, pode fechar... achei que marcando a resposta como solucionada já fechava automaticamente.

Pergunta meio boba mas não achei em lugar nenhum. Qual o significado de "CD" no nome do componente ACBrPIXCD ?

Boa tarde @Pedro Frayman, Muitos dos meus clientes utilizam a Verifone C680. Alguns com a Stone. Outros com a cooperativa Sicredi. Então pensei que era possível integrar meu sistema com essas maquininhas utilizando o ACBrPOSTEF. Sabe me dizer se existe documentação disponível para esses outros equipamentos? sem ser SmartPOS. Fiz uma busca na internet mas não achei nada.

Existem outras "maquininhas" que suportam integração POSTEF além da PAX S920 ? Vi algumas empresas utilizando integração do sistema comercial com a Verifone C680 e também com a Q92. Essas máquinas são compatíveis com o ACBrPOSTEF ? Existem outros modelos compatíveis ?

Especificamente no caso do TMedCollection não teriam memory leak já que o TMedCollection é uma TObjectList que é dona de seus itens, ou seja, os itens serão liberados junto com a coleção no momento da liberação. Por fim o trecho abaixo resolveu meu problema de AV, mas é um "workaround" e acredito que a não duplicação desses itens possa ocasionar problemas no futuro. FProd.Assign(ItemXML.Prod); // Ajuste técnico FProd.med.OwnsObjects := False; FProd.med.Clear; FProd.med.OwnsObjects := True; Agradeço o tempo de vocês.

Mas só pra deixar claro, meu problema nem é com a TDetCollection (apesar de para mim estar claro que existe um problema na cópia) e sim com a classe TMedCollection que não implementa o Assign de modo a criar cópias do TMedCollectionItem.