Painel de líderes

Olá Pessoal. Como vocês sabem estamos sempre nos esforçando pra entregar soluções melhores. Nos esforçamos a fazer isso nos nossos códigos, mesmo tendo uma equipe reduzida. Um problema que sempre nos incomoda é units com milhares de linhas. Isso não é boa prática de programação. Torna a legibilidade do código ruim. Dificulta a manutenção. Nesse sentido, uma das que mais notamos isso é a unit ACBrUtil.pas. Ela é uma unit utilitária que foi aglutinando mais e mais código com o passar dos anos. O que fizemos? Queremos dizer que resolvemos fazer alguma coisa sobre isso e começamos por dividir essa a unit ACBrUtil.pas em várias outras separando o código e migrando tipos e rotinas para as outras. A princípio, a separação ficou assim: "ACBrUtil.DateTime.pas" - rotinas relacionadas a manipulação de datas e horas "ACBrUtil.FilesIO.pas" - rotinas relacionadas a manipulação de arquivos, IO, e similares "ACBrUtil.Math.pas" - rotinas relacionadas a manipulação de números e conceitos matemáticos "ACBrUtil.Strings.pas" - rotinas relacionadas a manipulação de strings e textos "ACBrUtil.XMLHTML.pas" - rotinas relacionadas a manipulação de XML e HTML "ACBrUtil.Compatibilidade.pas" - rotinas relacionadas a compatibilidade. "ACBrUtil.Base.pas" - Todas as outras rotinas que não se encaixam nas units acima "ACBrUtil.pas" - Essa unit atualmente só serve como compatibilidade. Você deve substituir ela no seu código pelas acima. Quando? No momento dessa notícia ser escrita, a previsão do código é ir no final do dia de 23/03/2022. Já está no nosso SVN. O que isso significa no meu código? A princípio, a única coisa necessária a ser feito na sua aplicação é atualizar e reinstalar o ACBr. MAS... Vocês devem notar que se utilizarem alguma função da ACBrUtil.pas que foi migrada, começará a receber um warning que a função mudou para outra unit. Você deve atualizar isso assim que possível. Vamos parar por aí? Talvez venhamos a dividir ainda em outras units a ACBrUtil restante. Bem, a ACBrUtil agora foi completamente dividida. Pode ser que venhamos fazer algo semelhante no futuro com alguma ACBrUtil criada. Mas no momento damos esse trabalho por encerrado. É possível também que façamos isso em outras units que estão acumulando funções, tipos e métodos... A questão é que não vamos parar de melhorar o ACBr.

21/03/2022 - Publicada Nota Técnica 2020.001 v.1.20 da manifestação do destinatário da NF-e Homologação Produção NT Versão 01/03/2022 04/04/2022 1.10 04/04/2022 02/05/2022 1.20 Publicada na aba "Documentos", opção "Notas Técnicas", a Nota Técnica 2020.001 v.1.20 estabelecendo novos prazos de homologação e produção para as alterações divulgadas na versão 1.10. A versão 1.10 atualizou regra de rejeição e divulgou os prazos para manifestação do destinatário, conforme disposto no Ajuste SINIEF 44/20. Assinado por: Receita Federal do Brasil Fonte: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=dlSL5ODYKeg=

Boa tarde. Após o último commit, foram modificadas algumas rotinas no NFSeBrasil.Provider o que impossibilitou o componente de efetuar a leitura correta do XML de retorno. Tive que descomentar umas linhas que haviam sido comentadas no último commit, bem como refazer o método de trata o XML de retorno. Segue a unit anexa. Atenciosamente. NFSeBrasil.Provider.pas

Obrigado, vou tentar e dou retorno

Fortes report atualizado e o acbr também?

Bom dia, Estava com o mesmo problema e aparentemente o problema é o "T" durante a conversão de datas. Por favor verifique se esta alteração (ACBrXmlBase.pas) resolve o seu caso. @Italo Giurizzato Junior Por favor, veja se pode considerar esta alteração. Obs: Não usei simplesmente um StringReplace do "T" para evitar qualquer condição que eventualmente pudessem vir outros "T"s, mas se não enxergar problema nisso, basta utilizar: StringReplace(xData,'T','',[rfReplaceAll]);

Boa noite, Vamos acompanhar nesse tópico.

Consegui enviar nota também, parece que normalizou.

Faltam as DLLs do OpenSSL, na pasta do seu Executável

Olá pessoal, estamos provendo importantes modificações em nosso componente de Impressão de Etiquetas, o ACBrETQ, lembrando que esse componente também está disponível a todas as linguagens através da ACBrLibETQ ou ACBrMonitor Se você ainda não conhece uma impressora de Etiquetas e suas características, recomendo ver o vídeo abaixo: O que há de novo no ACBrETQ ? Incluímos um novo Modelo/Protocolo, o EscLabel. O Protocolo EscLabel foi criado pela Epson, para a sua linha de Impressoras ColorWorks. Esse protocolo é uma extensão do já conhecido protocolo ZPL2, da Zebra, porém com algumas extensões, para permitir características únicas das Impressoras da Epson, como Impressão em Cores, e ajuste dinâmico do tamanho da etiqueta. A Epson ao invés de reinventar a roda, tomou uma decisão sábia de licenciar o uso do ZPL2, que equivale a 90% do EscLabel... O método ImprimirCaixa, foi modificado para permitir informar como Parâmetro, o ângulo dos Cantos, para produzir Caixas com cantos arredondados... Exemplo: Canto: Integer = 0 (sem arredondamento), suportando valores 0 a 8 (8 máximo do arredondamento). Atualmente apenas os Modelos que Suportam ZPL2 e EscLabel, aceitam esse parâmetro... O Método CarregarImagem, foi modificado para retornar por referência, o Nome do Arquivo da Imagem que foi armazenado na memória da Impressora... Isso ocorre pois algumas impressoras limitam os caracetres aceitos, e o tamanho do Nome... e portanto tornará mais simples identificar o Nome como guardado na Impressora, a fim de utilizá-lo em comandos de Impressão futuro\ O Modelo ZPL2, foi modificado para permitir o uso de Imagens do Tipo PNG mono... e no caso do EscLabel, há pleno suporte de Imagens PNG coloridas Em breve disponibilizaremos um novo Demo, para demonstrar todo o poder da Epson EscLabel com as impressoras ColorWorks..

Acabo de enviar novas melhorias... Commit [r24972]

Tudo o que estiver na DANFE deve de existir no XML então tem que preencher os dados no xml e vai aparecer