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, 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á 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

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

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, 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.

Bom dia, deu certo, obrigado.

A pista é de recompilar o programa, reinstalar o programa na máquina do cliente.

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

Bom dia! Por favor, vejam se a resposta deste tópico lhes é útil:

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 @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.

Bom dia @ROGERIOHFB, Veja se isso lhe ajuda:

Bom dia @Mcq Desenvolvimentos, Usando os Schemas que se encontram na pasta: ...\Exemplos\ACBrDFe\Schemas\CTe ocorre o mesmo erro? Lhe pergunto isso, pois nessa pasta existe o arquivo cteModaAquaviario_v4.00.xsd Ao atualizar o ACBr, você atualiza todos os fontes de todas as pastas? Após a atualização reinstala o ACBr? Após a reinstalação compila a aplicação com a opção Build? Siga sempre esta lista: Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Obrigado pela contribuição. Criada TK-5377 para análise.

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.

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

Boa tarde! Coloque as dlls deste LINK na mesma pasta do .EXE da máquina problemática e faça um novo teste. Lembre-se de escolher as dlls de acordo com a arquitetura que compila a sua aplicação e não a do SO.

tem no site

Olá pessoal! Foi publicado no Portal Estadual da NFe da Sefaz de MG um aviso informando que foram disponibilizadas novas cadeias de certificado para NFe. As novas cadeias podem ser obtidas na aba Downloads e foram atualizadas no dia 22/04/2024. A troca das cadeias pela Sefaz será feita no dia 24/04/2024. E para que servem as Cadeia de Certificado? Preciso realizar a atualização das Cadeias de Certificado? Sim, é importante para que seu cliente continue realizando a emissão do DFe

Não. ambos são distintos. então não tem problemas ter os dois

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:

Ainda não tive... e pelo que notei, a DLL nova PGWebLib, está com problemas para solicitar dados do PinPad... estou tentando resolver isso com eles, primeiro...

Bom dia! O componente ACBrNFSe foi descontinuado e já não sofre mais manutenção a um bom tempo. Por isso, recomendo que migre para o componente ACBrNFSeX. O tópico abaixo pode ajudar com esta questão: No que diz respeito ao erro específico, todos os schemas utilizados pela NFSe estão disponíveis em: ACBr\trunk2\Exemplos\ACBrDFe\Schemas\NFSe. Localize a pasta do provedor que atende a cidade, copia os schemas utilizados e faça um novo teste.

Boa noite, Obrigado pela contribuição. Foram enviadas correções ao SVN que devem resolver o problema relatado, Rev-33416 Por favor atualize os fontes, reinstale os componentes, verifique se o problema foi resolvido e, se possível, nos informe se foi o resultado esperado.

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

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, testado e aprovado, vou atualizar no cliente muito obrigado

Se trata da quantidade vendida do lote em questão. O campo existe pois há um relacionamento de n lotes para o mesmo item da nota fiscal.

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.

Perfeito Daniel. Como estou com o ACBRMonitor via TCP uso o ESCPOS.setPorta() e logo após o ESCPOS.Imprimir(). Vou continuar então com o desenvolvimento. Obrigado!

@dna.automacao, O XML retornado esta no formato ANSI sendo que o correto seria UTF-8. e tem mais, veja: <situacao>RPS NÃO convertido em Nota Fiscal Eletrônica</li> A tag de abertura é situacao e a de fechamento é simplesmente li. De onde eles tiraram esse tal de "li" ? Além de gerar o XML no formato ANSI, gera ele corrompido. Assim fica difícil ler o dito cujo do XML.

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?

Bom dia deve ser o fortes report. pois é o monitor não, ele não está implementado

Olá pessoal! No dia 16/01/2024, foi publicado no Portal do MDF-e a Nota Técnica 2024/001 trazendo alterações nas regras de validação do MDF-e. Alterações Limitação de tempo nas chaves de acesso relacionadas no MDFe. Devido aos eventos de marcação que são gerados de forma automática no transito de mercadorias, o Fisco julgou relevante estabelecer uma data de corte na indicação das chaves e acesso de documentos associados ao MDFe. Para isso, foi implementado as seguintes regras de validação: F30a: Se informado grupo CTe, para cada um dos CTe relacionados. Verificar se o Ano/Mês da chave de acesso são anteriores a 6 meses da Data de Autorização do MDFe. cStat: 518 - Rejeição: Chave de acesso do CTe muito antiga. F37a: Se informado grupo NFe, para cada uma das NFe relacionadas. Verificar se o Ano/Mês da chave de acesso são anteriores a 6 meses da Data de Autorização do MDFe. cStat: 519 - Rejeição: Chave de acesso da NFe informada muito antiga. F45a: Se informado o grupo MDFeTransp, para cada um dos MDFe relacionados. Verificar se o Ano/Mês da chave de acesso são anteriores a 6 meses da Data de Autorização do MDFe. cStat: 520 - Rejeição: Chave de acesso de MDFe informada muito antiga. Alterações na regra de validação de veículos do modal rodoviário. Adiciona as seguintes regras de validação para o Modal Rodoviário: F89a: Se modal rodoviário, UF Carregamento e Descarregamento forem diferentes de Exterior. Verificar se as placas informadas (veículo Tração e Reboques) estão válidas de acordo com validador do órgão SENATRAN. Observação: Validação será aplicada após integração prevista com o órgão SENATRAN for efetivada. cStat: 521 - Rejeição: Placa de veículo inválida conforme SENATRAN. F89b: Se modal rodoviário, UF Carregamento e Descarregamento forem diferentes de Exterior. Verificar se a placa informada para o veículo de tração (tag: veicTracao) é do tipo Tração conforme base de dados do RNTRC da ANTT. cStat: 522 - Rejeição: Placa informada no veículo de tração pertence a um veículo rebocável. F89c: Se modal rodoviário e tipo do rodado for igual a Cavalo Mecânico (tag: tpRod=03). Rejeitar se não informado ao menos 1 veículo de reboque. cStat: 523 - Rejeição: Pelo menor um reboque deve ser colocado na composição em um transporte com cavalo mecânico. Remove a regra de validação que devolve a rejeição 684. Encerramento pelo Transportador. A regra de validação da rejeição 632 para validar o CNPJ do emissor ao tentar emitir um evento passa a vigorar com a seguinte redação: A regra de validação da rejeição 203 passa a vigorar com a seguinte redação: Prazo de Cancelamento do MDFe gerado pelo aplicativo da NFF Adiciona nova exceção a regra de validação da rejeição 220, que passa a vigora com a seguinte redação: Desativação do Serviço Assíncrono Conforme explicado no MOC, o webservice de lote assíncrono e o serviço de consulta de resposta do lote serão desativados. O MDFe sempre trabalhou com lote de um MDFe, o que torna desinteressante manter estes serviços, principalmente considerando que o método síncrono devolve as informações de autorização ou rejeição de forma imediata. DATAS Implantação em Homologação: 11/03/2024. Implantação em Produção: 08/04/2024. Desativação do webservice de lote assíncrono e do serviço de consulta de Lote: 30/06/2024 E como fica o ACBr? Como é possível observar, a NT trás alterações nas regras de validação aplicadas no webservice da Sefaz e desativação de serviço fornecido pelo mesmo, logo, alterações no ACBr não serão necessárias. No que se refere ao fim do envio no modo assíncrono, o componente ACBrMDFe, bem como o ACBrLibMDFe e o ACBrMonitor já estão prontos para o envio no modo síncrono. Para quem usa o componente, no programa exemplo do mesmo temos o botão [Criar e Enviar modo Síncrono] que exemplifica o modo de envio bem como a leitura do retorno. Para quem usa o ACBrLibMDFe, o terceiro parâmetro do comando MDFe_Enviar define se o envio será feito de maneira síncrona ou assíncrona. Para quem usa o ACBrMonitor, o quinto parâmetro no comando MDFe.CriarEnviarMDFe e o sexto no comando MDFe.EnviarMDFe definem se o envio será feito de maneira síncrona ou assíncrona. Veja a nota técnica na íntegra AQUI.

O fim do CFOP de substituição tributária, programado para 1º de abril de 2024 foi revogado pelo Ajuste SINIEF nº 29 de 2023. Já a unificação do CST e CSOSN, prevista para entrar em operação dia 1º de abril de 2024, também foi revogada pelo Ajuste SINIEF nº 34/2023. Fonte: documentação (nos links acima) e site SigaoFisco

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