Jump to content

Patrick Alves

Membros
  • Posts

    44
  • Joined

  • Last visited

Everything posted by Patrick Alves

  1. @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
  2. 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.
  3. @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.
  4. Que bom que deu certo @Jucemar Duarte! Numa horas dessas me paga um pizza! hehehe
  5. 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.
  6. 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.
  7. Boa tarde! Mais uma pequena correção na formatação das datas. ACBrBancoBanestes.pas
  8. 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
  9. 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.
  10. Adicionado leiaute CNAB240 para o banco Banestes. ACBrBoleto.rar
  11. 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
  12. 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.
  13. 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.
  14. Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno. pcesS5011.pas
  15. 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.
  16. 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>Empregador 2</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 3</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>1645.80</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador> Quando o Empregador 2 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>1</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 1</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 3</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>1645.80</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador> Quando o Empregador 3 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>2</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 1</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 2</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador>
  17. É 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.
  18. 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 ai!". Mais uma vez obrigado!
  19. 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.
  20. 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".
  21. Você encontra os códigos no manual do desenvolvedor https://portal.esocial.gov.br/manuais/manualorientacaodesenvolvedoresocialv1-6-4.pdf Página 36, 48 e 49 do manual. (Nas páginas 40 e 55 tem uma relação de códigos, que acredito ser de ocorrências, por não ter aceito o lote) Páginas 74 e 75. Os códigos de resposta do processamento também podem ser encontrados no portal do eSocial, na seção de "Documentação Técnica", no item "Mensagens do Sistema" (Pagina 70). https://portal.esocial.gov.br/manuais/mensagenssistemaesocialv1-4.pdf Acho que é por ai...
  22. Bom dia! Verifique se está sendo configurado corretamente a propriedade Configuracoes.WebServices.Ambiente. Parece que está enviando o xml montado para o ambiente de produção para o webservice de homologação.
  23. Boa noite @Diego Guima, O problema está nos schemas mesmo, tente apontar o caminho dos arquivos para: "ACBr\Exemplos\ACBrDFe\Schemas\eSocial". Acredito que sua pasta está faltando arquivos, pela imagem, só tem 46 arquivos, na pasta do ACBr tem 97. Acho que você só copiou os arquivos referentes a versão 02_04_02, mas lá existem outros arquivos necessários. No seu caso caso acho que é o "xmldsig-core-schema.xsd" que não está presente.
  24. Boa tarde @Diego Guima! Quando você carrega o xml, primeiro é feito a assinatura e depois a validação contra o schema. Por isso os dois xml's estavam assinados, mas repare que no xml evtInfoEmpregador-v02_04_02_error.xml, você vai encontrar o erro da validação no final do arquivo. Ao importar um xml que tenha a tag signature não será feito a assinatura e validação. Como o carregamento não é feito de forma completa o xml salvo (-S-1000-0.xml) é exatamente o mesmo que foi carregado.
×
×
  • 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.