Joceandro Perin

Bom dia Italo.. Atualizei os fontes.. No caso ali do 1200, pelos testes que eu fiz, acontece somente no 1200 de 13º que seria o anual, nesse caso tem que informar somente o ano AAAA, no 1200 de mensal AAAA-MM, ele não dá erro de validação e sobe normalmente..

Sim, eu coloquei a versão no final dos schemas disponibilizados pelo eSocial.. Outro detalhe que pegamos aqui nos testes com a 2.5 com os schemas da pasta de exemplos, ao enviar o 1200 de 13º por exemplo, retorna: Falha na validação dos dados do evento: evtRemun-v02_05_00 - 1824 - Element {http://www.esocial.gov.br/schema/evt/evtRemun/v02_05_00}perApur: 2018 is not a valid value of the local atomic type.

Isso mesmo, fiz um novo teste aqui excluindo e copiando novamente da pasta schemas do exemplo e funciona, mas as disponibilizadas pelo site do eSocial a principio não deu certo..

@Italo Jurisato Junior acho que tinha alguma confusão na minha pasta de schemas, excluí ela e peguei novamente a do diretório "Exemplos\ACBrDFe\Schemas\eSocial" e deu certo.. Porem a que foi disponibilizada pelo eSocial hoje, não dá certo.. Você tentou usar esse schemas novos?

Estranho, tentei usar o da pasta schemas e tentei o disponibilizado hoje no site do eSocial, ambos estão dando erro..

Comparando os schemas do 2.5 e 2.4.02, parece que houve algumas mudanças na tag principal, não sei se interfere isso, mas alguns atributos foram removidos..

Bom dia Italo, ele nem chega a gerar o XML, já para ali na validação com o schema.. Se mudar pra 2.4.02, funciona normal.. Altera pra 2.5, não gera mais nada..

Bom dia galera, verificando aqui o site do eSocial, foi disponibilizado hoje 20/12/2018, novos schemas do layout 2.5, porém mesmo atualizando os schemas, não conseguimos enviar nenhum evento com o 2.5 em homologação.. retorna o seguinte erro de validação com os schemas: Falha na validação dos dados do evento: evtInfoEmpregador-v02_05_00 - 1845 - Element {http://www.esocial.gov.br/schema/evt/evtInfoEmpregador/v02_05_00}eSocial: No matching global declaration available for the validation root. Alguém mais já tentou enviar?

Galera o problema acredito que era as atualizações do Windows Server 2012, fizemos as atualizações e aparentemente resolveu o problema.. Pode ser também que hoje pela manhã, os servidores do eSocial estavam passando por alguma instabilidade.. Mas enfim, pra registrar aqui, se alguém passar por isso, fica aí uma dica, rever as atualizações do Windows também..

Eu acho que é mesmo algum problema lá no eSocial, fizemos um teste agora a tarde aqui com certificado de outro cliente em produção e transmitiu normalmente.. Outra coisa que estou desconfiado e que passamos por um problema semelhante no passado, foi a atualização do Windows.. Vou entrar em contato com o cliente e verificar essas questões.. Obrigado @arce pelo retorno.. Os XML o cliente não me passou, vou ver se consigo, mas as configurações usamos o seguinte.. if (Trim(cds.AsStr('ARQUIVOPFX')) <> '') then begin Geral.SSLLib := libOpenSSL; Geral.SSLHttpLib := httpWinHttp; Certificados.NumeroSerie := ''; Certificados.ArquivoPFX := cds.AsStr('ARQUIVOPFX'); Certificados.Senha := cds.AsStr('SENHACERTIFICADO'); Certificados.VerificarValidade := True; end else begin //Assinando com o A3 e A1 sem PFX Geral.SSLLib := libWinCrypt; Geral.SSLHttpLib := httpWinHttp; Geral.SSLCryptLib := cryWinCrypt; Geral.SSLXmlSignLib := xsLibXml2; Certificados.ArquivoPFX := ''; Certificados.Senha := cds.AsStr('SENHACERTIFICADO'); Certificados.NumeroSerie := cds.AsStr('CERTIFICADO'); Certificados.VerificarValidade := True; end; Sempre usamos assim, até ontem estava transmitindo normalmente, hoje pela manhã que começou a retornar esse erro.. Por isso acho que deve ser algum problema lá como o @arce comentou.. Vou fazer mais umas verificações lá e na sequência obtendo sucesso dou um retorno aqui.. Obrigado..

Bom dia galera, estamos com vários clientes retornando esse erro abaixo de ontem pra hoje em ambiente de Produção, ambos entraram em contato com a RFB e o certificado está normal.. Parece que no ambiente de homologação está enviando.. Alguém está passando por esse problema?

Segue notícia.. http://portal.esocial.gov.br/noticias/comite-gestor-aprova-a-versao-2-5-do-leiaute-do-esocial https://portal.esocial.gov.br/manuais/leiautes-do-esocial-v2-5.zip https://portal.esocial.gov.br/manuais/esquemas-xsd-v2-5.zip Assim que eu tiver um tempinho, irei dar uma olhada no que impactou nessa versão e verificar a necessidade de ajustes no ACBr..

Em resumo, 1200 feito pra previdência e 1210 pra receita..

Bom dia, recentemente o eSocial disponibilizou WebServices para consulta de eventos enviados quando houver perca de protocolos, que pode ser consultado de diferentes maneiras, mas isso ainda precisaria ser implementado no ACBr.. Essa informação está no manual de orientação do desenvolvedor a partir da página 57.. https://portal.esocial.gov.br/manuais/manualorientacaodesenvolvedoresocialv1-7.pdf

Obrigado pela sugestão, mas também não é meu caso.. Acredito que seja mesmo alguma dll... O problema que eu não consigo debugar aqui pra tentar achar onde e quando acontece isso, pois o ambiente de homologação ultimamente está muito lento..

Bom dia Jonathan, Sim, possivelmente seja mesmo, aconteceu aqui hoje em um cliente, estava enviado em torno de 4 mil eventos, aí chega um hora que da "out off memory", aí tem que fechar a aplicação e abrir novamente..

Coloquei uma resposta equivocada.. Mas faça um teste, tente enviar um outro período..

Disponha, estamos aí pra se ajudar.. Valeu..

Entendi, então, possivelmente esta empresa entra agora no envio certo? Se for, deve ser enviada como 2018-07, pois pra essas empresas, essa é a data de inicio da obrigatoriedade no eSocial conforme aquele link que te passei, por isso não deve ser informada 2018-01 que foi o período de obrigatoriedade das primeiras empresas no eSocial.. Outro detalhe é que se você não enviar o iniValid com esses períodos corretamente, certamente que terá esses problemas de conflitos..

Boa tarde, Os eventos S-1000 e S-1005 sempre deverão ser enviados com a data de inicio do eSocial que é 2018-01 para produção e 2017-01 para homologação, a não ser que a data de abertura da empresa, seja posterior a uma dessas datas que aí sim, deve ser enviada com o período em que foi aberta.. Para os eventos S-2200 e S-2300, a data de inicio deverá considerar 2018-03 para produção e 2017-03 para homologação.. O envio do S-2190 só há necessidade quando a empresa ainda não tem todas as informações do empregado para o envio do S-2200 e S-2300, caso contrário, não há necessidade de envio deste evento.. Sobre a data de admissão, deverá enviar a data real da admissão, no seu caso 01/05/2016, neste caso você deve observar também o campo "cadIni" que vai influenciar no S-2200 e S-2300 que deverá set "S" quando for um cadastramento inicial, ou seja, a data de admissão for anterior a data de inicio dos eventos S-2200 e S-2300 que é 2018-03 para produção e 2017-03 para homologação.. Se for posterior a essas datas, "cadIni" deve ser enviado como "N" que sinaliza uma admissão.. Essas datas que citei, devem ser enviadas desta forma, para obedecer as regras de faseamento do eSocial e para as empresas que já entraram na primeira fase do eSocial.. Para as empresas que vão entrar a partir de agora, as datas mudam.. 01/07/2018 para os eventos iniciais e de tabelas, 01/09/2018 os eventos não periódicos, e 01/11/2018 para a folha de pagamento... Você poder dar uma olhada neste link para entender melhor.. http://portal.esocial.gov.br/noticias/esocial-sera-implantado-em-cinco-fases-a-partir-de-janeiro-de-2018

Também tenho esse problema quando faço um loop consultando os protocolos, dependendo da quantidade, também dá o mesmo erro..

Concordo plenamente.. E você já imaginou um escritório contábil, que tem "X" clientes e querem usar o A3 pra entregar o eSocial? Cada vez que for enviar um cliente em específico, terá que ficar conectando e descontando o A3 do servidor.. Tem desses também..

Bom argumento.. Estou usando do mesmo para os meus clientes.. Pegamos vários cenários aqui já com o A3 e cada hardware é um "parto de elefante gêmeos" pra fazer funcionar.. Em alguns clientes conseguimos convencer que o A1 é a melhor opção.. Mas ainda existem aqueles insistentes...

Boa tarde galera, Conforme NOTA TÉCNICA Nº 08/2018 DE AJUSTES DO LEIAUTE VERSÃO 2.4.02 publicada em 25/07/2018, foram incluídas novas opções nos campos indComerc e indAquis dos Eventos S-1250 e S-1260.. @Italo Jurisato Junior, @Juliomar Marchetti Segue unit ajustada para avaliação.. pcesConversaoeSocial.pas

Houve uma alteração nas datas de inicio do eSocial.. Produção Restrita deve ser enviado com 1/2017 e Produção 1/2018, também foi alterado o faseamento no ambiente de Produção Restrita para que a simulação seja igual ao ambiente de Produção..