Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Produto:

Microsiga Protheus


Descrição do Erro:

Problemas na Leitura de Marcações de Origem da Carol Quando Utilizado Cadastros de Relógios Exclusivo por Filial

Quando a tabela SP0 é usada de modo totalmente Exclusivo, e cada relógio que integra com o Clock In tem um código diferente, o sistema só lê/grava as marcações da primeira filial.

Cenário para Reproduzir o erro

Cenário

:
- Período de Apontamento

no MV_PONMES de

= 21.02.2022 à 20.03.2022

. MV_PAPONTA = 21/20

;
-

Configurado o ambiente para utilização da integração das marcações do Carol para o Protheus com base na documentação abaixo:
Integração Protheus x Carol - Importação de Batidas
-Cadastros de relógios exclusivos por filial, cada filial possui seu código de relógio;
-Foi cadastrado um relógio para filial D MG 01 com o código 444, já o relógio da D MG 02 ficou com 001, o compartilhamento das tabelas SPO e SP0 é totalmente Exclusivo;
-Foi utilizado os parâmetros da SX6 que contém a expressão MV_APICLO do cliente(conforme em anexo no final desse documento);
-Foi processado o API CAROL(PONAPI01);
-A leitura é realizada por filial. Ou seja, na primeira leitura é logado com a filial D MG 01, utiliza as perguntas filial de/até igual a D MG 01 e o código do relógio 444, esta leitura ocorre normalmente e grava nas tabelas de pré leituras RFB(cabeçalho com código do relógio e NSR), RFE(cabeçalho das marcações), neste processo é lido e gravado todas as marcações do período nas tabelas de pré leituras indiferente do filtro da filial e com isso altera o campo RR1_LOGIP de 0 para 1. Nesta etapa somente subirá as marcações para a tabela SP8 para filial filtrada nas perguntas, no caso do exemplo: D MG 01;
-Já na segunda leitura é logado com a segunda filial, neste exemplo D MG 02, preenchendo as perguntas de filial de/até igual a D MG 02 e o relógio respectivo da filial 001, neste caso ao término da leitura é retornado o log de 0 lido e 0 gravado, ao avaliar as tabelas de pré-leituras, na RFB é criado uma linha deletada do relógio 001 da filial D MG 02, já na RFE permanece as marcações que lá estavam sem mudar os campos relacionados ao processamento da leitura, como: RFE_DATAAP, RFE_FILORG, RFE_MATORG, RFE_PERAPO e etc. 
Obs.: Foi observado que se utilizar o mesmo código de relógio em ambas as filiais, as duas leituras ocorrem corretamente e gravam as marcações na tabela SP8. Porém vai permanecer somente uma linha do relógio 001 da filial D MG 01 na tabela de pré-leitura do cabeçalho (RFB). Ou seja, de todo o modo o processo de leitura não reconhecerá o relógio da filial D MG 02

Compartilhamento da SP0 = EEE;
- Cadastrar um relógio para a primeira filial com o código 444 e outro relógio para a segunda filial com código 001;
- Processar a rotina PONAPI01 para alimentar a tabela RR1;
- Processar a Leitura/Apontamento logado na primeira filial, e parametrizar a leitura apenas desta filial e do relógio 444. O processo será executado e os dados gravados nas tabelas normalmente;
- Processar uma segunda leitura, logado na segunda filial, filtrando apenas esta filial + relógio dessa filial. No log de ocorrências, o sistema aponta que 0 marcações foram lidas e gravadas;
- Em testes feitos em base local, notamos que se os relógios das filiais tiverem o mesmo código, as marcações são lidas para ambas filiais. Notamos que na RFB, é gravado registro apenas do relógio da primeira filial.


Evidências:

- Período de Apontamento:

...

-Pré-Leitura do cabeçalho(RFB):

-Já na tabela RFE as marcações da filial D MG 02 permanecem aguardando o processamento da leitura, ou seja, estão continuam sem preenchimentos dos campos:
RFE_DATAAP, RFE_FILORG, RFE_MATORG, RFE_PERAPO.
Image Removed

-As configurações dos parâmetros contendo a expressão MV_APICLO no dicionário SX6 do cliente, encaminho no anexo abaixo:
sx6t101_guaraves.dtc

...