MSS

Olá, @Anderson Mendonça! Necessário maiores informações, para analisar a origem do problema. Analisar se a origem do problema está no arquivo .INI Você está gerando arquivo .INI com as informações do evento ? Se sim, nesse arquivo existe o grupo "duracao" e dentro dele os itens "tpContr" e "dtTerm" estão com quais valores? Analisar se a origem do problema está no gerador do objeto referente ao evento S2206 Necessário saber como está sendo alimentado a classe TInfoContrato; para poder analisar os dados antes de chegar no gerador. Seria importante, anexar os arquivos gerados desde o inicio do processo, para facilitar o processo de analise. []s, Mário.

Bom dia, @Renato Rubinho! Comparei a unit commit [r35193] com a que estamos utilizando e confirmei que houve apenas a realocação das constantes (da entrada do método para entrada da unit) e essa alteração não afeta a funcionalidade do método. Substitui a nossa versão, fork da unit, pela versão atualizada da ACBr e estaremos liberando novas releases do nosso sistema nos próximos dias. Surgindo qualquer tipo de necessidade de correção informo a ACBr. Obrigado. []s,Mário

Olá, @Renato Rubinho! Anexo o arquivo da unit alterada. []s, Mário pcesConversaoeSocial.pas

Olá, @Renato Rubinho! Não respondi anteriormente, porque estava em licença pós-operatória. Não me recordo da existência específica de um problema que tenha gerado essa demanda. Fui implementar o evento S-2221 no nosso sistema e percebi o que explanei no inicio do post. Visando aprimorar, refatorei o código mencionado e passei para o nosso setor de Qualidade validar a geração e envio de TODOS os eventos do eSocial. Após homologação do departamento; encaminhei o código para a apreciação da ACBr. []s, Mário

Por ocasião da realização de algumas alterações na unit pcesConversaoeSocial, que foram aplicadas na revisão 24464, de 19/02/2022; foi criada uma constante (__ARRAY_MATRIX_EVENTO_INFO) para mapear e centralizar algumas das informações relacionadas aos eventos e versões do eSocial. A expectativa com essa implementação era que com a ocorrência de novas intervenções esse mapeamento poderia ser atualizado e aprimorado, possibilitando assim a refatoração de diversos códigos, migrando-os pouco a pouco para uma codificação mais dinâmica e flexível. Porém, a expectativa não correspondeu a realidade e o que aconteceu com o mapeamento foi simplesmente um copiar e colar, a cada nova versão do eSocial. A falta de alteração/refatoração/analise mais aprofundada além de não permitir a ampliação de uso do recurso, ainda pode gerar uma quebra de código, consumo elevado de recursos, multiplicidade desnecessária de informações, etc... (Ex: a versão atual do array __ARRAY_MATRIX_EVENTO_INFO já estava com 163 elementos definidos quando precisa de 77) Para adicionar o evento S-2221 corretamente na matriz; foi refatorado partes especificas de código, conforme detalhes a seguir: 1. Encapsulamento da constante __ARRAY_MATRIX_EVENTO_INFO dentro do unico metodo (GetMatrixEventoInfo) que a utiliza. 2. Adicionado o conceito de faixa/validade/range de versões para os eventos, no record TRecMatrixEventoInfo. 3. Adicionado o conceito de faixa/validade/range de versões para os eventos na constante (__ARRAY_MATRIX_EVENTO_INFO). 4. Adicionado uma constante para identificar o ultimo item do enumerador TVersaoeSocial (__LAST_VERSION). 5. Os blocos de códigos alterados estão delimitadas com os comentários: // [MSS - 19/08/2024 - Start] - # // [MSS - 19/08/2024 - End] - # Em anexo a unit pcesConversaoeSocial para analise, estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr. *** Alterações efetuadas no arquivo base: p/acbr/code - Revision 34924: /trunk2/Fontes/ACBrDFe/ACBreSocial/PCNeSocial/pcesConversaoeSocial.pas []s, Mário pcesConversaoeSocial.pas

Bom dia, Ronald. Verifique se não ocorreu problemas com o seu banco de dados, devido a queda de energia. Estou percebendo pelo trecho de código, que o XML vem de um banco de dados e ele pode estar com alguns registros danificados. []s. Mário

Bom dia. Conforme solicitado, estou anexando as units alteradas. []s, Mário pcesS2200.pas pcesS1010.pas

Boa tarde, Renato. Eu estava logando no Fórum da ACBr para criar um post a respeito de correções no método LerXML das units pcesS1010 e pcesS2200; mas desisti de abrir o post e vou interagir nesse aqui. O método LerXML dos eventos S-1010 e S-2200 atribuem valores para a propriedade Id utilizando-se de chamada para Leitor.rCampo e o correto seria Leitor.rAtributo. Na realidade eu creio que essa atribuição para Id no método LerXML seja desnecessário; porque essa propriedade é alimentada previamente ao passar pelo método TeSocialEvento.SetXML, da unit pcesGerador; Para solucionar o problema sem analisar maiores impactos eu apenas substitui o código, nas units pcesS1010 e pcesS2200: Id := Leitor.rCampo(tcStr, 'Id'); por if Self.Id = '' then Self.Id := Leitor.rAtributo('Id='); []s, Mário

Bom dia, Rubinho. Eu tinha atualizado a ACBr com a revisão 31188, semana passada, e tinha percebido que a correção mencionada ainda não havia sido aplicada; apliquei a correção na release e liberei uma versão RC (Release Candidate) do nosso sistema para o departamento de qualidade revalidar o processo do eSocial para as versões S1.01 e S1.02. Vou aguardar o retorno da qualidade com relação a essa versão do nosso sistema e após farei uma nova atualização da ACBr antes de liberar o sistema novamente para homologação. A solução que você aplicou está correta e foi a minha primeira opção de correção; porem eu optei por deixar mais claro o código da condicional e minimizar a possiblidade de eventuais problemas, se a ordem de definição do tipo for alterada. Mas o que importa é que está funcionando e não há necessidade de alterar o código da ACBr a cada atualização. Obrigado. []s, Mário Soares Santos

Boa tarde, Alexandre e Renato! Peço desculpas pela demora na resposta. Segue anexo a unit pcesConversaoeSocial, da revisão 30975, com a correção aplicada. Origem do código fonte: p/acbr/code - Revision 30975: /trunk2/Fontes/ACBrDFe/ACBreSocial/PCNeSocial/pcesConversaoeSocial.pas Não tenho nenhum XML nesse momento para anexar; porem o erro é simples de reproduzir: O XSD utilizado para validar o XML do evento S-1207, em versão de eSocial diferente da S-01.01.00 não é localizado corretamente porque o nome desse XSD é retornado incorreto (Schema). Até a versão S-01.01.00 o schema era "schevtCdBenPrRP" e após é "schevtBenPrRP". []s, Mário Soares Santos pcesConversaoeSocial.pas

Dando continuidade ao tópico Evento S-1207 - Problema de identificação do evento e aprimorando a solução apresentada anteriormente; segue apresentação de solução para novo problema encontrado,relacionado ao tópico. Resumo Validação do evento S-1207 não está encontrando o XSD correto, devido a teste via IF incorreto. Localização unit pcesConversaoeSocial; function TipoEventoToSchemaeSocial Linha +- 1508 - if (AVersaoeSocial <> veS01_00_00) then Analise No commit [r26739] da ACBr, de 14/09/2022 foi adicionado um teste via IF, na localização mencionada acima, que atendia as condições especificas até esse commit (versão S-01.01.00 do eSocial). No commit [r27742] da ACBr, de 08/12/2022 foi implementado recursos para atender a versão S-01.01.00 do eSocial, porem o teste via IF não foi modificado e o teste passou a retornar informação incorreta para a nova versão. Solução Modificar o teste via IF, mencionado acima, conforme abaixo: (-) if (AVersaoeSocial <> veS01_00_00) then (+) if ((AVersaoeSocial = ve02_04_01) or (AVersaoeSocial = ve02_04_02) or (AVersaoeSocial = ve02_05_00)) then []s, Mário Soares Santos

Boa tarde, Elton ! Analise realizada, correções e testes efetuados em ACBr - Trunk2 - Revisão 26002 - 30/06/2022 git-svn-id: https://svn.code.sf.net/p/acbr/code/trunk2@26002 6e92efe7-b92a-0410-a9ec-f9e4e41bb3a6 Fontes\ACBrDFe\ACBreSocial\PCNeSocial unit pcesGerador; unit pcesIniciais; unit pcesTabelas; unit pcesNaoPeriodicos; unit pcesPeriodicos; unit pcesConversaoeSocial; Código disponibilizado para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr. []s, Mário Soares Santos ACBr-eSocial-2022-07-01.zip

Olá, Elton ! No momento estamos utilizando uma versão congelada da ACBr de 05/04/2022 e não podemos atualiza-la sem analisar antes os impactos das alterações ocorridas após essa data. Assim que for possivel, baixarei a ultima versão da ACBr e realizarei um "compare" nas units que alteramos para verificar se as correções efetuadas permanecem válidas e não quebram o código da ACBr. Informarei nesse post quando realizar essa analise. []s. Mário Soares

Boa tarde, Willian. - eSocial - versão S1.00 - Acbr - versão trunk2 de 20/04/2022 - XSD - desatualizado Segue anexo nova versão dos arquivos XSD do eSocial, já renomeados para o padrão da Acbr. veS01_00_00.zip

Bom dia,Rafael. Eu não conheço nenhum método no WebService do eSocial que possibilite o retorno de um numero de protocolo para um lote enviado; e como não existe uma fórmula infalível para tratar essa questão de timeout; minha recomendação é que você utilize a técnica que eu chamo de "dividir para conquistar". Passo 1) Determine as condições iniciais para aplicação na formula a seguir: Exemplo: 50 eventos por lote em 10 segundos de timeout. Passo 2) Teste com as condições iniciais para ver se funciona; se funcionar divida o tempo de timeout pela metade e repita o processo até achar o timeout que funcione a contento. Passo 3) Se o passo dois não funcionar, mantenha as condições iniciais (ex: 50 x 10) e passe a dividir a quantidade de eventos pela metade; mantendo o timeout repita esse processo até encontrar a quantidade de eventos que possam ser enviados por lote no timeout inicial; ou até atingir um evento por lote no timeout inicial. Dicas: Importante testar a combinação encontrada para cada instalação e em diversos dias e horários. As condições de comunicação são dinâmicas e mudam inumeras vezes. Deixar esses parâmetros passiveis de serem alterados facilmente pelo sistema. Não engessar o sistema com a definição de valores fixos para todas as instalações; a comunicação entre o sistema local e servidor remoto depende de inúmeros fatores para que ocorra sem maiores problemas. Enfim; é na base da tentativa e erro que se encontrará a melhor combinação entre eventos x lote x timeout na instalação naquele momento. []s, Mário

Dando continuidade na solução apresentada no tópico "Eventos S-2400 e S-2410 - Problema de identificação de tipos de eventos" As atuais alterações implementam a utilização da versão do eSocial, existente na configuração. Foi necessário analisar e utilizar a versão do eSocial porque o problema apresentado no evento S-1207 está relacionado a tag <evtBenPrRP>, que na versão v2.5.xx é <evtCdBenPrRP>; então para manter a compatibilidade funcional entre as versões foi necessário implementar e validar a versão do eSocial. As alterações realizadas estão indentificadas através da palavra "[MSS", contida em comentário, que pode estar em apenas uma linha ou abrindo e fechando um bloco de alterações. As units afetadas são as seguintes: unit pcesGerador; unit pcesIniciais; unit pcesTabelas; unit pcesNaoPeriodicos; unit pcesPeriodicos; unit pcesConversaoeSocial; Estou disponibilizando o código para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr. []s, Mário Soares Santos ACBr-eSocial.zip

Boa tarde, Luiz. O ambiente de produção restrita está aceitando conexão usando-se única e exclusivamente o protocolo TLS v1.2. Eu tinha visto alguns meses atrás um informativo do eSocial que avisava sobre algumas mudanças nos processos de segurança de comunicação. Não sei se a questão do TLS está relacionada a esse informativo ou não, porque não localizei mais ele no site do eSocial. Mas vale lembrar que em 26/06/2015 (conforme consta no manual de orientação do desenvolvedor v1.11 - item 6.4) houve alteração do protocolo de segurança da camada de transporte de SSL para TLS; e pode ser que somente agora o eSocial tenha resolvido desabilitar o protocolo SSL. Cabe ainda ressaltar que no mesmo manual apresenta-se a criação de "Cifras", agora em 03/2022 e a aplicação da versão 1.3 do protocolo TLS. A TLS v1.3 não está em uso no ambiente de produção restrita, no ambiente de produção eu não verifiquei. []s, Mário Soares

Olá, Combinação de processos e configurações. 1) Na sequencia ao envio: Disparo da consulta imediatamente após o envio do evento, usando quantidade de tentativas de consulta e tempo de intervalo configuráveis/ajustáveis. 2) Na automatização/agendamento/cron job: Disparo da consulta do eventos pendentes de processamento usando quantidade de tentativas de consulta, tempo de intervalo e dias/horários configuráveis/ajustáveis. 3) Manual 1: No envio de novos eventos valida a existência de consultas pendentes e disponibiliza ao usuário a opção de realizar a consulta antes de processar o envio. 4) Manual 2: A qualquer momento o usuário pode disparar a execução da consulta de um evento especifico ou de vários; baseado em filtros. []s Mário

Olá, Guilherme. No web service do eSocial não existe, até o momento, nenhum método que seja possível realizar a consulta/validação que você precisa. A inexistência de tal método no eSocial inviabiliza a criação de rotinas, na ACBr, para efetuar a consulta mencionada; porque para tal seria necessário que a ACBr realizasse a gestão dos cadastros/eventos do eSocial o que não me parece ser a proposta do produto. Desconheço a existência de quaisquer web service do governo que permita realizar tal tipo de consulta. []s Mário

Oi, Elton ! Verifiquei os ajustes que você realizou e a principio não vi nada que pudesse ser causador de problemas na alteração principal. Porem; o próximo post veio demonstrar que uma coisa simples do ajuste quebraria todo o sentido da alteração principal. Oi, Lucas. Você foi o felizardo premiado em descobrir o primeiro problema. A correção que você fez funciona, mas ela não resolve a causa do problema na raiz, resolve parte do efeito causado. A seguir apresento o que detectei debugando o metodo StringXMLToTipoEvento() e a correção aplicada. O metodo LastIndexOf() retorna a ultima posicão encontrada da string e o metodo PosLast() retorna a proxima posição após encontrar a string; e isso gera inconsistências no processamento do metodo StringXMLToTipoEvento(). A correção foi aplicada nas linhas que utilizam o metodo PosLast(); corrigindo assim a informação desde o inicio e evitando-se que, ao debugar o código, as informações fiquem inconsistentes até o ponto de ajuste. []s, Mário Soares Santos pcesConversaoeSocial.pas

Oi, Elton ! Qualquer XML que obedeça a estrutura do S-2400, S-2410 e alguns outros, possíveis, porem ainda não analisados, irão passar pelo mesmo problema na função TEventos.LoadFromString. Conforme solicitado, segue anexo um XML do S-2400 que ao ser carregado através da função TEventos.LoadFromFile não é identificado corretamente; por causa do mencionado no start deste post. Os dados utilizados para preenchimento do XML anexo são fictícios. []s, Mário Soares Santos 1455215570001062022012408463305320-S-2400-0.xml

Olá Elton, Nesse momento estamos sob tensão total; porque desenvolvemos software exclusivamente para orgãos públicos e o eSocial é o projeto que estou responsável e focando em full time. Para criar um exemplo prático sobre a questão eu precisaria gastar algum tempo e isso agora é impensável. Vou tentar conseguir algumas horas livres mais lá pra frente e assim poder criar alguma coisa para apresentar. Estamos gerando os XML dos eventos através do nosso sistema de RH e alimentando as classes de ACBreSocial através do metodo LoadFromString. Mas posso adiantar que outros problemas decorrentes da falha na sincronização entre TEventoString e TTipoEvento irão ocorrer. []s, Mário Soares Santos

A identificação do tipo de evento errado nos eventos S-2400 e S-2410 causam problemas na geração/carga/assinatura/validação dos XMLs. Explicação: - Ao executar a função ACBreSocialEventos -> TEventos.LoadFromString é disparada a execução da função LoadFromString especifica referente ao grupo do evento do XML (pcesPeriodicos -> TPeriodicos.LoadFromString, pcesNaoPeriodicos -> TNaoPeriodicos.LoadFromString, pcesTabelas -> TTabelas.LoadFromString, pcesIniciais -> TIniciais.LoadFromString). - As funções LoadFromString de cada grupo de eventos utilizam-se da função pcesConversaoeSocial -> StringXMLToTipoEvento para identificar o tipo do evento a partir da identificação contida dentro do XML. - A função pcesConversaoeSocial -> StringXMLToTipoEvento utiliza um laço no array pcesConversaoeSocial -> TEventoString para localizar o enumerador pcesConversaoeSocial -> TTipoEvento. Problema: - O array pcesConversaoeSocial -> TEventoString e o enumerador pcesConversaoeSocial -> TTipoEvento não são equivalentes na quantidade e nem na ordem de ambos; causando assim retorno incorreto pela função pcesConversaoeSocial -> StringXMLToTipoEvento. Solução: - Buscando solucionar o problema acima mencionado, evitar maiores impactos em códigos legados e preparar um padrão que atenda aos antigos e novos eventos que estão por vir (S2500, S2501 e S5501 - v. S-1.0 - NDE 02/2021 - Processo Trabalhista) foram realizadas as seguintes alterações: - a) Adição de item no enumerador pcesConversaoeSocial -> TeSocialSchema; - b) Adição de itens no enumerador pcesConversaoeSocial -> TTipoEvento; - c) Criação do enumerador pcesConversaoeSocial -> TMatrixEventoInfo; - d) Criação do record pcesConversaoeSocial -> TRecMatrixEventoInfo; - e) Criação da constante pcesConversaoeSocial -> __ARRAY_MATRIX_EVENTO_INFO; - f) Criação da função pcesConversaoeSocial -> GetMatrixEventoInfo; - g) Refatoração da função pcesConversaoeSocial -> StringINIToTipoEvento; - h) Refatoração da função pcesConversaoeSocial -> StringXMLToTipoEvento; - i) Refatoração da função pcesConversaoeSocial -> TipoEventoToStrEvento; Observações: - Todas as alterações foram realizadas na unit pcesConversaoeSocial; - Todas as alterações estão identificadas e são facilmente localizadas através da palavra "[MSS", contida em comentário, que pode estar em apenas uma linha ou abrindo e fechando um bloco de alterações. Estou disponibilizando o código para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr. []s, Mário Soares Santos pcesConversaoeSocial.pas

Boa Tarde, @Italo Jurisato Junior! Testei a sua implementação e a mesma está correta (TeSocialEvento.GerarChaveEsocial), porem faltou aplicar o mesmo teste na procedure GerarIdeEmpregador, da unit pcesGerador. []s, Mário Soares Santos

Bom dia, @Italo Jurisato Junior! Estou atualizando a ACBr e modificando o código de preenchimento dos registros. Assim que eu terminar os testes te informo. []s, Mário Soares Santos