Estrutura de Fornecimento das Informações
O aplicativo Integra foi descontinuado a partir da versão 6.10.4.
Tabelas relacionadas ao processo de integração
As informações a serem integradas devem estar organizadas na forma de lotes, onde cada lote deverá ter uma determinada quantidade de dados que devem ser atualizados no Gestão de Pessoas. Estes lotes devem ser disponibilizados pelo sistema que está sendo integrado com o Gestão de Pessoas. Os padrões para a construção dos lotes são descritos a seguir.
Para o armazenamento das informações dos lotes, estão disponíveis na base de dados do usuário do Sistema Gestão de Pessoas, as seguintes tabelas da integração:
- R800ILT - Contém os lotes de informações que serão integradas;
- R800IMP - Contém, efetivamente, os dados de cada lote a ser integrado;
- R800ILG - Contém os erros/avisos provenientes de problemas durante o processo de integração;
- R800ASS - Contém as definições da configuração efetuadas no aplicativo;
- R800DEF - Contém as tabelas/campos que possuem os valores padrões.
A tabela R800IMP contém a seguinte estrutura:
- O sistema que provê os dados os gera;
- Os dados estão disponíveis para a Integração;
- O lote é processado pela Integração;
- O lote foi processado pela Integração e ele apresentou erros;
- O lote foi processado e não houve erros.
O conteúdo do campo STALOT poderá ser:
CODSIS | VARCHAR2(3) | |
CODLOT | NUMBER(6) | NOT NULL |
DATGER | VARCHAR2(8) | |
DESINT | VARCHAR2(40) | |
DESREF | VARCHAR2(40) | |
USUGER | VARCHAR2(12) | |
USUPRO | VARCHAR2(12) | |
DATPRO | VARCHAR2(8) | |
STALOT | NUMBER(1) |
A tabela R800ILT contém a seguinte estrutura:
CODLOT | NUMBER(6) | NOT NULL |
NUMLIN | NUMBER(20,4) | NOT NULL |
CONINT | VARCHAR2(250) |
A tabela R800ILG contém a seguinte estrutura:
CODLOT | NUMBER(6) | NOT NULL |
NUMLIN | NUMBER(20,4) | NOT NULL |
NUMSEQ | NUMBER(10) | NOT NULL |
DESLOG | VARCHAR2(250) | |
DESDML | VARCHAR2(250) |
A tabela R800ASS contém a seguinte estrutura:
CRISEN | VARCHAR2(1) |
FUNDEC | VARCHAR2(30) |
NOMDBL | VARCHAR2(30) |
TROSEN | VARCHAR2(1) |
DATEXE | DATE |
HOREXE | NUMBER(4) |
PEREXE | NUMBER(1) |
INTEXE | NUMBER(3) |
ENDEMA | VARCHAR2(30) |
A tabela R800DEF contém a seguinte estrutura:
NOMTAB | VARCHAR2(10) | NOT NULL |
NOMCAM | VARCHAR2(10) | NOT NULL |
TIPCAM | VARCHAR2(1) | |
VALCAM | VARCHAR2(100) |
Padrões e Exemplos para a construção dos lotes de informações
Cada lote possui zero ou várias linhas de dados que discriminam as inserções, alterações ou exclusões que deverão ser efetuadas nas tabelas do módulo Controle de Ponto e Refeitório. A seguir temos um modelo de um lote que insere um funcionário e seu histórico de crachá nas tabelas R034FUN e R038HCH do Gestão de Pessoas e, na sequência, exclui outro funcionário da tabela R034FUN. Para cada alteração, inclusão ou exclusão efetuada, deve-se inserir um registro na tabela R800IMP com todas as características abaixo, mesmo que referenciem a mesma tabela. Ainda nesta tabela estão exemplos para a importação de locais para a estrutura de organograma hierárquica e para a importação de usuários/colaborador.
Cada lote deverá conter um código único e, uma vez pronto, deverá ter o seu status modificado para disponível (StaLot = 2), indicando para a Rotina de Integração que ele já pode ser processado. Uma vez processado, o status desse lote será modificado para que não seja integrado novamente (StaLot = 4 ou 5).
Tabela R800ILT:
CODLOT | CODSIS | DATGER |
DESINT |
DESREF |
USUGER |
USUPRO |
DATPRO |
STALOT |
424 |
RON |
19990801 |
Alterações nos Registros de Colaboradores |
Rotina de Colaboradores |
OUTROSIS |
NULL |
NULL |
2 |
Tabela R800IMP:
CODLOT | NUMLIN | CONINT |
424 | 1 | [R034FUN] |
424 | 2 | ID_R034FUN=&NUMEMP=1 &TIPCOL=1 &NUMCAD=198 |
424 | 3 | NOMFUN='Joao DAvila Nascimento' |
424 | 4 | DATADM=TO_DATE('18-01-1999','DD-MM-YYY') |
424 | 5 | TIPADM=1 |
424 | 6 | ESTCAR=1 CODCAR=1 |
424 | 7 | VALSAL=000060000/100 |
424 | 8 | CODTMA=1 |
424 | 10 | [R038HCH] |
424 | 11 | ID_R038HCH=&NUMEMP=1 &TIPCOL=1 &NUMCAD=198 &DATINI=TO_DATE('10-08-1999', 'DD-MM-YYYY') &HORINI=600 |
424 | 12 | NUMCRA=100198 |
424 | 13 | DATFIM=NULL |
424 | 14 | HORFIM=0 |
424 | 15 | STATUS=1 |
424 | 20 | [R034FUN(*)] |
424 | 21 | ID_R034FUN=&NUMEMP=1 &TIPCOL=3 &NUMCAD=118 |
424 | 22 | [R016ORNL] |
424 | 23 | ID_R016ORNL=&TABORG=1 &CODLOC='102' |
424 | 24 | NOMLOC='Setor Administrativo' |
424 | 25 | DATREF='10/08/1999' |
424 | 26 | LOCPAI = '50' |
424 | 27 | [R999USUL] |
424 | 28 | ID_R999USUL=&NUMEMP=1 &TIPCOL=1 &NUMCAD=18 |
424 | 29 | LOGUSU='Josefa' SENUSU='1234' CRIUSU=2 |
424 | 30 | [R083ARI] |
424 | 31 | ID_R083ARI=&NUMEMP=1&CMPPPA=TO_DATE('10-08-1999', 'DD-MM-YYYY')&TABORG=1&NUMLOC=126 |
424 | 32 | +DESARI='Galpão com 1000 m2 em alvenaria, cobertura em laje, piso de concreto, ventilação |
424 | 33 | +, com janelas basculantes e iluminação natural complementada com lâmpadas fluorescentes |
424 | 34 | /e complementadas por ar condicionado central específico' |
Na importação do Local, caso o organograma utilize máscara, deve-se informar no CODLOC, o local precedido do pai, informando ponto para separá-los.
Inclusão do Local Pai
424 | 01 | [R016ORNL] |
424 | 02 | ID_R016ORNL=&TABORG=1 &CODLOC='50' |
424 | 03 | NOMLOC='Setor' |
424 | 04 | DATREF='10/08/1999' |
424 | 05 | LOCPAI = '' |
424 | 01 | [R016ORNL] |
424 | 02 | ID_R016ORNL=&TABORG=1 &CODLOC='50.01' |
424 | 03 | NOMLOC='Setor Administrativo' |
424 | 04 | DATREF='10/08/1999' |
424 | 05 | LOCPAI = '50' |
Onde:
- O nome da tabela que será alterada deve estar entre colchetes [];
- Para excluir um registro, deve-se infomar o nome da tabela seguido de "(*)" mais a chave do registro que se deseja excluir;
- A chave primária ou identificador do registro deve possuir um nome (exemplo: ID_R034FUN) e os campos que fazem parte desta chave primária devem ser precedidos de um "&". É necessária a presença de um espaço em branco entre cada campo da chave primária. Não deixe espaços entre o nome do campo, o sinal de igual (=) e o valor de cada campo (exemplo: Linha 2 e 11 da tabela anterior);
- Para campos do tipo string (cadeia de caracteres), devem ser automaticamente inseridos os apóstrofos delimitadores de texto (exemplo: Linha 3 da tabela anterior);
- Caso seja necessária a inclusão de apóstrofo dentro da string, este deve ser duplicado, como exemplo da linha 3 (exemplo: D"Ouro = D'Ouro);
- Campos do tipo Data poderão ser informados diretamente no padrão "DD/MM/YYYY", como exemplificado na linha 25;
- Os campos numéricos com casas decimais devem utilizar a mesma sintaxe utilizada na linha 7 da tabela anterior (60000/100 = 600,00), pois dependendo da configuração do banco de dados, as casas decimais podem ser definidas por ponto ou por vírgula;
- Podem ser especificados mais de um campo com valores por linha (exemplo: linha 6), sendo que os mesmos devem estar separados por 1 (um) espaço em branco. Podem ser definidos campos de qualquer tipo, desde que a definição dos mesmos siga os critérios definidos nos tópicos anteriores;
- Para tratamentos especiais da integração, serão utilizadas tabelas lógicas. A utilização das tabelas lógicas indica para a rotina de integração que o próximo registro possui um processamento diferenciado.
- Podem ser usadas mais de uma linha de comando quando a capacidade necessária para o campo ultrapassar 256 caracteres. As linhas a serem unidas devem ter o caracter + na primeira posição da linha conforme as linhas 32 e 33 da tabela anterior. Para indicar o término do comando, deve-se colocar o caracter "/" na última linha a ser unida, conforme linha 34 da tabela anterior.
A integração executará as atualizações seguindo a seqüência em que os lotes foram disponibilizados. Caso algum erro de processamento ocorra, ele será gravado na tabela de log de processamentos da rotina de integração (R800ILG) e o lote será sinalizado com o status de erro de processamento (StaLot = 4). Quando ocorre um erro, no log é informada a linha da entidade onde ocorreu a inconsistência. Baseado nesta linha o usuário poderá adotar as medidas necessárias para a solução do problema.
Caso o campo de e-mail do responsável pela integração tenha sido corretamente preenchido (nas configurações do aplicativo), uma mensagem é enviada ao responsável (com algumas mensagens de erro do lote integrado), indicando o número do lote onde o problema aconteceu. Isto permitirá uma maior agilidade na correção de problemas provenientes da integração.
Aspectos a observar:
- Para cada registro que deve ser modificado (por registro, entende-se toda a informação da tabela a ser integrada), deve-se incluir o nome da tabela, mesmo que sejam vários registros de uma única tabela. A Integração trata cada ocorrência de tabela como sendo o início de registro, até que qualquer outra referência de tabela ou o final do lote sejam encontrados;
- A origem das linhas do lote deverá obedecer as IRs (Integridades Referenciais) da base de dados do Gestão de Pessoas, isto é, não será possível inserir o registro de históricos de crachás para o novo colaborador se ele ainda não foi inserido na tabela de colaboradores. Em caso de necessidade, o cliente deverá entrar em contato com a área de Suporte da Senior e solicitar uma listagem de IRs das tabelas que deseja integrar;
- Deve-se definir corretamente o status do lote para que a rotina de Integração processe somente os lotes que estão prontos para tal;
- O sistema que fornecerá os dados da integração deverá entrar em contato com a Senior para obter uma lista completa e atualizada das estruturas das tabelas e integridades referenciais que farão parte da integração;
- O campo CODSIS da tabela R800ILT deve ser definido corretamente para o sistema que será feita a integração dos dados (RON - Controle de Ponto e Refeitório, RUB - Administração de Pessoal, e assim por diante);
- Os lotes que foram integrados e possuem o campo StaLot igual a 5 (cinco), poderão ser excluídos das tabelas R800ILT, R800IMP e R800ILG, pois eles já foram integrados corretamente. A exclusão das informações das tabelas R800ILT, R800ILG e R800IMP é de responsabilidade do cliente, sendo que ele deve providenciar constante manutenção nestas, para que a integração funcione adequadamente.