Manual Convergencia LOGIX Ponto Eletrônico

1. Requisitos de Implantação e Utilização

• • Logix 

o Versão Logix: 10.2 ou 11.0.

          o Último pacote Logix Atualizado. 

o Realizar a exportação dos itens definidos como Cadastros Básicos e Históricos da Folha do Logix para o Protheus:

• • • Cargo
    • Centro de Custo
    • Eventos
    • Unidade Funcional
    • Escala
    • Funcionários
      
      

• • Protheus

o Versão Protheus: 12.1.7 ou superior

          o Realizar a importação dos itens definidos como Cadastros do Ponto Eletrônico do Logix para o Protheus:

• • • Função
    • Centro de Custo
    • Verbas
    • Departamento
    • Turno
    • Funcionários
    • Cadastro de Períodos

                                 Na migração de Funcionários, efetuar a inclusão manual de um registro com o código 01 na tabela SPA – Regras de Apontamento, permitindo que na importação de

                                 funcionários no Protheus seja feita a inicialização da tabela SPF – Transferências de Turnos dos funcionários, que é obrigatório para o Protheus.

                                 Dessa forma, serão preenchidos com valores fixos os campos RA_REGRA, com o valor 01 e RA_SEQTURN, com o valor 01.

2. Instalação/Atualização

Cadastramento de programas no menu LOGIX

Parâmetros Gerais Logix

Execute o programa LOG00087 (Manutenção de Parâmetros) e acesse o seguinte caminho ADMINISTRAÇÃO LOGIX / CONTROLE GERAL / INTEGRAÇÃO ENTRE SISTEMAS    

           O parâmetro abaixo faz parte desta integração e deve ser devidamente atualizado antes da utilização:

Relacionamento De/Para de Empresa Logix X Empresa/Filial:

          Para que os registros dos arquivos possam ser exportados corretamente do Logix para o Protheus, é necessário informar o código da empresa e filial do sistema

          Protheus para o qual está migrando.

          Estas informações são registradas no LOG00083 (Cadastro de Empresas):

Nota: Para que estes campos possam ser informados é necessário ativar o parâmetro “Permite informar empresa/filial externa no cadastro de empresas ?”, no LOG00087.

Relacionamento De/Para Geral:

         Para que a migração funcione corretamente será necessário também realizar o relacionamento “De/Para” para algumas informações que são enviadas do Logix

         para o Protheus.

         Estes relacionamentos devem ser realizados no programa VDP10141 (Cadastro De/Para Geral):      

                     Para cada informação prevista no tratamento de relacionamento De/Para deve ser informada a tabela de cadastro correspondente:    

                    Nota: O detalhamento do DE/PARA para cada uma das informações acima será realizado na especificação de cada um dos itens de migração.

                     Este programa possui três formas de entrada de dados:

• • • Registro a registro: Ao utilizar as opções “Incluir” e “Modificar” da toolbar, os dados deverão ser informados na própria tela do programa, conforme imagem acima. Neste formato, para cada relacionamento é necessário efetuar uma nova inclusão.
      Nota: Esta deverá ser a opção padrão para cadastramento das informações da Migração, devido este programa não estar preparado para prever algumas situações específicas do RH Logix (Data de Validade Final e Inicial como sendo parte da chave primária da tabela, tratamento do código do Histórico Padrão relacionado ao evento).
    • Carga inicial: Esta opção somente pode ser utilizada para tabelas que ainda não tenha relacionamento registrado. Quando acionada, esta opção irá abrir uma tela que deverá ser indicada a tabela e o sistema de integração para o qual serão gravados os relacionamentos:

Ao confirmar, o sistema buscará todos os registros existentes na tabela informada e permitirá realizar todos os relacionamentos de uma só vez:

• • • Grade: Esta opção tem funcionamento semelhante à opção “Carga inicial”, porém permite a manutenção para todas as tabelas, independente se já possuem ou não relacionamento cadastrado.

Como funcionará o uso dos relacionamentos De/Para na Migração:

      Envio da Informação: Quando o arquivo for gerado, o sistema verificará a existência do relacionamento De/Para, utilizando como base para pesquisa a

           informação existente no Logix. Se não for encontrado este relacionamento, será enviado o próprio código do Logix.

3.     Contexto e Negócio

             Visando ofertar uma solução de RH mais adequada à necessidade dos clientes Logix, será implementado o UPGRADE de versão do ERP Logix RH para o produto

             Microsiga Protheus RH. Desta forma, o cliente poderá optar por uma solução que atenda melhor a sua gestão de Administração de Pessoal e gestão de Capital

             Humano.

              Nesta Upgrade, será contemplado o envio de informações que são compatíveis entre ambos os sistemas e que envolvem cadastros básicos, cadastros que estão

              relacionados diretamente a funcionários, além de informações que envolvam dados de históricos de pagamentos, onde há um grande volume de informações.

4.     Escopo e Finalidade

  Para atender ao contexto exposto acima, no escopo deste Upgrade foi definida a migração dos seguintes cadastros do Logix para o Protheus:

             Todas as migrações desenvolvidas serão realizadas através de Arquivos Textos.

5.     Limitações/Restrições

• • O sistema Protheus deverá ser instalado em um SGBD (Sistema Gerenciador de Banco de Dados). Não poderá ser utilizado este processo em arquivos DBF. 

• • Na importação no sistema Protheus não está previsto o conceito de Gestão de Corporativa. Dessa forma, deve-se utilizar somente o conceito de Empresa/Filial.

• • Não será feito o envio de informações de históricos de ponto do sistema Logix, como histórico de marcações, histórico de apontamentos, horas de banco de horas já quitadas. Será necessário manter um ambiente Logix RH, logo após a migração para realizar estas consultas, caso seja necessário. 
  • As parametrizações básicas referentes à Ponto Eletrônico devem ser previamente cadastradas, para atender a rotina, visto que estes dados não serão migrados do Logix:
  • • o Regras de Apontamento
    • o Horário Padrão
    • o Tipos de Refeições
    • o Refeições
    • o Tipos de Horas Extras
    • o Arredondamentos
    • o Eventos Abonados
    • o Períodos de Apontamento
    • o Mensagens Acesso
    • o Ocorrências Acesso
    • o Itens de Ocorrências Acesso
    • o Programação Ocorrências Acesso
    • o Horas Extras Autorizadas
    • o Visitantes
    • o Pré-Abonos
    • o Exceções
    • o Feriados
    • o Motivo Abono/Justificativa
    • o Motivo de Manutenção

• • Será realizada a migração das ocorrências do Logix para os eventos Protheus. No entanto será necessário realizar uma verificação detalhadas de todos os códigos migrados, principalmente com relação ao código dos eventos (Logix) / Verbas (Protheus), pois no Logix existem regras de negócio que divergem do Protheus.

6.     Como fazer

            Os passos para viabilizar a Migração são:

• • Identificar no Logix quais são as Empresas/Filiais existentes no Protheus, através do LOG00083 – Cadastro de Empresas.

• • No Logix, executar o programa RHP10003 – Exporta Dados Folha de Pagamento, selecionando os itens que serão exportados e a pasta onde serão gerados os arquivos:
                

• • Caso ocorra alguma inconsistência ou alerta na Exportação, será apresentada mensagem de erro e um relatório com as inconsistências. Estas ocorrências devem ser corrigidas/observadas no Logix, e caso necessário, efetuar a exportação novamente:

• • Os arquivos com as informações que foram exportadas serão geradas na pasta informada no programa de exportação.

• • No Protheus, deve-se executar o programa RHIMP01, através do REMOTE PROTHEUS

• • Devem-se selecionar as opções que serão importadas e a pasta onde estão os arquivos que serão importados.

• • Atentar para a pasta onde estão os arquivos, se existe o arquivo valida_empresas_protheus.unl, exportado pelo Logix. Este arquivo irá validar as Empresas/Filiais Protheus que foram cadastradas no Logix, para considerar na importação de todos os arquivos.

• • Após realizar a importação, caso ocorra alguma inconsistência ou alerta, será mostrada mensagem e as correções ou alertas devem ser observados:

• • Finalizada a importação, as informações poderão ser visualizadas nos cadastros do sistema Protheus GPE.
    
    

7.     Erros Comuns

            Os possíveis erros poderão ser encontrados nos relatórios de inconsistências, que poderão ser tratados:

•      Sistema Logix:
  • ITEM EXPORTADO - Empresa Logix XX não está relacionada a uma Empresa/Filial Protheus. Os ITEM EXPORTADO desta empresa não foram exportados.
  • Nota: o campo grifado ITEM EXPORTADO pode corresponder a qualquer item que foi selecionado na exportação.

Problema:

Esta mensagem ocorrerá para todos os cadastros exportados do Logix, quando não houver a associação das Empresas Logix a alguma Empresa/Filial Protheus através do programa LOG00083 – Cadastros de Empresas Logix e houver registros nas tabelas que estão sendo exportadas nas empresas Logix.

Solução:

Deve ser associado através do cadastro de Empresas Logix, as Empresas/Filiais Protheus. Pode ocorrer também de não haver a necessidade de exportar essas informações, por ser dados muito antigos. Dessa forma, pode-se ignorar este erro.

8.     Check-list de Suporte da Aplicação

   Deve-se verificar no sistema operacional, se as pastas onde serão gravados os arquivos possuem permissões para acesso à leitura/gravação.

9.     Detalhamento Técnico das Migrações

9.1 Ocorrência Logix X Eventos Protheus

Neste item serão exportadas as informações compatíveis com as Ocorrências do Ponto Eletrônico Logix, que serão importados nos Eventos de Ponto Eletrônico Protheus - PON.

9.1.1 Pré-Requisitos

• Verificar no arquivo gerado pelo Logix, se há o código da filial. Caso tenha esta informação no arquivo, a tabela SP9 deverá ser definida como Exclusiva.
• Exportar o Cadastro de Eventos Logix que deverá ser importado como as Verbas Protheus.
• TODAS as ocorrências Logix migradas para os eventos Protheus deverão ser revisadas, para relacionar os identificadores fixos de Ponto do sistema Protheus. Esta informação não será migrada do Logix devido os códigos não serem semelhantes.

9.1.2 Restrições

• Nesta exportação não estão previstas as seguintes informações que são relacionadas às ocorrências Logix, devido não haver uma relação com o sistema Protheus:
  • Montagem de Bases de Cálculos
  • Condições de existências

• Antes de iniciar a importação, será avisado ao usuário sobre o tamanho do campo da tabela quando no Logix for superior ao do Protheus, dando a opção de cancelar ou continuar a execução:

             Descrição do Evento (P9_DESC): no Logix -> 30 posições e no Protheus, 20 posições 

• • Se a resposta for afirmativa, ou seja, prosseguir a importação, se a informação que vier no arquivo for superior ao que o campo suporte no Protheus, será truncada.
  • Se a resposta for negativa, acessar o Configurador do Protheus e alterar o tamanho do campo citado.

9.1.3 Atributos migrados

Abaixo se encontra as informações que serão integradas entre os dois sistemas:

Abaixo se encontram as regras para cada um dos campos que serão migrados:

9.1.4 Empresa

• A empresa Logix deverá ser associada a uma Empresa/Filial do Protheus, previamente cadastrada no programa LOG00083 – Cadastros de Empresas.
• No arquivo texto, será gerado o código da Empresa Protheus. O código da Filial poderá gerar ou não, conforme definição de Empresas/Tabelas. 

9.1.5 Código

• Gerar para o sistema Protheus o valor do atributo informado na tabela Logix. 

9.1.6 Descrição

• Será gerado para o sistema Protheus o valor do atributo informado na tabela Logix.

9.1.7 Código da Verba

• Será enviado para o Protheus o código do evento Logix
• Para os eventos que possuem a numeração até 899, deverá levar com o mesmo código existente no Logix
• Para os eventos que estão com uma codificação maior ou igual a 900, deverá levar com o código que foi gerado automaticamente, e armazenado na tabela de DE-PARA (VDP_DPARA_GERAL).
• Na importação no sistema Protheus, será verificado se a Verba que está sendo importada encontra-se na base dados, ou seja, se já foi importada pela rotina de importação de Verbas. Se a Verba não existir na tabela SRV, será emitida a seguinte mensagem no LOG de importação e não será realizada a inclusão do registro na tabela SP9:

             Evento: XX/XX/XXX - Verba não cadastrada no cadastro de Verbas (SRV).

• O Logix permite que, para uma ocorrência, sejam relacionados vários eventos, permitindo relacionar os eventos, além da ocorrência, por Categoria Salarial e Vínculo Empregatício.
• No Protheus existe o relacionamento do Evento diretamente com a Verba.
• Dessa forma, para enviar o código do evento, será verificado para a ocorrência que está sendo exportada o primeiro código de evento relacionada para a ocorrência, ordenando por Categoria e Vínculo.

              Exemplo: No Logix existe a seguinte ocorrência:

• E a esta ocorrência estão relacionadas às seguintes situações aos eventos:

• • Para o Protheus será exportado o evento cujo código é 204 – Atraso Horista.Para os casos em que ocorrer esta situação, será emitida a seguinte mensagem na exportação, alertando o usuário que determinado evento não foi exportado para a ocorrência:
    • Ocorrência - O evento XXX para a ocorrência YY|ZZZ não foi exportado devido já ter sido exportado um evento para essa ocorrência.

Nota:

• • • •  O valor XXX corresponde ao código do evento que não foi exportado
      • Os valores “YY|ZZZ” correspondem a empresa Logix e código da ocorrência.

9.1.8 Tipo de Código

• Será gerado para o Protheus o tipo de identificação da ocorrência Logix, conforme valores aceitos pelo Protheus
• Com base no Valor Logix, de acordo com a tabela abaixo, será enviado para o Protheus conforme o Valor Protheus, definido na tabela:

• No Logix, as ocorrências definidas para base de cálculo/especial não indicam se serão com referência a proventos ou descontos.
• Dessa forma, como default, as ocorrências Logix que tiverem estas situações, serão TODAS enviadas como 3 – BASE PROVENTO.

9.1. 9 Desconto do DSR

• Será gerado para o Protheus o valor atribuído ao campo Perda DSR? no sistema Logix.
• Os valores entre ambos os sistemas são iguais (S – Sim; N – Não).
• Caso o valor deste campo no Logix seja nulo, será exportado como Nulo no arquivo.

9.1.10 Tipo de Código

• Será gerado para o Protheus o Tipo de Identificação da Ocorrência Logix.
• Com base no Valor Logix, de acordo com a tabela abaixo, será enviado para o Protheus conforme o Valor Protheus, definido na tabela:

• Entre os códigos dos sistema só há compatibilidade nas informações referentes à Horas Extras e Faltas.
• Dessa forma, todos os demais valores informados no Logix serão enviados como ZZ – Outros.

9.1.11 Acumula Banco de Horas

• Será gerado para o Protheus a indicação se a Ocorrência Logix faz parte da regra de banco de horas.
• Para verificar se a ocorrência no Logix está vinculada ao banco de Horas, será feita a verificação através do programa RHU7104 – Ocorrências Banco de Horas. Caso a ocorrência que está sendo exportada está cadastrada neste programa, será indicado neste campo no arquivo texto o valor S – Sim.
• Caso contrário, será exportado no valor como N – Não. 

9.1.12 Definição do arquivo de texto

• A carga das informações geradas do Logix para o Protheus será através de arquivo texto, com os campos separado por pipe (|).
• O arquivo será gerado com o nome: ocorrencias_logix.unl
• A ordem dos campos em cada registro será:
  • Empresa Protheus
  • Filial Protheus
  • Código do Evento
  • Descrição do Evento
  • Código da Verba
  • Tipo de código do Evento
  • Desconta DSR
  • Tipo de informação da ocorrência
  • Compõe Banco de Horas

9.1.13 Exportando as Informações

• Essa rotina exportará os dados da tabela de Ocorrências do Logix, cuja registros encontram-se ativos. A partir desta tabela, serão verificadas as tabelas OCOR_PTO_EVENTO e OCORRENCIAS_BH, verificando demais informações necessárias no arquivo texto que será exportado.
• O cadastro de Ocorrências segue o conceito de Empresa\Tabela, em que é possível realizar todo o cadastro das ocorrências em uma única empresa e as demais empresas utilizarão este mesmo cadastro.
• Dessa forma, a exportação das informações para o Protheus, seguirá a seguinte regra:
• Exportação da tabela de Ocorrências como Exclusivo: Quando houver uma Empresa/tabela diferente para o grupo de empresas do Protheus, será exportado o código da Filial Protheus, mantendo desta forma o cadastro de Eventos como exclusivo. Abaixo consta exemplo do cadastramento das informações: 

   No relacionamento entre Empresa Logix X Empresa/Tabela Logix e Empresa Logix X Empresa/Filial Protheus está da seguinte forma :                                                                                        

  O Logix possui as seguintes ocorrências cadastradas:                                                  

   Onde as ocorrências das Empresas Logix 01 e 02 serão cadastrados sempre na Empresa 01, e as ocorrências cadastradas na empresa 03 irão apontar sempre para empresa 03.

             Seguindo esta regra, as ocorrências que estão cadastradas na Empresa Logix 01, devem ser exportados para a Empresa Protheus/Filial Protheus 99/01 e

        99/02. E as ocorrências que estão definidas na Empresa Logix 03, devem ser exportadas para a Empresa Protheus/Filial Protheus 99/03. Sendo assim, o

        código da Filial no arquivo texto será sempre preenchido.

             Na exportação das Ocorrências no arquivo texto, ficará da seguinte forma:

            Sendo assim, há a necessidade de duplicação das ocorrências 100 e 110 para as empresas/filiais Protheus 99/01 e 99/02.

• •  Exportação da tabela de Ocorrências como Compartilhado: Quando houver uma Empresa/tabela igual para o grupo de empresas do Protheus, não será exportado o código da Filial Protheus, mantendo desta forma o cadastro de Eventos como compartilhado. Abaixo está um exemplo de cadastramento das informações:

             No relacionamento entre Empresa Logix X Empresa/Tabela Logix e Empresa Logix X Empresa/Filial Protheus está da seguinte forma:  

      O Logix possui as seguintes ocorrências cadastradas:  

    Onde as ocorrências das Empresas Logix 01, 02 e 03 serão sempre cadastradas na Empresa 01.

              Seguindo esta regra, as ocorrências que estão cadastradas na Empresa Logix 01, devem ser exportadas para a Empresa Protheus 99 . Sendo assim, o código

         da Filial no arquivo texto não será preenchido. 

              Na exportação da Ocorrência no arquivo texto, ficará da seguinte forma:  

9.1.14 Importando as Informações

• Logo após a importação pelo Protheus, será renomeado como XX_XX_XXXX_ocorrencias_logix.unl, indicando a data de importação do arquivo.

• Se houver necessidade de importar novamente o arquivo, deverá seguir um dos seguintes procedimentos:

• • Renomear o arquivo para ocorrencias_logix.unl, retirando a data do nome do arquivo ou

• • Gerar novamente o arquivo do sistema Logix.

• A importação das Ocorrências Logix irá popular a tabela SP9 - Eventos, onde a mesma deverá ser configurada conforme a definição da regra Empresa/Tabela definida no  Logix. 
• A inclusão/modificação dos registros respeitará a utilização do cadastro de Eventos (PONA100).
• Será verificado se o registro que está sendo importado já existe na tabela SP9, através da chave P9_FILIAL+P9_CODIGO. Caso exista, serão somente modificados os atributos que não compõe a chave da tabela. Se não existir o registro, será realizada uma inclusão.
• Na inclusão dos demais campos existentes na tabela e que não vierem no arquivo, assumirá o valor default do arquivo SX3, campo X3_RELACAO.

9.2 Relógio Logix X Protheus

Neste item será responsável pela a exportação das informações cadastrais do Relógio Ponto Logix, onde essas informações por sua vez serão importadas nos cadastros de Relógios/Modelos/Arquivos Ponto do Protheus - PON (Ponto).

9.2.1 Requisitos

• No Protheus, deve-se definir a tabela SP0 como exclusiva, pois no Logix esta tabela é sempre por Empresa.
• Definir um DE-PARA de códigos no Logix, caso o código do relógio Logix contenha mais de 3 posições. O DE-PARA deve ser definido através do programa VDP10141 – DE\PARA GERAL LOGIX. O valor do código do relógio a ser enviado para o Protheus obrigatoriamente deve ser definido com até 3 posições.
• Antes de iniciar a importação, será avisado ao usuário sobre o tamanho do campo da tabela quando no Logix for superior ao do Protheus, dando a opção de cancelar ou continuar a execução:

         Descrição do Relógio (P0_DESC): no Logix -> 30 posições e no Protheus, 15 posições

              Nome do Arquivo de Importação do Relógio (P0_ARQUIVO): no Logix -> 50 posições e no Protheus, 40 posições

• • Se a resposta for afirmativa, ou seja, prosseguir a importação, se a informação que vier no arquivo for superior ao que o campo suporte no Protheus, será truncada.
  • Se a resposta for negativa, acessar o Configurador do Protheus e alterar o tamanho dos campos citados.
    

9.2.2 Atributos migrados

Abaixo se encontra as informações que serão integradas entre os dois sistemas:             

Abaixo encontram-se as regras para cada um dos campos que serão migrados:

9.2.3 Empresa

• A empresa Logix deverá ser associada a uma Empresa/Filial do Protheus, previamente cadastrada no programa LOG00083 – Cadastros de Empresas
• No arquivo texto, sempre será gerado o código da Empresa Protheus e o código da Filial, pois esta tabela sempre será definida como exclusiva.

9.2.4 Código do Relógio

• Será gerado para o sistema Protheus o valor do atributo informado na tabela Logix
• No Logix, o tamanho do código do Relógio poderá conter até 5 caracteres. No Protheus, o tamanho do código do relógio é restrito a 3 posições.
• Será necessário prever um DE-PARA manual dos códigos do Logix para o Protheus, quando o código do relógio Logix tiver mais de 3 posições, informando o código que será gerado para o Protheus, com 3 posições.
• O programa que será utilizado para definição do DE-PARA será o VDP10141 – DE/PARA GERAL LOGIX.
   

     Onde o usuário irá informar os códigos de :

• • Tabela: LOCAL_REL_ELETR 
  • Sistema Integração: PROTHEUS
  • Campos DE:
    • Para cada registro de Relógios existente no Logix, informar o campo cod_empresa e o Valor da Empresa, o campo num_relogio e o valor do Relógio, como acima
  • Campos Para:
    • Deverá informar o código do Relógio que será convertido
  • Para os casos em que não seja definido o DE-PARA e o código do relógio for superior a 3 posições, o registro não deverá ser exportado e deverá gerar a seguinte mensagem de LOG de erros ao final do Processo:
    • “Relógio XX/XX não exportado. O código para o Protheus deve ser limitado a 3 posições. Criar DE-PARA (VDP10141).”

9.2.5 Descrição

• Será gerado para o sistema Protheus o valor do atributo informado na tabela Logix.

9.2.6 Tipo de Controle do Relógio

• Será gerado para o Protheus a função do relógio Logix, conforme valores aceitos pelo Protheus
• Com base no Valor Logix, de acordo com a tabela abaixo, será enviado para o Protheus conforme o Valor Protheus, definido na tabela:

• No Logix, existe a função AFD, que permite a importação de arquivos que foram gerados pelos REPs (Relógios Eletrônico de Ponto) neste formato. No Protheus não há esta indicação. Os relógios com este formato são definidos como P. Dessa forma, será exportada como controle P – Ponto para o Protheus.

9.2.7 Caminho do Arquivo

• Será gerado para o Protheus o valor do nome do arquivo que é importado no Logix. No Logix, esta informação está associada à tabela ARQ_BAT_REL, cadastrado no programa RHU1920 – Relógios – Arquivos em Meio Magnético. Portanto dessa forma, será associado com a tabela de relógios (LOCAL_REL_ELETR), cadastrado no programa RHU5300 – Relógios Coletores.
• Para enviar ao Protheus, será utilizado o caminho do arquivo acrescentando a extensão.
• Caso o valor deste campo no Logix seja nulo, será exportado como Nulo no arquivo.
  
  

9.2.8 REP

• Será gerado para o Protheus o código do REP, associado ao relógio do Logix.
• Se este campo vier preenchido no arquivo, será atribuído no Protheus, ao valor do campo P0_INC o valor 1 – SIM, pois indica que o arquivo que será importado é incremental, ou seja, sempre será complementado o mesmo arquivo com marcações novas.

9.2.9 Posição Inicial Crachá

• Será gerado para o Protheus o valor da posição inicial do crachá do funcionário no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos, Nome do Campo = ‘NUM_MATRICULA’. Caso haja o preenchimento do valor Nome do Campo = ‘PIS’, a posição inicial deste prevalecerá sobre o ‘NUM_MATRICULA’.

9.2.10 Posição Final Crachá

• Será gerado para o Protheus o valor da posição final do crachá do funcionário no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos, Nome do Campo = ‘NUM_MATRICULA’. Caso haja o preenchimento do valor Nome do Campo = ‘PIS’, a posição final deste prevalecerá sobre o ‘NUM_MATRICULA’.

9.2.11 Posição Inicial do Número do Relógio

• Será gerado para o Protheus o valor da posição inicial do número do relógio no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘COD_RELOGIO’.

9.2.12 Posição Final do Número do Relógio

• Será gerado para o Protheus o valor da posição final do número do relógio no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘COD_RELOGIO’.
  
  

9.2.13 Posição Inicial do Dia

• Será gerado para o Protheus o valor da posição inicial do dia do arquivo de ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘DIA’.

9.2.14 Posição Final do Dia

• Será gerado para o Protheus o valor da posição final do dia no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘DIA’.

9.2.15 Posição Inicial do Mês

• Será gerado para o Protheus o valor da posição inicial do mês no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘MES’.

9.2.16 Posição Final do Mês

• Será gerado para o Protheus o valor da posição final do mês no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘MES’.

9.2.17 Posição Inicial do Ano

• Será gerado para o Protheus o valor da posição inicial do ano no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘ANO’.

9.2.18 Posição Final do Ano

• Será gerado para o Protheus o valor da posição final do ano no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘ANO’.

9.2.19 Posição Inicial da Hora

• Será gerado para o Protheus o valor da posição inicial da hora no arquivo de importação do ponto que é utilizado no Logix No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘HORA’.

9.2.20 Posição Final da Hora

• Será gerado para o Protheus o valor da posição final da hora no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘HORA’.
  

9.2.21 Posição Inicial do Minuto

• Será gerado para o Protheus o valor da posição inicial do minuto no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘MINUTO’.

9.2.22 Posição Final do Minuto

• Será gerado para o Protheus o valor da posição final do minuto no arquivo de importação do ponto que é utilizado no Logix No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘MINUTO’.
  

9.2.23 Posição Inicial da Função

• Será gerado para o Protheus o valor da posição inicial da função no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘COD_FUNCAO’.

9.2.24 Posição Final da Função

• Será gerado para o Protheus o valor da posição final da função no arquivo de importação do ponto que é utilizado no Logix. No Logix, esta informação está cadastrada no programa RHU5530 – Modelos de Relógios Eletrônicos Nome do Campo = ‘COD_FUNCAO’

9.2.25 Definição do arquivo de texto

• A carga das informações geradas do Logix para o Protheus será através de arquivo texto, com os campos separados por pipe (|).
• O arquivo será gerado com o nome: relógio_logix.unl.
• A ordem dos campos em cada registro será:

• • Empresa Protheus
  • Filial Protheus
  • Código do Relógio
  • Descrição do Relógio
  • Tipo de Controle
  • Caminho/Nome do arquivo
  • REP
  • Posição inicial do Crachá no arquivo texto
  • Posição final do Crachá no arquivo texto
  • Posição inicial do Número do relógio no arquivo texto
  • Posição final do Número do relógio no arquivo texto
  • Posição inicial do Dia no arquivo texto
  • Posição final do Dia no arquivo texto
  • Posição inicial do Mês no arquivo texto
  • Posição final do Mês no arquivo texto
  • Posição inicial do Ano no arquivo texto
  • Posição final do Ano no arquivo texto
  • Posição inicial da Hora no arquivo texto
  • Posição final da Hora no arquivo texto
  • Posição inicial do Minuto no arquivo texto
  • Posição final do Minuto no arquivo texto
  • Posição inicial da Função no arquivo texto
  • Posição final da Função no arquivo texto

9.2.26 Exportando as Informações

• As informações que irá compor o arquivo serão encontradas no programa RHU5530 – Modelos de Relógios Eletrônicos; RHU5300 – Relógios Coletores; RHU1920 – Relógios Arquivo em Meio Magnético
• A tabela LOCAL_REL_ELETR possui os registros dos cadastros dos relógios do Logix, e partir dela, serão relacionadas às tabelas que possuem as informações das posições das informações no o arquivo texto (MODELO_REL_ELETR/CFG_BAT_REL) e a tabela que possui o caminho do arquivo (ARQ_BAT_REL).
• A tabela de Relógios é sempre definida por empresa. Dessa forma, quando houver a exportação das informações para o Protheus, deverá exportar sempre a Empresa Protheus e Filial Protheus.
• A exportação do registro do relógio somente ocorrerá se houver o caminho do arquivo, relacionado à tabela ARQ_BAT_REL, sendo que este é um campo obrigatório no Protheus. Para os casos em que houver o cadastro da tabela LOCAL_REL_ELETR mas não houver o cadastro na tabela ARQ_BAT_REL será emitida a seguinte mensagem de erro e não será exportado o arquivo:
• Relógio XX/XXXX não exportado. Não há referência ao caminho do arquivo, no programa RHU1920.

9.2.27 Importando as Informações

• Logo após a importação pelo Protheus, será renomeado como XX_XX_XXXX_relogio_logix.unl, indicando a data de importação do arquivo.

• Se houver necessidade de importar novamente o arquivo, deverá seguir um dos seguintes procedimentos:

• • Renomear o arquivo para relogio_logix.unl, retirando a data do nome do arquivo ou

• • Gerar novamente o arquivo do sistema Logix.

•  As informações serão importadas na tabela SP0, onde a mesma deverá ser configurada como exclusiva, devido a tabela de Relógios no Logix sempre ser definida por empresa.
• A inclusão/modificação dos registros deverá respeitar a utilização do cadastro de Relógios (PONA030).
• Será verificado se o registro que está sendo importado já existe na tabela SP0, através da chave P0_FILIAL+P0_RELOGIO. Caso exista, serão somente modificados os atributos que não compõe a chave da tabela. Se não existir o registro, será realizada uma inclusão.
• Na inclusão dos demais campos existentes na tabela e que não vierem no arquivo, será assumido o valor default do arquivo SX3, campo X3_RELACAO
• O atributo p0_tipoarq será sempre iniciado com o valor T, pois os arquivos no Logix sempre são no padrão ASCII.
• O atributo p0_inc será atribuído 1 – Sim , caso o campo p0_rep for preenchido pelo Logix. Caso não haja preenchimento do código do REP, o campo p0_inc será atribuído 2 – Não.
  
  

9.3 Crachá Provisório Logix X Protheus

Este item trata da exportação das informações cadastrais dos crachás provisórios do Logix, onde essas informações serão importadas no cadastro de crachás provisórios do Ponto do Protheus - PON (Ponto).

9.3.1 Pré-Requisitos

Exportar o Cadastro de Funcionários Logix para o Protheus. Caso haja códigos de matrículas no Logix com tamanho superior a 6 posições será previsto DE/PARA de códigos automaticamente, gerando a codificação sequencial.

9.3.2 Atributos migrados

Abaixo encontra-se as informações que serão integradas entre os dois sistemas:

No Logix existem duas tabelas que armazenam as informações de crachás provisórios. Dessa forma, será feita a leitura em ambas as tabelas, dos crachás provisórios que estão em aberto e será enviado para o Protheus para

uma tabela somente, SPE:                    

Abaixo encontram-se as regras para cada um dos campos que serão migrados:

9.3.3 Empresa

• • A empresa Logix deverá ser associada a uma Empresa/Filial do Protheus, previamente cadastrada no programa LOG00083 – Cadastros de Empresas.
  • No arquivo texto, sempre será gerado o código da Empresa Protheus e o código da Filial, pois esta tabela sempre será definida como exclusiva.

9.3.4 Número do Crachá

• • Será gerado para o Protheus o número do crachá provisório do funcionário Logix
  • Os crachás cadastrados através do programa RHU6615 – Crachá Provisório Funcionário, tabela cracha_funcionário, serão migrados conforme o cadastro.
  • Os crachás que são cadastrados no Logix através do programa RHU4505 – Relacionar o número do crachá com o número da matrícula, gravados na tabela rhu_crch_funcio, pode conter até 15 caracteres numéricos. No Protheus, o campo do crachá provisório é composto por até 10 posições.
  • Dessa forma, caso haja códigos de crachás com valores superiores a 10 posições e que estão em aberto, data de validade maior que a data atual ou nula) não será permitida a exportação, sendo emitida a mensagem abaixo, caso não haja de/para de códigos: 
    

• • • Crachá Provisório XX/XXXXXXXX/XXXXXXXXXXXXXXX/99-99-9999: Crachá (RHU4505) não suportado no Protheus. Prever novo código no VDP10141

       Nota: o valor XX/XXXXXXXX/XXXXXXXXXXXXXXX/99-99-9999 representa a Empresa Logix/Matrícula do Funcionário/Número do

           Crachá Provisório/Data de Validade Inicial do RHU4505.

• • O Cadastro do DE/PARA deverá ser previsto através do VDP10141, conforme abaixo:         

Onde o usuário irá informar os códigos:

• • • Tabela: RHU_CRACH_FUNCIO
    • Sistema Integração: PROTHEUS
    • Campos DE:

• • • • empresa e o valor da Empresa do Funcionário.
      • matricula e o número da Matrícula do Funcionário.
      • dat_valid_inicial e a data de Validade Inicial do Crachá.

• • • Campos Para:

• • • • Deverá ser informado o código do crachá que será gerado para o Protheus.

• • O processo irá converter o crachá, com base nas informações cadastradas no DE/PARA para o novo código de crachá que o Protheus possa receber.

9.3.5 Matrícula

• • O código da matrícula do funcionário no Logix pode conter até 8 caracteres numéricos.
  • No Protheus, o código da matrícula é limitado a 6 posições Numéricas.
  • Caso ocorra esta situação, onde não será possível levar o código da Matrícula do Funcionário para o Protheus, devido a restrição de tamanho os códigos serão gerados sequencialmente.
  • Esta codificação será gerada quando houver a exportação do Cadastro de Funcionários do Logix para o Protheus. Portanto a exportação deste cadastro é pré-requisito para exportar os crachás em aberto dos funcionários.
  • Se houver na empresa que está sendo exportado algum código de matrícula superior a 6 posições, será buscado na tabela VDP_DPARA_GERAL, se existe uma relação de TODAS as matrículas Logix para ser levado a nova matrícula para o Protheus.
  • Se o código da matrícula do funcionário for superior a 6 dígitos e não houver nenhuma relação no cadastro de DE-PARA, será gerada a mensagem abaixo e não irá exportar o registro para o Protheus.

• • • Crachá Provisório: Funcionário XX/XXXXXXXX - Não foi gerado para o Protheus. Exportar o Cad. de Funcionários para gerar a matrícula.

• • Por default no Protheus, todas as matrículas são previstas com 0 (zeros) à esquerda. Desta forma, todas as matrículas geradas, independente de ser previsto o número sequencial ou não, serão preenchidas com 0, até completar 6 posições.

       Importante: Não será necessário prever o DE/PARA dos códigos para estes casos, onde o código da matrícula no Logix for inferior a 6 dígitos, pois no Logix este código

                                  será sempre numérico, não influenciando o 0 (zero) à esquerda.

• • Na importação no sistema Protheus, será verificado se a matrícula que está sendo importada encontra-se na base dados, ou seja, se já foi importada pela rotina de importação de funcionários. Se o funcionário não existir na tabela SRA, será emitida a seguinte mensagem no LOG de importação:

• • • Crachá Provisório: XX/XX/XXXXXX – Funcionário não encontrado. Registros de Crachá Provisório não foram importados.

9.3.6 Data de Validade Inicial

• • Gerar para o sistema Protheus o valor do atributo informado na tabela Logix.

9.3.7 Data de Validade Final

• • Gerar para o Protheus a data de validade final do crachá provisórios.
  • Para os casos em que a data final do crachá seja nula, será atribuído o valor 31/12/2100.

9.3.8 Definição do arquivo de texto

• • A carga das informações geradas do Logix para o Protheus será através de arquivo texto, com os campos separado por pipe (|).
  • O arquivo será gerado com o nome: cracha_provisorio_logix.unl
  • A ordem dos campos em cada registro será:
    

• • • Empresa Protheus
    • Filial Protheus
    • Número do Crachá Provisório
    • Número da Matrícula do funcionário
    • Data de início de validade do crachá
    • Data de validade final do crachá

9.3.9 Exportando as Informações

• • As informações que serão exportadas referem-se aos programas RHU6615 – Crachá Provisório Funcionário e RHU4505 – Relacionar o número do crachá com o número da matrícula
  • O processo irá ler as duas tabelas, RHU_CRCH_FUNCIO/CRACHA_FUNCIONARIO, para os crachás que estão com data de validade em aberto. Os registros serão gerados no arquivo primeiramente da tabela RHU_CRCH_FUNCIO e logo em seguida da tabela CRACHA_FUNCIONARIO.

9.3.10 Importando as Informações

• • A inclusão/exclusão dos registros irá respeitar a utilização do cadastro de Crachás Provisórios (PONA120)
  • Quando for realizar a inclusão na tabela SPEXX0 (onde o XX corresponde ao código da empresa) deverá excluir todos os registros que referem-se aos crachás e importar todos os que vierem no arquivo.
  • Após a leitura do arquivo, será renomeado para xx-xx-xxxx_cracha_provisorio_logix.unl, que irá indicar qual foi a data de importação do arquivo.

9.4 Horário Padrão Logix X Protheus

Esse item será responsável por permitir a importação dos horários de trabalho dos funcionários do Logix, no sistema Protheus.

9.4.1 Pré-Requisitos

• • Verificar no arquivo gerado pelo Logix, se há o código da filial. Caso tenha esta informação no arquivo, a tabela SPJ deverá ser definida como Exclusiva.
  • Na importação no sistema Protheus não está previsto o conceito de Gestão de Corporativa. Dessa forma, deve-se utilizar somente o conceito de Empresa/Filial.

9.4.2 Atributos Migrados

9.4.3 Empresa Logix X Empresa/Filial Protheus

• • A empresa Logix deverá ser associada a uma Empresa/Filial do Protheus, previamente cadastrada no programa LOG00083 – Cadastros de Empresas, conforme especificado nos Pré-Requisitos desta especificação.
  • No arquivo texto, será gerado o código da Empresa Protheus. O código da Filial poderá gerar ou não, conforme definição de Empresas/Escala. No item 5 deste documento, está especificado a regra para geração ou não do código da Filial.

9.4.4 Escala ESCALA_HORARIOS.cod_escala (Logix) èSPJXX0.pj_turno (Protheus)

• • Enviar para o sistema Protheus o código da Escala do sistema Logix
  • Este código já foi migrado previamente através da opção do Migrador Escala
  • Deverá formatar o código com 3 posições, preenchendo zeros a esquerda

9.4.5 Dia da Semana (Logix) èSPJXX0.pj_dia (Protheus)

• • De acordo com a data base da Escala Logix (escala. dat_base_escala) deverá verificar qual o dia da semana que se enquadra através da função WEEKDAY(escala. dat_base_escala)
  • Será enviada as informações da seguinte forma:                     

9.4.6 Semana (Logix) é SPJXX0.pj_semana (Protheus)

• • Será enviado ao Protheus o ciclo da escala de trabalho que foi montado pelo usuário.
  • No Logix, basta definir um ciclo que o sistema sempre considera a repetição automaticamente, sem a necessidade de definições de como será repetido este ciclo.
  • No Protheus, há a necessidade de cadastrar todos os ciclos que o horário de trabalho deverá compor.
  • Desta forma, será enviado para o Protheus a sequencia, dos horários para cada semana trabalhada, até onde o mesmo ciclo começará a se repetir.
  • Sempre será considerado o início da escala de trabalho como sendo uma SEGUNDA-FEIRA, pois no Protheus sempre é definido como o início da semana este dia, na escala de trabalho.
  • Exemplo (1):

• • • No Logix existe a definição da seguinte escala de trabalho:

• • • Esta escala representa 5 dias trabalhado e um dia de folga. Neste caso, ela seguirá um ciclo cujo o próximo horário trabalhado cairá em um DOMINGO, ao invés da SEGUNDA, não completando a semana de 7 dias
    • Desta forma, para o Protheus será exportado na seguinte forma:

• • • •    O ciclo começara a se repetir a partir do dia 14/10. Desta forma, será enviado 6 semanas, ou seja, até uma semana antes do início da repetição do ciclos. 
  • Exemplo (2):
    • No Logix existe a definição da seguinte escala de trabalho:

• • • Esta escala representa um ciclo de 7 dias onde sempre se repetirá este mesmo ciclo, com os mesmo horários nos mesmos dias da semana, conforme abaixo:

• • • Dessa forma será enviado sempre uma única semana para o Protheus, pois representará que esta mesma semana será sempre a mesma, quando o ciclo se repetir.

9.4.7 Tipo de Horário HORARIO_COMPL.tip_horarios (Logix) èSPJXX0.pj_tpdia (Protheus)

• • • Converter para o Protheus conforme os tipos de horários disponibilizados nos horários Logix.     

9.4.8 Horário de Início do Expediente horarios.hor_ini_expediente (Logix) èSPJXX0.pj_entra1 (Protheus)

• • • Enviar o horário de início do expediente.
    • Enviar no formato 00:00.

9.4.9 Horário de Início do Intervalo horarios.hor_ini_intervalo (Logix) èSPJXX0.pj_saida1 (Protheus)

• • • Enviar o horário de início do intervalo.
    • Enviar no formato 00:00.

9.4.10 Horário de Fim do Intervalo horarios.hor_fim_intervalo (Logix) èSPJXX0.pj_entra2 (Protheus)

• • • Enviar o horário de fim do intervalo.
    • Enviar no formato 00:00.

9.4.11 Horário de Fim do Expediente horarios.hor_fim_expediente (Logix) èSPJXX0.pj_entra3 (Protheus)

• • • Enviar o horário de início do expediente.
    • Enviar no formato 00:00.

9.4.12 Definição do arquivo texto:

• • •  A carga das informações geradas do Logix para o Protheus, será através de arquivo texto, com os campos separado por pipe (|). O arquivo será gerado com o nome: horarios_logix.unl
    • A ordem dos campos em cada registro será:

• • • • Empresa Protheus
      • Filial Protheus
      • Escala
      • Dia da Semana
      • Semana
      • Tipo de Horário
      • Horário de Início do Expediente
      • Horário de Início do Intervalo
      • Horário de Fim do Intervalo
      • Horário de Fim do Expediente

9.4.13 Exportando as Informações: Sistema Logix

• • • A partir da opção Horários, conforme Protótipo de Tela 01, definida no programa exportador Logix RHP10003 – Exporta dados Folha de Pagamento, deverá ser chamada a função RHP1000321, que irá realizar todo o processamento para exportar as informações de Horários do Logix.
    • Os horários de trabalho estão inseridos nas escalas de trabalho do funcionário, previamente enviadas através da opção Escalas do programa exportador. Esta opção é tida como pré-requisito para permitir a importação dos horários no Protheus.

• • • No Logix, é realizado o cadastramento dos horários através do programa RHU0180 – Horários de Trabalho conforme abaixo:

• • • E as escalas de trabalho, onde constam os horários, é definido através do programa RHU1060 – Escalas de Trabalho.

• • • Sempre quando houver a seleção opção Horários, deverá exportar todos os horários que compõe a escala de trabalho.
    • Deverá ser enviado todas as semanas em que a escala de trabalho não irá se repetir, possibilitando que no Protheus seja identificado todas as semanas possíveis da escala.
    • Para cada ciclo, será incrementado com um código da semana (01, 02, 03, etc..).
    • Para a montagem das semanas, será sempre iniciado a data base da escala como sendo a data uma segunda-feira. A data do mês poderá ser 01/02/2001 – Segunda-Feira.
    • A lógica par a montagem do ciclo poderá ser utilizada a função de listagem de  escalas, do RHU1060, utilizando como data fim 25/02/2001.
    • O cadastro de Escala/Horários segue o conceito de Empresa\Escala, em que é possível realizar todo o cadastro das Escalas de Trabalho em uma única empresa e as demais empresas utilizarão este mesmo cadastro.  Segue o mesmo conceito de Empresa\Tabela, mas há um outro campo, Empresa acesso tabela “escala”, que está definido no RHU3330 – Parâmetros de Empresas RHU, conforme indicação abaixo:

• • • Dessa forma, a exportação das informações para o Protheus, seguirá a seguinte regra:

                                                     I.          Exportação da tabela de Escalas/Horários como Exclusivo: Quando houver uma Empresa/Escala diferente para o grupo de empresas do

                                                                 Protheus, será exportado o código da Filial Protheus, mantendo desta forma o cadastro de Turno/Horários como exclusivo. Abaixo consta

                                                                 exemplo do cadastramento das informações: 

                                                     No relacionamento entre Empresa Logix X Empresa/Escala Logix e Empresa Logix X Empresa/Filial Protheus está da seguinte forma :    

O Logix possui as seguintes escalas cadastradas : 

Onde as Escalas das Empresas Logix 01 e 02 serão cadastrados sempre na Empresa 01, e as escalas cadastradas na empresa 03 irão apontar sempre para empresa 03.

 Seguindo esta regra, as escalas que estão cadastrados na Empresa Logix 01, devem ser exportados para a Empresa Protheus/Filial Protheus 99/01 e 99/02. E as escalas que estão definidas na Empresa

Logix 03, devem ser exportados para a Empresa Protheus/Filial Protheus 99/03. Sendo assim, o código da Filial no arquivo texto será sempre preenchido.

                                        Na exportação da Escala no arquivo texto, ficará da seguinte forma:        

Sendo assim, há a necessidade de duplicação das escalas 100 e 110 para as empresas/filiais Protheus 99/01 e 99/02.

                                                            II.          Exportação da tabela de Escalas/Horários como Compartilhado: Quando houver uma Empresa/tabela igual para o grupo de empresas do

                                                                         Protheus, não será exportado o código da Filial Protheus, mantendo desta forma o cadastro de Turno/Horários como compartilhado. Abaixo

                                                                         está um exemplo de cadastramento das informações:

                                                            No relacionamento entre Empresa Logix X Empresa/Escala Logix e Empresa Logix X Empresa/Filial Protheus está da seguinte forma:            

O Logix possui as seguintes escalas cadastradas: 

Onde as escalas das Empresas Logix 01, 02 e 03 serão sempre cadastradas na Empresa 01.

 Seguindo esta regra, as escalas que estão cadastradas na Empresa Logix 01, devem ser exportadas para a Empresa Protheus 99 . Sendo assim, o código da Filial no arquivo texto não será preenchido. 

 Na exportação da Escala no arquivo texto, ficará da seguinte forma:  

• • • • Para a verificação da empresa/filial Protheus, deve-se verificar, a partir da empresa Logix, o registro definido na tabela LOG_EMP_FILIAL_LOGIX_PROTHEUS, nos atributos: EMPRESA_PROTHEUS e FILIAL_PROTHEUS
      • O valor do campo EMPRESA/ESCALA, deve ser verificado a partir da função rhu0010_cod_empr_escala(p_cod_empresa)
      • Caso haja escalas em que não foram relacionadas as suas Empresas uma Empresa/filiais Protheus através da tabela LOG_EMP_FILIAL_LOGIX_PROTHEUS, deverá ser dada mensagem de alerta ao final do processo indicando esta inconsistência:
        • Escala/Horários - Empresa Logix XX não foi associada a uma Empresa/Filial Protheus. As escalas/Horários desta empresa não foram exportadas.

9.4.14 Importando as Informações: Sistema Protheus

• • • A importação deverá prever a inclusão na tabela SPJXX0.
    • A partir da opção Horário, conforme Protótipo de Tela 02, definida no programa importador Protheus RHIMP01 – Importa dados Folha de Pagamento, deverá ser chamada a função RHIMP17, que irá realizar todo o processamento para importar as informações de Horários Logix para Horário Padrão Protheus.
    • O compartilhamento da tabela SPJ deverá ser configurada conforme a definição da regra Empresa/Escala definida no  Logix. 
    • A inclusão/modificação dos registros deve verificar se o registro que está sendo importado já existe na tabela SPJ, através da chave PJ_FILIAL + PJ_TURNO + PJ_SEMANA + PJ_DIA. Caso exista, deverá somente modificar os atributos que não compõe a chave da tabela. Se não existir o registro, deverá realizar uma inclusão.
    • Na inclusão dos demais campos existentes na tabela e que não vierem no arquivo, deverá assumir o valor default do arquivo SX3, campo X3_RELACAO
    • Após a leitura do arquivo, deverá ser renomeado para xx-xx-xxxx_horarios_logix.unl, que irá indicar qual foi a data de importação do arquivo. Se houver a necessidade de importar novamente o arquivo, deverá seguir o um dos seguintes procedimentos:
    • Renomear o arquivo para horarios_logix.unl, retirando a data do nome do arquivo ou
    • Gerar novamente o arquivo do sistema Logix.

9.5 Banco de Horas Logix X Protheus

Neste item será responsável pela a exportação das informações do banco de horas em aberto no Logix, onde essas informações por sua vez serão importadas no cadastro de banco de horas do Protheus - PON (Ponto).

9.5.1 Pré-Requisitos

• • Exportar o Cadastro de Funcionários Logix para o Protheus. Caso haja códigos de matrículas no Logix com tamanho superior a 6 posições, os códigos serão gerados seqüencialmente.
  • Exportar o Cadastro de Eventos Logix que deverá ser importado como as Verbas Protheus.
  • Exportar o Cadastro de Ocorrências Logix que deverá ser importado como os Eventos Protheus.
  • As horas de banco de horas serão geradas para o Protheus acrescidas do seu índice de valorização, conforme os registros cadastrados no Movimento de Banco de Horas (MOVTO_BH) Logix. Por Exemplo: Caso o funcionário tenha 2 horas no banco de Horas, estas já estão valorizadas. Podem estar como 2 horas Reais de Banco de Horas (o índice de valorização no Logix é igual a 1) ou era 1 hora de banco e foi valorizada com o índice 2, ou seja, 100%.
  • O Logix enviará os códigos dos Eventos (Logix) do movimento de Banco de Horas, que estão relacionados à Ocorrência (Logix) de Banco de Horas, devido esta informação estar aberta por Eventos (Logix). Será necessário prever o cadastramento no Protheus dos Eventos (Protheus) e relacionar às Verbas (Protheus), que estão vindo no arquivo, pois para gravar o Evento (Protheus) na tabela de Movimentação de banco de horas do Protheus, será verificado na tabela SP9, qual o evento relacionado à Verba. Importante observar que uma verba não poderá estar cadastrada em mais de um evento. 

9.5.2 Atributos migrados

Abaixo encontram-se as informações que serão integradas entre os dois sistemas:

Abaixo encontram-se as regras para cada um dos campos que serão migrados:

9.5.3 Empresa

• • A empresa Logix deverá ser associada a uma Empresa/Filial do Protheus, previamente cadastrada no programa LOG00083 – Cadastros de Empresas.
  • No arquivo texto, sempre será gerado o código da Empresa Protheus e o código da Filial, pois esta tabela sempre será definida como exclusiva.

9.5.4 Matrícula

• • O código da matrícula do funcionário no Logix pode conter até 8 caracteres numéricos
  • No Protheus, o código da matrícula é limitado a 6 posições numéricas
  • Caso ocorra esta situação, onde não será possível levar o código da Matrícula do Funcionário para o Protheus, devido à restrição de tamanho, as matrículas serão geradas seqüencialmente para serem exportadas no Protheus.
  • Esta codificação será gerada quando houver a exportação do Cadastro de Funcionários do Logix para o Protheus. Portanto a exportação deste cadastro é pré-requisito para exportar os históricos de Banco de Horas dos funcionários.
  • Se o código da matrícula for superior a 6 posições, deverá buscar na tabela VDP_DPARA_GERAL, se existe uma relação da matrícula Logix para ser levada a nova matrícula para o Protheus
  • Se o código da matrícula do funcionário for superior a 6 dígitos e não houver nenhuma relação no cadastro de DE-PARA será gerada a mensagem abaixo e não exportar o registro para o Protheus:

• • • Banco de Horas: Funcionário XX/XXXXXXXX - Não foi gerado para o Protheus. Exportar o Cad. de Funcionários para gerar a matrícula.

• • Se for gerada a inconsistência para uma matrícula, a mensagem acima não deverá ser repetida, visto que será processado o mesmo funcionário para vários registros.
  • Na importação no sistema Protheus, será verificado se a matrícula que está sendo importada encontra-se na base dados, ou seja, se já foi importada pela rotina de importação de funcionários. Se o funcionário não existir na tabela SRA, será emitida a seguinte mensagem no LOG de importação:

• • • Banco de Horas: XX/XX/XXXXXX –  Funcionário não encontrado. Registros de Banco de Horas não foram importados.

9.5.5 Data

• • Será gerado para o sistema Protheus o valor do atributo informado na tabela Logix.

9.5.6 Código da Ocorrência

• • Ocorrência Logix que corresponde no sistema Protheus ao código do Evento
  • Este campo não será utilizado para gravar na tabela SPI.
  • O campo PI_PD será atribuído conforme seleção na tabela SP9, a partir do código da verba enviada do Logix no arquivo texto.

9.5.7 Código do Evento

• • Será gerado do Logix o código do evento.
  • Os códigos de Eventos Logix possuem DE/PARA de códigos, que deverá ser previsto na exportação.
  • Para os eventos que possuem a numeração até 899, deverá levar com o mesmo código existente no Logix
  • Para os eventos que estão com uma codificação maior ou igual a 900, deverá levar com o código que foi gerado automaticamente, e armazenado na tabela de DE-PARA (VDP_DPARA_GERAL).
  • No final da exportação do Logix, será emitida a seguinte mensagem de alerta para o usuário prever o cadastramento das verbas de Banco de Horas no Protheus
    • Banco de Horas: Os eventos Logix devem ser relacionados no Cadastro de Eventos Protheus: XXX, XXX, XXX, XXX, XXX, XXX, ...

• • • • Será realizado o agrupamento por código do evento, de cada registro que foi enviado, evitando que seja visualizada a duplicação do código do evento na mensagem.
      • Os códigos já serão os convertidos do DE/PARA.
  • Na importação no sistema Protheus, será verificado se a Verba que está sendo analisada encontra-se na base dados, ou seja, se já foi importada pela rotina de importação de Verbas. Se a Verba não existir na tabela SRV, será emitida a seguinte mensagem no LOG de importação e não será continuada a análise para importação do Banco de Horas:

• • • Banco de Horas XX/XX/XXX - Verba não cadastrada. Necessário realizar a importação do cadastro de Verbas do Logix.

• • Se não houver incoerência na consistência acima, será continuado a importação e análise do registro.
  • O evento, que é considerado como a Verba no Protheus, será também relacionado previamente a um Evento no Protheus, que será considerado para buscar o seu código e gravar na tabela SPI.
  • Para encontrar o código do evento, será relacionado com a tabela SP9. Dessa forma, o campo exportado pelo Logix não será utilizado para gravar na tabela SPI.
    • Se não encontrar um evento relacionado acima, será emitida a mensagem de erro no Protheus e não importar o registro:

• • • • Banco de Horas: Empresa/Filial/Verba XX/XX/XXX não relacionada a um Evento no cadastro de Eventos
    • Se encontrar mais de um evento relacionado acima, será emitida a mensagem de erro no Protheus e não importar o registro:
      
      • Banco de Horas: Empresa/Filial/Verba XX/XX/XXX não permitido relacionar a mais de um Evento no cadastro de Eventos.

• • Se não ocorrer nenhuma inconsistência acima, será gravado o código do Evento da tabela SP9 no campo PI_PD.

9.5.8 Centro de Custo

• • Será buscado o código do Centro de Custo da tabela de Unidade Funcional, com base na Unidade Funcional e a Data de Processamento selecionada na tabela HIST_FUNCIO.

9.5.9 Quantidade de Horas

• • Será gerado para o Protheus a quantidade de horas de banco
  • As horas no Logix são armazenadas valorizadas. Dessa forma, serão enviadas do Logix para o Protheus valorizadas, conforme parametrizações do banco de Horas Logix. 

9.5.10 Departamento

• • Buscar o código da Unidade Funcional das informações do Histórico do Funcionário
  • Se não encontrar o histórico para o período do banco, será buscado a Unidade Funcional do cadastro de Funcionários.

9.5.11 Cargo

• • Buscar o código do Cargo das informações do Histórico do Funcionário
  • Se não encontrar o histórico para o período do banco, será buscado o Cargo do cadastro de Funcionários.

9.5.12 Definição do arquivo de texto

• • A carga das informações geradas do Logix para o Protheus, será através de arquivo texto, com os campos separado por pipe (|).
  • O arquivo será gerado com o nome: banco_horas_logix.unl
  • A ordem dos campos em cada registro será:

• • • Empresa Protheus
    • Filial Protheus
    • Número da Matrícula
    • Data da ocorrência
    • Código da Ocorrência
    • Código do evento
    • Código do Centro de Custo
    • Quantidade de Horas
    • Código do Departamento
    • Código do Cargo

9.5.13 Exportando as Informações

• • A exportação do banco de horas respeitará as seguintes regras:

• • • Será considerado somente o período que esteja em aberto da tabela PAR_BH_SIND, programa RHU6976 – Parâmetros de Banco de Horas.
    • Conforme a Empresa e Sindicato selecionados de Parâmetros de Banco de Horas, serão selecionados os funcionários ativos com base na empresa e sindicato. Com base nestes funcionários, serão selecionados os registros da tabela de Movimento de Banco de Horas (MOVTO_BH) dos funcionários.
    • Do Movimento de Banco de Horas, serão selecionados somente os registros que estão em banco de Horas, ou seja, não foram pagos em folha. Será também considerado o período do banco de horas em aberto, que foi selecionado na tabela de Parâmetro de Banco de Horas (PAR_BH_SIND).
    • Estas consistências fazem parte das regras de fechamento do banco de horas, definidas no programa RHU6973. 

• • No Logix, as ocorrências são abertas por evento, ou seja, na tabela de Movimentação de Banco de Horas, já estão especificados os eventos que podem ser pagos na folha ou que serão compensados em banco de Horas, ou posteriormente serem pagos em folha, no fechamento.
  • Dessa forma, serão gerados para o Protheus os registros por Evento, ao invés de sumarizar por ocorrência.
  • No Protheus deverá haver uma parametrização dessas ocorrências e eventos para realizar a importação adequadamente, visto que estas parametrizações não serão possíveis migrar devido às regras serem muito divergentes. 

9.5.14 Importando as Informações

• • A inclusão/modificação dos registros respeitará a utilização do cadastro de Lançamentos de Banco de Horas (PONA200)
  • No momento da importação serão excluídos todos os registros da tabela SPI e importados novamente. Isto será necessário devido a processamentos que serão necessários para inclusão dos dados na tabela SPI.
  • Para realizar a inclusão, serão observada as regras definidas ao campo Código do Evento, onde serão consistidos:

• • • Se a verba vinda do Logix existe na tabela SRV.
    • Se há Evento cadastrado na tabela SP9, com base na verba vinda do Logix.
    • Se não há Eventos que utilizem da mesma verba.
  • A gravação dos campos que não vem no arquivo texto ou que tenham alguma regra especifica, seguirão a regra conforme abaixo:

• • • Campo PI_QUANT: Este campo será gravado com o valor do campo PI_QUANTV, devido às informações do Logix já serem enviadas valorizadas
    • Campo PI_FLAG: Gravar com o valor I – Informado, devido não ser gerado pelo Protheus
    • Campo PI_STATUS: Deixar branco
    • Campo PI_DTBAIX: Deixar branco, devido não haver histórico de pagamento. O pagamento será realizado no Protheus. 

• • Após a leitura do arquivo, o mesmo será renomeado para xx-xx-xxxx_banco_horas_logix.unl, que irá indicar qual foi a data de importação do arquivo. 

Vídeo

• Vídeo hospedado no youtube e inserido no template por meio da macro Widget Connector.

** Canal do youtube e software de vídeoem definição.