Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

Patrick Alves

Membros
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

16 Good

About Patrick Alves

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    Espirito Santo

Recent Profile Visitors

976 profile views
  1. Boa tarde! Mais uma pequena correção na formatação das datas. ACBrBancoBanestes.pas
  2. Boa tarde! Obrigado @Juliana Tamizou e @José M. S. Junior! Consegui os arquivos de retorno para testar, foi preciso alterar alguns pontos da função "TACBrBancoBanestes.LerRetorno240". ACBrBancoBanestes.pas
  3. Bom dia @Juliana Tamizou! Sim, arquivo de remessa e boletos homolagados! Somente o arquivo de retorno não foi validado ainda, estamos esperando nosso cliente retornar os testes.
  4. Adicionado leiaute CNAB240 para o banco Banestes. ACBrBoleto.rar
  5. Ao ler o xml do provedor ISSIntel, este tem as tags de cancelamento geradas, porém sem conteúdo. Assim notas "normais" estão sendo importadas como canceladas. Nota cancelada: <NfseCancelamento> <Confirmacao> <Pedido> <InfPedidoCancelamento> <IdentificacaoNfse> <Numero>62</Numero> <Cnpj>11081549000174</Cnpj> <InscricaoMunicipal>30488</InscricaoMunicipal> <CodigoMunicipio>3200706</CodigoMunicipio> </IdentificacaoNfse> <CodigoCancelamento></CodigoCancelamento
  6. Entendi Jucemar, nesse caso não tem jeito, cada rubrica tem que identificar o beneficiário. Concordo com você que teria outras formas de prestar essas informações (algo parecido com o plano de saúde no S1200 talvez), pode ser que tenham bons motivos pra ter feito assim, ou na pressa pra entregar era o que tinha... kkkk. Como falei antes, aqui temos o beneficiário vinculado ao trabalhador e na hora de gerar o xml, ao identificar que é pensão, pegamos os dados do vínculo e montamos as tags. O e-Social tem evoluído bastante (veja quantas alterações no layout), pode ser que amanhã ou dep
  7. Opa! Então, para cada rubrica com incidência de IRRF 51, 52, 53, 54 ou 55 o grupo <penAlim> deve ser informado, nas demais o grupo deve ser omitido. Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las. Assumindo que você é o desenvolvedor do programa e de todo modo precisa ter várias rubricas de pensão, o beneficiário deve ser informado para cada uma rubrica no xml, mas no seu programa você pode realizar esse vinculo somente uma vez e quando for gerar o evento busca esse
  8. Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno. pcesS5011.pas
  9. O evento S-2240 deve ser enviado por trabalhador, não podendo conter mais de um (trabalhador) no mesmo evento. O layout não permite.
  10. Então... vc tem que partir do ponto de vista do empregador que está enviando a remuneração. Pegando o exemplo que vc passou, temos 3 empregadores e cada um deles vai enviar um evento de remuneração para o empregado em questão, acho que ficaria algo assim: Quando o Empregador 1 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>1</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empr
  11. É como no layout mesmo Renato. No MOS, é apresentado do ponto de vista do empregado, mas como é o Empregador que entrega o evento, o indMV é a forma como o próprio Empregador vai calcular o INSS sobre a remuneração devida ao funcionário. Repare que no MOS tem outro exemplo que mostra um indMV para cada Empregador. Na teoria todos os Empregadores do empregado em questão deveriam enviar os grupos remunOutrEmpr iguais e só mudaria o indMV considerando o calculo do INSS.
  12. Obrigado pela resposta Alisson, na verdade fiz uma afirmação sem ao menos testar se era isso mesmo. Vendo o código da função GerarXML dos eventos parece que o Id é sempre gerado pela função GerarChaveEsocial, mas entrando nela constatei que faz o teste se o Id está preenchido e retorna ele mesmo. Estou armazenando os lotes enviados no bd, então quando não consigo concluir o envio do lote marco o evento como "timeout", quando é feita nova transmissão vinculo o novo lote ao anterior. Na consulta, se veio a flag de evento duplicado pego o protocolo e gravo no lote anterior. "Acho que é por a
  13. Boa tarde pessoal! De um tempo pra cá, o ambiente de produção restrita está muito lento, e por varias vezes vem ocorrendo timeout no envio do lote. Para recuperar o protocolo, vi que é necessário enviar o evento com o mesmo id, que no processamento é retornado o protocolo do envio original e o evento é definido como duplicado. Como estão fazendo para recuperar o protocolo de envio se ao passar o id para o evento, ao gerar o xml o componente sempre gera um novo id? Estão carregando o xml enviado anteriormente? Mas ai teria que manipular o xml para remover a assinatura aplicada.
  14. Opa! Estava me referindo a página 70 do manual de orientação, lá tem a descrição do campo cdResposta que fala das "mensagens do sistema".
×
×
  • Create New...