GuilhermeCosta

Regasm é um exe que esta dentro da pasta do .Net na pasta Windows, na minha maquina só reconheceu o comando rodando por la.

Bom dia Srs, resolvi o problema executando o comando regasm CertFly.dll

Boa tarde, estou utilizando Windows 10 x64, copiei a DLL e o TLB para a pasta system32 e sysWOW64, ao executar o comando: regsvr32 %windir%\System32\Certfly.tlb ou regsvr32 %windir%\sysWOW64\Certfly.tlb é apresentado a mensagem em anexo. Teria que recompilar a DLL em 64 bits? Se for o caso como proceder? Qualquer versão do c# me permite compilar o projeto? Obrigado.

Bom dia Srs, Quando executo o exemplo me apresenta a mensagem de erro "Classe não registrada". Tentei executar o comando "regsvr32 CertFly.dll" porém é apresentado o erro "DllRegisterServer não foi localizado". Como proceder? Obrigado.

Tenho certeza que em produção a versão 2.3 não entrará, principalmente pelo fato dela não atender a reforma trabalhista. Agora sobre novembro, procurei alguma nota oficial mas não achei nada confirmando que em novembro estará disponível o ambiente de teste na versão 2.4, apenas algumas empresas dizendo isso em seus blogs/forum, e essas mesmas empresas diziam que em outubro entraria a versão 2.3 no ambiente de teste, mas nada oficial. Talvez seria o caso de criar mais uma pasta nos branches para a versão 2.4, para que possamos ir postando as alterações sem que o componente deixe de realizar a comunicação com os WSs do eSocial, e quando fosse disponibilizado a ambiente na versão 2.4, apenas substituiríamos os arquivos, pois não é necessário manter a versões antigas, visto que sempre terá apenas uma versão disponível em produção. Apenas um sugestão...

No manual de orientação do desenvolvedor diz "Para cada tipo de evento haverá apenas uma versão de leiaute vigente em um determinado período." Entendo que irão substituir, é que até o momento a versão 2.2.02 foi a unica que eles disponibilizaram. No caso temos duas versões que ainda não disponibilizaram o WS (2.3 e 2.4), e não esta claro se a 2.3 estará disponível antes de liberarem a 2.4

Boa tarde, O problema dessas versões que eles vão lançando é que o ambiente de homologação não está acompanhando as versões do leiaute... Eu cai na besteira de implementar a versão 2.3, e ainda não consegui realizar os testes no ambiente de homologação devido estar na versão 2.2.02, inclusive já até tinha postado no fórum algumas das alterações na geração para atender ao leiaute 2.3. E no pouco que li, ainda não está claro se será lançado o ambiente de homologação na versão 2.3 ou se será publicado um novo ambiente direto na versão 2.4. @Juliomar Marchetti vi também que postaram os fontes assinando em SHA-256 e enviando para os WS, mas ainda não consegui olhar, sabe se foi necessário um "downgrade" para o leiaute 2.2 para conseguir realizar a comunicação. Se caso foi, para que possamos ir atualizando o componente para as novas versões acredito que será necessário implementar as modificações sempre mantendo as gerações nos leiautes antigos para que o componente não fique inutilizável com os WS ativos. Nesse caso a melhor opção seria uma pasta AcbrSocial para cada versão do leiaute nos branches? Espero ter sido claro com minha dúvida... Obrigado

Na verdade ele não está ativo, ele apenas continuaria na base do eSocial, caso tivesse gerado uma alteração informando o fim da validade do mesmo. No exemplo que citou, teria que enviar um novo evento de inclusão. Este comportamento é apenas para os eventos de tabela, para os demais eventos, a exclusão ela ocorre apenas por intermédio do evento S-3000.

Tem razão, realmente não é necessário enviar dois eventos, porém o armazenamento (pelo menos das chaves) ainda se faz necessário para o caso de uma futura retificação.

Lembrando que para os eventos de tabelas, você tem 2 tipos de alteração. A alteração simples, ela se comporta como uma retificação, você informa a chave (no caso da tabela de rubrica você deverá informar "codRubr, ideTabRubr, iniValid, fimValid") para identificar qual evento você estará retificando. Você retificaria um evento, no caso de te-lo enviado com as incidências erradas por exemplos. Mas digamos que você tenho enviado o evento de forma correta, porém, a partir de uma determinada data, este evento em questão passou a ter um incidência que antes não tinha (seja por uma convenção coletiva ou uma portaria do MTE), neste caso, se o seu sistema utilizar a mesma rubrica, você deverá enviar dois eventos, um de alteração, indicando a data fim para aquele evento, e um de inclusão, informando as novas incidências... Talvez por isso o amigo @hnq_campos mencionou o fato de ter que armazenar tudo. E realmente, gerenciar tudo isso, é um problemao...

@Joceandro Perin, eu não tenho o levantamento de tudo que falta dos eventos não periódicos, já faz alguns dias que não consigo mexer no componente... Das ultimas vezes que alterei, eu apenas gerava os arquivos com o demo do Acbr, ai caso não validasse, ai sim eu passo um pente fino para ver o que esta diferente com o leiaute. Realmente, as ultimas alterações que realizei com a geração dos eventos não periódicos eu já postei aqui no forum... Abraços...

@Everton Weyand, Project>Options>Resource Compiler > Description no quadro "Usage options" deve estar marcada a opção "Designtime and runtime". Isso pode mudar um pouco dependendo da versão do Delphi.

Boa tarde Srs, @Juliomar Marchetti, segue em anexo algumas alterações para validação de alguns eventos não periódicos (S-2190, S-2200 e S-2230). Alterei o S-1000 pois na geração do campo vrSubteto estava passando o tipo "tcInt" (alterei para Dec2). Alterada algumas propriedades de publico para published. Alteração dos campos codsusp que ainda estavam como inteiro em alguns eventos. Classe TSucessaoVinc centralizada na unit Commmom Obrigado. AcbrBranches.rar

Se esta usando o componente, ainda é necessário realizar a alteração no algoritmo de assinatura, de SHA1 para SHA256.

Bom dia, o campo "codSusp" estava como string devido o manual exigir um campo numérico de 14 POSIÇÕES onde deixando como inteiro limitaria ao valor de "4294967295". Até a versão 2.1 o campo IdeMinLei (que era chamado de siglaMin) tinha valores estipulados, porém no leiaute 2.3, o mesmo exige um campo String de 70 posições sem valores estipulados. Apenas a alteração no campo tpDep não traria problemas. Abraços

Realmente a situação que citou estava errada, segue em anexo a correção. Estava sendo criando o objeto TInfoOp no método construtor da classe TInfoCadastro.Quais as outras situações que encontrou? Abraços eSocial_S1000.pas

Bom dia, Poderia sim, não me atentei a isso, assim que possível faço a refatoração... vlw

Boa tarde Srs, @Juliomar Marchetti Segue em anexo as alterações para validação com o novo leiaute 2.3 para os eventos iniciais/tabelas/periódicos e a criação do novo evento S-1295. Anexei também os schemas da nova versão. Obrigado. Acbr Branches.rar

@Hudson G Leite, infelizmente estou sem skype no momento, vou dar uma olhada nas alterações, @guilhermedoj, estou terminando uns ajustes nos eventos de tabelas e periódicos, falta os não periódicos, a comunicação com o ws e falta também fazer a alteração na assinatura, pois está utilizando o algoritmo errado de acordo com o manual, o correto é o SHA256.

@Hudson G Leite, ainda não foi implementado, pois este evento foi inserido na versão 2.3 e ainda não revisei nenhum evento não periódico.

Bom dia, o projeto está com o leiaute na versão 2.2.02, estou atualizando os eventos de tabelas e eventos periódicos para o leiaute 2.3. Falta atualizar os eventos não periódicos para o leiaute 2.3 e a comunicação com os WSs

Bom dia @Hudson G Leite, esta utilizando qual método para selecionar o certificado?

Boa tarde Srs. @Juliomar Marchetti, baixei os arquivos porém não consegui identificar qual está com a codificação diferente, todos que abro o notepad me diz que está como padrão ANSI, e no lazarus diz que está no padrão "CP1252". Pode me indicar algum outro software para analisar a códificação dos arquivos? Estou anexando novamente os arquivos do 25/05, porém apenas os que estão faltando nos branches, que são necessário para compilação dos exemplos referente aos eventos periódicos. Obrigado. @jeancantu, ja leu a resolução que o comitê gestor soltou? http://portal.esocial.gov.br/institucional/legislacao/resolucao-no-9-de-21-de-junho-de-2017 parece que agora vai hein, segunda já começa... Fontes.rar

Boa tarde Srs, @Juliomar Marchetti, segue em anexo as alterações nos eventos não periódicos de acordo com o novo leiaute 2.2.02. Algumas alterações constantes no anexo, dependem dos arquivos anexados no post do dia 25/05, porém eles ainda não constam nos branches, existe algum problemas com os aquivos postados? O evento S-2305 foi substituído pelo evento S-2306. Algumas classes do evento 1200 foram passadas para a unit "commom" para poderem ser usadas nas classes dos eventos não periódicos, por isto o mesmo consta novamente no arquivo em anexo. Nos exemplos desabilitei a geração do evento S-4000 e S-4999 pois os mesmos não constam mais no novo leiaute. Abraços. eSocial.rar

Bom dia amigos, @Juliomar Marchetti, segue em anexo as alterações nos eventos periódicos para validação dos mesmos no leiaute 2.2.01. Os arquivos referente aos eventos 1200 e 1202 estão bem diferentes dos constantes nos branches pelo fato do leiaute ter mudado bastante. Foi criado um novo evento, o 1207. No 1280, constará bastante remoção de fonte, pelo fato do indicador de desoneração ter sido removido do leiaute. No restante foi alteração simples, alguns grupos removidos (Exemplo 1300 a parte de contribuição sindical). Está em anexo 1 XSD, pois existia uma expressão regular incorreta e o arquivo acabava não sendo validado. Atualizei os exemplos também. Acredito estar tudo ok eSocial.rar