Painel de líderes

@Alexandre Felippeto Henzen As correções estão no SVN Rev-35818

Enviado um Commit At revision: 35827, na próxima compilação do ACBrLibPIXCD, por favor atualize e faça um novo teste.

Boa tarde @Diego Foliene, colocando o número de série do certificado conseguiu pegar, obrigado.

Olá pessoal! Temos o prazer de informar que o componente ACBreSocial foi compatibilizado com a versão Simplificada 1.3 do e-Social! Um agradecimento especial ao membro de nossa comunidade @Marcelo Pontes Melim pela contribuição. As alterações foram efetuados levando em consideração o leiaute mais recente e os arquivos de schema. Versões da ACBrLibeSocial e do ACBrMonitorPLUS compiladas posteriormente a data de 31/10/2024 deverão englobar as modificações. As documentações das respectivas soluções serão atualizadas para refletir a atualização. O programa exemplo em Delphi foi atualizado e o do Lazarus também será para refletir as alterações. Contamos com o apoio da comunidade para reportar qualquer problema no fórum e também em nosso Discord. IMPORTANTE: Como a atualização traz alterações no leiaute, também é muito importante e necessário que atualizem também os arquivos de schema. Para mais detalhes sobre as alterações, confira o tópico abaixo:

Configurando [PIXCD] PSP=1 (Itaú), ao enviar uma requisição PIXCD_CriarCobranca ou PIXCD_ConsultarCobranca não está retornando o texto do QRcode que é utilizado para gerar a imagem e realizar o pagamento. No log do ACBrPIXCD em anexo apresenta a comunicação com o banco Itaú e o retorno do texto do QRCode na tag pixCopiaECola. acbrpixcd.log

Bom dia, tudo bem? NFSe - Getúlio Vargas RS (4308904) Alteração de URL/Link de Produção Na terça-feira, dia 29/10/2024 Interrupção nos sistemas da PM Getúlio Vargas Na segunda-feira, dia 28/10/2024, o sistema de NFSe e os demais sistemas da PM Getúlio Vargas não estarão operando devido à migração para servidores em nuvem. Na terça-feira, dia 29/10/2024 serão divulgados os links dos novos endereços de acesso no Site da Prefeitura Municipal > Serviços > Serviços Online > NFSe e DEISS. É importante frisar que os acessos a partir da terça-feira devem ser feitos pelos novos links, pois os antigos não estrão mais operando. Contribuintes que utilizam emissão na modalidade webservice também devem atualizar os endereços de envio dos RPS. Link de acesso ao site de produção para emissão de NFS-e no portal: NFS-E - PRODUÇÃO(29/11/2024): https://getuliovargas.govbr.cloud/nfse.portal/ Link webservices produção(29/10/2024): https://getuliovargas.govbr.cloud/nfse.portal.integracao/services.svc Deve ser alterado no arquivo desta forma: [4308904] ; Atualizado em 29/30/2024 Nome=Getulio Vargas UF=RS Provedor=Pronim Versao=2.03 ProRecepcionar=https://getuliovargas.govbr.cloud/nfse.portal.integracao/services.svc HomRecepcionar=http://sistemaspmgv.no-ip.info:8083/nfse.portal.integracao.teste/services.svc *Obs: No site consta apenas a url nova de produção, não temos informações sobre a nova url de homologação.

Anexo componente atualizado para a versão 1.3 e programa exemplo. Todos os eventos modificados foram testados através da geração e validação no programa exemplo. Os eventos S-5001, S-5002, S-5003 e S-5011 foram modificados e não testados. ACBreSocial.zip Programa Exemplo.zip XSD veS01_03_00.zip O programa exemplo em Delphi foi sem o arquivo dpr. Programa Exemplo.zip

Obrigado. Vou tentar aqui. Agradeço a atenção em retirar um tempinho para me responder. Porém não creio que seja a minha tela seja o problema, o maior problema é o meu cliente acostumado em usar o ACBRNFe que tem a possibilidade de visualizar antes de enviar. O que deixa o cliente com a dúvida pairando no ar... Porque na NFe ele consegue visualizar e na NFSe ele não consegue. Só isso. Rsrsrsr Mas agradeço a atenção.

Olá pessoal! A solução para o meu caso foi simplesmente não fechar o socket. Optei por não utilizar o comando FecharSocket, pois essa abordagem resolveu o problema. Como essa solução é específica para minha situação, e não tenho outras impressoras para testar, não vou compartilhar o arquivo aqui. No entanto, implementei um tratamento para decidir se o FecharSocket deve ser utilizado ou não, dependendo do caso. Uma observação interessante é que, ao debugar o código sem meus ajustes, o timeout não ocorria. Porém, ao rodar a aplicação normalmente (fora do modo de depuração), o timeout acontecia. Tentei até adicionar um Sleep após chamar o FecharSocket, mas isso também não resolveu. Espero que essas informações possam ajudar outros desenvolvedores a encontrar uma correção, se necessário. Obrigado.

Obrigado Italo pelas informações

tudo certo, obrigado

Certo, Vou verificar. Obrigado

Olá Pessoal, Atualizamos nosso site com DEMO e tudo. Novo link abaixo. https://ifoodcomponente.com.br/restaurante/ WhatsApp Comercial (11)9-9831-0204 Hoje estamos com mais de 60 clientes com mais de 3.000 restaurantes homologados.

Boa tarde @windsoft, Tenho esse referente a Maceió (veja a data) os caras são uma piada. Dependendo com quem você conversar na EICOM eles contam histórias totalmente diferente.

@C4Dev Pode confirmar um ponto. na semana passada tivemos uma alteração nos envios do json do sicoob , a cliente esta com o EXE atualizado com este update. Eu pergunto pq estou testando em SANDBOX, testei varias vezes, 1000 boletos e nao tive o AV. Vc pode por favor verificar se esta com esta atualização.

Obrigado.. Vou testar e te falo.

Boa tarde, Criada a TK-6183 para avaliação. Obrigado pela contribuição

Bom dia @willian_delan, Muito obrigado pela colaboração, já foi criado a TK-6182 para a atualização.

estamos trabalhando nesta tarefa, assim que concluida, reporto aqui.

Bom dia @RodrigoAlvim, Como esse tópico teve inicio a implementação do provedor e ele já esta com duas páginas, vou fechar pois o provedor já foi implementado. Surgindo novos problemas ou duvidas favor criar um novo tópico. Desde já muito obrigado pela colaboração e compreensão.

Ainda não, conversei com meus gestores sobre isso, mas como vai alterar a rotina, tela e funcionalidade (informar as datas e tal) deverá passar por análise de PO antes de ir para desenvolvimento (mas será feito). No momento só preciso ajustar o erro para continuar funcionando no cliente, até que seja migrada para outra forma de consulta.

Boa tarde @HASA, Foi criado a TK-6180 para verificar todos os tipos de consulta que o webservice de São Paulo disponibiliza.

Foi publicada a versão 24.2.D das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/10/2024 até 30/11/2024 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" foi, não se esqueça de realizar a atualização de seus clientes. Fonte : De Olho no Imposto

Boa tarde @WINDEL, Já se encontra no SVN o DACTE para o CT-e Simplificado feito em Fortes Report. Caso você utilize o Fortes Report, já pode atualizar todos os fontes de todas as pastas, reinstale ao ACBr, recompilar a sua aplicação e fazer os testes de impressão. Caso utilize o Fast Report vai ter que aguardar um pouco mais.

Olá Pessoal, É com grande prazer que comunico o envio ao SVN do componente para impressão do DANFCom em Fortes Report bem com o DAEventos em papel A4. No momento se faz necessário a instalação do componente via os pacotes disponíveis. Em breve o ACBrInstall será atualizado visando a instalação do componente. Ainda falta pequenos ajustes na impressão do DANFCom, mas ele já esta funcional.

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; E para quem usa ACBrLib ou ACBrMonitorPLUS? Os diferentes modos de envio também são considerados e estão disponíveis em ambas as soluções. No que diz respeito ao envio, os comandos também possuem um parâmetro que define se o envio será síncrono ou assíncrono. Vamos ver o exemplo do MDFe: Para a ACBrLib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); ALote: Número do Lote a ser enviado. AImprimir: Se True, imprime DAMFDe caso o MDFe seja autorizado. ASincrono: Se True envia o MDFe em modo sincrono. sResposta: Usado pelo retorno, contem as informações retornadas pela consulta. esTamanho: Usado pelo retorno, contem o tamanho da string (sResposta). Então o comando ficaria: MDFe_Enviar(ALote, AImprimir, False, sResposta, esTamanho) ou MDFe_Enviar(ALote, AImprimir, True, sResposta, esTamanho) Para o ACBrMonitorPLUS: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) 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) Ficando: MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, True, bEncerrado) ou MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, False, bEncerrado) A hora de ler a resposta também muda um pouco. No envio assíncrono, temos uma seção [Envio], [Retorno] e [MDFe + Numero do Documento]. Já no envio síncrono, não existe mais a seção [Retorno] e a seção MDFe é concatenada com a chave de acesso. Resposta Assíncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [Retorno] CStat= CUF= ChaveDFe= DhRecbto= Msg= Protocolo= VerAplic= Versao= XMotivo= cMsg= nRec= tpAmb= xMsg= [MDFe1] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo= Resposta Síncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [MDFe12345678901234567890123456789012345678901234] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo=

A edição abaixo do Papo PRO trás informações relacionadas:

Eu só uso o Free, mesmo em Android e FMX... eu acho que o DisposeOf foi inserido na fase negra do compilador NEXTGEN (que já morreu)... parece que quem criou esse compilador realmente não gostava da linguagem Delphi Nesses links tem algo sobre isso: https://stackoverflow.com/questions/27818697/how-to-free-a-component-in-android-ios