Patrick Alves
-
Total de ítens
44 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Patrick Alves
-
-
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.
-
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
- 1
-
1 hora atrás, Jucemar Duarte disse:
nrInsc' deveria ser o CNPJ do próprio estabelecimento do OGMO e o rateio por Operador seria feito em 'codLotacao'?
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.
1 hora atrás, Jucemar Duarte disse:Imaginei que, ao fornecer o CNPJ do OGMO iria misturar a folha dos trabalhadores avulsos com a folha dos funcionários do próprio OGMO
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.
- 1
-
19 horas atrás, Jucemar Duarte disse:
Desta forma, no demonstrativo de remuneração do evento S1200, é informado o CNPJ do Tomador/Operador Portuário.
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!
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".
- 1
-
Bom dia @Juliana Tamizou!
Sim, arquivo de remessa e boletos homolagados!
CitarBoa tarde!
Boleto está homologado.
Obs. 1: O acompanhamento correto da carteira é feito pelo aviso de movimentação este informa: as liquidações, tarifas, baixas, protestos etc, pode ser impresso no internet Banking ou Office Banking, além desse relatório há o relatório de inconsistências, no qual pode-se verificar, no próximo dia útil ao envio da remessa, se houve rejeições, dúvidas quanto à impressão de ambos, favor ligar para 08006452030.
Obs. 2: O arquivo de retorno tem as mesmas informaçãoes contidas no aviso de movimentação, porém é destinado à gestão da base de dados seja de usuários de office Banking ou Sistema próprio. Este é encaminhado diariamente via @EDI, dúvidas quanto ao recebimento e processamento, favor ligar para 08006452030Somente o arquivo de retorno não foi validado ainda, estamos esperando nosso cliente retornar os testes.
-
Adicionado leiaute CNAB240 para o banco Banestes.
-
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.
-
Jovem,
1 - Eventos de Tabelas
2 - Eventos Não Periódicos
3 - Eventos Periódicos- 2
-
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.
- 1
-
Opa!
1 hora atrás, JUCEMAR DUARTE disse:Isso sugere que cada rubrica de pensão deverá gerar (pelo menos) um registro com os dados do pensionista
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.
1 hora atrás, JUCEMAR DUARTE disse:Os registros do pensionista poderão se repetir de acordo com a quantidade de rubricas dentro do período
Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las.
1 hora atrás, JUCEMAR DUARTE disse:Se for do jeito que estou pensando, teremos inúmeras replicações desnecessária de dados
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.
1 hora atrás, JUCEMAR DUARTE disse:Tenho receio que esses dados replicados possam em algum lugar interferir em totalizadores internos
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.
- 3
-
Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno.
- 1
- 1
-
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.
- 1
-
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>
- 2
- 1
-
É 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.
-
8 horas atrás, Alisson Souza Pereira disse:
Na verdade o componente não gera um novo ID, implemente algo que ligue os dois envios e quando for esse caso vc popula com o ID do primeiro envio e será sucesso.
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!
-
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. -
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".
-
Você encontra os códigos no manual do desenvolvedor
https://portal.esocial.gov.br/manuais/manualorientacaodesenvolvedoresocialv1-6-4.pdf
1 hora atrás, RenatoE disse:ACBreSocial.WebServices.ConsultaLote.RetConsultaLote.Status.cdResposta
Codigo : 201 - Lote Processado com Sucesso.
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)
1 hora atrás, RenatoE disse:ACBreSocial.WebServices.ConsultaLote.retEventos.Items[Index].Processamento.cdResposta
Codigo: 201 - Sucesso // 202 - Sucesso Advertência
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...
-
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.
-
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.
-
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.
Falha ao interpretar o XML "xmlParseDoc" no S-1250 e S-1260
em ACBreSocial
Postado
@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