Ir para conteúdo
  • Cadastre-se

Patrick Alves

Membros
  • Total de ítens

    44
  • Registro em

  • Última visita

Posts postados por Patrick Alves

  1. @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.

  2. 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.

    • Curtir 1
  3. 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.

  4. Bom dia @Juliana Tamizou!

    Sim, arquivo de remessa e boletos homolagados!

    Citar

    Boa 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 08006452030

    Somente o arquivo de retorno não foi validado ainda, estamos esperando nosso cliente retornar os testes.

  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>
    			</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

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

    • Curtir 1
  7. 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.

    • Curtir 3
  8. 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>

     

    • Curtir 2
    • Obrigado 1
  9. É 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.

  10. 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!

  11. 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.

  12. 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...

  13. 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.

  14. 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.

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...