Jump to content

Hudson G Leite

Membros
  • Posts

    35
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Hudson G Leite's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

8

Reputation

1

Community Answers

  1. O evento S-1010 - Tabela de Rubricas, na tag codIncCPRP, contém ocorrência 0-1! O Preenchimento se faz necessário em incidência da rubrica para as contribuições do Regime Próprio de Previdência Social - RPPS/regime militar. Adicionado uma validação para gerar a tag somente se codIncCPRP <> cicpNenhum! Segue em anexo para análise. pcesS1010.pas
  2. Bom dia, @Italo Jurisato Junior, veja se pode verificar a alteração na unit. pcesS2399! "... não gerar o grupo { verbasResc } " se desligamento igual 07 - Mudança de CPF.
  3. Bom dia, Na geração do registro "S-2399 - Trabalhador Sem Vínculo de Emprego/Estatutário - Término" quando o desligamento seja igual " 07 - Mudança de CPF " alterado para não gerar o grupo "verbasResc", conforme layout v2.5 segue a regra: "N (se {mtvDesligTSV} = [07] ...}) pcesS2399.pas
  4. Boa noite, @IMATECH Quando o registro S1210 seja referente a 12/2018 onde ocorreu o pagamento em no período de apuração 01/2019 deve-se enviar como tipo de pagamento = 9 ( Pagamento relativo a competências anteriores ao início de obrigatoriedade dos eventos periódicos para o contribuinte ). No seu sistema basta você preencher o grupo [detPgtoAnt, infoPgtoAnt] dessa forma não será necessário existir o S1200 referente a dezembro. No meu entendimento um exemplo: <infoPgto> <dtPgto>2019-01-05</dtPgto> <tpPgto>9</tpPgto> <indResBr>S</indResBr> <detPgtoAnt> <codCateg>101</codCateg> <infoPgtoAnt> <tpBcIRRF>12</tpBcIRRF> <vrBcIRRF>680.93</vrBcIRRF> </infoPgtoAnt> <infoPgtoAnt> <tpBcIRRF>42</tpBcIRRF> <vrBcIRRF>54.47</vrBcIRRF> </infoPgtoAnt> <infoPgtoAnt> <tpBcIRRF>41</tpBcIRRF> <vrBcIRRF>159.33</vrBcIRRF> </infoPgtoAnt> <infoPgtoAnt> <tpBcIRRF>11</tpBcIRRF> <vrBcIRRF>1702.34</vrBcIRRF> </infoPgtoAnt> <infoPgtoAnt> <tpBcIRRF>00</tpBcIRRF> <vrBcIRRF>2987.97</vrBcIRRF> </infoPgtoAnt> </detPgtoAnt> </infoPgto>
  5. Bom dia, Estou gerando o arquivo de pagamento S-1210 onde dentro do mesmo período de apuração: 05/2018, houve salário mensal e férias! Exemplo: 01/05/2018 Até 14/05/2018 ::: Houve atividade normal do funcionário 15/05/2018 ::: Início das Férias do Funcionário. Dúvida: 1º Deve-se Gerar o registro de pagamento das férias com 2 dias antes do gozo das férias? 2º Deve-se Gerar o registro de pagamento de férias + salário mensal no dia 30/05/2018, gerando apenas um único registro de pagamento? obs: (salário mensal) - houve a geração com sucesso no registro 1200 - Remuneração!
  6. Bom dia, Em produção restrita a alguns dias venho observando uma elevada demora nas consultas dos protocolos por parte do esocial! Retorno do eSocial - 101 - Lote em Processamento. Se estiverem passando por essa situação, como estão contornando?
  7. Bom dia, @anderson.mendonca Quando você enviou o registro S-1000 qual o valor da tag IniValid?
  8. Bom dia, a admissão preliminar do funcionário está inferior a obrigatoriedade do esocial. <dtAdm>2004-03-17</dtAdm> possivelmente o empregador foi enviado com uma <iniValid> diferente da data base de obrigatoriedade do esocial. Sugestão se for em ambiente de produção restrita: envie o empregador com <iniValid>2016-01</iniValid> produção restrita: 2016-01 produção - eventos iniciais e tabelas: 2018-01 produção - eventos periódicos: 2018-03
  9. Bom dia, os eventos iniciais e tabelas para uma alteração/exclusão não precisa ser informado os número de recibo. Caso o seu evento S-1000 você tenha recebido um recibo significa que o registro foi aceito pelo esocial. Para realizar uma alteração a questão é: Exemplo. Na inclusão você utilizou a competência. <iniValid> 2018-01 </iniValid>, então na [ alteração ] você deverá informar na tag <iniValid>2018-01</iniValid> a mesma utilizada no registro de inserção para o esocial. A tag <novaValidade> <iniValid>2018-02</iniValid></novaValidade> você informa a nova validade da alteração.
  10. Boa tarde, Uma nova alteração no registro: s-2300 e s-2306. A alteração é um detalhe: atualmente o campo ... [ natAtividade ] do registro está sendo identificado por [ natAtivididade ], alterei a nomeclatura. Outra modificação foi na função: LerArqIni(...) para o campo ... [ infoTSVInicio.natAtividade ] esta sendo lido de [ INIRec.ReadString(sSecao, 'cadIni', '1')) ] modifiquei para ler [ INIRec.ReadString(sSecao, 'natAtividade', '1')) ], se concordarem com a mudança, favor subir no svn! pcesS2300.rar pcesS2306.rar
  11. Boa tarde, @Italo Jurisato Junior uma nova implementação para o registro de desligamento. Alteração campo [ consigFGTS ] - Informações sobre operação de crédito consignado com garantia de FGTS, adicionado uma coleção de itens! Dentro da geração do registro [ consigFGTS ] está compatível com a versão: ve02_04_01, gerando apenas uma única linha! Quando tiver um tempo para análise e se concordarem com a mudança, favor subir no svn! pcesS2299.pas
  12. Boa noite, realizei 2 alterações: uma registro S2299 - Adicionando o campo [ qtdDiasInterm ] para versão (VersaoDF <> ve02_04_01) uma na unit [ pcesCommon ] na classe [ TSucessaoVinc ] criando a property [ CnpjEmpSucessora ] para encaixar melhor no contexto do registro... S2299, antes estava sendo usado o cnpjEmpregAnt! Modifiquei na geração do registro S2299 para ler a nova propriedade [ CnpjEmpSucessora ] se concordarem com a mudança, favor subir no svn! pcesCommon.pas pcesS2299.pas
  13. :::: Boa tarde, No executável de exemplo do esocial alguém têm passado pelo problema no momento da assinatura do registro. "Falha ao localizar o nó de Assinatura". Observação! Unit: ACBrDFeXsLibXml2 Classe: TDFeSSLXmlSignLibXml2 -> function: LibXmlFindSignatureNode(...) SignNode está igual a Nil... ao disparar o erro é executado novamente a função: LibXmlFindSignatureNode(...) sendo que a segunda vez fica (SignNode está diferente de Nil) Abaixo configuração:
  14. Bom dia Senhores, @Alisson Souza Pereira é um retorno de consulta. Após os envios de lotes! @juuninho o evento s-1000 está enviado com sucesso inclusive com retorno de recibo e hash. Como foram enviados 2 lotes para o registro s-1030 o primeiro lote contendo 50 eventos tenho o retorno Ok - inclusive os recibos, o segundo lote que se torna o problema, devido ter enviado em paralelo com o primeiro lote, o esocial recusa, conforme mensagem do tópico inicial. @LUIZTEC também realizei o envio de lotes superior a 50 eventos e passou corretamente. Só estou preocupado em validações futuras.
  15. Contexto.: Estou enviado o registro [ S-1030 ] dividido em 2 lotes. Sendo o primeiro Lote com 50 eventos e o Segundo Lote com 24 eventos. Realizei a quebra devido ter lido que para lote deveira conter 50 eventos por lote. Retorno eSocial "A regra de precedência na transmissão de eventos não foi seguida. Eventos desse tipo não devem ser enviados para processamento em paralelo. Ver seção 5.6.1 do Manual de Orientação do Desenvolvedor." Alguém está passando por essa situação? Dessa forma eu teria que enviar o primeiro Lote e esperar a confirmação para depois enviar o segundo lote.
×
×
  • 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.