Jump to content

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png click.png click.png

Danúbio Viana Nogueira

Membros
  • Posts

    15
  • Joined

  • Last visited

Danúbio Viana Nogueira's Achievements

Apprentice

Apprentice (3/14)

  • Reacting Well Rare
  • Collaborator Rare
  • First Post
  • Week One Done
  • One Month Later

Recent Badges

13

Reputation

  1. 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.
  2. OK, futuramente criarei um tópico novo. E agradeço igualmente!
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. Atualizado e testado com sucesso na versão 2.5 do layout. Agradeço igualmente!
  9. 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
  10. Boa tarde! Atualizei o repositório do ACBr para a última revisão (22027), e creio ter encontrado um erro que invalida o arquivo XML no envio do evento S-3000 do eSocial, caso a versão do layout seja menor ou igual a 2.5. Houve uma alteração que acabou retirando a inclusão do campo "indApuracao" no grupo "ideFolhaPagto" para exclusão do evento S-1210. Porém este campo só se tornará opcional na versão simplificada do layout. Assim, coloquei uma condição para gerar o referido campo caso a versão do eSocial seja menor ou igual a 2.5. Em anexo está o arquivo conforme alterei. pcesS3000.pas
  11. Prontamente! Eu que agradeço e parabenizo pelo projeto. Segue em anexo o arquivo ajustado. pcesS2399.pas
  12. Sim, eu havia feito update hoje pela manhã, estou na revision 21803. Desta vez olhei em outros arquivos para ver se há mais algum que repita a mesma estrutura, mas não encontrei nenhum outro. Creio que sejam apenas estes dois.
  13. @Marcelo Pontes Melim, Boa tarde! Encontrei o mesmo erro que já havia relatado para o evento S2306, mas desta vez no evento S2399. No arquivo pcesS2399, linhas 306-308, está: if VersaoDF > ve02_05_00 then if obj.matricula = '' then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Novamente, acredito que a solução seja a mesma da vez anterior: if (VersaoDF <= ve02_05_00) or (obj.matricula = '') then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Agradeço pelo empenho em manter o código atualizado!
  14. @Marcelo Pontes Melim Boa tarde! Acredito ter encontrado um erro na implementação do pcesS2306, linhas 345-347, que impactou o envio do respectivo evento na versão 2.5 do layout. No referido trecho está: if VersaoDF > ve02_05_00 then if obj.matricula = '' then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Porém, desta forma acabará por não enviar o campo "codCateg" na versão 2.5 do layout, que é obrigatório. Creio que para corrigir, o trecho deveria ser alterado da seguinte maneira: if (VersaoDF <= ve02_05_00) or (obj.matricula = '') then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Agradeço pela atenção e pelo esforço de desenvolvimento!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.