Patrick Alves

@ISBS @EMBarbosa Nos eventos S-1250 e S-1260 o grupo "nfs" está sendo gerado incorretamente pelo componente, resultando em um xml inconsistente. No anexo arquivo corrigido. pcesGerador.pas

Caro @Elvis Pesconi, parece estar funcionando somente em produção, obtive os mesmos erros na restrita. Lembrando que a chave não é informada somente para consulta do S-1000, para as demais tabelas deve ser informada.

@Elvis Pesconi Olhando no manual o evento S-1000 aplica a regra "REGRA_INFO_EMP_VALIDA_CLASSTRIB_NATJURID" que define "b) A classificação tributária [85] somente pode ser utilizada se a natureza jurídica do declarante for Administração Pública (grupo [1])." Olhando no xml vc está enviando a classificação 85, e mesmo que no leiaute não tenha o campo da natureza, ele ainda valida a informação. Pode ser que a classificação a ser usada não seja a 85.

Que bom que deu certo @Jucemar Duarte! Numa horas dessas me paga um pizza! hehehe

Acho que seria isso mesmo, se vc pegar no leiaute a chave do grupo "ideEstabLot" é : "tpInsc, nrInsc, codLotacao" e deve ocorrer de 1 a 500 vezes para o trabalhador. Pelo que entendi o "contrato" do trabalhador é com o OGMO então acredito que devem estar juntos mesmo, mas serão apurados de acordo com suas categorias e lotações.

Será que não deveria ser o CNPJ de um estabelecimento do OGMO cadastrado no S-1005 e aí no cadastro da lotação (S-1020) vir o CNPJ do Tomador dependendo do tipo.

Boa tarde! Mais uma pequena correção na formatação das datas. ACBrBancoBanestes.pas

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

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.

Adicionado leiaute CNAB240 para o banco Banestes. ACBrBoleto.rar

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> </InfPedidoCancelamento> <ns2:Signature/> </Pedido> <InfConfirmacaoCancelamento> <Sucesso>true</Sucesso> <DataHora>2020-02-20T08:39:18.110-03:00</DataHora> </InfConfirmacaoCancelamento> </Confirmacao> </NfseCancelamento> Nota Normal: <NfseCancelamento> <Confirmacao> <Pedido> <InfPedidoCancelamento/> <ns2:Signature/> </Pedido> <InfConfirmacaoCancelamento> <Sucesso>false</Sucesso> </InfConfirmacaoCancelamento> </Confirmacao> </NfseCancelamento> Segue arquivo com correção para análise. pnfsNFSeR.pas

Jovem, 1 - Eventos de Tabelas 2 - Eventos Não Periódicos 3 - Eventos Periódicos

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 depois isso mude, mas isso é o que temos pra agora.

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 vinculo e repete para cada uma. Como são dados cadastrais não vejo como poderia interferir em algum totalizador. É interessante que os valores do campo <vlrPensao> corresponda aos valores das rubricas, no meu caso o valor da rubrica e o valor da pensão foi sempre o mesmo. As rubricas de pensão alimentícia devem ser informadas porque interferem na formação da base de calculo do IRRF, então se você esta se referindo a totalizações que o sistema do e-Social faz, acho que o valor das rubricas que são importantes. Acredito que esses dados estão sendo solicitados mais para fazerem algum tipo de cruzamento de informação com a declaração do IR ou algo do tipo, para efeito de cálculo e fechamento da folha, o que vale é o valor da rubrica.

Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno. pcesS5011.pas