Painel de líderes

Olá parceiros de TEF do ACBr, temos uma notícia muito importante. Isso é necessário, porque a validade do certificado, que está nas versões anteriores, e é responsável pela conexão segura (SSL), irá expirar em 30/06 Nesse tópico esperamos esclarecer as dúvidas de como saber se o seu terminal precisa de atualização, e como aplicar a atualização. 1 - Como sei qual a versão que está instalada no cliente ? A várias formas de identificar isso... 1.1 - Você pode ver as propriedades da DLL no Windows Clique com o Botão Direito, sobre o arquivo PGWebLib.dll, e acesse "Propriedades" Clique na Aba "Detalhes", e veja a versão: 1.2 - Você pode notar on Log da PGWebLib, qual é a versão da DLL..Exemplo: 2 - Onde baixar a nova DLL PGWebLib, para atualização ? Humm.. temos duas opções aqui... por favor veja os itens 2.1 e 2.2 2.1 - Se você já Homologou com a Nova DLL Segura versão 4.1.25.x ou superior Então provavelmente você já sabe que pode achar ela nesse link: https://paygodev.readme.io/docs/kit-para-atualização-da-documentação IMPORTANTE: Apenas use essa versão, se você já homologou a mesma Lembrando que você deve ter os fontes do ACBr atualizados, para usar essa nova DLL Segura... Se você ainda não conhece a Nova DLL Segura, por favor leia o tópico abaixo: 2.1.1 - Porque é necessário re-homologar para usar a Nova DLL segura ? Apesar de todos os métodos da DLL permanecerem o mesmo, muito do processo de instalação da DLL mudou, e portanto é importante testar se sua aplicação está 100% compatível Você deve solicitar a re-homologação no HelpDesk da Setis, abrindo um Ticket em: https://dev.proj.setis.com.br/servicedesk/customer/portal/16 É importante que todas aplicações sejam re-homologadas com essa nova versão, pois ela que receberá as melhorias no futuro, além de cuidar de atualizações automáticas, evitando assim, problemas de atualização, no futuro. Por favor leita o tópico indicado acima, para ter uma melhor compreensão das melhorias criadas de Performance e Segurança, nessa nova DLL 2.2 - Usar DLL compatível com série 4.1.15.x, com prazo de validade de certificado estendido. Essa versão é a que você deve usar, se ainda não testou e homologou a nova DLL Segura (acima) Você pode achar a PGWebLib 4.1.15.2 nesse Link Para atualizar usando essa DLL, é bem simples... Basta copiar a nova versão, sobre a antiga... Provavelmente a PGWebLib.dll estará na mesma pasta do seu .EXE Observe que existem versões da DLL para o ambiente de Produção e Certificação, além de x86 e x64 Você deve usar a versão x86, para aplicações compiladas em 32 bits (mesmo que o Windows seja 64 bits) 2.1.1 - Qual a validade da PGWebLib 4.1.15.2 ? Essa versão tem um certificado com validade até Fevereiro de 2025, mas não espere até lá para re-homologar sua aplicação com a Nova DLL segura (leia acima) 3 - O que acontecerá se eu não atualizar a PGWebLib ? Você receberá um erro de conexão SSL, sempre que tentar se comunicar com a PayGo 4 - Vou homologar TEF PayGo agora. Qual versão devo usar ? Você necessariamente, precisa usar a versão mais nova, ou seja a DLL Segura, da série 4.1.25.x ou superior Você pode achar a versão dessa DLL em: https://paygodev.readme.io/docs/kit-para-atualização-da-documentação Observe que essa versão da DLL, possui um instalador e um processo de ativação após a instalação. Isso é necessário, para instalar a DLL na pasta Segura, e instalar os Serviços que irão garantir a segurança da DLL Todo o processo de instalação e ativação, é descrito no Link acima, na documentação da PayGo 5 - Eu já estou homologado na versão nova, 4.1.25.x ou superior. Posso instalar a versão anterior ? Não é recomendado. Use a nova DLL Segura Apenas a nova versão, ou seja, a 4.1.25.x ou superior será mantida. Portanto instalar a versão inferior, apenas o obrigará a atualizar manualmente mais uma vez o terminal desse cliente, no futuro

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=

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! Foi publicado no dia 23/04/2024 na página de notícias do eSocial, uma notícia informando que o conjunto de cifras utilizado no estabelecimento da conexão com o eSocial será revisado. A medida visa aprimorar a segurança no serviço do eSocial e acarretará na eliminação dos protocolos TLSv1.0 e TLSv1.1 de acordo com o cronograma: 24/06/2024: Eliminar o protocolo TLSv1.0 24/07/2024: Eliminar as cifras CBC 26/08/2024: Eliminar o protocolo TLSv1.1 Após a revisão das cifras, caso haja tentativa de conexão com o web service do eSocial e o resultado seja uma mensagem como a abaixo: É um forte indício de que a conexão foi feita utilizando uma versão do TLS ou cifra não suportada. Caso isso ocorra é importante buscar uma versão do sistema operacional utilizado que suporte a conexão. Lembrando que as soluções ACBr são compatíveis com o protocolo TLSv1.2, com a configuração podendo ser definida no componente nativo na propriedade: ACBreSocial.SSL.SSLType := LT_TLSv1_2; E através de parametrização no Monitor e na Lib. Leia a notícia original na íntegra AQUI.

Olá pessoal! Foi publicado no dia 26/04/2024 comunicado pelo ENCAT informando sobre a Entrada em vigor em 08/04/2024 do novo Evento "Registro de Passagem Automático Originado no MDF-e". Segue conteúdo do mesmo na íntegra: Fonte: https://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=V1q2al1iwg4= Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação em nosso Discord.

Não esta alimentando os dados do InfoIRComplem... Fiz o A juste no pcesS5002 Segue Anexo para AnalizepcesS5002.pas

Revise suas configurações de SSL/TLS conforme recomendações do tópico a seguir.

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

Você salvou as dlls na mesma pasta na aplicação? No seu primeiro print está selecionada homologação, tente mudar para produção. Teste com o programa de exemplo no cliente para ver se ocorre o mesmo problema, na aba consultas existe o botão Consulta Cadastro

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! Conferindo no painel Situação SVC é possível observar que a Sefaz do Mato Grosso ativou a contingência às 12h35 do dia 26/04/2024, com previsão de permanecer ativada até às 09h00 do dia 29/04/2024. 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 @Rafael - ATS Informática por compartilhar a informação em nosso Discord.

Certo, então não tem nada que o Acbr possa fazer no caso desses erros relatados acima, são todos problemas dos estados? Muito obrigado!

Bom dia @fefevilela, O que tudo indica a SEFAZ-AM não oferece mais esse serviço, pois a URL que temos acusa que não existe mais, tentei mudar no final de 2 para 4, mas também diz que não existe.

João, Já esta no SVN.

Tudo certo, agora entendi e gerei o qrCode certinho, valeu mesmo pela atenção!

Bom dia, deu certo, obrigado.

boa tarde, só para informar que ainda estou verificando com o provedor ipm, troco de atendente assim que estamos atualizando a situação para o novo atendente do ipm, ficamos no aguardo de uma resposta da parte do suporte do ipm.

então não me passaram detalhes sobre oq foi alterado nessa atualização, me passaram o contato agora da fiorilli, para entrar em contato direto com eles, vou também fazer um teste do envio assincrono e no outro, para ver se o problema se repete, os "testes" que estou fazendo é em produção mesmo. assim que tiver uma posição aviso aqui

Bom dia Antonio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas para analise. TK-5379

Bom dia @ROGERIOHFB, Veja se isso lhe ajuda:

Ótimo! Muito obrigado!

Boa tarde! O exemplo pega o retorno como uma string, mas se você abrir o método, vai ver que é uma classe.

A diferença agora me parece estar no final da URL para a qual é feita a requisição. Esta é a informação do TxId. Conferindo no log da Lib, você utilizou: WANO80 para ela. Veja o valor que consta no log do teste no exemplo nativo: 93920DE81DCB43EA9C09FB8425AB3782 Conforme manual dos padrões para iniciação no PIX, o TxId precisa respeitar essas regras: Por favor, corrija o valor do TxId respeitando as especificações e faça um novo teste.

Opa Italo, bom dia. Tudo bem? Vou fazer com os exemplos que você me passou Muito Obrigado.

tem no site

Bom dia Carvalho, O componente ACBrNFSeX possui uma rotina de leitura para provedores que seguem o layout da ABRASF versão 1, uma outra rotina que segue a versão 2 da ABRASF e diversas rotinas para os provedores que tem layout próprio. Isso faz com que haja a necessidade de se informar "configurar o componente" o código do município para a qual a nota foi emitida, desta forma o componente sabe qual das diversas rotinas de leitura ele vai utilizar. O componente não possui um método que carrega o XML como uma string detecta o município para o qual a nota foi emitida e retorna o código IBGE do mesmo. Caso você queira contribuir com o provedor implementando esse método ficaremos muito agradecidos pela colaboração.

Olá ! MUITO OBRIGADOOOO pelo retorno! Já liberei uma versão do projeto para o cliente , mas testarei a implementação. Apenas para ilustrar a minha necessidade em ter o nome do arquivo do xml gerado por fase: 1. Desenvolvi uma API para fazer integração via arquivo texto com outra aplicação, para a geração de 3 eventos do eSocial (2210,2220,2240). 2. Devolvo um json com um resumo do processamento e o nome do arquivo xml (*env-lot.xml) no envio para que a aplicação do cliente possa processar o xml e atualizar o BD dele. 3. Na consulta do lote enviado devolvo um json com o resumo do processamento o nome do arquivo xml(*sit.xml) para que a aplicação do cliente possa processar o xml e atualizar o BD dele. Então, para o meu caso eu precisaria poder recuperar o nome destes dois arquivos especificamente, no envio o *env-lot.xml e na consulta *-sit.xml. att. Cristian

Bom dia Castro, Após o envio no modo Síncrono se o MDFe foi autorizado você pode pegar a chave da seguinte forma: Chave := ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe; Mas também você pode obter a chave da seguinte forma: Chave := ACBrMDFe1.Manifestos[0].NumID; Essa segunda forma se faz necessário que o o XML do MDFe tenha sido gerado.

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.

Olá pessoal! Foi publicado um aviso no Portal da Nota Fiscal Eletrônica informando que os ambientes autorizadores de NFe da Sefaz de Pernambuco vão passar por uma parada emergencial no dia 24/04/2024 às 17 horas para ajustes na infra estrutura de redes, com previsão de permanecer indisponíveis por um período de 4 horas. Durante esse tempo, os contribuintes deverão realizar a emissão de nota em contingência que de acordo com o painel Situação SVC será ativada no dia 24/04/2024 às 16h30 e encerrada às 08h00 do dia 25/04/2024. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações deste tópico:

Boa tarde @Italo Giurizzato Junior, em contato com o provedor Elotech, identifiquei que para consultar a NFse por faixa, mesmo que o número inicial seja igual ao número final, precisa enviar as duas tags para evitar o erro de timeout; então imagino que teria que alterar nesse local: Fiz essa alteração aqui localmente e deu certo consultar por faixa:

Olá pessoal! Foi publicada a Portaria N° 066/2024 que trás novas alterações relacionadas a este tópico. A publicação conta com dois artigos. O art. 1º altera alguns textos do artigo 1º da Portaria nº262/2023, visando trazer mais clareza e coesão para os contribuintes no que diz respeito as situações cujo pagamento foi feito através de pagamento instantâneo. Redação antiga: Nova redação: Vejam que agora é identificado que a integração informando o endtoEndId no campo cAut e o idTemPag deverá ser feita quando o pagamento for efetuado através de QrCode dinâmico. Além disso é explicado também que o idTemPag poderá ser informado quando for o caso, dando a entender que nos casos em que houver identificação por número de série ou número lógico do dispositivo usado para gerar o QrCode a informação poderá ser adicionada, mas nos casos em que não houver uma identificação precisa, não será necessário informar o mesmo. Além destas alterações, a nova portaria também adiciona os seguintes artigos: Fornecendo mais flexibilidade para operações entre matrizes e filiais de empresas que estejam estabelecidas no estado do Mato Grosso. Por fim, conforme possibilidade prevista anteriormente, a portaria também trás uma nova lista de CNAEs que serão obrigados a realizar a vinculação dos meios de pagamento ao documento fiscal a partir de 01/07/2024: SUBCLASSE CNAE DENOMINAÇÃO DATA INÍCIO OBRIGATORIEDADE 4530-7/03 Comércio a varejo de peças e acessórios novos para veículos automotores 1°/07/2024 4530-7/04 Comércio a varejo de peças e acessórios usados para veículos automotores 1°/07/2024 4530-7/05 Comércio a varejo de pneumáticos e câmaras de ar 1°/07/2024 4711-3/01 Comércio varejista de mercadorias em geral, com predominância de produtos alimentícios hipermercados 1°/07/2024 4711-3/02 Comércio varejista de mercadorias em geral, com predominância de produtos alimentícios - supermercados 1°/07/2024 4712-1/00 Comércio varejista de mercadorias em geral, com predominância de produtos alimentícios - minimercados, mercearias e armazéns 1°/07/2024 4713-0/02 Lojas de variedades, exceto lojas de departamentos ou magazines 1°/07/2024 4713-0/04 Lojas de departamentos ou magazines, exceto lojas francas (duty free) 1°/07/2024 4722-9/01 Comércio varejista de carnes - açougues 1°/07/2024 4722-9/02 Peixaria 1°/07/2024 4723-7/00 Comércio varejista de bebidas 1°/07/2024 4724-5/00 Comércio varejista de hortifrutigranjeiros 1°/07/2024 4731-8/00 Comércio varejista de combustíveis para veículos automotores 1°/07/2024 4732-6/00 Comércio varejista de lubrificantes 1°/07/2024 4741-5/00 Comércio varejista de tintas e materiais para pintura 1°/07/2024 4742-3/00 Comércio varejista de material elétrico 1°/07/2024 4743-1/00 Comércio varejista de vidros 1°/07/2024 4744-0/01 Comércio varejista de ferragens e ferramentas 1°/07/2024 4744-0/02 Comércio varejista de madeira e artefatos 1°/07/2024 4744-0/03 Comércio varejista de materiais hidráulicos 1°/07/2024 4744-0/04 Comércio varejista de cal, areia, pedra britada, tijolos e telhas 1°/07/2024 4744-0/05 Comércio varejista de materiais de construção não especificados anteriormente 1°/07/2024 4744-0/06 Comércio varejista de pedras para revestimento 1°/07/2024 4744-0/99 Comércio varejista de materiais de construção em geral 1°/07/2024 4753-9/00 Comércio varejista especializado de eletrodomésticos e equipamentos de áudio e vídeo 1°/07/2024 4759-8/99 Comércio varejista de outros artigos de uso pessoal e doméstico não especificados anteriormente 1°/07/2024 4771-7/01 Comércio varejista de produtos farmacêuticos, sem manipulação de fórmulas 1°/07/2024 4771-7/03 Comércio varejista de produtos farmacêuticos homeopáticos 1°/07/2024 4789-0/99 Comércio varejista de outros produtos não especificados anteriormente 1°/07/2024 Leia a portaria na íntegra AQUI. Este tópico foi construído com base em notícia publicada pela AFRAC que pode ser encontrada AQUI.

Segue tópico com informações sobre as mudanças do Reinf, desde a ativação do modo assíncrono.

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

Boa tarde Willian, Abra o arquivo ACBrNFSeXServicos.ini Altere a URL e siga os passos que se encontram no inicio do arquivo.

Boa tarde @phulano, Neste caso você vai usar o ACBrLibNFSe (se o power cobol lhe permite consumir DLL) ou o ACBrMonitor Plus que trabalha com troca de arquivos TXT. Essas empresas de Jaú/SP são os primeiros a lhe solicitar emissão de NFS-e? Se sim, reforço a leitura do tópico sugerido pelo @Diego Foliene.

Eu uso 5 pq tem umas impressoras que acabam cortando a impressão com margens pequenas demais, com essas que vc passou deu certo, vou utilizar elas como padrão e ver se não dá problema de corte, obrigado.

Enviei as alterações ao SVN... Commit [r33340]

Olá pessoal! Foi divulgada a versão 1.01 desta Nota Técnica 2024/001. A nova versão adiciona no leiaute do evento de encerramento um campo para indicar quando o encerramento for registrado pelo transportador terceiro.(indEncPorTerceiro). O mesmo deve ser preenchido com o valor 1 quando o transportador que estiver emitindo o evento de encerramento for diferente do emitente. As datas de entrada em vigor permaneceram as mesmas (11/03/2024 para homologação e 08/04/2024 para produção). A adição do campo foi enviada ao SVN e portanto, já se encontra disponível nos fontes mais atuais. Um agradecimento ao membro de nossa comunidade @Datacamp por chamar atenção em nosso Discord a respeito da nova versão. Leia a versão 1.01 na íntegra AQUI.

Como você pode ver na descrição do próprio link que você postou não é oficial. Ainda não fomos contatados sobre esse link e nem sobre o motivo de terem usado o nome "ProjetoACBr". No momento não vemos problemas de alguém hospedar o código no GitHub. Mas gostaríamos de ser contatados. Se alguém souber quem está por trás desse link específico, pedimos para que os avise para entrar em contato conosco. Em especial, podem procurar o @Daniel Simoes, a @Juliana Tamizou . Também estou a disposição. Há possibilidade de no futuro mantermos um mirror oficial do GitHub? Sim. Quando? Não sabemos...

CustomPos é outro protocolo... A LX300 usa Esc/P2

Bom dia. Tive o mesmo problema relatado acima. Para mim resolveu aplicando a configuração sugerida pelo Agnaldo Prates. Obrigado Agnaldo!!!

sim todas indexadas, tabela master com 21 mil registros.ja resolvir passei para UNIDAC( 10 X mais rapido que firedac ). nem tudo nativo sao mil maravilhas. o unidac em termos fetch é muito mais poderoso que o firedac.