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.

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

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

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

Essa url pix.santander.com.br/qr/v2/cobv/1041accf-a5a8-4278-89a4-fd7821aac930 e parte do conteúdo que deve ser utilizado para gerar a Imagem do QrCode. Conforme a Nota 27 que consta no print do @Diego Foliene, a imagem do QrCode deve ser gerada conforme as regras do Banco Central. 1. Veja no manual do Banco Central que a url que você recebe no retorno é apenas parte do qrcode * Para maiores detalhes, leia o manual do banco central, para entender o processo * Explicando parcialmente como é a composição dessa string, ela é quebrada nestes grupos, conforme abaixo * Em cada grupo, os dois primeiros dígitos indicam o ID a que se refere o valor do grupo * O terceiro e o quarto dígitos indicam a quantidade de dígitos que o valor terá * A sequência é o valor, obtido a partir do quinto dígito até a quantidade de dígitos especificada no terceiro e quarto dígito 000201 010212 26700014br.gov.bcb.pix 2548pix.example.com/8b3da2f39a4140d1a91abd93113bd441 52040000 5303986 5802BR 5913Fulano de Tal 6008BRASILIA 62070503*** 630464E4 2. String final detalhada no item 1 00020101021226700014br.gov.bcb.pix2548pix.example.com/8b3da2f39a4140d1a91abd93113bd44 15204000053039865802BR5913Fulano de Tal6008BRASILIA62070503***630464E4 3. Analise o método PIXQRCodeDinamico, da classe TACBrBoletoPIXQRCode ( ../trunk2/Fontes/ACBrBoleto/ACBrBoleto.pas ) * Ele gera o EMV (string completa conforme destacado no item 1) * Esse conteúdo gerado é o que deverá ser utilizado para a imagem do QrCode

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

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.

Boa tarde Diego, Segue o Log ArquivoLog vi agora, alem do log criado com o nome que defini no aruivo ini, foi criado um log acho que padrão. segue no anexo ACBrLibPIXCD-20240424.log ACBrLib.ini

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

Olá! Alguém poderia me ajudar em como recuperar o nome do arquivo xml que foi gerado pelo componente? Através da dica que recebi do @Diego Foliene não estou conseguindo. Exemplo no anexo. Muito obrigado.

A propriedade irá armazenar o nome do arquivo de retorno do método. Os exemplos a seguir, respectivamente dos itens destacados no post anterior, serão os retornos que você receberá no PathNome. Envio: 20240423212314-rec.xml Consulta do Protocolo: 1.2.202404.0000000000123456789-sit.xml Tomando como exemplo os nomes acima: 1. No processo de Envio, você terá o PathNome=20240423212314-rec.xml * O prefixo "20240423212314" será o mesmo para "*-rec-soap.xml", "*-env-lot.xml", "*-env-lot-soap.xml", "*-rec.xml" * Você poderá identificar o arquivo que deseja, concatenando o sufixo "-env-lot.xml" com o prefixo obtido PathNome="20240423212314" 2. No processo de Consulta do Protocolo, você terá o PathNome=1.2.202404.0000000000123456789-sit.xml * Esse já é o arquivo que você deseja

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

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:

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.

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.

Isso, foi o que eu fiz , atualizei o Acbr hoje pela manhã para a ultima revisão e assim a tag IndDeduzDeson passou a não ser mais informada no XML com valor padrão 0. A principio dessa maneira resolveu.

Ola, Aproveitando o assunto vi que na Lib não imprime o código de barras quando PosCanhoto=0(prCabecalho) e PosCanhotoLayout=1(prlBarra) só funciona quando PosCanhoto=1 = prRodape

Boa tarde @Italo Giurizzato Junior Atualizei os fontes, reinstalei e fiz os testes. Não resolveu, a propriedade link ainda chega vazia. Estava analisando sua alteração e vi que vc fez a alteração na função PreencherNotaRespostaConsultaLoteRps, então tentei depurar para identificar o motivo que não preenche. Coloquei um breakpoint onde vc fez a alteração e percebi que não passa por aquela função, essa função de preencher é chamada pela TratarRetornoConsultaLoteRps que também não passa por ela. Até identifiquei que o processo está passando pela função TratarRetornoConsultaNFSeporRps, que tem o nome parecido com a que deveria passar, mas não é a mesma. De repente consegui te ajudar com essas informações? Desde já, agradeço a atenção.

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.

Bom dia! Por favor, veja se as orientações presentes neste tópico lhe são úteis:

Boa tarde @Italo Giurizzato Junior, se quiser posso enviar esse exemplo para o provedor e questionar eles sobre o problema de como esta vindo o retorno da consulta?

Por favor, configure o Log do Componente no ACBrLib.. https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca23.html ArqLog -> Informe um Path e NivelLog = 4 Faça um teste com o programa nativo do componente Se ainda sim retornar a mesma mensagem.. Precisa falar com a PSP.. pode ser algo relação ao certificado.

respondido em : https://discord.com/channels/798697718800318484/798968895707938826/1230892694591635558

Bom dia! Infelizmente é mais comum do que imagina, existem provedores que não possuem ambiente de homologação, provedores que usam o mesmo ambiente só diferenciando por tag no XML e por ai vai. Que bom que deu certo! Obrigado pelo feedback.

Nessa seção abaixo a função tenta converter string para o tipo TMateraWithdrawType. Entretanto sempre vai retornar o tipo mwtNone porque a string tá sendo transformada em UpperCase e comparada em outra case. Correção no arquivo em anexo. ACBrSchemasMatera.pas

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

Bom dia @ALTAMOGIANA, Você atualizou todos os fontes de todas as pastas? Reinstalou o ACBr com a opção de apagar arquivos antigos marcada? Compilou a aplicação com a opção Build?

Boa noite, A opção que o @Diego Foliene indicou é utilizada para identificar os xmls dos eventos, os xmls dos lotes, retornos e consultas aparentemente não tem esse tratamento. Criada TK-5360 para analisar a possibilidade dessa implementação.

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

Segure Resposta da SEFAZ MG sobre o vIcmsSubstituto Senhor(a), bom dia! Desde janeiro de 2018 está previsto no art 37, Anexo XV do RICMS que em operações sujeitas à ST o fornecedor deveria informar dados relacionados à ST, tais como Base de Cálculo e Valor do ICMS Retido anteriormente. Desse modo, caso o fornecedor das mercadorias não tenha prestado essa informação, o contribuinte precisará recorrer a ele para definir como preencher corretamente esses campos da Base de Cálculo do ICMS ST e do ICMS ST retido anteriormente. Com relação aos campos pST e vICMSSubstituto esclarecemos que a partir da versão 1.30 da NT 2018.005 o preenchimento dos campos N26a (tag pST) foi alterado para ter ocorrência "0-1" (preenchimento opcional) no "Grupo de Repasse do ICMS ST" e o campo N26b (tag vICMSSubstituto) foi alterado para ter ocorrência "0-1" (preenchimento opcional) nos Grupos: "Grupo Tributação do ICMS= 60", "Grupo de Repasse do ICMS ST" e "Grupo CRT=1 (CSON 500)". Entretanto, ainda que os campos pST e vICMSSubstituto tenham preenchimento facultativo, em algumas situações serão de preenchimento obrigatório a partir de regras de validação previstas na NT 2018.005, como nas que seguem abaixo: N12-81 - Se informado CST = 60 em operações que não sejam para consumidor final (tag: indFinal=0, "Normal"): - Não informada Base de Cálculo ICMS Retido na operação anterior (tag: vBCSTRet), Alíquota suportada pelo Consumidor Final (tag: pST) , Valor do ICMS próprio do Substituto (tag: vICMSSubstituto) e Valor do ICMS ST Retido na operação anterior (tag: vICMSSTRet). Observação: Implementação opcional a critério da UF. Facult. N12a-50 - Se informado CSOSN = 500 em operações que não sejam para consumidor final (tag: indFinal=0, "Normal"): - Não informada Base de Cálculo ICMS Retido na operação anterior (tag: vBCSTRet), Alíquota suportada pelo Consumidor Final (tag: pST), Valor do ICMS próprio do Substituto (tag: vICMSSubstituto) e Valor do ICMS ST Retido na operação anterior (tag: vICMSSTRet). Observação: Implementação opcional a critério da UF. Facult. Por fim, cabe destacar que o contribuinte deverá verificar nas páginas 12 e 16 da NT nos itens "3.4 Grupo N. Grupo Tributação do ICMS= 60", e "3.6 Grupo N. Grupo CRT=1 (CSON 500)" as orientações quanto ao correto preenchimento dos campos N26 - vBCSTRet - Valor da BC do ICMS ST retido, N26a - pST - Alíquota suportada pelo Consumidor Final, N26b - vICMSSubstituto - Valor do ICMS próprio do Substituto e N27 - vICMSSTRet - Valor do ICMS ST retido conforme o tipo de operação. Não havendo o preenchimento correto dos campos informados e considerando a novas regras de validação, ocorrerá a o erro 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet [nItem: 999], conforme disposto na página 20 da NT. O contribuinte que tiver observado as regras acima e que, ainda assim apresente erro na validação da NF-e, deverá nos enviar os arquivos XML de envio e o XML de retorno da NF-e contendo a rejeição informada para que possamos realizar análise pontual do problema. Obs: A lista das regras da NT 2018.005 que serão implementadas por MG poderão ser verificadas em planilha disponível em: http://nfce.encat.org/desenvolvedor/regras-de-validacao/

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.