Painel de líderes

Provavelmente os fontes do seu Acbr estão desatualizados. Estou conseguindo emitir notas normalmente pra essa cidade, sem nenhum problema desse tipo.

Olá pessoal! Como muitos sabem, o time do ACBr está constantemente buscando trazer novas soluções e melhorias com o objetivo de facilitar e melhorar o dia a dia dos desenvolvedores. Com isso em mente, as rotinas dos componentes de DFe estão passando por um processo de migração das units do pcn para units baseadas na classe ACBrXMLDocument. Certo, mas como isso vai ajudar os desenvolvedores? Sabemos que os leiautes dos documentos fiscais podem conter uma quantidade considerável de informações, gerando assim arquivos XML de tamanho considerável. As rotinas de geração e de leitura de arquivos XML utilizando ACBrXMLDocument trazem um ganho de performance considerável em comparação ao pcn, com primeiro sendo até 60 vezes mais rápida em comparação. Ouçam esta edição do Papo PRO ACBr para mais detalhes sobre as razões para esta mudança e as vantagens da mesma: Para que você possa utilizar estas novas classes, ao instalar o ACBr, é preciso selecionar no instalador a opção em destaque no print. Convidamos aos membros da comunidade ACBr para que testem as novas classes e aguardamos um feedback. Até a próxima pessoal!

Bom dia, tudo bem? Estou com um problema na carga de informações nutricionais. Seria dois pontos que encontrei sobre os campos com Estendido no nome (ProteinasEstendido429, GordurasTotaisEstendido429, AcucaresTotaisEstendido429,AcucaresAdicionadosEstendido429). Esses campos mesmo indo zerado no arquivo de informações nutricionais, eles fazem que os campos (Proteinas429, GordurasTotais429, AcucaresTotais429,AcucaresAdicionados429) sejam substituídos por 0. Ao preencher esses campos com nome estendido, ao gerar o arquivo de carga para balança, está saindo com valores errado, valores 10x maior que o informado , acredito que seja por causa do metodo PreencherToledoMGV7 , aonde ao adicionar esse campo no arquivo com o metodo LFIll passa eles assim : LFIll(Produtos[i].Nutricional.AcucaresTotaisEstendido429,5) , esse metodo por padrão quando não informa a casa decimal usa 2 casas , porém no arquivo usa apenas 1 casa decimal para esses campos

Olá pessoal! Foi publicado no dia 02/06/2025, no Diário Oficial do Estado de São Paulo, a PORTARIA SRE 28, DE 30 DE MAIO DE 2025. Esta portaria estabelece o uso da Declaração de Conteúdo Eletrônica (DC-e), modelo 99 no estado, por pessoa física ou jurídica, não contribuinte de ICMS, para acobertar operações de transporte em hipótese que não é exigido documento fiscal, a partir de 01/10/2025. Vale mencionar que o ACBr já dispõe de componente para emissão da mesma, conforme tópico abaixo: E que também foi feita edição do Papo PRO ACBr tratando sobre o tema:

Olá pessoal! No dia 25/03/2025 foi publicada a versão 1.00 da NT2025/001. Alterações NFC-e: Leiaute QR-Code versão 3 O controle da autenticidade do conteúdo do QR-Code impresso no DANFE NFC-e para notas emitidas em contingência será feito por meio da assinatura de campos específicos do QR-Code e a inclusão do resultado da assinatura no mesmo. Neste novo modelo não será mais necessário controlar o Código de Segurança do Contribuinte(CSC), com previsão de eliminação dos mesmos(ainda sem data definida). NFC-e para Produtor Rural - Pessoa Física Em várias UFs é concecida uma Inscrição Estadual para os produtores rurais utilizarem com CPF. Isso gerava certa complexidade operacional para gerenciar os CSCs. Por causa disso, a orientação agora é que seja utilizado o novo leiaute QR-Code (versão 3) para o produtor rural pessoa física(exceto no PR). Para pessoa jurídica é permitida a escolha entre a versão 2 ou 3. Resposta Síncrona para Lote com somente 1 (uma) NF-e O envio de Lotes de NF-e que contenham apenas uma nota, agora deve ser feito de maneira síncrona. Controle do Atraso na Data de Emissão da NF-e A data de emissão da NF-e que anteriormente aceitava um atraso de 30 dias da data atual, agora aceitará um atraso de apenas 7. Regras de validação Desativa a regra de validação GAP03a-2 que devolvida cStat 776 e Rejeição: Solicitada resposta síncrona para UF que não disponibiliza este atendimento, substituindo a mesma pela GAP03a-3 que devolve cStat 452 e Rejeição: Solicitada resposta assíncrona para Lote com somente 1 (uma) NF-e. Altera a regra de validação que devolve cStat 228 e Rejeição Data de Emissão muito atrasada para que valide um prazo de 7 dias independente do tipo da emissão. Altera regras para validar o campo Identificador da IE do Destinatário (indIEDest). Adiciona regras de validação para verificar se foi informado dados de cobrança para pagamento a vista ou data de vencimento superior a dez anos. Torna obrigatórias algumas regras de validação antes facultativas que verificavam a presença e também validavam os dados detalhando o pagamento no grupo que recebe os dados do cartão (card) na NF-e/NFC-e. Adiciona regras de validação específicas para versão 3 do QR-Code. Datas Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 E como fica o ACBr? Foi criada em nosso backlog a #TK-6814 para adequação dos fontes do ACBr para versão 3.0 do QR-Code. Qualquer novidade será divulgada neste tópico. Leia a Nota Técnica 2025/001 na íntegra AQUI. Leia a versão 6.0 das especificações técnicas do DANFE NFC-e QR Code AQUI.

Olá pessoal! Foi publicado no Diário Oficial do Estado do Ceará no dia 22/05/2025 o Decreto Nº 36633 de 19/05/2025. Este decreto possui dois artigos que estabelecem a obrigatoriedade da vinculação dos meios de pagamento eletrônico ao seu respectivo documento fiscal eletrônico mediante interligação tecnológica com o programa emissor do mesmo para NF-e e NFC-e. É preciso mencionar, no entanto, que os prazos de implementação propriamente ditos não foram definidos no decreto, portanto, é de entendimento geral que uma regulamentação mais detalhada é necessária, então espera se a publicação de uma nova portaria ou ato normativo trazendo informações como previsões de casos de aplicação, os prazos de implementação e outros detalhes. Leia o Decreto na íntegra AQUI. O mesmo pode ser encontrado no Diário Oficial do Estado AQUI, na página 3.

Está no manual do DANFE NFCe e QrCode: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=k/IuuaW4YiY= Se você usa o ACBr não precisa se preocupar com isso, já está implementado.

Obrigado, @Alexandre de Paula Muito coerente a sua opinião.

Obrigado... Analisando...

Após instalar o fast report. tu abriu seu delphi e então fechou ele para só então instalar o ACBR?

Olá pessoal! Atualmente o Projeto ACBr conta com pelo menos mais de 80 diferentes componentes que podem auxiliar a vida do desenvolvedor (e isso contando somente os nativos para Delphi/Lazarus) ! Portanto, entendemos que buscar um auxílio no momento de tirar alguma dúvida sobre algum desses componentes pode ser confuso a princípio, ficando a dúvida de onde essa dúvida deve ser enviada. Por isso, visando facilitar essa jornada, foram adicionadas descrições nos canais em nosso servidor do Discord, com o objetivo de ajudar a todos para que possam se localizar e saber qual é o canal correto para tirar suas dúvidas. Basta conferir no topo do canal. Vejam alguns exemplos: Essas descrições também foram adicionadas nos canais exclusivos para os membros PRO e também nos canais de atendimento exclusivos dos corporativo.

Fiz os teste como pediu , com a alteração no ACBr que tinha mencionado gerou corretamente os dados Coloquei uma porperty boolean e fiz as alterações como na imagem Caso ImprimeCamposEstendido = falso não informa esses campo no arquivo para a balança , assim não substitui os campos (Proteinas,GordurasTotais,AcucaresTotais429,AcucaresAdicionados429) INFNUTRI_SemCamposEstendido.TXT INFNUTRIComCamposEstendido.TXT ACBrCargaBal.pas editado ACBrCargaBal.pas

Não fiz nenhuma alteração que usamos o .bpl Acredito que uma property imprime valores estendido como falso como padrão resolveria e ajustar PreencherToledoMGV7 colocando 5,1 ( passando o paramentro decimal no caso 1 ) imprime valores estendido = false não iria adcionar esses campos no arquivo , pois mesmo zerado eles ignora

Olá pessoal! Se você não sabe do que se trata as classes baseadas em ACBrXMLDocument, o tópico abaixo tem mais detalhes: Mas em um resumo: São classes criadas de forma a utilizar as vantagens da LibXML para leitura e escrita dos arquivos XML. Elas são mais rápidas do que as classes baseadas na PCN. Elas foram criadas com o objetivo de substituir a PCN. Como podem ver no tópico indicado acima, desde antes de dezembro de 2024 essas novas classes já estão disponíveis e podem ser utilizadas pela comunidade através de opção no instalador. Agora, 6 meses depois, decidimos que a essas classes serão adotadas como padrão pelo ACBr, ou seja, ao invés de a opção vir desmarcada no instalador, ela vira selecionada por default. Por que estamos realizando esta mudança? Como é mencionado no tópico, consideramos que elas trazem vantagens em comparação com as classes da PCN. Depois de um período de 6 meses, com a comunidade já podendo utilizar elas e sem relatos recentes de problemas, consideramos que elas já estão maduras o suficiente para serem adotadas como padrão. Com o advento da Reforma Tributária, fica inviável manter a manutenção tanto nas classes PCN quanto nas classes ACBrXMLDocument, portanto, os novos campos relacionados a reforma foram adicionadas somente nas novas classes. Quais impactos essa mudança pode gerar? Como mencionado, essas novas classes precisam da LibXML para o correto funcionamento, portanto as dlls devem ser devidamente distribuídas junto ao executável ou estarem presentes no Path. Se você utiliza as units em sua aplicação, é provável que precise realizar a troca para evitar problemas de escopo. Por exemplo, substituir na seção uses da sua aplicação, onde tiver pcnNFeW por ACBrNFe.XmlWriter e onde tiver pcnNFeR por ACBrNFe.XmlReader.

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom e ACBrNFe. Os fontes alterados bem como os Schemas e os programas exemplos dos 5 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Estamos trabalhando já no componente ACBrNFSeX, mas como dito anteriormente até a postagem desse tópico não foi publicado os Schemas. No que se refere a NFSe temos duas questões: 1. A NT publicada com as mudanças no layout referente a Reforma Tributária é no layout da NFS-e Padrão Nacional (não confundir com ABRASF). 2. Hoje o componente ACBrNFSeX atende 1848 cidades, algumas delas contrataram provedores que usam a versão 1 do layout da ABRASF, outras contrataram provedores que usam a versão 2 do layout da ABRASF e outras contrataram provedores que tem layout próprio. Não sabemos qual a atitude dos provedores que utilizam a versão 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout no que se refere a Reforma Tributária. Eles vão alterar o layout que usam para adequar a Reforma ou vão abandonar o layout em uso e vão passar a usar o layout da NFS-e Padrão Nacional? Não temos a resposta para essa pergunta. Até a próxima pessoal.

Olá Pessoal, Já se encontra no SVN a implementação dos eventos: Insucesso na Entrega da NF-e e o Cancelamento do Insucesso na Entrega da NF-e no componente ACBrNFe. Quero frisar o que o @Diego Foliene, colocou em sua postagem anterior que o Ambiente de Homologação já esta liberado para recepcionar os referidos eventos e somente a partir do dia 24/06/2024 é que vai ser liberado o ambiente de produção. O programa exemplo feito em Delphi já foi alterado, agora ele possui os botões para exemplificar os dois novos eventos. Façam os seus testes usando o programa exemplo antes de iniciar a implementação em suas aplicações. Quanto o ACBrLibNFe e o ACBrMonitor Plus os novos eventos vão estar disponíveis assim que forem liberados as novas verões de ambas as ferramentas. Serão atualizados os manuais do ACBrLibNFe e do ACBrMonitor Plus. Fiquem atentos.

Use os schemas da pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe. Foi necessário um ajuste nos schemas oficiais para funcionar com xsLibXML2. Caso contrário qualquer string com menos de 3 caracteres causará falha de validação.