Painel de líderes

Olá Pessoal, Caso alguém tenha informações sobre as cidades abaixo no que se refere a provedor, URLs, schemas, por favor nos informes. A ideia é fazer com que o componente ACBrNFSeX atenda o maior numero possível de cidades acima de 100 mil habitantes. Cidades com mais de 200 mil habitantes não atendidas pelo componente: 2303709 Caucaia/Ceará - Trabalha com formato TXT e no site tem a opção para importar o arquivo Cidades com menos de 200 mil e mais de 100 mil habitantes não atendidas pelo componente: 1301902 Itacoatiara/Amazonas 1303403 Parintins/Amazonas 1500107 Abaetetuba/Pará 1501709 Bragança/Pará 1501808 Breves/Pará 1502103 Cametá/Pará 1505502 Paragominas/Pará 1507953 Tailândia/Pará 1508100 Tucuruí/Pará 1600600 Santana/Amapá 2103307 Codó/Maranhão 2107506 Paço do Lumiar/Maranhão 2111201 São José de Ribamar/Maranhão 2306405 Itapipoca/Ceará 2307700 Maranguape/Ceará 2510808 Patos/Paraíba 2513703 Santa Rita/Paraíba 2600054 Abreu e Lima/Pernambuco 2606804 Igarassu/Pernambuco 2612505 Santa Cruz do Capibaribe/Pernambuco 2613701 São Lourenço da Mata/Pernambuco 2900702 Alagoinhas/Bahia 2924009 Paulo Afonso/Bahia 3300308 Barra do Piraí/Rio de Janeiro 3302270 Japeri/Rio de Janeiro 3516408 Franco da Rocha/São Paulo 3547304 Santana de Parnaíba/São Paulo Ultima checagem com o arquivo ACBrNFSeXServicos.ini realizada na data de 19/04/2024.

Olá Pessoal, Mais um documento fiscal eletrônico a vista. Portal do DC-e: Portal da Declaração de Conteúdo Eletrônica (svrs.rs.gov.br) Está disponível no Portal dos Documentos Fiscais Eletrônicos a área temática dedicada a Declaração de Conteúdo Eletrônica - DCe. Nesta área poderá ser encontrado material técnico como Manuais e Schemas, Legislação, Notícias e serviços relacionados ao documento fiscal. O que vem a ser o DC-e: O Projeto DCe tem como objetivo a implantação de um modelo nacional de declaração de conteúdo eletrônica, visando a substituir a sistemática de utilização da declaração de conteúdo em papel, melhorando a visibilidade dessa declaração e permitindo, ao mesmo tempo, o acompanhamento em tempo real das operações. No Portal encontramos os Manuais e os Schemas, ainda não estão disponíveis as URLs de homologação e de produção (vamos aguardar). Para informações sobre a legislação, acesso o portal pois estão disponíveis tanto o ajuste SINIEF que instituiu o DC-e quanto o Ato COTEPE.

Olá pessoal! O envio do MDFe de forma assíncrona está com os dias contados, com a previsão de ser encerrado no dia 30/06/2024. O tópico abaixo tem mais detalhes a respeito. Mas fica então o questionamento, o que muda? Bem, antes de falar sobre isso, vamos responder a outra pergunta: Qual é a diferença entre o envio assíncrono e o envio síncrono? De maneira bem simples, a diferença entre essas formas de envio é a quantidade de conexões que é feita para com o web service da Sefaz. No envio assíncrono, primeiro sua aplicação envia o XML para o web service e recebe um número de recibo. Então, a aplicação faz uma nova requisição para o web service consultando o número de recibo para obter as rejeições ou em caso de sucesso o MDFe. Já no envio síncrono, em uma só requisição é enviado para o web service e na resposta já vem as rejeições ou o MDFe quando em caso de sucesso. Se você pensou: Isso se deve ao fato de que visando auxiliar os desenvolvedores que utilizam o componente, esse processo é automatizado, ou seja, a consulta já era feita automaticamente pela solução. Entendi a diferença entre os modos de envio, mas o que eu preciso mudar na minha aplicação? A primeira coisa que você deve se atentar é no comando que utiliza para fazer o envio do MDFe para o web service. Veja quais são os parâmetros do método Enviar no comando nativo. // Parâmetros do método Enviar: // ALote = Número do Lote // AImprimir = Se True imprime automaticamente o DAMDFE // ASincrono = Se True o envio é no modo Síncrono, caso contrario Assíncrono. ACBrMDFe.Enviar(Alote, AImprmir, ASincrono); Estes parâmetros são refletidos também nos comandos tanto da Lib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); Quanto do Monitor: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) Parâmetros: nXMLMDFe - Caminho do XML do MDF-e nLote - Número do Lote (opcional) nAssinar - Assinar o XML (opcional - informe 0 para não assinar) nImprimi - Imprimir MDF-e (opcional - informe 1 para imprimir) nImpressora - Nome da Impressora (opcional) bAssincrono - Por padrão o envio é Assíncrono, informa "False" para envio Sincrono bEncerrado - Imprimir Mensagem de "MDFe Encerrado", (opcional - informe 1 para imprimir) Então, a partir de 30/06/2024, será preciso informar corretamente o parâmetro que define o modo de envio, para que o mesmo seja feito de forma síncrona. No momento de ler o retorno, também serão necessárias mudanças. Caso utilize o componente nativo para Delphi/Lazarus, a classe que vai ler as informações não é mais a Retorno e sim a Enviar. //Ao invés de ler as informações de: ACBrMDFe.WebServices.Retorno.XXXX //Agora vai ler de: ACBrMDFe.WebServices.Enviar.XXXX Se você utiliza o Monitor ou a Lib, a principal diferença será no momento de ler as informações do MDFe. No envio assíncrono elas ficavam contidas na seção [MDFe + Número do MDFe], no entanto, na resposta do envio síncrono elas ficam em [MDFe+ Chave de Acesso do MDFe]. Mas eu não tenho a Chave de Acesso ainda, como vou conseguir ler? A chave de acesso de um documento fiscal deve ser montada seguindo uma regra estabelecida no MOC. Por isso, tanto a Lib quanto o Monitor possuem um método específico que se alimentado com as informações necessárias devolvem a chave de acesso montada. São eles: MDFe.GerarChave para o Monitor. MDFe_GerarChave para a Lib. Portanto, fazendo uso deste método é possível obter a informação que é precisa para realizar a leitura da seção.

Olá Pessoal, Muitos DF-e (Documentos Fiscais Eletrônicos) foram implementados para o seu envio ser em Lotes contendo de 1 até 50 documentos. Esse modo de envio em lote funciona no modo assíncrono. Outros DF-e já foram implementados com o modo de envio unitário, ou seja, só podemos enviar um documento por vez, consequentemente esse modo de envio funciona no modo síncrono. A primeira diferença que podemos notar é: No envio assíncrono podemos enviar um lote contendo de 1 até 50 documentos, já no envio síncrono podemos enviar somente um documento por vez. A segunda diferença diz respeito ao retorno: No envio assíncrono temos como retorno do webservice um numero chamado de Recibo que atesta que o webservice recebeu o lote enviado, por outro lado no envio síncrono não temos o numero do Recibo como retorno. A terceira diferença se refere ao resultado do processamento: No envio assíncrono devemos realizar uma consulta se utilizando do numero do Recibo. É o retorno dessa consulta que nos vai dizer se o(s) documento(s) enviado(s) para o webservice foi ou foram processado(s) com sucesso. Já no envio síncrono não temos no retorno o numero do Recibo, logo não temos como realizar a consulta pelo numero do Recibo, alias não se faz necessário uma vez que no retorno do envio síncrono o que temos de retorno já é o resultado do processamento, portanto já temos na resposta se o documento foi processado com sucesso ou não. DF-e que já nasceram com o modo de envio Síncrono: BP-e = Bilhete de Passagem Eletrônico BP-e TM = Bilhete de Passagem Eletrônico Transporte Metropolitano GTV-e = Guia de Transporte de Valores Eletrônico DC-e = Declaração de Conteúdo Eletrônica NFCom = Nota Fiscal de Comunicação Eletrônica DF-e que nasceram com o modo de envio Assíncrono e que mudaram ou vão mudar para Síncrono: CT-e = Conhecimento de Transporte Eletrônico (desde 06/2023 só funciona o modo Síncrono) CT-e OS = Conhecimento de Transporte Eletrônico Outros Serviços (desde 06/2023 só funciona o modo Síncrono) MDF-e = Manifesto de Documentos Fiscais Eletrônicos (Modo Assíncrono será desativado em 30/06/2024) NFC-e = Nota Fiscal ao Consumidor Eletrônica (desde 04/09/2023 só funciona o modo Síncrono) DF-e que possui os dois modos de envio Assíncrono e Síncrono: NF3-e = Nota Fiscal de Energia Elétrica Eletrônica Observação: Notem que nas listas acima não aparece a NF-e = Nota Fiscal Eletrônica, o motivo é que a NF-e nasceu somente com o modo Assíncrono de envio, depois passou a ter o modo de envio Síncrono, mas este modo não se encontra disponível na SEFAZ de São Paulo e Bahia. O Fisco já sinalizou que pretende acabar com o modo de envio Assíncrono da NF-e, deixando somente o modo Síncrono. A motivação para essa mudança é que por volta de 90% dos lotes recepcionados por todas as SEFAZ de todas as UF possuem somente um documento. Sendo assim não faz muito sentido consumir dois serviços (Recepção e Consulta) para apenas um documento, lembrando que no modo Assíncrono se faz necessário a Consulta pelo numero do Recibo para obter o resultado do processamento. Já que 90% dos contribuintes enviam as suas notas de forma unitária, ou seja, uma nota por vez, tanto a SEFAZ quanto o desenvolvedor do Software sairiam ganhando com essa mudança, pois a SEFAZ eliminaria o serviço de Consulta pelo numero do Recibo e o Software ficaria mais rápido pois não precisaria executar essa consulta. Quando vai ocorrer essa mudança não sei, o Fisco não disse quando, mas vai ocorrer. Codificação para quem utiliza os componentes: A titulo de exemplo será utilizado o componente ACBrMDFe, mas podemos replicar para os demais. O método Enviar possui 3 parâmetros: function Enviar(const ALote: String; Imprimir: Boolean = True; ASincrono: Boolean = False): Boolean; overload; ALote = Numero do Lote que contem os documentos a serem enviados para o webservice da SEFAZ. Imprimir = Se True (valor padrão) diz que o Documento Auxiliar vai ser impresso no final do processo, se False diz que não vai ser impresso. ASincrono = Se False (valor padrão) diz que o modo de envio é Assíncrono, se True diz que o modo de envio é Síncrono. Exemplo de Envio no modo Assíncrono (só deve ser utilizado pelos DF-e que ainda possuem esse modo de envio): ACBrMDFe1.Enviar(NumLote); ou ACBrMDFe1.Enviar(NumLote, False); Exemplo de leitura do retorno do envio no modo Assíncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Retorno.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Retorno.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Retorno.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Retorno.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Retorno.Recibo); Lines.Add('Protocolo: ' + ACBrMDFe1.WebServices.Retorno.Protocolo); end; Exemplo de Envio no modo Síncrono (utilizado pelos DF-e que só possuem ou também tem este modo de envio): ACBrMDFe1.Enviar(NumLote, True, True); ou ACBrMDFe1.Enviar(NumLote, False, True); Exemplo de leitura do retorno do envio no modo Síncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('Chave: ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe); Lines.Add(''); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Enviar.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Enviar.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Enviar.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Enviar.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Enviar.Recibo); end;

Olá boa tarde Diego!! Após quebrar a cabeça aqui achei o problema ... era a versão do java que estava desatualizada aqui no PC. Obrigada pela atenção!

Bom dia @Aggille Sistemas de Gestão, Na versão 2.04 devemos atribuir o código da Obra e a Arte nos respectivos campos: NFSe.ConstrucaoCivil.CodigoObra := 'código da obra'; NFSe.ConstrucaoCivil.Art := 'arte';

Reportando. Funcionou perfeitamente a propriedade pathNome. Muito obrigado @Renato Rubinho !!!

Bom dia @Lindomar S. Menezes, O MDF-e foi enviado no modo Assíncrono ou Síncrono?

Mudanças na certificação digital devem começar em junho, diz presidente do ITI https://capitaldigital.com.br/mudancas-na-certificacao-digital-devem-comecar-em-junho-diz-presidente-do-iti/ Contribuição de @Arimateia Jr

Obrigado, antes de você mandar eu já tinha reiniciado uma instalação do zero, e deu tudo certo !! Obrigado a todos

Olá pessoal, espero que estejam todos bem. Compartilho com voçês um projeto em que venho trabalhando, acabei tendo que deixar o projeto de lado por algum tempo, mas agora estou trabalhando nele e devo disponibilizar os fontes nos proximos dias.

Boa tarde executando em meu ambiente de testes com escala monitor 100% ACBrNFe.DANFE.NovaEscala := 96; ACBrNFe.DANFE.AlterarEscalaPadrao := False;

to ligado @Daniel InfoCotidiano nessa minha api roda outras features tbm, nesse caso não posso deixar que um componente/unit altere o padrão, por isso isolei o componente e manipulei a maneira como ele usa o defautl do s.o (fork), apesar de não concordar não vem ao caso, com os ajustes que apliquei esta funcionando e não vou ter problema quando pessoal do time ajustar alguma coisa, mesmo assim fico grato pela atenção que deram sobre o caso, muito obrigado. Att.

Boa tarde @ANDERSON JUNIOR GADO DA SILVA Falando com o time isso foi colocado pq servidores como Amazon são em inglês e alguns usuários sugeriram isso. Comportamento com meu ambiente de testes: Utilizado diretivas do Linux no LAzarus: Resultou como esperado: Quando não usamos ele pega padrão do Sistema Operacional, mas add a virgula como separador decimal.

@C4Dev, Muito obrigado pela colaboração, já Inclui na minha lista de tarefas para analise.TK-5362

Bom dia. Vou entrar em contato com eles. Obrigado por enquanto.

Obrigado, agora tenho um norte...

Resolvido usando o método NFSE_ConsultarNFSeGenerico.

Agora funcionou corretamente. Muito obrigado pela ajuda!

Bom dia @tryideas sistemas, Se tratando do Padrão Nacional a emissão de notas via portal (site) podemos usar o usuário e senha, mas via webservice se faz necessário o uso do certificado digital, pois o XML do DPS (Declaração Provisória de Serviço) que devemos gerar e enviar para o webservice deve ser assinado digitalmente.

Bom dia @C4Dev, Vou rever a alteração que fiz.

Bom dia @Mauricio Elias e @lucimauro, Os contadores dos seus clientes o que dizem sobre essa questão? Por se tratar de um assunto fiscal o melhor caminho é procurar um bom contador.

@Renato Rubinho Bom dia, enviei os dados no [email protected], em relação manual foi o mesmo em anexo, eu só testei em produção.

Boa tarde! É alguma nota emitida em uma operação especial? Como devolução ou algo assim? Simples Nacional não tem destaque de ICMS, porém quando existe uma condição legal, você deve usar o CSOSN 900 e preencher os campos correspondentes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde! O web service de homologação do Fiorilli possui uma divergência com o de produção nesse sentido.(Entendemos que seja um bug do lado deles). Para isso foi criada a configuração intitulada "Assinaturas": Altere no seu arquivo ACBrLib.ini, na seção [NFSe] para opção correspondente a "Não Assinar" e faça novo teste no ambiente de homologação.

Bom dia @Victor H. Gonzales - Panda Consultamos a Sicredi e, ao que tudo indica, quando o nosso número é erado pela API, retornará sempre 60. Resposta Sicredi em anexo. Obrigado.

Boa tarde a todos. Vi o post do @Diego Foliene na base de conhecimentos sobre o envio de nova em modo Sincrono e comecei a realizar as modificações necessárias, troquei as opções "webservices.RETORNO.xxxx" por "webservices.ENVIAR.xxxx", só estou tendo dificuldades em obter a chave, ele não reconhece o comando "ACBrMDFe1.WebServices.ENVIAR.ChaveMDFe". Alguma dica. Grato,

Boa noite, Implementada propriedade PathNome para retorno do arquivo gerado em envio de lote, consultas e download de eventos. Enviado para o SVN na Rev-33419 Por favor atualize os fontes, reinstale os componentes e, se possível, nos informe se foi o resultado esperado. Atualizados programas de exemplo em Delphi e Lazarus com tratamento da nova propriedade. 1. Envio de lote terá o prefixo padrão de data e hora * Propriedade: ACBreSocial1.WebServices.EnvioLote.PathNome Exemplos: * 20240423212314-rec-soap.xml * 20240423212314-env-lot.xml * 20240423212314-env-lot-soap.xml * 20240423212314-rec.xml 2. Consulta de Protocolo terá o prefixo sendo o número do Protocolo * Propriedade: ACBreSocial1.WebServices.ConsultaLote.PathNome Exemplos: * 1.2.202404.0000000000123456789-sit-soap.xml * 1.2.202404.0000000000123456789-ped-sit.xml * 1.2.202404.0000000000123456789-ped-sit-soap.xml * 1.2.202404.0000000000123456789-sit.xml 3. Consulta Identificadores terá o prefixo sendo a composição da consulta * Propriedade: ACBreSocial1.WebServices.ConsultaIdentEventos.PathNome Exemplos: * S-1000-00010602000120-01-2024-20240423213439-ped-con-soap.xml * S-1000-00010602000120-01-2024-20240423213439-con.xml * S-1000-00010602000120-01-2024-20240423213439-con-soap.xml * S-1000-00010602000120-01-2024-20240423213439-ped-con.xml 4. Download terá o prefixo padrão de data e hora * Propriedade: ACBreSocial1.WebServices.DownloadEventos.PathNome Exemplos: * 20240423214526-ped-dow-soap.xml * 20240423214526-dow.xml * 20240423214526-dow-soap.xml * 20240423214526-ped-dow.xml

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Aumente o timeout para 30k ou mais, pode estar interrompendo o processo no meio.

Copie, para a pasta da aplicação, as dlls da OpenSSL da mesma arquitetura que você compila a aplicação. ../trunk2/DLLs/OpenSSL/1.1.1.10/

Acho que descobri, coloquei "DMI" e deu certo.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

O DistribuicaoDFe não gera NSU para o próprio emitente, afinal ele já tem o XML. No caso da NFe leia a NT 2014.002, está bem explicado o funcionamento, quem recebe cada documento, e as condições de uso.

Bom dia! Desculpem a demora em retornar. Desinstalei a versão 8.0 do ZeosLib e instalei a 7.1. Funcionou! Obrigado! João

Boa tarde!! Problema resolvido!! Refizemos as devidas alterações e atualizações do ACBR e o aparentemente o problema foi resolvido. Agradeço imensamente a ACBR pelo apoio!!!! Muito obrigado

Caraca juro que procurei por algo assim mas nao vi kkkk Mas muito obrigado !!!!

Boa tarde @Diego Foliene, entendido, vou encaminhar, assim que me responderem dou um retorno

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Só uma OBS, o suporte da IPM me ligou agora... ativaram os serviços e esta tudo funcionando!!!

Olá pessoal, Tenho boas novas, foi enviado para o SVN a implementação de um novo provedor chamado Sam, esse provedor se utiliza do mesmo layout do provedor WebFisco. Cidades atendidas pelo provedor Sam: Areiópolis/SP, Brejo Alegre/SP, Echaporã/SP, Júlio Mesquita/SP e Porangaba/SP. Abaixo Informações do referido provedor. ------------------------------------ Informações sobre o provedor: Sam - Versão: 1.00 - Layout: Próprio Autenticação Requer Certificado Digital Requer Login/Senha Não requer Chave de Acesso Não requer Chave de Autorizacao Não requer Frase Secreta Serviços Disponibilizados Não permite o envio de Lote em Modo Assíncrono Não permite o envio de Lote em Modo Síncrono Permite o envio Unitário em Modo Síncrono Não permite Consultar a Situação do Lote Não permite Consultar o Lote Permite Consultar o Rps Permite Consultar a NFS-e Não permite Consultar uma Faixa de NFS-e Não permite Consultar Serviço Prestado Não permite Consultar Serviço Tomado Permite Cancelar NFS-e Não permite Substituir NFS-e Não permite Gerar Token Não permite Enviar Evento Não permite Consultar Evento Não permite Consultar DF-e Não permite Consultar Parâmetros Não permite Consultar Sequencia de Rps Não permite Consultar Link da NFS-e Não permite Consultar NFS-e por Chave Particularidades Permite mais de um serviço Não permite o envio da tag OutrasInformacoes no Rps ------------------------------------ As informações acima podem ser obtidas de qualquer provedor. Basta configurar o programa exemplo com a cidade desejada e clicar no botão [Informações sobre o Provedor] que se encontra na aba: Geral.

Hmm, infelizmente só essa mensagem não nos ajuda muito a encontrar o problema. Tente encontrar um fato em comum. Por exemplo, todas as telas que abrem e ocorre o problema tem determinado componente, ou herdam de determinada classe. Conversando junto a equipe de consultores, um teste sugerido foi abrir todos os forms do projeto e recompilar. Também foi sugerido testar compilando em debug a aplicação para ver se exibe mais informações sobre o problema.

Boa tarde @Datacaixa, Você pode pegar essa e outras informações da seguinte forma: ACBrNFe1.NotasFiscais[0].NFe.procNFe.dhRecbto

Esse erro é problema no json do boleto que está errado...quando você informa um dado errado no json do boleto retorna esse erro ai DADOS INCONSISTENTES - 0840 Você está testando o boleto hibrido Bradesco ou PIX Puro do Bradesco?

Olá pessoal! Conferindo no painel Situação SVC, é possível observar que a Sefaz de Pernambuco está com contingência agendada para o dia 21/04/2024, com previsão de inicio às 07h00 e encerramento no dia 22/04/2024 às 09h00. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso Discord.

Boa tarde Ronaldo, Já esta no SVN.

Olá comunidade do ACBr, É com muita satisfação, que anunciamos a criação de um novo componente, o ACBrAbecsPinPad, no Package ACBrSerial O que faz o ACBrAbecsPinPad ? Esse componente permite que você se comunique de forma direta, com PinPads que sigam o protocolo ABECS. Com ele você poderá realizar tarefas como: Limpar e Exibir Mensagens no Display Exibir imagens PNG, JPG, GIF no Display (útil para exibição de QRCode, Animações e Logos) Efetuar Perguntas padrões no PinPad, e coletar a resposta dos usuários (os tipos de perguntas, são padronizados pela ABECS) Exibir Menus no PinPad (útil para pesquisa de satisfação) Coletar Informações do PinPad, como: Num.Serial, capacidades da Tela, Memória disponível, etc No mercado nacional, todos os PinPads comercializados, precisam seguir essa especificação. Você pode encontrar a especificação do Protocolo ABECS, nesse Documento Não é o intuito desse componente, contemplar os métodos de captura de cartão e senha, pois isso exige o conhecimento de tarefas complexas, e chaves para a comunicação segura... Essas tarefas já são realizadas pelas bibliotecas de TEF como a PayGo O que é um PinPad ? O Pin Pad pode ser definido como um equipamento eletrônico de pagamento que faz a leitura de cartões e que conta com um teclado para que o cliente possa digitar a senha (se necessário) e, assim, validação da transação financeira. O Pin Pad não é um aparelho autônomo. Ele precisa estar conectado a outros elementos para funcionar, tais como um PC ou um PDV Android. De modo geral, eles aceitam diferentes tipos de cartões — a exemplo dos de crédito, débito, vale-alimentação e vale-refeição — e das mais variadas bandeiras. Fonte: https://zoop.com.br/blog/pagamento/o-que-e-pin-pad/ Veja um exemplo do Equipamento: Q25 da Tectoy Onde posso achar o novo componente ? Os fontes já estão disponíveis no SVN do ACBr. Demos em Lazarus e Delphi já estão disponíveis na pasta: \ACBr\Exemplos\ACBrSerial\ACBrAbecsPinPad... A versão mínima do Delphi é a 10.3.x, isso ocorre porque as versões anteriores não suportam Imagem PNG, e o Pinpad não suporta Imagem em formato BMP. O que preciso para testar ? Qualquer PinPad, que seja compatível com ABECS. Lembrando que todos os PinPads vendidos no mercado brasileiro o são. A versão da ABECS que nos baseamos a 2.12, entretanto ele deve ser compatível com versões inferiores... Você pode ver a versão da biblioteca ABECS embarcada no seu PinPad, quando o mesmo é inicializado. Por norma da ABECS, o PinPad deve possuir cabo USB, mas disponibilizar uma Porta Serial, quando conectado ao equipamento.Portanto, sempre usaremos a comunicação Serial do ACBr, para "falar" com o PinPad É importante que você instale o Driver do Fabricante do equipamento, antes de iniciar os testes, pois o driver genérico do Windows, pode não funcionar adequadamente... O ACBrAbecsPinPad está disponível em Lib (DLL) ? Não no momento, mas há planos futuros... Quem é a ABECS ? A Abecs atua desde 1971 como representante oficial do setor de meios eletrônicos de pagamento no Brasil. É responsável pela interlocução do setor perante o mercado, os órgãos públicos e a sociedade. Congrega atualmente mais de 90 empresas desse segmento, representando assim mais de 96% do mercado. Entre seus associados estão instituições financeiras, bancos digitais, adquirentes, bandeiras, fintechs, marketplaces, empresas de tecnologia, entre outras que atuam no sistema de pagamentos. É a interlocutora do setor em assuntos regulatórios e promove a autorregulação desde 2008. Consolida e divulga o balanço de dados do setor, realiza anualmente o Congresso de Meios Eletrônicos de Pagamento (CMEP), fomenta o desenvolvimento do mercado em seus comitês e grupos de trabalho e promove campanhas que incentivam o uso consciente do cartão, entre outras atribuições. https://abecs.org.br/quem-somos Exemplo do componente ACBrAbecsPinPad carregando e exibindo uma imagem no PinPad

uses ACBrSocket; [...] HTTP := TACBrHTTP.Create(nil); try HTTP.TimeOut := 10000; try HTTP.HTTPGet(Format(URL, [Campo1, Campo2])); except // tratar erros end; Retorno := Trim(HTTP.RespHTTP.Text); finally HTTP.Free; end; Pode também estudar os componentes da pasta ACBrTCP, como o ACBrConsultaCNPJ e ACBrCEP, eles herdam de ACBrHTTP, e você pode criar o seu próprio componente dessa forma.

Olá pessoal, Alguns já notaram que dependendo do DF-e - Documento Fiscal Eletrônico, o modo de envio é assíncrono e ou síncrono. Quais DF-e podem ser enviados em determinado modo e quais são as condições? NF-e: como normalmente enviamos um lote com até 50 notas o modo de envio é assíncrono e funciona para todas as UF. Podemos enviar NF-e em modo síncrono, mas neste caso só é permitido o envio de apenas 1 nota. O modo de envio síncrono não esta disponível para as UF: SP, BA e GO. NFC-e: como normalmente enviamos 1 nota por vez o modo de envio é síncrono, mas caso seja necessário enviar 2 ou mais notas obrigatoriamente o modo de envio deverá ser assíncrono. CT-e: como normalmente enviamos um lote com até 50 conhecimentos o modo de envio é assíncrono e funciona para todas as UF. Podemos enviar CT-e em modo síncrono, mas neste caso só é permitido o envio de apenas 1 conhecimento. O modo de envio síncrono não esta disponível para as UF: MG, PR e SP. CT-e OS: como só é possível o envio de 1 por vez o modo de envio é síncrono para todas as UF. MDF-e: pode ser assíncrono ou síncrono para todas as UF, uma vez que, quem recepciona é sempre a SVRS. Detalhe o envio é sempre unitário, ou seja, só podemos enviar somente um manifesto por vez. BP-e e BP-e TM é síncrono para todas as UF e só podemos enviar 1 bilhete por vez.

Marque a opção de usar arquivo de configuração .cfg.