Sófolha

Boa tarde! Apenas para contribuir com o tópico, tudo indica que a mudança está relacionada exclusivamente à aceitação da nova cadeia de certificados pelo ambiente responsável pela transmissão dos eventos ao eSocial, não sendo necessária nenhuma adequação específica no ACBr. Conforme divulgado pelo eSocial, a nova cadeia de certificados da Sectigo já está em utilização no ambiente de Produção Restrita desde janeiro de 2026. Em nossos testes, mesmo após a remoção manual do certificado raiz Sectigo Public Server Authentication Root R46, o Windows realizou sua reinstalação automaticamente durante uma nova comunicação com os WebServices do eSocial. Com base nesses testes, a expectativa é que estações de trabalho e servidores com o Windows devidamente atualizado não apresentem qualquer impacto após a implantação da mudança em Produção. Por outro lado, podem ocorrer falhas de comunicação em ambientes com versões mais antigas do Windows, sistemas desatualizados ou que possuam restrições para atualização automática de certificados. De qualquer forma, estamos acompanhando atentamente nossa base de clientes e monitorando possíveis ocorrências relacionadas a essa alteração, para identificar e tratar rapidamente qualquer impacto não previsto. Espero que essa experiência ajude outros colegas que também estejam avaliando os possíveis reflexos dessa mudança. At.te.

De acordo com a Nota Técnica 2023.001 (Tributação Monofásica sobre Combustíveis) a regra de validação LA03d foi excluída (Obrigatória a informação do campo vPart (id: LA03d) para produto "210203001 – GLP" (tag:cProdANP) (NT 2016.002)), mas no ACBr continua sendo feita a validação. Segue em anexo o arquivo (ACBrNFeNotasFiscais.pas) com a correção. ACBrNFeNotasFiscais.pas

Boa tarde! @Juliomar Marchetti, o código foi corrigido parcialmente. Por favor, observe a estrutura do tipo "TAltContratual" na imagem abaixo, focando nas propriedades "Vinculo" e "infoRegimeTrab". Agora, compare com a imagem subsequente, onde a classe "Vinculo" também contém a propriedade "infoRegimeTrab". Ambas estão referenciando a mesma classe "TInfoRegimeTrab". Na última versão do método "gerarAltContratual" (veja a imagem abaixo), nas linhas 310, 312, 313 e 314, o sistema acessa as propriedades do atributo "objAltContratual.Vinculo.infoRegimeTrab", enquanto na linha 318, utiliza as propriedades de "objAltContratual.infoRegimeTrab". Além disso, na função "function TEvtAltContratual.LerArqIni(const AIniString: String): Boolean;", todos os valores são atribuídos à propriedade "InfoRegimeTrab" do objeto. As alterações sugeridas por @Andergoncalves padronizaram o acesso à propriedade "objAltContratual.Vinculo", incluindo a modificação na função "TEvtAltContratual.LerArqIni". Resumindo, parte do código utiliza "objAltContratual.Vinculo.infoRegimeTrab." e outra parte utiliza "objAltContratual.infoRegimeTrab.". Acredito que seguir a sugestão do @Andergoncalves, conforme também é feito no S-2200 com a estrutura "vinculo.InfoRegimeTrab", seria mais adequado. Atenciosamente,

Bom dia, Realizamos um levantamento entre nossos clientes que relataram esses erros e identificamos que eles estão usando diversas Autoridades Certificadoras diferentes. Alguns exemplos incluem Link RDB V2, Certisign RFB G5, Certifica Minas v5 e Soluti Multipla v5, Safeweb RFB v5. Além disso, é importante destacar que esses certificados são os mesmos usados para transmitir eventos no eSocial. Essas informações nos levam a descartar a hipótese de que o problema esteja relacionado aos certificados ou à sua instalação. Para reforçar nossa posição, foi publicada ontem uma mensagem no portal Sped. Ela informa que a revisão do conjunto de protocolos TLS na EFD-Reinf, que originalmente estava programada para 21/10/2023 e implicava na desativação do uso de TLS 1.0 e TLS 1.1, foi adiada para janeiro de 2024. A data exata ainda será divulgada. Provavelmente, ainda estão ajustando os servidores para recepcionar as informações com esse nível de criptografia. Adiamento da revisão do conjunto aceito de TLS na EFD-Reinf (rfb.gov.br) At.te,