Andergoncalves

Hoje o eSocial está na versão 1.2 Simplificada. A versão 2.5 e anteriores foram descontinuadas faz tempo.

Sim a partir da versão 1.0 Simplificada não vai dar problema. Somente para versão 2.5 e anterior. No evento S-2200 verificamos que já está tudo atualizado e correto populando o atributo "Vinculo", apenas como informei anteriormente tem que tomar cuidado para que seja informado agora o atributo "Vinculo" nas aplicações. É muito importante não esquecer de alterar o atributo AltContratual para AltContratual.Vinculo na aplicação.

Boa Tarde. No S-2200 já não existe mais o campo mtvAlter. Apenas fiz a atualização desta parte na função. Foi retirado está parte devido a não existir no Atributo "Vinculo". Meu fonte esta atualizado com a Revion 33236.

Bom dia. Implementando o atributo "Vinculo" na função "TEvtAltContratual.LerArqIni". Subindo a versão final do arquivo. Obrigado pcesS2206.pas

A partir da versão 1.0 simplificado e no S-2200 não existe mais : Foi excluído. Foram feito as seguintes alterações e testado o envio no ambiente de produção restrita. Ajuste na procedure GerarAltContratual. É muito importante que não esquecer de alterar o atributo AltContratual para AltContratual.Vinculo na aplicação. pcesS2206.pas

Irei verificar aqui. Obrigado

No S-2200 está correto com o atributo 'Vinculo', somente no S-2206 teremos que alterar os atributos. Inclusive ficarmos atentos para alterar nas aplicações.

O "infoRegimeTrab" está sendo utilizado a partir de "objAltContratual.Vinculo" apenas na parte alterada. Nas demais referências desse objeto no arquivo pcesS2206.pas, está sendo utilizado a partir de "objAltContratual". Além disso, a função "TEvtAltContratual.LerArqIni " não acessando os atributos de "objAltContratual.Vinculo". Se alterar conforme sugerido por "paulosilva0306", será necessário corrigir as aplicações que já enviam o S-2206, pois será preciso preencher os objetos a partir de "objAltContratual.Vinculo". Além disso, será necessário corrigir a função "TEvtAltContratual.LerArqIni"

Após a alteração, a rotina passou a buscar o atributo 'infoRegimeTrab' e 'infoContrato' a partir do atributo 'Vinculo'. Anteriormente, essa informação era buscada a partir do objeto. O grupo 'vinculo' foi incluído no layout da versão 1.0 em diante, no entanto, o componente não estava utilizando as informações desse atributo. Entendo que, se formos utilizar o atributo 'vinculo', será necessário corrigir nossas aplicações para atribuir os valores dos atributos no 'Vinculo'. if objAltContratual.infoRegimeTrab.Vinculo.InfoCeletista.cnpjSindCategProf <> '' then GerarInfoCeletista(objAltContratual.Vinculo.infoRegimeTrab.InfoCeletista) Inclusive na função TEvtAltContratual.LerArqIni teremos que ajustar para ler o atributo 'Vinculo'.

Boa tarde. Sim. Hoje está metade 2.5 e a outra metade Simplificada.

Bom dia. Atualizamos o ACBR hoje e nos deparamos com uma situação de erro quando enviamos o Evento S-2206. Consultando os posts vimos que houve alteração: Agradecemos a colaboração. A respeito da alteração seria para compatibilizar os atributos conforme a versão do ACBR? O atributo "Vinculo" conforme leiaute do eSocial a partir da versa 1.0 Simplificado. Se sim: tanto o infoRegimeTrab e infoContrato estão ligados ao "Vinculo" a partir da versão 1.0 Simplificada. Conforme imagem acima podemos ver que não foi compatibilizado conforme a versão do ACBR na linha 310 para baixo, como estando sendo na linha 300 a geração do grupo. Na linha 310 faltou também incluir o "Vinculo" para comparar e gerar o grupo InfoEstatutario. objAltContratual.Vinculo.infoRegimeTrab.InfoCeletista.cnpjSindCategProf. Também verifiquei nas estrutura do ini temos que fazer a compatibilidade das versões do ACBR. A alteração irá impactar em todos que estão enviando hoje com os atributos da versão 2.5. Qual caminho foi proposto pela alteração? "Compatibilizar" ou "Alterar" para versão atual? Daí podemos definir qual será a linha de desenvolvimento que iremos seguir para ajudar nossos amigos da comunidade. Obrigado Anderson Mensagem de erro retornada pelo eSocial com a atualização feita hoje.

Boa tarde. Estou disponibilizando uma sugestão de mudança no evento S-2299 gerado pelo processo trabalhista que estava dando erro por não ser informado a tag nrProcTrab, Onde ele estava filtrando somente quando motivo de desligamento for 17. Conforme leiaute do eSocial versão 1.2 a única validação se o número do processo deve conter no mínimo 20 algarísmos. Obrigado original: mudança: pcesS2299.pas

Bom dia. Realizei mais um ajuste no Enumerator do tpRegTrab e tpTpRegPrev. Estou enviando em anexo com as novas atualizações. Obrigado pela atenção. pcesConversaoeSocial.pas

Bom dia. Fazendo testes para enviar o evento S-2500 me deparei com algumas situações. Os valores de tpTpRegTrab (trCLT) e tpTpRegPrev (rpRGPS) estavam com o valor inicial 1. Existe casos em que não existe valor a ser informado para a geração do S-2500. Estava criando as Tags </codCBO> e </infoVinc> ocasionando erro na validação schema. As alterações foram validas e enviadas no Ambiente de Produção restrita. Obrigado pcesConversaoeSocial.pas pcesS2500.pas

Bom dia. Hoje fiz teste e está funcionando.

Boa tarde! Acredito que o ACBR ainda não implementou a criptografia utilizando o TLS 1.3. Analisando o código fonte da ACBR, observei que ao usar a propriedade SSLType definida como LT_TLSV1_3, a função TACBrWinHTTPReqResp.SetConnectionSSL opera da mesma maneira que a configuração LT_ALL. A configuração LT_ALL utiliza a criptografia do SSL2, SSL3 ou TLS1, conforme pode ser visto na imagem abaixo. Isso explica por que, ao transmitir eventos para a EFD-Reinf, funcionou, pois utilizou um protocolo mais antigo de criptografia, que ainda está operacional, mas tem data prevista para ser bloqueado pela Receita Federal do Brasil em 20/10/2023. Ao testar o TLS 1.3 no eSocial, o ACBR direciona para o mesmo código que a EFD-Reinf está usando. Uma vez que o servidor do eSocial tem um tratamento específico para essa situação, ele retorna um erro informando que o protocolo SSL é incompatível, reforçando a nossa tese de que o protocolo TLS 1.3 ainda não está implementado no ACBR. Surge uma dúvida: não tenho certeza se estou aplicando os critérios de avaliação corretamente ou se, de fato, o protocolo TLS 1.3 ainda não foi implementado no ACBR.

Bom dia @Renato Rubinho. Obrigado a todos pela informação. Renato fiz o teste aqui mudando para TLS1_3 e funcionou. Porém depurando o código do ACBR achei uma função que pode ser que funcione assim mesmo ou teria que implementar o TLS1_3. Ele acessa justamente o mesmo valor da opção TL_all. C:\ACBR\Fontes\ACBrTCP\ACBrWinHTTPReqResp.pas Obrigado Anderson

@Alexandre de Paula fizemos outro teste aqui enviando pelo eSocial com a mesma empresa e certificado A3 e funcionou. TLS 1.2.

O problema somente acontece com o certificado do Tipo A3. Testes realizados com A1 funciona perfeitamente no TLS 1.2.

Boa tarde @Alexandre de Paula Obrigado pela atenção. Fizemos testes com nossa aplicação e também com programa exemplo da ACBR, com o SSLType LT_TLSv1.2 e apresenta o erro: Com SSLType LT_TLSv1.1 foi enviado:

Boa tarde a todos, Após uma análise aprofundada dos posts referentes ao tema, ainda não conseguimos chegar a uma conclusão definitiva sobre a questão em discussão. Em nosso sistema, Iniciamos a configuração padrão com o SSLType definido como LT_TLSv1_2. Entretanto, temos registrado uma série de chamados em nosso suporte técnico que relatam o erro "Inativo/Inoperante" ao tentar transmitir eventos para o EFD-Reinf. Como solução temporária, realizamos a alteração desse parâmetro para LT-ALL, o que permitiu a transmissão dos eventos sem problemas. No entanto, é importante destacar que, conforme a informação disponibilizada em http://sped.rfb.gov.br/pagina/show/7280, a Receita Federal do Brasil passará a aceitar apenas conexões TLS na versão 1.2 ou superior a partir de 21/10/2023. Isso nos causa preocupação, uma vez que receamos enfrentar o mesmo erro no próximo mês. Para melhor compreender a situação, reproduzimos o erro que nossos clientes têm encontrado em nosso ambiente de desenvolvimento. Aqui, utilizamos o Windows 11, na versão mais atualizada, e, ao tentar enviar um evento para o EFD-Reinf, também nos deparamos com a mensagem "Inativo/Inoperante". Fiz testes com : LT_all OK - funcionou LT_TLSv1_0 OK - funcionou LT_TLSv1_1 OK - funcionou LT_TLSv1_2 ERRO - inativo ou inoperante Fazendo teste em minha máquina que esta com o Windows atualizado ocorre o mesmo erro. Além disso, em nossas avaliações nos ambientes dos clientes, a maioria dos quais são escritórios de contabilidade, notamos que em um mesmo escritório foi possível transmitir eventos para uma empresa que utiliza certificado A3, enquanto outra empresa, também com o mesmo tipo de certificado, apresentou o erro mencionado. Essa observação nos leva a concluir que o problema não parece estar ligado ao ambiente do cliente. Agradecemos a todos pelo empenho e pelas sugestões até o momento. Contudo, vale ressaltar que continuamos investigando a origem desse problema. Caso algum colega possua informações adicionais ou contribuições que possam nos auxiliar a encontrar uma solução definitiva, seremos imensamente gratos.

Boa Tarde. Primeiramente agradecer ao empenho de todos os envolvidos. Implementamos a rotina de consulta de CNPJ e está funcionando perfeitamente. Obrigado Anderson

Bom dia! Estou enviando como sugestão de alteração, uma versão atualizada do Eventos S-2500, no ambiente 1.2 do eSocial. Onde foram feitos ajustes e criado objetos. Foram feitos ajustes nos arquivos de configuração do ACBR para que seja possível selecionar o ambiente na versão 1.2 e os schemas. Agora estamos aguardando a liberação do ambiente no eSocial para testes. Obrigado Anderson pcesConversaoeSocial.pas pcesS2500.pas ACBreSocialConfiguracoes.pasv_S_01_02_00.zip

Boa tarde! Estou disponibilizando ajuste de novos Tipo de Contrato para o Evento S2500 que constam no leiaute da versão 1.2 do eSocial. Obrigado Anderson pcesConversaoeSocial.pas