MSS

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

Bom dia, Adailton. É necessário executar algumas processos para execução com sucesso da etapa de envio dos eventos do eSocial. Esse XML que você passou é o processo de envio do lote de eventos e ele não é o último processo a ser executado. Quando você executa esse processo com sucesso recebe um numero de PROTOCOLO. O próximo processo que deve ser executado é uma consulta usando esse número de protocolo. O retorno do processo de consulta irá informar se os dados enviados no lote estão corretos ou se ocorreu algum tipo de erro. Se não ocorreu erros relacionado ao evento que está dentro do lote, a consulta irá informar o número de RECIBO do evento. O evento somente irá aparecer no Portal Web se você receber o numero de RECIBO do mesmo no processo de consulta. []s, Mário Soares

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