Em 21.08.09, entrou em vigor a Portaria nº 1.510 do Ministério do Trabalho e Emprego disciplinando o registro eletrônico de ponto e a utilização do Sistema de Registro Eletrônico de Ponto – SREP – no Brasil. Para a utilização do SREP é obrigatório o uso do REP, um equipamento de automação utilizado exclusivamente para o registro de jornada de trabalho e com capacidade para emitir documentos fiscais, além de realizar controles de natureza fiscal, referentes à entrada e à saída de empregados nos locais de trabalho. O REP é responsável, dentre outras finalidades, por gerar o arquivo-fonte de dados – AFD – que contém informações sobre os registros de marcações dos empregados.  Esses registros podem ser tratados pelo Programa de Tratamento de Registro de Ponto, cuja função se limita a acrescentar informações que complementem eventuais omissões no registro de ponto ou indiquem marcações indevidas. A Portaria estabelece ainda, que a obrigatoriedade do REP entre em vigor após 12 meses da data da publicação da Portaria, enquanto que o Programa de Tratamento de Registro de Ponto deve atender às determinações da Portaria a partir da data de sua publicação, podendo receber dados em formato diferente daquele especificado para o arquivo AFD.Recomenda-se a leitura integral dos documentos disponibilizados pelo Ministério do Trabalho em:http://www.mte.gov.br/pontoeletronico/default.asp

• SIGAPON

• todos

• Brasil

• todos

O sistema é atualizado logo após a aplicação do pacote de atualizações (Patch) desta FNC.

1.        As implementações descritas nesse documento somente se aplicam aos dados gerados após a atualização do RPO. Os dados gerados anteriormente, não serão contemplados pelas modificações realizadas. Além disso, as alterações foram muito extensas e devem refletir na regra de negócios da empresa, portanto, os impactos dessa atualização deverão ser analisados cuidadosamente.  Assim, antes de realizar a atualização e proceder com a adequação das tabelas é ESSENCIAL a realização de cópia das tabelas utilizadas pelo SIGAPON.

2.        Recomenda-se que a aplicação das rotinas envolvidas nessa implementação seja realizada apenas no início do próximo período de apontamento e não num período em andamento.

3.        Todas as rotinas que obrigatoriamente devem atender à Portaria nº 1.510 passam a ter em seu descritivo os complementos: Texto ou título da rotina + “SREP – Portaria 1510/2009 de 21.08.2009”.

Por exemplo:

Em “Atualizações\Lançamentos\Marcações” (PONA040), exibe-se o título “Ponto Eletrônico [Manutenção das Marcações – SREP – Portaria 1510/2009 de 21.08.2009]”.

Outro exemplo:

Em “Miscelânea\Cálculos\Elim.Marcações” (PONM050), é exibido o título: “Eliminação das Marcações – SREP – Portaria 1510/2009 de 21.08.2009”. Caso os complementos não sejam demonstrados conforme mencionado, indica que a rotina não está atualizada.

      Seguem os nomes das rotinas onde devem ser exibidos os complementos:

Para desempenhar as funcionalidades referentes ao tratamento de registro de ponto na forma descrita pela Portaria, o módulo Ponto Eletrônico sofreu adequações nos seguintes processos:

1.       Leitura de Marcações

   (PONM010 – “Miscelânea\Cálculos\Leitura/Apont.marc”)

Foram criadas duas tabelas para armazenar as marcações do arquivo gerado pelo REP: RFB – Cabeçalho de pré-leitura e RFE – Pré-leitura. O conteúdo dessas tabelas não poderá ser modificado pelo usuário nem tão pouco serem eliminadas, uma vez que garantirão a integridade das informações originais.

Nesse primeiro momento, até que seja adotado o REP, essas tabelas serão alimentadas com as marcações geradas pelo equipamento de registro de marcações existentes nas empresas, como por exemplo, o relógio de ponto, a catraca, etc. No caso de equipamentos que, além do registro de marcações, executam também o controle de acesso de outras pessoas que não sejam empregados, essas tabelas poderão conter marcações de não empregados. É importante lembrar que 12 meses após a publicação da Portaria, o REP deverá ser utilizado somente para o registro de marcações de empregados. As referidas tabelas são:

·            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:

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”. Esse campo será “alimentado” com o conteúdo do campo “Nome Arquivo” (P0_ARQUIVO) informado no Cadastro de Relógios (PONA030).

o     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) que corresponde à data e hora inicial, e o campo “Dt.Hr. Final” (RFB_DTHRLF) que corresponde à data e hora final da leitura do arquivo de marcações. O conteúdo desses campos está no formato AAMMDDHHmm onde:

§   AA – Ano

§   MM – Mês

§   DD – Dia

§   HH – Hora

§   mm – Minuto

o     Identificação do usuário que acionou o processo de leitura: para essa informação foi criado o campo “Usuário” (RFB_USUARI).

o     Data e hora da geração do arquivo de marcações: para essa 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

o   Última linha lida ou registro do arquivo de marcações registrado na tabela de Pré-leitura – RFE: essa 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, esse 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 através do botão “Visualizar”.

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

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

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

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

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

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

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

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.

o     “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.

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

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

·         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”). Isso significa que as informações geradas numa empresa/filial não poderão ser “transferidas” para outra empresa/filial.

·         Realizada implementação para otimizar a performance da rotina de Leitura de Marcações (PONM010). Para isso foi realizada 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 de 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 que se deva manter a integridade dos dados originais. Dessa forma, as marcações contidas na tabela RFE não poderão ser modificadas ou suprimidas. Com isso, o usuário deverá ter especial atenção ao disponibilizar o arquivo de marcações para leitura. Como nesse 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

Nesse 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 influenciará 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, poderá 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, poderão ser registradas da mesma forma. Isso, além de não representar o fato ocorrido, poderá gerar um acréscimo considerável à base dados.

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

2.       Cadastro de Relógios

   (PONA030 – “\Atualizações\Cadastros Ponto\Relógios”)

   No Cadastro de Relógios – SP0, para configurar a forma de interpretação do arquivo de marcações, criou-se o campo:

1.        “Incremental” - Esse campo determina se a cada geração pelo relógio, o arquivo de marcações é complementado com informações adicionais, ou seja, se é incremental ou não. Caso esse campo tenha sido configurado para considerar o arquivo de marcações associado ao relógio como sendo um arquivo não incremental e, no entanto, um arquivo incrementado for submetido à leitura, as marcações pré-existentes poderão ser consideradas como anomalias conforme o parâmetro MV_DESPMIN e classificadas como desprezadas. 

O motivo de descarte será aquele definido na tabela RFD – Motivo Manutenção - como sendo uma rejeição automática. Se o arquivo de marcações gerado pelo relógio foi configurado como não incremental e, se de fato for incremental, o arquivo será considerado corrompido.

Adicionalmente, foi criado o campo:

·         “REP” – para conter a identificação numérica do equipamento de automação denominado REP quando esse estiver disponível. Um relógio associado ao REP não poderá ser eliminado caso tenha marcações registradas pela leitura de marcações. Também, o relógio não poderá ter o número do REP substituído caso tenha marcações registradas pela leitura de marcações.

Foi alterado também o campo do tipo de arquivo:

·         “Tipo Arquivo” – para poder identificar qual é o tipo de arquivo a ser importado referente as marcações realizadas pelos funcionários. Este campo permitirá a importação via Xbase, via Texto (padrão ASCII) e o novo formato chamado REP que estará efetuando a leitura das marcações diretamente na tabela do banco de dados das marcações geradas pelo REP.

3.          Cadastro de Regra de Apontamento

      (PONA060 – “\Atualizações\Cadastros Ponto\Regras Apontamento”)

Para as empresas em que o intervalo de repouso/alimentação é pré-assinalado, na regra de apontamento foi criado um campo específico para determinar qual intervalo a ser gerado automaticamente será o considerado como pré-assinalado:

§  “Pré-assin.” – o usuário poderá selecionar um dos intervalos possíveis. Por exemplo, ao selecionar “1” estará determinado que o primeiro intervalo a ser gerado seja o considerado como pré-assinalado. Somente os intervalos gerados poderão ser considerados como pré-assinalados. 

Segue um exemplo de como identificar um intervalo válido para registro no REP.

Horário previsto:

Conforme o exemplo acima, somente o intervalo para o almoço poderá ser configurado para registro no REP.

Uma exigência da nova Portaria é o fornecimento das horas trabalhadas não extraordinárias. Dessa forma, passa a ser obrigatória a configuração da regra de apontamento para que essas horas sejam apuradas pelo sistema. Como consequência, esse fato poderá influenciar no pagamento dos mensalistas, pois geralmente para essa categoria a regra de apontamento não é configurada para apurar as horas trabalhadas. Assim, foi criado um campo na própria regra:

§  “Hr.Norm.Fol.”– para determinar se as horas não extraordinárias apuradas no apontamento deverão ser  ou não desconsideradas no Cálculo Mensal (PONM070). Se desconsideradas não serão enviadas para a folha de pagamento. Para esse caso, estão compreendidos os eventos associados aos seguintes identificadores do Ponto:

4.       Cadastro de Motivo de Manutenção (Novo)

             (PONA430 – “\Atualizações\Cadastros Ponto\Motiv.Manutenção”)

Para automatizar e facilitar o controle de justificativas para inclusão, alteração e descarte de informações foi criada a tabela de Motivo de Manutenção – RFD.  Atualmente, somente foram implementadas justificativas padronizadas de manutenção para as marcações. Se desejar, o usuário poderá modificar as descrições das justificativas através desse cadastro. As justificativas criadas são:

§   1 – Inclusão manual de marcações

§   2 – Rejeição manual de marcações

§   3 – Rejeição automática de marcações (quando a marcação foi desprezada devido à parametrização do sistema).

§   4 – Inclusão automática

Os motivos acima não podem ser eliminados por serem de uso exclusivo do Sistema. É possível criar outros motivos além dos padronizados para uso em futuras customizações.

Conforme foi exposto, durante o processo de leitura, as marcações descartadas devido ao uso do parâmetro MV_DESPMIN, serão registradas com o motivo 3 – Rejeição automática de marcações.

5.          Cadastro de Tabela de Horário Padrão

             (PONA080 – “\Atualizações\Lançamentos\Tab.Horário Padrão”)

A Portaria nº 1.510 determina a geração de um arquivo magnético para controle de jornadas para efeitos fiscais – ACJEF onde é necessário destacar o intervalo de repouso/alimentação do empregado. Assim, na tabela de horário padrão foi criado um campo para essa finalidade:

·       “Interv.SREP” – Indica o intervalo do horário contratual a ser considerado na geração do arquivo de controle de jornada para efeitos fiscais – ACJEF. 

O usuário poderá optar por um dos intervalos controlados pelo sistema.

6.          Manutenção de Marcações

             (PONA040 – “Atualizações\Lançamentos\Marcações”) /

             (PONA230 – “Atualizações\Lançamentos\Marcações P/ C.c”) /

             (PONA280 – “Atualizações\Lançamentos\Integrados”)

Nas manutenções de marcações, foram adicionados novos campos para controlar os acréscimos ou supressões de marcações:

§   O campo “Turno” (P8_TURNO/PG_TURNO) passa a ser apenas visual e identifica o turno corrente para o dia de apontamento ao qual a marcação se refere.

§   Foi adicionado o campo “Sequência” (P8_SEMANA/PG_SEMANA) que corresponde à sequência/semana do turno de trabalho. O usuário somente poderá visualizar essa informação.

§   Os campos correspondentes ao turno e à sequência permitem identificar o horário padrão correspondente as marcações, salvo as situações de exceção, folga automática na semana e turno opcional (horários alternativos).

§   O campo “Data Apont.” (P8_DATAAPO/PG_DATAAPO) corresponde à data de apontamento da marcação. O usuário somente poderá visualizar essa informação.

§   O campo “Número REP” (P8_NUMREP/ PG_NUMREP) armazena o número de fabricação do REP onde foi realizado o registro da marcação. O usuário somente poderá visualizar essa informação. Enquanto o REP não for adotado pela empresa esse campo permanecerá vazio.

§   O campo “Tp.Marc.REP” (P8_TPMCREP/PG_TPMCREP) pode possuir “D” como conteúdo caso o registro seja “DESCONSIDERADO” pelo usuário ou pelo processo de leitura.

§   O campo “Tipo Reg.” (P8_TIPOREG/ PG_TIPOREG) identifica uma marcação original – “O” – ou um registro Incluído por digitação – “I” – e ou se refere a uma marcação de intervalo PRÉ-ASSINALADO – “P”.

§   O campo “Motivo Reg.” (P8_MOTIVRG/PG_MOTIVRG) armazena o motivo da inclusão do registro ou desconsideração da marcação. Esse motivo corresponde a uma das justificativas na tabela de Motivos de Manutenção – RFD e poderá ser preenchido caso o conteúdo do campo “Tp.Marc.REP” (P8_TPMCREP) seja “D” ou se o conteúdo do campo “Tipo Reg.” (P8_TIPOREG/ PG_TIPOREG) for “I”.

Os dados de origem das marcações podem ser apenas visualizados e são identificados pelos campos:

§   “Empresa Orig.” (P8_EMPORG/PG_EMPORG) que corresponde ao código da empresa onde foi registrada a marcação.

§   “Filial Orig.” (P8_FILORG/PG_FILORG) que corresponde ao código da filial onde foi registrada a marcação.

§   “Mat. Orig.” (P8_MATORG/PG_MATORG) que corresponde à matrícula onde foi registrada a marcação.

§   “Data Hora” (P8_DHORG/PG_DHORG) que corresponde à combinação Data e Hora de quando foi registrada a marcação.

§   “ID. Org” (P8_IDORG/PG_IDORG) que corresponde à sequência do registro da marcação.

Quando um registro for modificado, desprezado ou incluído pelo usuário, os seguintes campos serão alimentados:

§   “Data Log” (P8_DATAALT/PG_DATAALT) onde será gravada a data da manutenção da marcação.

§   “Hora Log” (P8_HORAALT/PG_HORAALT) onde será gravada a hora da manutenção da marcação.

§   “Usuário” (P8_USUARIO/PG_USUARIO) onde será gravada a identificação do autor da manutenção da marcação.

O botão “Deleta Coluna...[F4]” passa a ser chamar “Desconsidera Marcação... [F4]”. No caso do campo “Tipo Reg.” (P8_TIPOREG) da marcação for igual a “O” será solicitado o motivo para desconsiderar a marcação e somente após o preenchimento desse motivo pode-se prosseguir com a operação. Será sugerido como motivo a descrição definida na tabela de Motivos de Manutenção – RFD, código “2 “– Rejeição manual de marcações. O campo “Tp.Marc.REP”, nessa condição, será alimentado com “D”.

§   Foi criado o botão com a descrição “Restaurar..Alt+R.” para recuperar as marcações originais desconsideradas. Serão restauradas as marcações originais conforme a data de apontamento da marcação “Data Apont.” (P8_DATAAPO) coincidente com o conteúdo do campo “Data Apont.” da tabela de Pré-leitura (RFE_DATAAP) em substituição às marcações tratadas. Nesse caso, o motivo de manutenção ficará vazio.

§   No caso de inclusão de marcação será solicitado o motivo para incluir a marcação e somente após o preenchimento do motivo pode-se prosseguir com a operação. Será sugerido como motivo a descrição definida na tabela de Motivos de Manutenção – RFD, código “1” - Inclusão manual de marcações. Para todas as marcações incluídas/geradas o campo “Tipo Reg.” (P8_TIPOREG) será alimentado com “I”.

§   As marcações desconsideradas não serão visualizadas nas manutenções, salvo as recém-desconsideradas que deixaram de ser apresentadas nos acessos subsequentes às manutenções de marcações.

§   As marcações automáticas identificadas como marcações referentes a intervalo pré-assinalado, ou seja, intervalo para repouso/alimentação, terão o conteúdo do campo “Tipo Reg.” (P8_TIPOREG) como “P”.

7.       Apontamento de Marcações

             (PONA040 – “\Atualizações\Lançamentos\Marcações”)

             (PONA230 – “\Atualizações\Lançamentos\Marcações P/ C.c”)

             (PONA280 – “\Atualizações\Lançamentos\Integrados”)

             (PONM010 – “\Miscelânea\Cálculos\Leitura/Apont.marc”)

Todos os tipos de horas extras deverão ser especificados em eventos distintos. Por exemplo, os códigos dos eventos de horas extras normais diurnas e noturnas deverão ser diferentes para possibilitar a geração do arquivo ACJEF.

Dessa maneira, é possível identificar as horas diurnas e noturnas e seus percentuais correspondentes uma vez que os códigos dos eventos das horas são distintos por tipo e percentual.

As horas trabalhadas noturnas e diurnas deverão ser obrigatoriamente apontadas.

8.        Manutenção de Apontamentos

(PONA130 – “Atualizações\Lançamentos\Apontamentos”)

Nas manutenções de apontamentos, poderão ser visualizados novos campos de apontamentos:

§   “Turno” (PC_TURNO/PH_TURNO) referente ao turno de trabalho

§   “Sequência” (PC_SEMANA/PH_SEMANA) que corresponde à sequência/semana do turno de trabalho.

As informações de turno e sequência serão obtidas a partir das marcações de origem e do calendário do funcionário na ausência delas (faltas, por exemplo). Esses campos permitem identificar o horário padrão correspondente aos apontamentos, salvo as situações de exceção, folga automática na semana e turno opcional (horários alternativos).

§   “% Adicional” (PC_PERCENT/PH_PERCENT) utilizado para registrar o percentual de valorização (P4_PERCENT) correspondente às horas extras a serem apontadas.

As informações relativas a turno, sequência e percentual serão geradas durante o apontamento das marcações.

Nas manutenções de apontamentos, quando um registro for modificado, desprezado ou incluído pelo usuário, os seguintes campos serão “alimentados”:

§   “Data Log” (PC_DATAALT/PH_DATAALT) onde será gravada a data da manutenção do apontamento.

§   “Hora Log” (PC_HORAALT/PH_HORAALT) onde será gravada a hora da manutenção do apontamento.

§   “Usuário” (PC_USUARIO/PH_USUARIO) onde será gravada a identificação do autor da manutenção do apontamento.

Não é mais permitida a exclusão de nenhum lançamento das tabelas dos apontamentos acumulados (SPH) para garantir a integridade das informações.

9.       Manutenção de Eventos do Ponto

             (PONA100 – “\Atualizações\Cadastros Ponto\Eventos”)

Nessa manutenção o usuário deve classificar os eventos do Ponto Eletrônico através do campo “Classific.” (P9_CLASEV). Por exemplo, quando um evento for classificado como hora extra não poderá apresentar um identificador “Ident.Ponto” (P9_IDPON não poderá estar preenchido).

O campo “Classificação” deve possuir um conteúdo correspondente ao identificador de ponto ao qual o evento está associado. Por exemplo, se o identificador for “010” – Falta integral, o evento deverá ser classificado como “02” – Falta. Seguem as classificações possíveis:

§  “01” – Hora Extra

§  “02” – Falta

§  “03” – Atraso

§  “04” – Saída no Expediente

§  “05” – Saída Antecipada

§  “ZZ” – Outros

Se o evento não possuir identificador ou se o identificador não corresponder às classificações de “01” a “05”, deverão ser classificados como “ZZ”.

      Na tabela de Tipos de Horas Extras – SP4, somente será possível selecionar eventos do ponto que tenham sido c           classificados como horas extras (P9_CLASEV igual a “01”).

10.    Geração do arquivo-fonte de dados tratados – AFDT

             (PONM410 – “Miscelânea\SREP\AFDT”)

O AFDT - Arquivo-fonte de Dados Tratados é o arquivo que contém as marcações dos empregados, tanto as originais quanto as incluídas (ou desprezadas) manualmente pelo usuário ou automaticamente através do SIGAPON.

Nessa opção, o usuário pode determinar a geração do arquivo magnético para um grupo de filiais, empregados e um intervalo de datas. São identificados os períodos de apontamento compreendidos pelo intervalo de datas fornecido. Para cada período e filiais informadas, são obtidas todas as informações correspondentes ao PIS do empregado e essas informações são concentradas por CNPJ. Isso significa que se cada uma das filiais possuir um CNPJ diferente (considerando todos os algarismo do CNPJ) e um empregado estiver presente em mais de um a filial, as informações do empregado serão demonstradas em cada uma das filiais.  Caso mais de uma filial possua o mesmo CNPJ (considerando todos os algarismos), as informações serão concentradas em um único CNPJ.

Cenário 1 – Cada filial apresenta um CNPJ diferente, as informações são demonstradas para cada CNPJ.

Cenário 2 – As filiais apresentam o mesmo CNPJ, as informações são demonstradas no mesmo CNPJ.

Os registros são gerados no leiaute especificado para o AFDT e o arquivo magnético é gravado no local informado pelo usuário. Se for encontrada alguma inconsistência nos dados considerados para a geração, um log de ocorrência é emitido ao final do processo.

Outras inconsistências que impeçam o prosseguimento da operação podem ser informadas ao usuário e o processo poderá ser abortado conforme a criticidade envolvida.

Todo o limite superior de um intervalo de critério de filtro não pode ser vazio.  Por exemplo, para o intervalo de filiais a ser considerado, a pergunta referente à última filial não pode ter conteúdo vazio.

O arquivo gerado é gravado no local informado pelo usuário com o nome “AFDT”.

As principais mensagens (entre aspas) que podem ser listadas no log da geração são:

§   “PIS INVÁLIDO” – O PIS do empregado lido está em branco.

§   “Nome do arquivo inválido.” – O nome do arquivo informado para a geração não é “AFDT”.

§   “Marcações impares. Filial:” – A jornada do dia anterior terminou com uma marcação de entrada. Faltou a saída.

·            “-- Empresa: Sem Marcações” – Não foram encontradas marcações de empregados para empresa.

·            “Erro de Inconsistência. Marcação original ausente do arquivo-fonte Tratado:” – Uma marcação registrada pelo empregado não foi encontrada na tabela de marcações (SP8) ou na tabela de marcações acumuladas (SPG).

11.               Geração do arquivo de controle de jornada para efeitos fiscais – ACJEF

                   (PONM420 – “Miscelânea\SREP\ACJEF”)

O arquivo ACJEF – Arquivo de Controle de Jornada para Efeitos Fiscais - contém os horários contratuais, às horas diurnas e noturnas não extraordinárias, e as faltas e atrasos realizados pelo empregado. Além disso, contém as horas extras discriminadas conforme o seu percentual de valorização e o período realizado (diurno ou noturno).

Nessa opção, o usuário pode determinar a geração do arquivo magnético para um grupo de filiais, empregados e um intervalo de datas. São identificados os períodos de apontamento compreendidos pelo intervalo de datas fornecido. Para cada período e filiais informadas nos são obtidas todas as informações correspondentes ao PIS do empregado e essas informações são concentradas por CNPJ. Isso significa que se cada uma das filiais possuir um CNPJ diferente (considerando todos os algarismos do CNPJ) e um empregado estiver presente em mais de um a filial, as informações do empregado serão demonstradas em cada uma das filiais.  Caso mais de uma filial possua o mesmo CNPJ (considerando todos os algarismos), as informações serão concentradas em um único CNPJ.

Cenário 1 – Cada filial apresenta um CNPJ diferente, as informações são demonstradas para cada CNPJ.

Cenário 2 – As filiais apresentam o mesmo CNPJ, as informações são demonstradas no mesmo CNPJ.

Os registros são gerados no leiaute especificado para o ACJEF e o arquivo magnético é gravado no local informado pelo usuário.

Se for encontrada alguma inconsistência nos dados considerados para a geração, um log de ocorrência é emitido ao final do processo. Outras inconsistências que impeçam o prosseguimento da operação podem ser informadas ao usuário e o processo pode ser abortado conforme a criticidade envolvida.

Todo o limite superior de um intervalo de critério de filtro não pode ser vazio.  Por exemplo, para o intervalo de filiais a ser considerado, a pergunta referente à última filial não pode ter conteúdo vazio.

O arquivo gerado será gravado no local informado pelo usuário com o nome “ACJEF”.

As principais mensagens (entre aspas) que poderão ser listadas no log da geração são:

·         “PIS INVÁLIDO” – Não foi informado o PIS do empregado no seu cadastro.

·         “Nome do arquivo inválido.” – O nome do arquivo deve ser ACJEF

·         “-- Empresa: Sem Apontamentos” – A empresa não contém apontamentos para a geração do ACJEF.

·         “Nenhum Evento está configurado como Hora Extra. Filial:” – Classifique os eventos de horas extras.

·         “Nenhum Evento está configurado como Hora Faltas/Atrasos. Filial:” – Classifique os eventos de faltas/atrasos.

·         “Nenhum Evento está configurado como Hora Diurna. Filial:” – Classifique os eventos de hora diurna.

·         “Nenhum Evento está configurado como Hora Noturna. Filial:” – Classifique os eventos de hora noturna.

·         “Código de Hora Extra utilizado em mais de um tipo. Filial:” – Os eventos de horas extras deverão ser distintos por faixa e tipo de dia.

·         “Evento de Hora Extra Não Encontrado para a Filial:” – Existe um evento na base de dados, mas não foi encontrado na tabela de horas extras.

12.    Cálculo Mensal

             (PONM070 – “Miscelânea\Cálculos\Cálculo Mensal”)

As informações no arquivo ACJEF – Arquivo de Controle de Jornadas para Efeitos Fiscais – devem ser demonstradas dia a dia. Em virtude disso, foi criada uma nova tabela:

§  RFF – Pré-ACJEF, é exclusiva por filial, contém as informações de horas trabalhadas, faltas/atrasos, horas extras e compensadas. Sendo estas ultimas correspondentes as horas de banco de horas/compensação. As horas demonstradas já terão as horas abonadas deduzidas:

o     O campo “Filial” (RFF_FILIAL/RFG_FILIAL) corresponde à filial do empregado.

o     O campo “Matricula” (RFF_MAT/RFG_MAT) corresponde à matrícula do empregado.

o     O campo “Data” (RFF_DATA/RFG_DATA) refere-se à data de ocorrência do evento do ponto.

o     O campo “Cod. Evento” (RFF_PD/RFG_PD) é o código do evento do ponto.

o     O campo “Destino” (RFF_TIPO/RFG_TIPO) corresponde ao destino das horas do evento do ponto. Quando as horas forem enviadas para a folha de pagamento seu conteúdo será 1. Quando as horas forem para o banco de horas seu conteúdo será 2.

o     O campo "Qtde.calcul." (RFF_QUANTC/RFG_QUANTC) refere-se a quantidade de horas apuradas para o evento no padrão sexagesimal.

o     O campo “Centro Custo” (RFF_CC/RFG_CC) é o centro de custo de ocorrência do evento.

o     O campo “Flag” (RFF_FLAG/RFG_FLAG) representa o “status” do registro do evento.

o     O campo “Período Apon.” (RFF_PAPONT/RFG_PAPONT) corresponde ao período de apontamento no qual ocorreu o evento.

o     O campo “Sinal” (RFF_SINAL/RFG_SINAL) refere-se ao sinal das horas apuradas para o evento. Quando possuir o conteúdo 1, as horas apuradas serão somadas na geração do ACJEF e quando possuir o conteúdo 2, as horas apuradas serão subtraídas na geração do ACJEF. O resultado da soma ou subtração será demonstrado nas colunas de horas diurno/noturnas, faltas/atrasos, horas extras ou compensadas do arquivo ACJEF, conforme a classificação do evento (campo  "Classific."  na manutenção de Eventos do Ponto).

Processo

As horas são apuradas conforme a sua periodicidade (diária, semanal, quinzenal ou mensal) e na tabela RFF são registradas dia a dia.

Abono de horas

Com a execução do atualizador exigido para essa implementação, o conteúdo dos seguintes parâmetros foram modificados:

·           MV_DEDABBH – passa a ter obrigatoriamente o conteúdo ‘S’. Significando que as horas apontadas serão deduzidas das horas abonadas que vão para o banco de horas.

·           MV_FOLVBH – passa a ter obrigatoriamente o conteúdo ‘S’. Significando que se o destino das horas apontadas e abonadas for diferente, as horas apontadas serão deduzidas das horas abonadas.

A conjugação desses dois parâmetros, com a configuração descrita acima, pretende evitar possíveis distorções quando as horas apontadas vão para o banco de horas e as horas abonadas vão para a folha de pagamento e vice-versa.

Cenário 1 – Horas apontadas para banco de horas e horas abonadas para a folha de pagamento.

Nesse exemplo, as horas de faltas foram enviadas para a folha de pagamento e o abono para o banco de horas. Dependendo da configuração dos eventos (provento ou desconto, por exemplo) essa quantidade de horas pode ser descontada em duplicidade. Com a alteração dos valores padrão dos parâmetros mencionados, evita-se esse tipo de distorção.

·         Deve-se atentar que as customizações e regras de negócio da empresa quanto ao uso do abono deverão ser revistas em virtude das modificações mencionadas.

·         As horas configuradas para banco de horas serão demonstradas na tabela SPI – Banco de Horas – dia a dia, mesmo que alguns eventos estejam configurados para serem apurados semanalmente, quinzenalmente ou mensalmente.  Por exemplo, considerando o evento de horas extras no mês, com apuração semanal:

·         Apontamento

·         Banco de Horas após o Cálculo Mensal apresenta as horas diariamente.

·         Antes, seguindo o exemplo, no dia 23/10/2009 era apresentada a soma das horas referente à semana.

·         Após o Cálculo Mensal recomenda-se a geração do arquivo magnético ACJEF e a conferência de suas informações antes do Fechamento Mensal (PONM090 – “Miscelânea\ Fechamentos\ Mensal”)

13.    Fechamento Mensal

             (PONM090 – “Miscelânea\Fechamentos\Mensal”)

As informações da tabela RFF – Pré-ACJEF – com data igual ou menor que o fim do período a ser fechado, são transferidas para a tabela RFG – Acumulado de Pré-ACJEF ao realizar o fechamento mensal.  Dessa maneira, recomenda-se a geração e conferência do arquivo magnético ACJEF antes de realizar o fechamento.

Não será disponibilizada uma manutenção para a tabela RFF – Pré-ACJEF (e sua correspondente acumulada, RFG), dessa maneira não será possível a modificação de seu conteúdo após o fechamento mensal.

14.    Integração Aplicativo TSA (Totvs Controle de Acesso) via WebServices

·         As informações cadastradas no módulo do Ponto Eletrônico serão enviadas via WebServices para o aplicativo TSA conforme a a execução das rotinas/cadastros abaixo. A lista de mensagens de erro da integração estão no final deste documento.

O campo PIS (RA_PIS) teve o tamanho alterado para 12 (doze) posições, porém o campo só aceitará 11 (onze) posições. Dessa forma, não será necessário alterar o número do PIS dos funcionários no Cadastro de Funcionários.

O número de PIS não é único no sistema, ou seja, na tabela SRA (Funcionários) pode haver um ou mais funcionários com o mesmo número de PIS (múltiplos vínculos). Nesse caso, a rotina de leitura (PONM010) fará o seguinte tratamento para identificar para qual matrícula será feita a gravação das marcações: verificará as matrículas que possuem o mesmo número de PIS e os turnos de trabalho das matrículas, para checar a proximidade do horário apontado com os horários cadastrados na tabela de horário padrão (PONA080) e, assim, obtém de qual turno é o apontamento e fará a marcação na matrícula correta. Se, por acaso, todas as matrículas possuírem o mesmo turno de trabalho, a marcação será gravada na primeira matrícula encontrada com o número de PIS de registro

Antes de executar o compatibilizador RHUPDMOD é imprescindível:

a)       Realizar o backup da base de dados do produto que será executado o compatibilizador (diretório “\PROTHEUS11_DATA\DATA”) e dos dicionários de dados "SXs" (diretório “\PROTHEUS11_DATA\ SYSTEM”).

b)       Os diretórios acima mencionados correspondem à instalação padrão do Protheus, portanto, devem ser alterados conforme o produto instalado na empresa.

c)        Essa rotina deve ser executada em modo exclusivo, ou seja, nenhum usuário deve estar utilizando o sistema.

d)       Se os dicionários de dados possuírem índices personalizados (criados pelo usuário), antes de executar o compatibilizador, certifique-se de que estão identificados pelo nickname. Caso o compatibilizador necessite criar índices, irá adicioná-los a partir da ordem original instalada pelo Protheus, o que poderá sobrescrever índices personalizados, caso não estejam identificados pelo nickname.

e)       O compatibilizador deve ser executado com a Integridade Referencial desativada*.

1.        Em Microsiga Protheus TOTVS Smart Client (se versão 10) ou ByYou Smart Client (se versão 11), digite RHUPDMOD no campo Programa Inicial.

2.        Clique no botão OK para continuar.

3.        Será apresentada uma tela de seleção de módulos.

4.        Selecione SIGAPON – Ponto Eletrônico.

5.        Clique em Ok para prosseguir.

6.        Após a confirmação é apresentada uma tela para seleção do compatibilizador.

7.        Selecione a opção “16 – Atualização Unificada Portaria No. 1.510”.

8.        Ao confirmar, é apresentada uma mensagem de advertência sobre o backup e a necessidade de sua execução em modo exclusivo.

9.        Clique em Sim para iniciar o processamento. O primeiro passo da execução é a preparação dos arquivos.

10.     É apresentada uma mensagem explicativa na tela.

11.     Em seguida, é apresentada a janela de “Atualização concluída” com o histórico (log) de todas as atualizações processadas. Nesse log de atualização, são exibidos somente os campos atualizados pelo programa. O compatibilizador cria os campos que ainda não existam no dicionário de dados.

12.     Clique no botão Gravar para salvar o histórico (log) apresentado.

13.     Clique no botão OK para encerrar o processamento.

Para a correta atualização do dicionário de dados, certifique-se que a data do compatibilizador seja igual ou superior a 12/08/2011.

1.     Criação ou Alteração no arquivo SX3 – Campos.

·       Tabela SP0 - Relógios

·       Tabela: SP0 – Relógios

·       Tabela SP1 - Refeições

·       Tabela SP5 - Movimento Refeitório

·       Tabela SP8 - Movimento de Marcações

·       Tabela SPG - Histórico de Marcações

·       Tabela SPN - Histórico Movimento Refeitório

·       Tabela SPZ - Acessos Visitantes

·       Tabela SRA - Funcionários

·       Tabela: SP8 – Marcações

·       Tabela: SPG – Marcações Acumuladas

·       Tabela: SPC – Apontamentos

·       Tabela: SPH – Acumulados de Apontamentos

·       Tabela: SPA – Regras de Apontamento

·       Tabela: SPJ – Tabela de Horário Padrão

·       Tabela: SP9 – Eventos

·       Tabela: RFD – Motivo Manutenção

·       Tabela: RFE – Pré-leitura