Alisson Souza Pereira

@brunomachadogp você pode procurar mais informações sobre o assunto mas em resumo é isto: SEFIP está com os dias contados, para alguns empregadores ela só está responsável pela guia do FGTS e nada mais. Não há geração de dados para a DCTFWeb, a mesma é uma página dentro do ECAC onde você controla o pagamento dos DARFs Processo: Você irá alimentar o eSocial e o Reinf (ambos tem no ACBR), quando você fizer o fechamento dos dois automaticamente vão enviar os dados à DCTFWeb, dai você entra na página da DCTFWeb e faz a geração das guias.

Sem o XML fica difícil de ajudar.

@Mauro Jose Conte, a data do SST é diferente da data do início do eSocial, mesmo na base de teste existe também a questão do faseamento, nos meus testes coloquei o início da maneira que o eSocial informou no portal. 2019-03, não sei se antes disso irá funcionar, porém essa foi a data que passou a funcionar estes eventos na base de teste. Tenta dessa maneira que dará certo.

@Antonio Carlos Araujo Sobrinho, exatamente. * O lote pode conter mais de 1 evento por vez. * O protocolo do envido é um por lote. * O protocolo de sucesso(Recibo) é um por evento e este que é a sua garantia de sucesso. * Evento de tabela não aceita envio em concorrência.

Boa tarde, o evento S-5013 possui vazamento de memória FastMM An unexpected memory leak has occurred. The unexpected small block leaks are: 1 - 12 bytes: TInfoDpsFGTS x 1 13 - 20 bytes: TLeitor x 1, TDpsPerApurCollectionItem x 3, Unknown x 1 21 - 28 bytes: TDpsPerApurCollection x 1, Unknown x 1 69 - 76 bytes: TStringList x 1 117 - 124 bytes: Unknown x 1 Correção pcesS5013.pas

Bom dia, o evento S-2299 possui vazamento de memória FastMM --------------------------- Unexpected Memory Leak --------------------------- An unexpected memory leak has occurred. The unexpected small block leaks are: 1 - 12 bytes: TInfoPerApur x 1, TInfoAgNocivo x 1 13 - 20 bytes: TLeitor x 1, Unknown x 1 21 - 28 bytes: TDmDevCollection x 1, TDMDevCollectionItem x 1, TInfoTrabIntermCollection x 1, TideEstabLotCollection x 1, TRubricaCollection x 1, UnicodeString x 23, Unknown x 2 29 - 36 bytes: TideEstabLotItem x 1, UnicodeString x 25 37 - 44 bytes: UnicodeString x 1 45 - 52 bytes: TRubricaCollectionItem x 23 69 - 76 bytes: TStringList x 1 117 - 124 bytes: Unknown x 1 205 - 220 bytes: Unknown x 1 Correção pcesS2299.paspcesCommon.pas

Atualmente estou utilizando 10.3 Rio, porém noto que este vazamento ocorre desde quando implantei o eSocial em 2018 e naquela época utilizava 10. 1 Berlin e posterior mente 10.2 Tokyo. Ao invés de comentar o código, passar qualquer valor para o DadosPFX conforme solicitado. DadosPFX := 'Texto apenas para ter algum valor.'; Não há memory leak, e só dá erro na segunda verificação LerPFXInfo if EstaVazio(DadosPFX) then raise EACBrDFeException.Create('Erro ao Carregar Certificado'); if not LerPFXInfo(DadosPFX) then raise EACBrDFeException.Create('Erro ao ler informações do Certificado.'+sLineBreak+ 'Provavelmente a senha está errada' );

Boa tarde, @EMBarbosa minha aplicação depois de algum tempo rodando acabava travando devido o consumo elevado de memória, Cada vez que o XML era assinado aumentava de 0,1 a 1 mega, se a linha for comentada a memoria para de sobrecarregar(comentar a linha não é a solução é só o teste que fiz) Sobre o FastMM sempre utilizo em meu desenvolvimento, segue as informações que tenho. Quando é executado o comando ReadStrFromStream ocorre memory Leak An unexpected memory leak has occurred. The unexpected small block leaks are: 13 - 20 bytes: TLeitor x 1, Unknown x 1 69 - 76 bytes: TStringList x 1 117 - 124 bytes: Unknown x 1 Se a linha for comentada não há vazamento de memória, ocorre o exception e cancela a assinatura do XML. Não acredito que o problema de memória seja por causa de configuração, mas segue a configuração que estou utilizando. SSLLib := libOpenSSL; SSLHttpLib := httpWinHttp;

Mudei para a assinatura com o certificado instalado na máquina, com isso contorno a situação, porém o problema ainda existe. Não sei exatamente como corrigir.

Consumo de memória só aumenta utilizando Open SSL(Certificado Digital.pfx) Fonte: ACBrDFeOpenSSL.pas Procedure: TDFeOpenSSL.CarregarCertificado Comando: DadosPFX := ReadStrFromStream(FS, FS.Size); O comando ReadStrFromStream é responsável por aumenta o consumo de memória toda vez que um arquivo XML é assinado e esse consumo mesmo após destruir o componente ACBreSocial não é subtraído.

Realmente no manual o campo é do tipo numérico. Após a mudança para tcStr o XML está sendo gerado com sucesso. Obrigado!

A Tag unMed era do tipo integer e estava sendo gerada mesmo que não fosse passado valor para a propriedade 1)Existe situações que este campo não pode ser preenchido. 2)0 Não é um valor válido para o campo. Segue arquivo atualizado. @Italo Jurisato Junior pcesS2240.pas

@kartter Quando li o seu post entendi que era dentro da mesma empresa apenas setores diferente, se fosse assim concordo com o Italo. O segundo caso é uma clínica de terceiros, ela pode gerar os arquivos no formado INI, você recebe esses arquivos e simplesmente assina e envia. dá uma olhada por exemplo no: pcesS2299.pas function TEvtDeslig.LerArqIni(const AIniString: String): Boolean;

De fato Quando é instanciado o TTrabalhador em pcesCommon já está criando a classe das informações de deficiência, e em pcesGerador se todos os itens forem falsos não é gerado as informações de deficiência (Baseado no meu XML que não gera a tag de de deficiência, acreditava que era pela assinatura da classe). Neste caso para resolver seu caso de forma simples, quando não quiser informar ao eSocial, basta preencher tudo com não, ou você pode alterar esses dois pontos para trabalhar com assinatura da classe e verifica se passa pela aprovação.

@JoshSilva {infoDeficiencia} é opcional, ou seja, você pode deixar de informar o conjunto inteiro referente à deficiência, agora se você optar por preencher um dos itens referente à deficiência, obrigatoriamente você terá que informar todos os campos, e como os itens são um type o default é o primeiro item, logo o ACBr está corretíssimo.

Como você fez a geração dos eventos para 2018-11 / 2018-12? 2018-11 Folha e décimo foram enviados no mesmo S-1200, ou seja, há dois demonstrativos no S-1200? 2018-12 Folha Foi enviado no S-1200 mensal e Décimo foram enviados no S-1200 anual?

@RenatoE verifique o XML de retorno do S-1299, checa se não há divergência do que foi calculado pelo sistema com o que foi calculado pelo eSocial. Como você fez ageração dos eventos? De décimo e folha? de mais detalhes do que você fez nesse processo.

Muito provável que seja.

@Paulo Aguiar Junior Me desculpe, quando sai alterando algumas informações mexi nesse número também... Está aqui o arquivo atualizado contendo o demonstrativo 123 e o 456 que estão no S-1210 S1200 2018-11 Envio (Folha).xml S1200 2018 Envio (Decimo).xml

@Paulo Aguiar Junior Esses são os S-1200 que compõem o S-1210. Décimo Segunda parcela e Folha 2018-11 S1200 2018 Envio (Decimo).xml S1200 2018 Retorno (Decimo).xml S1200 2018-11 Envio (Folha).xml S1200 2018-11 Retorno (Folha).xml

Bom dia, fiz o envio do S-1210 contendo o pagamento da folha 05/12/2018 e o do décimo 20/12/2018; Para todos os colaboradores o eSocial retornou a ocorrência de advertência 723 - Valor líquido inválido, em alguns casos chegou a informar uma valor líquido negativo; Não trabalho com pagamento parcial e nunca tive problemas com o valor líquido do evento; Envio.xml Retorno.xml

@oprata Parece que fizeram uma alteração que quebrou os fontes, não dei uma olhada porque já estão analisando e não atualizei os fontes ainda. Acredito que logo logo estará corrigido.

@mmcamilo Bom dia, para obter o recibo vocês terá que enviar exatamente o mesmo XML, atente-se ao nº do ID e aos dados, se alguma coisa for diferente o eSocial irá dar erro. Se for a mesma informação inclusive o ID do evento, o eSocial entende que você está tentando recuperar o nº do recibo. Quando é realizado este procedimento no XML de retorno haverá uma tag que identifica essa operação

@ismaelspaniol Poste o Retorno do S-1200, é muito provável que o seu sistema tenha feito o cálculo e o eSocial deu outro valor, principalmente no que diz respeito a contribuição previdenciária. No retorno do S-1200 ou seja (S-5001) é possível saber onde está essa diferença.

@Flavio Ramires Não tinha conhecimento desse site, fiz o teste e deu o mesmo erro, porém não estou tendo problemas para enviar para o eSocial. Fiz o teste verificando o XML do lote e não de um único evento, pode até ser que seja isso... Você realmente tem a necessidade de utilizar esse serviço? Sem ele estou conseguindo enviar todos os eventos normalmente.