Danúbio Viana Nogueira

Bom dia! Depois de um bom tempo sem atualizar o ACBR, fiz o update e notei que houve uma importante reestruturação na unit ACBrUtil. Realizei então diversos testes com a geração dos eventos do eSocial, e me deparei com um pequeno problema que possivelmente mais alguém possa vir a enfrentar. O problema consistia em que, ao realizar a validação de schema do XML de um lote de eventos, por vezes aparecia uma mensagem semelhante à seguinte: Element '{http://www.esocial.gov.br/schema/lote/eventos/envio/v1_1_1}evento', attribute 'Id': 'IDXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not a valid value of the atomic type 'xs:ID'. Analisando o XML do lote gerado, me dei conta de que o erro era devido ao fato haver mais de uma ocorrência de eventos do mesmo tipo com a mesma ID. Depurei o processo de geração da ID dos eventos, e descobri que por conta da reestruturação, na implementação da função TeSocialEvento.GerarChaveEsocial na unit pcesGerador, o uso da unit ACBrUtil.Base tomou precedência em relação à pcnAuxiliar, e que ambas possuem uma implementação da função IntToStrZero, porém, com comportamentos ligeiramente diferentes. Assim, a função utilizada para gerar o número sequencial da ID dos eventos passou a utilizar a função IntToStrZero da unit nova, e a ter um novo comportamento em alguns casos. Resumidamente, ambas as funções IntToStrZero retornam uma string com um número inteiro completando com zeros à esquerda, porém, a função IntToStrZero da pcnAuxiliar faz o truncamento do campo à esquerda ("123456" -> "23456"), ao passo que a função IntToStrZero da unit ACBrUtil.Base faz o truncamento à direita ("123456" -> "12345"). Essa diferença no retorno das funções em geral seria irrelevante para a geração da ID do evento, exceto quando o sequencial informado tenha um comprimento maior que cinco dígitos. Por coincidência, este era exatamente o meu caso, pois utilizo um generator de banco de dados para informar o sequencial, cujo valor ultrapassou a casa dos cinco dígitos, fazendo com que eventos gerados para a mesma empresa dentro do mesmo segundo ficassem com o mesmo sequencial, e portanto, a mesma ID. A mudança no comportamento na geração da ID talvez seja proposital, talvez seja acidental, mas de qualquer maneira, deixo aqui minha sugestão de alteração para que a geração da ID volte a ter o comportamento anterior. Em anexo está a alteração que realizei na unit pcesGerador, especificando na função TeSocialEvento.GerarChaveEsocial que a chamada à IntToStrZero seja a da que está implementada na unit pcnAuxiliar, tal como era anteriormente. De qualquer modo, mesmo que a equipe do projeto ACBR decida não acatar a minha sugestão, sabendo o que ocasionou o problema, fica fácil resolver alterando a minha aplicação. pcesGerador.pas

Boa tarde, @EMBarbosa! Fiz o update e testei, encontrei um pequeno problema que também aparecia em outro tópico. Postei uma sugestão que pode ser acessada pelo link abaixo: https://www.projetoacbr.com.br/forum/topic/66192-evento-2220-gerar-exame/?do=findComment&comment=431659&_rid=113635

Boa tarde! Fiz a atualização do ACBR e teste do evento S-2220 há pouco, também me deparei com a situação descrita, e fiz a alteração conforme a contribuição do colega. Além dos dois campos já alterados, fiz também a alteração no campo "ResAso": Alterei também o campo "OrdExame" para ser informado independentemente do campo "ProcRealizado", pois, embora o campo seja obrigatório para o código "0281", não vi nenhum impedimento para enviá-lo com quaisquer outros códigos. Segue em anexo o arquivo com as alterações que realizei. pcesS2220.pas

Boa tarde! Fiz a atualização do ACBR agora há pouco e me deparei com a necessidade de fazer as alterações na geração destes campos. Em anexo estão as units conforme alterei. As alterações se resumem a criar opções para as situações onde não são informados os campos "resAso", "ordExame" e "indResult", uma vez que no leiaute simplificado versão 1.0 o envio destes três campos é opcional. Para cada um dos campos, criei a opção "xxNaoInformado", onde "xx" é o prefixo do campo. Também alterei a criação dos objetos para que a opção "não informado" seja a padrão. Talvez esta última alteração necessite ser revista, pois, anteriormente os valores padrão eram diferentes. Espero que minha contribuição seja útil. PCNeSocial.zip

Bom dia, prezados colegas! Fiz o update com as últimas alterações no ACBr com relação ao eSocial, e revisei a geração de alguns eventos que possam ter a informação do campo indGuia. Com o devido respeito ao trabalho dos colegas, e também com os devidos agradecimentos, pois me baseei no código deles, fiz algumas alterações que acredito simplificarem a geração do grupo ideEvento para os eventos: S-1200 a S-1300, S-2190, S-2200 a S-2420. Pelo que pude notar, todos estes eventos podem ser resumidos em quatro grupos, e para cada grupo já havia uma classe implementada: Evento que não têm informações de Retificação nem de Apuração -> TIdeEvento; Eventos que têm informações apenas de Retificação -> TIdeEvento2; Eventos que têm informações de Retificação e de Apuração -> TIdeEvento3; Eventos que têm informações apenas de Apuração -> TIdeEvento4. Com a necessidade da inclusão do campo indGuia no leiaute S1.0, uma nova classe chamada TIdeEventoGuia foi criada herdando da TIdeEvento2. Porém, o campo indGuia pode ocorrer também em eventos que pertençam às classes TIdeEvento3 e TIdeEvento4. Seria possível criar uma nova classe TIdeEventoGuiaX herdando da respectiva classe TIdeEventoX, bem como uma nova procedure de geração para cada classe TIdeEventoGuiaX. Porém, particularmente, acho mais complexo do que parametrizar as classes e procedures já existentes. Além disso, os parâmetros para os dois outros campos indicativos já existiam, de modo que criar um novo parâmetro não seria algo estranho. Assim, optei por não criar subclasses, mas por utilizar as já existentes e parametrizar a procedure que gera o grupo ideEvento para cada classe, de modo que a geração de cada evento faz a chamada de sua procedure correspondente, informando os parâmetros necessários para gerar as informações adequadamente, caso os parâmetros necessários sejam diferentes dos que ficaram definidos por padrão. Em anexo seguem as alterações que realizei. No arquivo pcesCommon.pas linha 602 há um bloco de comentário resumindo as alterações que intentei realizar. Embora eu tenha testado as alterações que realizei em ambiente de Produção Restrita, envio minhas sugestões no intuito de compartilhar conhecimentos, e de que sejam também revisadas, corrigidas e melhoradas. Agradeço ao projeto e aos colaboradores pelos conhecimentos compartilhados, e aguardo caso tenham críticas, dúvidas ou novas sugestões. PCNeSocial.zip

Compreendo o seu ponto de vista, sua opinião é bem-vinda. Acredito que quando o leiaute 2.5 sair de uso no ano que vem, será realmente necessário remover os campos antigos. Minha sugestão foi apenas visando não gerar estranhamento, caso alguém ainda esteja acostumado apenas ao leiaute 2.5, nem gerar incompatibilidade com os códigos já implementados. Particularmente, qualquer que seja a decisão do pessoal do projeto, para mim será uma boa decisão.

OK, futuramente criarei um tópico novo. E agradeço igualmente!

Bom dia! Recentemente fiz testes de envio do evento S-2210 e me deparei com um problema que acredito ser necessário corrigir na geração do XML. Os nós dos campos hrAcid e hrsTrabAntesAcid estavam sendo gerados incondicionalmente, porém no leiaute S1.0 eles são obrigatórios apenas quando o tipo do acidente é Típico. Assim, alterei a geração do arquivo, de modo que os nós sejam gerados apenas quando informados, como é especificado no leiaute S1.0, desconsiderando a especificação do leiaute 2.5, uma vez que este evento deve ser enviado apenas no leiaute S1.0, conforme Nota Orientativa S-1.0 01/2021 - Rev. 06/07/2021, p. 3 (disponível em https://www.gov.br/esocial/pt-br/documentacao-tecnica/manuais/nota-orientativa-s-1_0-01_2021-rev-06-07-2021.pdf) : Também alterei o campo codSitGeradora para ser sempre gerado, pois a informação é obrigatória. Em anexo segue minha sugestão de alterações. pcesS2210.pas

Bom dia! Fiz ontem o update da revision 23254 contendo as alterações nesta unit, testei e ocorreu tudo certo. Notei também que foram criadas as propriedades para os novos campos na classe TSucessaoVinc. Assim, fiz um ajuste que acredito possa ajudar tanto quem já utiliza as propriedades antigas, quanto quem passará a utilizar as propriedades novas. A alteração consiste basicamente em pegar o campo específico para o devido leiaute, e caso este não esteja informado, pegar o campo alternativo. if VersaoDF >= veS01_00_00 then begin tpInsc := ideTrabalhador.infoComplem.sucessaoVinc.tpInsc; nrInsc := ideTrabalhador.infoComplem.sucessaoVinc.nrInsc; if nrInsc = '' then begin tpInsc := ideTrabalhador.infoComplem.sucessaoVinc.tpInscAnt; nrInsc := ideTrabalhador.infoComplem.sucessaoVinc.cnpjEmpregAnt; end; Gerador.wCampo(tcInt, '', 'tpInsc', 1, 1, 1, eSTpInscricaoToStr(tpInsc)); Gerador.wCampo(tcStr, '', 'nrInsc', 14, 14, 1, nrInsc); end else begin tpInsc := ideTrabalhador.infoComplem.sucessaoVinc.tpInscAnt; nrInsc := ideTrabalhador.infoComplem.sucessaoVinc.cnpjEmpregAnt; if nrInsc = '' then begin tpInsc := ideTrabalhador.infoComplem.sucessaoVinc.tpInsc; nrInsc := ideTrabalhador.infoComplem.sucessaoVinc.nrInsc; end; if VersaoDF >= ve02_05_00 then Gerador.wCampo(tcInt, '', 'tpInscAnt', 1, 1, 1, eSTpInscricaoToStr(tpInsc)); Gerador.wCampo(tcStr, '', 'cnpjEmpregAnt', 14, 14, 1, nrInsc); end; Em anexo segue a minha sugestão de alteração. pcesS1200.pas

Bom dia! Fiz ontem o update da revision 23254 e notei uma alteração na geração do XML do evento S-1020 que acredito possa ser melhorada. Os campos tpInscProp e nrInscProp do grupo infoEmprParcial são obrigatórios no leiaute 2.5: Porém os mesmo campos são opcionais no leiaute S1.0: Embora eu não tenha encontrado a explicação do motivo para esta mudança, acredito que seja melhor deixar conforme especificado nos leiautes. Assim, alterei o código de geração destes campos da seguinte maneira: if VersaoDF >= veS01_00_00 then begin if infoLotacao.DadosLotacao.InfoEmprParcial.nrInscProp <> '' then begin Gerador.wCampo(tcStr, '', 'tpInscProp', 1, 1, 1, eSTpInscPropToStr(self.infoLotacao.DadosLotacao.InfoEmprParcial.tpInscProp)); Gerador.wCampo(tcStr, '', 'nrInscProp', 1, 14, 1, infoLotacao.DadosLotacao.InfoEmprParcial.nrInscProp); end; end else begin Gerador.wCampo(tcStr, '', 'tpInscProp', 1, 1, 1, eSTpInscPropToStr(self.infoLotacao.DadosLotacao.InfoEmprParcial.tpInscProp)); Gerador.wCampo(tcStr, '', 'nrInscProp', 1, 14, 1, infoLotacao.DadosLotacao.InfoEmprParcial.nrInscProp); end; Desta forma, os campos continuam sendo obrigatórios no leiaute 2.5, mas no leiaute S1.0 serão gerados apenas se o número de inscrição for informado. pcesS1020.pas

Boa tarde! Ao implementar correções no envio do Evento S-1200 na versão do layout simplificado S-1.0, notei que este evento sofreu alteração de nome em dois campos do grupo "sucessaoVinc". No layout 2.5 Enquanto no layout S-1.0 Repare que as informações a serem enviadas são as mesmas em ambas as versões. Para adequar a geração do arquivo às diferenças entre os dois layouts, implementei a seguinte alteração, a qual também envio em anexo: Deste modo, a partir da versão S-1.0 o evento passará a gerar as informações nos campos com os nomes atualizados ("tpInsc" e "nrInsc"), mas caso a versão do layout seja anterior permanecerá da mesma forma como era gerado anteriormente ("tpInscAnt" e "cnpjEmpregAnt"). Porém, embora a solução desta forma seja mais fácil para mim, pois não precisarei alterar o código fonte onde informo os valores dos campos, penso que para o Projeto ACBr esta simples alteração trará um dilema. Pelo fato de os campos apresentarem nomes diferentes nos dois layouts, quem começar a implementar o envio do S-1200 diretamente no layout S-1.0 não encontrará uma correspondência exata entre os nomes dos campos. Assim, gostaria de não apenas postar a solução que implementei, mas também de perguntar se a solução implementada pelo Projeto ACBr será diferente para este caso? pcesS1200.pas

Boa tarde! Creio ter encontrado uma necessidade de alteração na geração do XML do evento S-1299, decorrente de alterações no cronograma do eSocial, conforme descritas na nota orientativa "Nota Orientativa S-1.0 01/2021 -Rev. 06/07/2021 -Convivência de versões 2.5 e S-1.0" (https://www.gov.br/esocial/pt-br/documentacao-tecnica/manuais/nota-orientativa-s-1_0-01_2021-rev-06-07-2021.pdf). Conforme a nota, o campo "indExcApur1250" passou a ser aceito para eventos enviados com período de apuração até o mês 06/2021 na versão 2.5 do layout. Também alterei para que o campo seja incluído, caso a versão do layout seja 2.5 em diante, pois o campo consta nesta versão do layout, bem como na versão 1.0 do layout Simplificado. Em anexo segue o arquivo com as alterações que realizei. pcesS1299.pas

Atualizado e testado com sucesso na versão 2.5 do layout. Agradeço igualmente!

Boa tarde @EMBarbosa! E me desculpe pela demora em responder. Atualizei o ACBR e realizei o teste de envio do evento S-3000, que, conforme o esperado, ocorreu sem problemas. No entanto, notei também que houve uma alteração no evento S-2306, e resolvi testar. De modo semelhante ao que ocorreu com o evento S-3000 anteriormente, na validação do evento S-2306 ocorreu um erro quando na versão 2.5 do layout do eSocial. O erro ocorreu pela falta do campo "nmRazao" no grupo "instEnsino". Acredito que esta alteração no referido evento foi realizada para compatibilizar com a versão do layout S-1.0, a qual permitirá informar apenas o CNPJ sem informar os demais campos. Porém, a versão 2.5, que é versão a atual em produção, permanece com a regra anterior que exige a informação do campo "nmRazao". Assim, realizei a alteração no código deste evento, a qual segue em anexo à esta mensagem. Por ora não encontrei mais alterações que influenciem na geração e envio do eSocial na versão 2.5 do layout, mas seguirei testando e caso encontre outras correções necessárias, postarei aqui no fórum. Agradeço a você e a todos que contribuem ao projeto ACBr, e parabenizo pelo excelente trabalho! pcesS2306.pas

Agradeço igualmente ao projeto!