Victor H. Gonzales - Panda

Um dos maiores provedores de certificados HTTPS, Let’s Encrypt, deixará de usar um certificado raiz mais antigo na próxima semana – o que significa que você pode precisar atualizar seus dispositivos para evitar que quebrem. Let’s Encrypt, uma organização sem fins lucrativos de uso gratuito, emite certificados que criptografam as conexões entre seus dispositivos e a Internet em geral, garantindo que ninguém possa interceptar e roubar seus dados em trânsito. Somente milhões de sites contam com o Let’s Encrypt. Mas, como avisado pelo pesquisador de segurança Scott Helme, o certificado raiz que Let’s Encrypt usa atualmente – o IdentTrust DST Root CA X3 – irá expirar em 30 de setembro. Depois disso, computadores, dispositivos e clientes da web – como navegadores – não irão mais certificados confiáveis que foram emitidos por esta autoridade de certificação. Para a grande maioria dos usuários do site, não há nada com que se preocupar e 30 de setembro será um dia normal. Dispositivos mais antigos, no entanto, podem ter alguns problemas, assim como ocorreram quando o AddTrust External CA Root expirou em maio. Como resultado, Stripe, Red Hat e Roku sofreram interrupções. “Dada a diferença de tamanho relativa entre Let’s Encrypt e AddTrust, tenho a sensação de que a expiração da raiz do IdenTrust tem o potencial de causar mais problemas”, alertou Helme em uma postagem de blog, referindo-se ao próximo vencimento. Os dispositivos que podem ser afetados pela expiração do certificado são aqueles que não são atualizados regularmente, como sistemas incorporados que não são projetados para atualizar automaticamente ou smartphones que executam versões de software com anos de idade. Os usuários que executam versões anteriores do macOS 2016) e do Windows XP (com Service Pack 3) provavelmente enfrentarão problemas, juntamente com clientes dependentes do OpenSSL 1.0.2 ou anterior e PlayStations mais antigos que não foram atualizados para um firmware mais recente. Enquanto Android, nas palavras de Let’s Encrypt, tem um “problema antigo e conhecido com atualizações do sistema operacional”, a organização sem fins lucrativos tem uma solução alternativa que pode impedir que a maioria dos smartphones seja afetada pelo vencimento. A organização este ano fez a transição para seu próprio certificado ISRG Root X1, que não expira até 2035. Embora muitos dispositivos Android ainda não confiem neste certificado – ou seja, versões do Android (Nougat) 7.1.1 e anteriores – Let’s Encrypt obteve um assinatura cruzada para seu próprio certificado que é válido por mais tempo do que a raiz de assinatura, o que significa que a maioria dos dispositivos Android deve permanecer livre de falhas por mais três anos. Alguns dispositivos Android ainda podem ter problemas, Let’s Encrypt disse, e é recomendável que os usuários que executam o Android (Lollipop) 5.0 instalem o Firefox. “Para o navegador integrado de um telefone Android, a lista de certificados raiz confiáveis vem do sistema operacional – que está desatualizado nesses telefones mais antigos”, explica Let’s Encrypt. “No entanto, o Firefox é atualmente único entre os navegadores – ele vem com sua própria lista de certificados raiz confiáveis.” A Let’s Encrypt, que no início de setembro emitiu mais de dois bilhões de certificados desde sua fundação em 2014, disse ao TechCrunch que os usuários deveriam observar quantos clientes estão usando versões afetadas do OpenSSL e sistemas operacionais antigos. Seu conselho para aqueles que não podem atualizar é “verificar se faz sentido servir uma cadeia de certificados com nosso novo sinal cruzado”. É difícil prever o que acontecerá em 30 de setembro, mas como diz Helme: “Pelo menos algo, em algum lugar vai quebrar”. Fonte : Resources for Certificate Chaining Help - Let's Encrypt (letsencrypt.org) Fonte : O certificado raiz do Let's Encrypt está prestes a expirar e pode danificar seus dispositivos - TEG6

Bom dia, Consegue recriar no programa de demonstração e anexar aqui o fluxo evidenciando o problema onde ocorre o AV ?

Boa noite @Jéter Rabelo Ferreira É possível validar a unit em anexo se está em conformidade ao merge? Obrigado ACBrBoletoW_Itau.pas

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Segregado Layout 6 ou 4 significa a nota de versão 3 do manual: - Layout 4: N/Número do Banco Cobrador deve vir nas posições 63 a 70 e 76 a 83. Nesta Carteira, o cliente envia o título para o banco Daycoval, já com o Nosso Número do Correspondente Itaú sem o DV calculado. O Campo deve ocupar 08 posições, com zeros à esquerda. O DV do NN Itaú irá somente no boleto físico. - Layout 6: N/N Daycoval inserido nas posições 63 a 70. - Nome do arquivo fixo, utilizar a propriedade PrefixNomeRemessa - Informar o código do layout 4 ou 6 no campo LayoutVersaoLote

Boa noite, no manual nessa posição seria o campo NossoNumero, composto pelo numero do documento fiscal correspondente + numero de parcela se houver

Referente a nomenclatura que é fixo mas variável por contrato ou regra bancária : Criado propriedade PrefixArqRemessa, se informado ela será usada, do contrário, será usado o prefixo 2HQ como padrão já utilizado do componente;

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

TK-1940 LITERAL UNICRED / UNICRED DO BRASIL (Versão Lote 944 derivado da 044) Ambos manuais bancários utilizam LayoutVersaoLote = 44. portanto quando informado indiferente de CNAB400 ou CNAB240 a propriedade LayoutVersaoLote = 944 será informado como UNICRED o literal na remessa para LayoutVersaoLote diferente de 944 será informado o literal UNICRED DO BRASIL no arquivo de remessa.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Correção do modulo 11 do DV do banco

Boa tarde, Então temos algum truncamento de informação. Pois aqui está se dizendo que : "A Ficha de compensação não está coesa", que tinha erros na compensação e que não tinha um manual do mesmo e que o suporte deles eram escasso, eu teria que ler todo a thread para relembrar o caso no momento. Mas se você tem já a implementação no CNAB nos padrões da ACBr e a ficha de pagamento está sem erros, está sendo paga normalmente, vamos dar sequencia na implementação, vamos alinhando o assunto. Se você tem acesso a documentação deles, anexe aqui o manual de ficha de compensação deles, os arquivos fontes corretos, e vamos finalizar essa thread. Abraços

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

não existe implementação, e pelo CNAB como pode acompanhar aqui na Thread, falta informações por parte do banco, parece que não é fácil realizar essa integração por CNAB, não tem um apoio / material por parte do banco.

A partir de 16 de novembro, as instituições financeiras poderão bloquear o recebimento de transferências via Pix a pessoas físicas por até 72 horas, caso haja suspeita que a conta beneficiada seja usada para fraudes. A medida consta de resolução publicada hoje (28) pelo Banco Central (BC), com medidas adicionais de segurança para o sistema instantâneo de pagamentos. Segundo o BC, o bloqueio preventivo permitirá que a instituição financeira faça uma análise mais cuidadosa de fraude em contas de pessoas físicas, aumentando a chance de recuperação dos recursos por vítimas de algum crime ou extorsão. O bloqueio será imediatamente comunicado ao usuário recebedor. A resolução também torna obrigatória a notificação de infração, por meio da qual as instituições registram eventuais irregularidades e compartilham as informações com as demais instituições sempre que houver consulta a uma chave Pix. Atualmente, essa notificação é facultativa. O BC também ampliou o uso do mecanismo para transações em que pagador e recebedor tenham contas no mesmo banco e para operações rejeitadas por suspeita fundada de fraude. O uso de informações vinculadas às chaves Pix será ampliado para prevenir fraudes. As instituições poderão consultar as notificações de fraudes vinculadas a usuários finais mesmo em procedimentos não vinculados diretamente ao sistema de pagamentos instantâneos, como abertura de contas. Responsabilização A resolução obrigou que os mecanismos de segurança adotados pelas instituições sejam no mínimo iguais aos procedimentos do BC. Casos de excessivas consultas de chaves Pix que não resultem em liquidação ou de consultas a chaves inválidas deverão ser identificados e devidamente tratados. O BC também determinou que as instituições que oferecem o Pix serão responsabilizadas caso fique comprovado que a fraude decorreu de falhas nos mecanismos de segurança e de gerenciamento de riscos. As instituições estarão obrigadas a usar as informações vinculadas às chaves Pix como um dos fatores para autorizar ou rejeitar transações. Aprimoramento Em nota, o BC informou que as medidas criam incentivos para que os participantes do Pix aprimorem cada vez mais seus mecanismos de segurança e de análise de fraudes. Todas as medidas entrarão em vigor em 16 de novembro, exceto os limites de R$ 1 mil para transações noturnas entre pessoas físicas, aprovado na semana passada, que entra em vigor em 4 de outubro. Edição: Claudia Felczak Fonte : Banco Central aprova medidas adicionais de segurança para Pix | Agência Brasil (ebc.com.br)

A SEFAZ SP para emissão de documentos modelo 55 [NFE] na data de 29/09/2021 está apresentando algumas inconsistências na transmissão. Alguns documentos são transmitidos outros falham. Existe neste momento Contingência ativa e informada no portal nacional "Contingência Ativada Desde 29/09/2021 05:05:00"

Boa noite, não conheço a engine Fortes, mas windows para Linux pode ser problema que não está achando a fonte utilizada no relatorio e está pegando outra no lugar. Ou alguma configuração de compactação

Boa noite, Verifica o schemas do xml

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

Resumo : A partir de 1º.01.2022, os contribuintes do ICMS e do IPI deverão utilizar a versão 3.0.7 do Manual de Orientação do Contribuinte (MOC), com as implementações da Nota Técnica EFD-ICMS IPI nº 1/2021, versão 1.0, a serem publicadas no Portal Nacional do Sistema Público de Escrituração Digital (Sped) e disponibilizada no site do Confaz. Publicação DOU : DIÁRIO OFICIAL DA UNIÃO Publicado em: 27/09/2021 | Edição: 183 | Seção: 1 | Página: 56 Órgão: Ministério da Economia/Secretaria Especial do Tesouro e Orçamento/Conselho Nacional de Política Fazendária ATO COTEPE/ICMS Nº 62, DE 17 DE SETEMBRO DE 2021 Altera o Ato COTEPE/ICMS nº 44/18, que dispõe sobre as especificações técnicas para a geração de arquivos da Escrituração Fiscal Digital - EFD. A Comissão Técnica Permanente do ICMS - COTEPE/ICMS, na sua 185ª Reunião Ordinária realizada nos dias 13, 14, 16 e 17 de setembro de 2021, em Brasília, DF, com base no "caput" da cláusula quarta do Convênio ICMS nº 143, de 15 de dezembro de 2006, resolveu: Art. 1º O art. 1º do Ato COTEPE/ICMS nº 44, de 07 de agosto de 2018, passa a vigorar com a seguinte redação: "Art. 1º Fica instituído o Manual de Orientação do Leiaute da Escrituração Fiscal Digital - EFD ICMS IPI, conforme alterações introduzidas pela Nota Técnica EFD ICMS IPI nº 2021.001 v1.0, publicada no Portal Nacional do Sistema Público de Escrituração Digital (SPED), que terá como chave de codificação digital a sequência "6141D8CB1D8D503F348CA06BDAF2A387", obtida com a aplicação do algoritmo MD5 - "Message Digest 5", e disponibilizada no sítio eletrônico do CONFAZ (www.confaz.fazenda.gov.br). Parágrafo único. Deverão ser observadas as regras de escrituração e de validação do Guia Prático da Escrituração Fiscal Digital - EFD ICMS/IPI, versão 3.0.7, publicado no Portal Nacional do Sistema Público de Escrituração Digital (SPED), que terá como chave de codificação digital a sequência "40717A97869031175948FB6614BBF4D5", obtida com a aplicação do algoritmo MD5 - "Message Digest 5".". Art. 2º Este ato entra em vigor na data da sua publicação no Diário Oficial da União, produzindo efeitos a partir de 1º de janeiro de 2022. Carlos Henrique de Azevedo Oliveira, Presidente da COTEPE/ICMS, Adriano Pereira Subirá da Receita Federal do Brasil, Adriano Chiari da Silva da Procuradoria Geral da Fazenda Nacional, Maria José do Carmo Maia do Estado do Acre, Marcelo da Rocha Sampaio do Estado de Alagoas, Robledo Gregório Trindade do Estado do Amapá, Thiago Cabeleira do Estado do Amazonas, Ely Dantas de Souza Cruz do Estado da Bahia, Victor Hugo Cabral de Morais Junior do Estado do Ceará, Leonardo Sá Santos do Distrito Federal, Rômulo Eugênio de Siqueira Chaves do Estado do Espírito Santo, Elder Souto Silva Pinto do Estado de Goiás, Luis Henrique Vigário Loureiro do Estado do Maranhão, Patrícia Bento Gonçalves Vilela do Estado do Mato Grosso, Miguel Antônio Marcon do Estado do Mato Grosso do Sul, Fausto Santana da Silva do Estado de Minas Gerais, Simone Cruz Nobre do Estado do Pará, Fernando Pires Marinho Júnior do Estado da Paraíba, Mateus Mendonça Bosque do Estado do Paraná, Manoel de Lemos Vasconcelos do Estado de Pernambuco, Gardênia Maria Braga de Carvalho do Estado do Piauí, Guilherme Alcantara Buarque de Holanda do Estado do Rio de Janeiro, Luiz Augusto Dutra da Silva do Estado do Rio Grande do Norte, Leonardo Gaffrée Dias do Estado do Rio Grande do Sul, Emerson Boritza do Estado de Rondônia, Larissa Góes de Souza do Estado de Roraima, Ramon Santos de Medeiros do Estado de Santa Catarina, Luis Fernando dos Santos Martinelli do Estado de São Paulo, Rogério Luiz Santos Freitas do Estado de Sergipe, Antônio Teixeira Brito Filho do Estado do Tocantins. CARLOS HENRIQUE DE AZEVEDO OLIVEIRA Diretor Fonte : ATO COTEPE/ICMS Nº 62, DE 17 DE SETEMBRO DE 2021 - ATO COTEPE/ICMS Nº 62, DE 17 DE SETEMBRO DE 2021 - DOU - Imprensa Nacional (in.gov.br)

- Remova a suite do ACBr instalada - Remova a suite do FastReport instalada - Limpe o LibPath todas as referencias ao FastReport e ACBr - Limpe todas essas BPL espalhadas tanto do FastReport e ACBr - Reinstale o FastReport - Não coloque arquivos fontes (pas) do FastReport no LibPath - Faça o Download de uma nova fonte do ACBr do SVN - Instale o ACBr

Boa tarde, Se funciona na versão anterior, qual o commit que quebrou ? Lembrando, que é necessário versão comercial do mesmo, pois necessita da parte de scripts, se no seu libpath tiver por exemplo a versão Embarcadero, pode ocorrer erros; Mas no caso do log, está dizendo que está faltando o package frx25, e pelo o que vi, você tem ele espalhado para vários lugares, tudo indica que sua instalação não está coesa do FastReport, esse monte de bpl está errado, está conflitando as coisas, eu removeria tudo esses pacotes que está espalhado, limparia o library path, primeiramente isso, faria uma instalação do FastReport limpa, e deixaria apenas o Lib do rebuild do FastReport, lembrando que, no LibPath não deve ficar códigos fontes lá, somente os DCU compilados. Depois faria a instalação limpa também do ACBr.

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

Bom dia ai é regra da sua aplicação em tratar os retornos. a distribuição é para todas as personas envolvidas, conforme a NT 2014.002 e foto no post acima extraído dela, ai a regra de negocio da sua aplicação que fara a inteligência desejada

Além disso você tem que analisar o vBC dos Itens Está nas Nota Técnicas. Fórmula do DIFAL na NT 2020.005: ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) * pICMSInterPart Fórmula do DIFAL até a NT 2020.005: vBCUFDest * (pICMSUFDest - pICMSInter) * pICMSInterPart