Painel de líderes

@Ismael Faustino, enviei ao SVN.. modificações, baseado nas suas sugestões... Boa parte das mudanças na ACBrComum, não foram necessárias, após incluir uma mudança na ACBr.inc // lazrus Android com LAMW, não suporta Dialogs, Forms, {$IFDEF LAMW} {$DEFINE NOGUI} {$ENDIF} Também preferi mudar os IFDEFs para "FPC", do que "LAMW"... pois assim fica mais dependente do compilador, do que do Framework... Em synaser.pas, apliquei alguns ajustes, que já havíamos detectado aqui... para rodar em Android... Se possível, por favor atualize os fontes, com essas modificações, e reporte o resultado

Beleza, vamos estar implementando aqui e qualquer coisa retornamos para vocês.

Agora foi... ACBrComum.zip OpenSSLExt.pas ACBrSocket.pas ssl_openssl_lib.pas synaser.pas

@Ismael Faustino, muito obrigado pela contribuição... Eu mesmo pretendo analisar e fazer o Merge... Talvez seja necessário, compactar todos arquivos em um único Zip

O protocolo deve ser TLS 1.2. e dai pode ser atualizações do windows faltando

Boa tarde a todos, Já esta no SVN as alterações realizadas tanto para atender a versão 2.1.1 quanto ao novo ambiente de recepção dos eventos que agora é uma API Rest. Favor atualizarem todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes. Foram feitas alterações nos programas exemplos (Delphi e Lazarus), eles trazem dicas de como obter o retorno tanto do envio quando das consultas.

ACBrUtil.Math.pasEstou crinado este tópico para compartilhar as alterações necessário no ACBr para compatibilidade com LAMW(Desenvolvimento Android com Lazarus). Instalação LAMW. O LAMW pode ser obtido diretamente no github pelo seguinte link: :https://github.com/jmpessoa/lazandroidmodulewizard Para iniciantes pode ser usado LAMW Manager para instalar o ambiente completo de desenovolvimento. Para que deseja usar a versão 2.2.4 do Lazarus recomento instalar via FPDeluxe. Obs: O ideal é usar a versão mais recente do LAMW pois já exise ajustes oriundos da compatibilização. Alterações realizadas: 1 - Foi criado uma diretiva chama LAMW para diferenciar códigos LAMW com FMX ou VCL. 2 - Syanpse: 2.1 - synaser.pas: Este arquivo foi feito um ajuste no método procedure TBlockSerial.Flush; pois o código implementado usava um método que não existe no FPC. O código modificado foi enviado ao Synapse(https://sourceforge.net/p/synalist/feature-requests/28/) procedure TBlockSerial.Flush; begin {$IFNDEF MSWINDOWS} {$IFDEF ANDROID} ioctl(FHandle, TCSBRK, 1); {$ELSE} SerialCheck(tcdrain(FHandle)); {$ENDIF} {$ELSE} SetSynaError(sOK); if not Flushfilebuffers(FHandle) then SerialCheck(sErr); {$ENDIF} ExceptCheck; end; synaser.pas ------- 2.2 - No arquivo ssl_openssl_lib existe uma chamada para System.IOUtils que OS é Android. Fiz um tratamento iguinorar quando for FPC. Também foi modificado o InitSSLInterface, este ainda precisa de mais testes. ssl_openssl_lib.pas 3 - ACBrComum: 3.1 - O arquivos(ACBrUtil, ACBrUtil.XMLHTML.pas, ACBrUtil.Math.pas, ACBrUtil.Compatibilidade.pas, ACBrUtil.DateTime.pas, ACBrUtil.Strings.pas, ACBrUtil.Base.pas) com um chamada para a unit forms e isso impede a execução do projeto no Android. Isso ocorre pq o LCL é imbutido pelo compiado a aplicação na abre no android. Para resolver o problema foi feito o tratamento com IFNDEF LAMW nos pontos onde é feita a chama. Obs: A unit forms não é usada e poderia ser remvida destas units. ACBrUtil.DateTime.pasACBrUtil.Compatibilidade.pasACBrUtil.XMLHTML.pasACBrBase.pas 3.2 - A unit ACBrBase.pas contém uma chama para a unit Dialogs e também usa o método MessageDlg no código. Foi feito o tratamento com IFNDEF LAMW e este bloco não vai gerar problemas pois é usado apenas em tempo de desenvolvimento. ACBrReg.pas 3.3 - Na unit ACBrUtil.FilesIO.pas foi feito um tratamento para a unit forms, modificado o ApplicationPath que quando for LAMW usara o params(0). 4 - ACBrDiversos: O unico componente que apresentou problema foi ACBrCalculadora isso porque ele criar um usa TForm. Obs: Precisa de teste individual por componente. 5 - ACBrTCP: Os unicos componentes que apresentão problemas são ACBrTCPServer eACBrDownload. Obs: Precisa de teste individual por componente. 6 - ACBrPIX: Não apresentou problema com o projeto e precisa de testes. Obs: Precisa de teste individual por componente.

Prezados, existem outros tópicos de pessoas que questionaram, pediram ou sugeriram a adição da possibilidade de impressão de NFE com o componente ACBrNFeDANFeESCPOS. No último tópico a respeito disso foi sugerido que fosse alterado ACBrNFeDANFeESCPOS para ACBrNFCeDANFeESCPOS, e que o ACBrNFeDANFeESCPOS fica-se apenas para NF-e. Eu alterei o código ACBrNFeDANFeESCPOS e adicionei apenas duas propriedades (que podem ser renomeadas talvez para algo mais adequado) para determinar a adoção da "NT2020.004 - DANFE_SIMPLIFICADO v1.00" que prevê a DANFE em modelo reduzido. Como a NT não determinar um layout, mas sim apenas campos obrigatórios, eu preservei o máximo do layout atual do arquivo atual, bem como do código. Algumas impressoras ESCPOS não consegue imprimir códigos de barras c128 com 44 dígitos, o que teoricamente (questão de interpretação talvez da NT?) inviabiliza o uso do modelo, mas mesmo assim adicionei uma propriedade para desativer a impressão do código de barras c128 da chave de acesso. ACBrNFeDANFeESCPOS.pas

no arquivo de configuração ACBrLib.ini, deve utilizar tpAmb=0 (Produção). Ai funciona certinho para o ambiente que precisa.. Que bom que conseguiu resolver !

Galera, desculpa o erro foi meu! No layout da NF-e tbAmb = 1 é produção, e no .ini tbAmb = 1 é homologação. Acabei me confundindo aqui. Hj meu usuário não é mais pró!

sim corrigido pelo diego. ele está só API mas não tem PIX no caso

pode ser um Limite de Anexos na sua conta... https://www.projetoacbr.com.br/forum/attachments/

Boa tarde! Conferi junto aos outros consultores. Para o Sicredi, Híbrido com QRCode apenas via CNAB. Pode utilizar o Sicredi via API, mas não tem o QRCode.

Bom dia @C4Dev! Veja a estrutura da procedure SalvarRetornoWebService A variável ConteudoEhXML recebe o valor da função StringIsXML que procura os símbolos < e > no conteúdo da mensagem. function StringIsXML(const AString: String): Boolean; begin Result :=(pos('<', AString) > 0) and (pos('>', AString) > 0); end; O conteúdo do arquivo que você anexou é: Por isso o fluxo entendeu que o a mensagem era um JSON e gerou um arquivo JSON. Agora quanto a mensagem em si, considerando o conteúdo dela e que a mesma foi devolvido no Soap de resposta, me parece ser problema do lado do provedor. Mas caso queira confirmar, se possível, por favor, faça um revert dos seus fontes antes da última atualização que fez e detectou o problema e realize um novo teste.

Entrei em contato com o suporte da Apple. As aplicações precisam passar pela analise deles e depois fazer a distribuição para os clientes. Obrigado.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-3592

Olá @Diego Foliene Resolvi, seguindo essa dica: https://grantm.github.io/perl-libxml-by-example/installation.html

Bom dia Glauber, Você notou que na mensagem de erro o grupo Signature possui um prefixo? element ns2:Signature. Pois bem, não existe esse prefixo, o ambiente de homologação possui um bug onde espera pelo prefixo. O provedor Fiorilli esta ciente do problema e até hoje empurra com a barriga e não corrige. Infelizmente temos que fazer testes no ambiente de produção.

É importante ter as Dlls do OpenSSL atualizadas também, mas note que nesse caso eu me referi as Dlls da LibXML São as utilizadas pela configuração

Bom dia a todos. Com muita luta conseguir conversar com pessoal da libre para verificar o erro de retorno, eles identificaram o erro e ajustou, caso alguém poder também testar se agora está retornando corretamente numero da nota, xml e situação e protocolo. desde já muito obrigado.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-3590

Bom dia ! Assim q vc obteve o seu token? Sicredi //Configuração do componente ( Não há modo de homologação.. é tudo em produção ) - Solicitar para o gerente da conta liberar o produto COBRANÇA ONLINE - Entrar na conta, no meu COBRANÇA e ir na opção CÓDIGO DE ACESSO->GERAR. Será gerado um token. ACBrBoleto1.Cedente.CedenteWS.ClientID:= ( token gerado conforme explicado acima ) Somente essa opção é necessária, pois a cada requisição o ACBR envia esse token pro banco e recebe outro token para a operação solicitada. -- Demais configurações como de costume nos outros bancos -- Recomendado utilizar arquivo pfx com openSSL // ACBrBoleto.WebServices.SSCryptLib := cryOpenSSL ACBrBoleto.WebServices.SSLHTTPLib := httpOpenSSL ACBrBoleto.WebServices.SSLType := LT_TLSv1_2 ACBrBoleto.WebServices.TimeOut := 30000 ACBrBoleto.WebServices.UseCertificateHTTP := False

Boa noite, Diego Resolvido obrigado valeu

Saudações Digitais comunidade ACBr! O Componente ACBrBoleto na camada WS passou por algumas refatorações, onde a mesma foi segregada e alterada. A camada Rest não é mais proveniente do ACBrDFe, agora é via Synapse, somente a comunicação dos bancos via Soap continua via ACBrDFe. As classes foram divididas que pertencem ao WSRest e ao WSSoap : /trunk2/Fontes/ACBrBoleto/ACBrBoletoWS.Rest.OAuth.pas /trunk2/Fontes/ACBrBoleto/ACBrBoletoWS.Rest.pas /trunk2/Fontes/ACBrBoleto/ACBrBoletoWS.SOAP.pas Também informamos que com a ajuda da comunidade e contribuição Aggille Sistemas Gestão / Jean Peixoto, agora no componente foi incluído via API o banco Inter via API.

Olá Pessoal, Novamente a tabela de NCMs passará por mudanças, com as já tradicionais inclusões e também exclusões de códigos. Foi publicado a nota versão da NT que traz a nova tabele de NCM com efeitos a partir de 01/04/2023. Sobre a Vigência Ambiente de Homologação: 15/03/2023 Ambiente de Produção: 01/04/2023

Preencha o COD_VER com o valor esperado pelo validador. ../trunk2/Fontes/ACBrTXT/ACBrSPED/ACBrSPEDPisCofins/ACBrEPCBlocos.pas unit ACBrEPCBlocos; interface uses SysUtils, Classes, DateUtils, ACBrTXTUtils; type /// Vers�o do Leiaute do arquivo - TRegistro0000 TACBrCodVer = ( vlVersao100, // C�digo 001 - Vers�o 100 ADE Cofis n� 31/2010 de 01/01/2011 vlVersao101, // C�digo 002 - Vers�o 101 ADE Cofis n� 34/2010 de 01/01/2011 vlVersao200, // C�digo 002 - Vers�o 200 ADE Cofis n� 20/2012 vlVersao201, // C�digo 003 - Vers�o 201 ADE Cofis n� 20/2012 de 14/03/2012 vlVersao202, // C�digo 004 vlVersao310, // C�digo 005 - ADE Cofis n� 82/2018 - Apura��o em 01/01/2019 vlVersao320 // C�digo 006 - ADE Cofis ??? - Apura��o em 01/01/2020 ); TACBrVersaoLeiaute = TACBrCodVer;

Bom dia! Após discussão do assunto e consenso do grupo ACBr, estas opções que chegaram a existir por um tempo, foram suprimidas por momento. O entendimento é que se tiver desconto líquido ou desconto por percentual estaria o DANFE sendo impresso de forma irregular ao Manual. Abaixo segue informações do Manual de Orientação ao Contribuinte.

Olá pessoal! Com muito prazer anunciamos que foi enviado hoje cedo ao SVN mais uma nova implementação de leiaute para o Reinf. A versão 2.1. Queremos agradecer de coração ao nosso moderador @Renato Rubinho que trabalhou nessa alteração. Como sempre fiquem atentos as novidades, logo liberaremos os ajustes para o ACBrMonitor. Também, se encontrarem qualquer problema, como sempre criem tópicos no fórum para relatar. Bom trabalho a todos!

Bom dia! O problema foi resolvido, porém estou deixando aqui a solução que pode ser util para outros. O problema era na configuração do Windows, e segue o caminho: Painel de controle, Região. Aba Administrativo, alterar localidade do sistema. Deixar desmarcado o check Beta: Usar Unicode UTF-8 para suporte de linguagem mundial; No cliente eles instalaram uma camera e acredito que seja esse sistema que alterou, deixando marcado UTF-8; Obrigado a todos pela atenção!

Boa tarde a todos, A Consulta pelo numero do protocolo para atender a API Rest que é utilizada pela versão 2.1.1 já esta pronta. O componente ACBrReinf já esta realizando essa consulta e a API esta retornado o resultado do processamento. O próximo passo agora é adequar a leitura dos retornos, tanto do envio quanto da consulta, pois os retornos da API Rest não são envelopados e algumas tag estão com nomes diferentes do retorno gerado pelo WebService. Assim que essas adequações forem realizadas e testada, retornarei aqui para avisa-los. Atenção: As alterações que fiz ainda não foram para o SVN.

Boa tarde a todos, Realizei alterações no componente ACBrReinf visando o envio dos eventos da versão 2.01.01 para a API Rest. O envio foi realizado com sucesso e a API retornou o XML de retorno. Como essa API trabalha no modo Assíncrono após o envio não temos o resultado do processamento e sim apenas o numero do protocolo. De posse do numero do protocolo será necessário realizar uma consulta para que enfim possamos ter o resultado do processamento do(s) evento(s) enviado(s). O próximo passo agora é implementar no componente essa consulta. Assim que ela for implementada e testada, retornarei aqui para avisa-los. Atenção: As alterações que fiz ainda não foram para o SVN.

Boa tarde a todos, Conforme a postagem acima do Renato, a nova versão do Reinf vai passar a utilizar uma API Rest e não mais um WebService Soap. Isso significa que vamos ter que realizar alterações no componente ACBrReinf para atender esse requisito. A Equipe ACBr já esta analisando e buscando a melhor maneira de fazer essas alterações.

Boa tarde, Foram desenvolvidos os leiautes dos novos registros relacionados à versão 2.1, mas ainda não haviam disponibilizado o ambiente de testes. Para a nova versão foi alterada o forma de transmissão dos eventos, utilizando agora o modo assíncrono via REST, ao invés de webservices como era até então, conforme manual disponível neste link. O modo de envio assíncrono, necessário para envio na versão 2.1, ainda está na fila de implementações. Assim que for disponibilizado no componente atualizaremos este tópico.

Bom dia, Sugiro ainda ver o canal dedicado a estes avisos no discord.

Olá pessoal, como vocês estão indo neste começo de ano? Sem querer me alongar nessa introdução, mas não poderia deixar de agradecer a todos os nossos ouvintes de 2022. Beleza, vamos lá... às novidades! 1. Frequência semanal alterada para 2 sessões por semana, ocorrendo na terça e quinta. A ideia que acompanha essa decisão, é a de trazer mais planejamento, relevância e também audiência para os podcasts. Alguns usuários também relatavam, que ficava muito difícil acompanhar tudo, com 3 sessões por semana. Pois é, se estava difícil conciliar o tempo para acompanhar, imagina para produzir? Por esses motivos, nós vamos agora realizar as sessões na terça e quinta. O intervalo da quarta ajudará muito também o time do ACBr com as nossas outras demandas, como a produção e manutenção dos componentes e atendimento de nossos assinantes do ACBr Pro. Para alguns, essa mudança pode não soar muito como vantagem. Nós compreendemos, por isso, temos mais uma novidade à seguir! 2. Sessões com convidados presenciais, com câmeras ao vivo, transmitidas no YouTube! É isso mesmo! Nós vamos convidar as pessoas para gravarem ao vivo conosco diretamente de nossa sede no interior de São Paulo. Será um formato que você provavelmente já viu por aí em outros podcasts maiores, com câmeras gravando as expressões e gestos dos participantes e interação com o Chat ao vivo. Essas sessões ocorrerão com menos frequência, sendo sessões especiais, que vamos divulgar com muita antecedência para todos os interessados não perderem. A ideia é dar mais espaço para nossos convidados e agregar mais conteúdo com os recursos visuais que vamos ter. Assim como em uma palestra do Dia do ACBr, as sessões presenciais do Papo Pro ACBr vão ser um show de conhecimento, cultura e destaque das tendências sobre o nosso mercado, a automação comercial do Brasil! Estamos muito empolgados com as novidades que estão por vir, e vocês deverão receber mais informações em breve sobre as primeiras sessões presenciais. Por isso, fique conectado conosco, no Discord, nas redes sociais e é claro, aqui na nossa casa, o fórum do ACBr, onde você sempre será bem-vindo. Até mais, uma boa semana!

ACBrMonitorPLUS também já esta compatível com a versão 2.1 do Reinf. Atualização do Manual ACBrMonitorPLUS Rev. 27961.

Fernando, Teste desta forma: // Carrega o XML do Manifesto ACBrMDFe1.Manifestos.Clear; ACBrMDFe1.Manifestos.LoadFromFile(sNomeXML_MDFe); // Carrega o XML do Evento vinculado ao Manifesto ACBrMDFe1.EventoMDFe.Evento.Clear; ACBrMDFe1.EventoMDFe.LerXML(sNomeXML_Evento); // Imprime o Evento no papel e gera a sua imagem em PDF ACBrMDFe1.ImprimirEvento; ACBrMDFe1.ImprimirEventoPDF;