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