Produto:

Microsiga Protheus®Protheus

Ocorrência:

Leitura e apontamento - PONM010.

Passo a passo:

Ao realizar uma leitura das marcações, a partir da rotina Leitura e Apontamento (Miscelânea/ Cálculos/ Leitura/Apontamento), o sistema verifica no Cadastro de Relógios qual o caminho estipulado para guardar as informações das marcações do funcionário e gravará na rotina Marcações.

Para isso, quando é rodada esta rotina, o sistema armazena informações em 4 tabelas diferentes:

• SP8- Tabela de marcações, nesta tabela são armazenadas todas as batidas realizadas pelo funcionário. Caso o responsável pelo sistema realize alguma alteração nas marcações ou inclusão de marcações, as mesmas são gravadas nesta tabela também.
• SPC - Tabela de apontamentos, esta tabela é responsável pelos apontamentos realizados pela rotina. O sistema confronta as marcações realizadas com as configurações do funcionário, como Cadastro de Turno, Tabela de horário padrão e Regra de apontamento.
• RFE – Tabela de Pré-leitura, também exclusiva por filial, contém as informações de registros das marcações.
• RFB - Cabeçalho de pré-leitura. Contém informações de cada acionamento de leitura das marcações, sendo exclusivo para cada filial. As principais informações são:
  
  

Nome completo do arquivo lido: o campo Arquivo (RFB_ARQ) armazena o caminho e nome do arquivo de marcações, como por exemplo, c:\relogio\marc.txt. Este campo será alimentado com o conteúdo do campo Nome Arquivo (P0_ARQUIVO) informado no Cadastro de Relógios (PONA030).

Data e hora do início e fim da leitura do arquivo: para armazenar essas informações foram criados os campos: Dt. Hr.Inicial (RFB_DTHRLI),  este corresponde à data e hora inicial, e o campo Dt.Hr.Final (RFB_DTHRLF) corresponde à data e hora final da leitura do arquivo de marcações. O conteúdo destes campos está no formato AAMMDDHHmm onde:
AA – Ano
MM – Mês
DD – Dia
HH – Hora
mm – Minuto

Identificação do usuário que acionou o processo de leitura: para esta informação está disponível o campo Usuário (RFB_USUARI).

• Data e hora da geração do arquivo de marcações: para esta informação foi criado o campo Dt.Hr.Arq (RFB_DTHRG), cujo conteúdo está no formato AAMMDDHHmm onde:
  

  AA – Ano
  MM – Mês
  DD – Dia
  HH – Hora
  mm – Minuto

• Última linha lida ou registro do arquivo de marcações registrado na tabela de Pré-leitura – RFE: esta informação está contida no campo ID. Org (RFB_IDORG).
  

  Por exemplo:
  Se o arquivo texto de marcações possui 500 linhas, o primeiro valor do campo ID. Org (RFB_IDORG) é 1 e ao final da leitura será 500.
  Uma vez que o REP esteja implementado, este campo será alimentado com o conteúdo referente ao campo NSR (Número Sequencial de Registro), fornecido pelo REP.
  Todas as ocorrências de leitura podem ser observadas por meio do botão Visualizar.

• RFE – Tabela de Pré-leitura, também exclusiva por filial, contém as informações de registros das marcações, por exemplo:

O campo Crachá (RFE_CRACHA) corresponde ao número do crachá do empregado /visitante.

O campo Data (RFE_DATA) armazena a data da marcação do empregado.

O campo Data Apont. (RFE_DATAAP) corresponde à data de apontamento da marcação do empregado.

O campo Horário (RFE_HORA) contém a hora da marcação do empregado.

O campo Centro Custo (RFE_CC) refere-se ao centro de custo do empregado no dia data marcação.

Natureza (RFE_NATU) corresponde à natureza da marcação, tendo como opções:

0 – empregado, caso encontre o crachá ou crachá provisório;
1 – visitante (conforme os parâmetros de visitantes);
2 – acesso;
3 – desconhecido, no caso do crachá não for identificado (conteúdo desconhecido).

Importante!
Alguns campos da tabela RFE, podem estar sem informação conforme a natureza do registro lido, por exemplo, quando não for possível identificar o detentor do crachá ou porque o REP não está implementado, ou ainda, porque as informações não são de empregados (no caso de acesso de visitantes) o que mantém o campo Mat. Origem vazio.

Período Apon. (RFE_PERAPO) armazena o período de apontamento da marcação. É utilizado na obtenção de todas as marcações do período de apontamento.

Linha (RFE_LINHA) contém os dados da linha ou registro original do arquivo de marcações lido em formato texto.

Para registrar a origem da marcação foram criados os campos:
Empresa Orig. (RFE_EMPORG) que corresponde ao código da empresa onde a marcação foi registrada.
Filial Orig. (RFE_FILORG) que corresponde ao código da filial onde a marcação foi registrada.
Mat. Orig. (RFE_MATORG) que corresponde ao código da matrícula onde a marcação foi registrada. Esse campo é alimentado ao identificar o funcionário detentor do crachá (titular ou provisório).
Data Hora (RFE_DHORG) que corresponde à combinação data e hora de quando a marcação foi registrada no formato AAMMDDHHmm. Onde:
AA – Ano
MM – Mês
DD – Dia
HH – Hora
mm – Minuto

ID. Org (RFE_IDORG) que corresponde à sequência do registro da marcação.

Cada linha ou registro do arquivo de marcações lido corresponde a um numerador sequencial. Por exemplo, se o arquivo texto de marcações possui 500 linhas, o primeiro valor desse campo é 1 e o último registro ao final da leitura é 500.

Uma vez que o REP esteja implementado, esse campo é alimentado com o conteúdo referente ao campo NSR (Número Sequencial de Registro), fornecido pelo REP.

Importante!

• A tabela RFE – Pré-leitura NÃO DEVE ser mencionada nos parâmetros utilizados na transferência de funcionários (MV_ARQTRAN, MV_TRFDELM e MV_TRFNOCC). Isto significa que as informações geradas numa empresa/filial não podem ser transferidas para outra empresa/filial.
• Realizada implementação para otimizar a performance da rotina de Leitura de Marcações (PONM010), para isso foram realizadas alterações no processamento da leitura e no apontamento das marcações do funcionário. Além disso, foi criada uma Tabela Acumuladora (RFH) para armazenar os registros existentes na Tabela de pré-leitura (RFE).
• Assim como ocorre com as Tabelas Mensais do Ponto Eletrônico, como a de Marcações do Funcionário (SP8), por exemplo, a Tabela de Pré-Leitura (RFE) terá o registro de marcações oriundas do relógio do período de apontamento mensal. Quando a rotina Fechamento Mensal (PONM090) for executada, ao término do período de apontamento, os registros da Tabela de Pré-Leitura (RFE) serão transportados para a Tabela Acumuladora (RFH).

A Portaria estabelece maner a integridade dos dados originais. Desta forma, as marcações contidas na tabela RFE não podem ser modificadas ou suprimidas. Com isso, o usuário deve ter especial atenção ao disponibilizar o arquivo de marcações para leitura. Como neste primeiro momento, não será adotado o REP e os equipamentos existentes não disponibilizam de forma padrão, informações para um controle efetivo de marcações, este será realizado por parametrização. Agora com a Portaria, no entanto, existem restrições, sobretudo na forma de identificar e registrar as marcações indevidas.

É importante lembrar que o processo de geração do arquivo de marcações não é realizado ou controlado pelo Ponto Eletrônico, mas pelo programa do fabricante do equipamento de registro das marcações.

Basicamente existem dois processos de disponibilização do arquivo de marcações, para leitura, gerados pelo dispositivo de registro não REP:
1. Arquivo Novo
Neste processo o arquivo é substituído a cada nova geração. Ou seja, as marcações geradas anteriormente são descartadas e não mais estarão presentes no arquivo gerado.
Por exemplo: se o arquivo de marcações apresentava 100 registros e foram geradas mais cinco marcações, as 100 primeiras são perdidas e o arquivo passa a ter apenas as 5 últimas marcações geradas pelo equipamento de registro de marcações.

2. Arquivo Incrementado
Nesse caso, são acrescentados novos registros aos gerados antes da última geração. Sendo que os registros antigos permanecem em posições físicas anteriores aos últimos gerados.

Por exemplo: se um arquivo texto apresentar 100 marcações e forem acrescentadas 5 novas marcações, as primeiras 100 linhas correspondem as 100 primeiras marcações geradas e as 5 linhas restantes às últimas 5 marcações geradas.

É importante observar que os processos de leitura e identificação de marcações estão baseados nas posições físicas dos registros. Portanto, a alteração do posicionamento dos registros das marcações influência na interpretação e na verificação de consistência das informações lidas, ocasionando inclusive o cancelamento do processo de leitura e da geração do arquivo-fonte de dados tratados – AFDT – citado na Portaria.

Por exemplo: se uma marcação quando lida, estava na posição física 100, e ocorreu a modificação do arquivo, de modo que o registro da marcação passou a ser 200; essa mesma marcação, quando submetida a uma segunda leitura, pode ser registrada, na tabela RFE, como uma marcação indevida e rejeitada automaticamente, apesar do empregado ter registrado apenas uma vez essa marcação. Naturalmente que todas as demais marcações, lidas anteriormente, podem ser registradas da mesma forma. Isso, além de não representar o fato ocorrido, pode-se gerar um acréscimo considerável à base dados.

Fato semelhante ocorre se um arquivo texto for associado a um relógio cujo leiaute não seja correspondente. Nesse caso, as informações podem ser interpretadas de forma inadequada. Por exemplo, onde se esperava ler a informação de data da marcação, pode ser interpretada uma determinada hora e assim, o registro pode ser rejeitado por não constituir em informação coerente.

Caso tenha sido feito a leitura e apontamento e o sistema apresenta no log de ocorrências a informação de 0 lidas e 0 gravadas, ou de X marcações lidas e Y gravadas, deverá ser realizado o procedimento:

Cad. relógio - 3 dígitos no campo código e campo REP preenchido se for o novo formato AFD, se não for, devem deixar sempre em branco.
Cad. Funcionários - Pegar numero do PIS do TXT.
Fazer backup e em seguida dropar as tabelas RFE, RFB, SP8, SPC

Em Atualizações / Cad. Ponto / Períodos - Verifique se o período que esta tentando, esta cadastrado, se estiver DELETE. No período só devem conter as linhas dos períodos já encerrados e são inseridas automaticamente pelo sistema quando se faz o encerramento, o usuário não pode informar nada.

Ainda no cadastro do Período clique em - Modif. Per. Apontamento – clique na segunda opção Período” Ajuste o ponmes e paponta para ficar igual ao do cliente.

Para fazer a leitura:

• Data base, ultimo dia do Período (ultimo dia do PONMES).
• Confira bem os parâmetros, veja se turno, regra, código de relógio estão corretos e os demais parâmetros também.
• A pergunta ler a partir, deve ser cad. de relógio sempre.
• Caso mesmo assim não leia, verifique os parâmetros MV_VISINI e MV_VISIFIM, se não tiver numeração de crachá reservada de fato para visitantes o ideal é que eles fiquem em branco.
• Existe também o MV_GETDIAA e o MV_GETDIAP, que devem ser olhados sempre que o cliente disser que lê tudo, só não ler a ultima marcação do ultimo dia do periodo que fica depois da meia noite, então neste caso o MV_GETDIAP deve estar pelo menos com 1.
• Nunca se esqueçam que mesmo existindo o novo REP, as regrinhas antigas que tínhamos para quando Lê e não grava continuam valendo.
• As vezes o cliente esquece de colocar o PIS ou Crachá no cadastro do funcionário e de fato VAI LER e NÃO vai gravar. Para resolver uma consulta genérica na SRA resolve.
• Quando não for AFD, vejam quantos dígitos tem o crachá, veja se na SRA, no SRA_ CRACHA tem a mesma quantidade de dígitos também.
• Quando for leitura do Modelo antigo, no cadastro de relógio ainda funciona o F4, que mostra se o relógio está configurado corretamente, se está buscando as informações corretas do TXT.
• Verifique se o arquivo que o sistema está lendo não é de um período errado, ou se não é um TXT de outra empresa, então , SEMPRE, uma consulta genérica com o PIS extraído do TXT do cliente, será fundamental.

Importante: Para o funcionamento correto do sistema, é fundamental que o fonte PONM010 esteja sempre atualizado.

Sempre que for realizar uma segunda leitura do TXT é essencial que seja realizado o backup das tabelas RFE, RFB, SP8 e SPC e em seguida apagar as informações referentes ao período ou a leitura que está sendo feita. A data base deve permanecer sempre na ultima data do período a ser lido.