Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Jucemar Duarte

Membros
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

12 Good

1 Follower

About Jucemar Duarte

  • Rank
    Membro

Recent Profile Visitors

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

  1. EMBarbosa, você tem razão. Eu cheguei à mesma conclusão ao estudar melhor o assunto. Obrigado.
  2. "No meu caso faço a tratativa antes, mando para o componente apenas os 50 registros, no segundo envio mando os outros 50." - Alisson, Pois é, amigo Alisson, atualmente estou jogando na conta do usuário escolher quais registros ele quer enviar (com limite de 50). Mas isso não é nada elegante. Vou estudar o assunto. Acredito que dê para fazer sim. Acompanhe comigo: minha aplicação gerou um XML gigante com (por exemplo) 100 eventos. Quando carrego para o componente, o mesmo particiona em 100 XMLs já assinados. Vou tentar fazer com que, na montagem do lote, o componente gere, em v
  3. O e-social impõe a limitação de 50 eventos por lote a ser enviado. Não consegui identificar, dentro do método Enviar do componente ACBreSocial, em que momento esse limite é tratado. Alguém pode me ajudar? Esclarecimento: Não carrego os registros nos INIs. Minha aplicação possui uma rotina que gera um XML no formato do esquema (podendo ter mais de 50 registros/eventos). A partir daí, uso o Eventos.LoadFromFile para transportar para o componente ACBreSocial e assiná-lo. Em seguida, faço o envio com o método Enviar. Funciona bem, até encontrar lotes com mais de 50 eventos. Alguma id
  4. Olá, amigo Marcelo Pontes Melim, primeiramente, parabéns pelo trabalho. Estou analisando suas adequações para o e-social simplificado. Apareceu uma questão em "pcesConversaoeSocial". Na function "StrToVersaoeSocial", a correta atribuição da nova versão, segundo o formato do esquema, não seria obrigatoriamente,, '_S_01_00_00' ? Veja a ilustração:
  5. Patrick, sua explicação está perfeita! Tal como eu mesmo havia interpretado. Funcionaria sem problema se não fosse por um detalhe: a folha em questão tem mais de um evento de pensão. Explicação: A folha que estou integrando pertence a uma categoria de trabalhadores avulsos que não possuem férias e 13º. Todavia, por meio de acordos, em sua folha mensal são pagas verbas compensatórias de férias e 13º. Isso acaba gerando, obrigatoriamente, a cada mês, as rubricas de desconto de Pensão Mensal, Pensão Férias e Pensão 13º. Meu amigo, isso é só o começo! O evento S1210 se relaci
  6. Olá colegas, Me tirem uma dúvida: no layout do evento S1210, o grupo <penAlim>, que trata do detalhamento de pensões alimentícias, está em um nível hierárquico abaixo do grupo <retPgtoTot>. Isso sugere que cada rubrica de pensão deverá gerar (pelo menos) um registro com os dados do pensionista. Os registros do pensionista poderão se repetir de acordo com a quantidade de rubricas dentro do período. Isso é muito estranho! Se for do jeito que estou pensando, teremos inúmeras replicações desnecessária de dados. Tenho receio que esses dados replicados possam em algum lugar in
  7. Caro EMBarbosa, já está tudo esclarecido. Segundo as últimas documentações do e-social, a empresa que represento passou a ser do grupo 3, portanto as datas de obrigatoriedade foram alteradas. Obrigado.
  8. Luana, você está completamente certa! Ogmo entra no grupo de entidades sem fins lucrativos. Estava trabalhando como se fosse do grupo 2. Isso gera outra dúvida: os eventos iniciais de tabelas, enviados com data de início em 07/2018, deverão ser retransmitidos com a data 01/2019?
  9. Luana, muito obrigado por sua interferência... - A alteração da data de início no ambiente de homologação é uma informação muito importante. - Quanto ao motivo por não funcionar no ambiente produção ainda é misterioso. Minha tributação é tipo "09", portanto dentro do prazo para envio. Além disso, não vejo relação com o evento S1005, pois os trabalhadores avulsos (S2300) não dependem dele.
  10. Caros colegas, permitam-me ressuscitar o assunto, pois estou enfrentando um problema similar. Pois bem... 1) Minha empresa se enquadra no grupo 2 na questão de obrigatoriedade. 2) Todos os eventos iniciais foram recebidos com sucesso, usando, como <iniValid>, "2018-07", tanto no ambiente de teste, quanto na produção. 3) Inciamos, então, o envio dos eventos não periódicos com o S-2300 - Cadastro de Trabalhadores Sem Vínculo. O lote foi montado, validado, assinado e enviado. 4) No ambiente de teste (produção restrita), o processamento indica que "não existe o reg
  11. Ítalo, a solução apresentada no citado tópico ainda não me serve pois se trata de uma empresa do grupo 1. Mas é o mesmíssimo problema! Com sua permissão, gostaria de reabrir a discussão daquele tópico, apresentando o meu caso.
  12. Amigos, achei um tópico que fala do mesmo erro no fórum público. Seria de boa etiqueta se seu ressuscitasse o referido tópico para ter a participação dos colegas que já passaram por isso?
  13. Sim, EMBarbosa. Como disse, os eventos iniciais foram recebidos com sucesso e a data de obrigatoriedade dos eventos não-periódicos (como o S-2300) abriu no último dia 10.
×
×
  • Create New...