Integração GT x Akita no formato Cloud (gtsoft-rest-api e akitasoft-rest-api)

gustavo_siqueira

Integração GT x Akita no formato Cloud

Configuração básica dos artefatos

akitasoft

ASW0140:

campo "Considera Documento" com a opção "GT Soft Cloud" salva.

-> Não precisa de configuração específica no application.yml

gtsoft

GT0110:

campo "Tipo Integração API" com a opção "Webhook" salva;
campo "Url Webhook Sistema Integrado" com a url da akitasoft-rest-api. Exemplo: http://insoft-lnx25:7480/akitasoft-rest-api/
a url precisa estar completa nesse formato 'http://site:porta/akitasoft-rest-api/'

GT0115:
Nessa tela deve ser cadastrado o de-para de tipos de pessoas que as contratantes vão considerar para integrar.

campo "Contratante" é a contratante do GT, integrando pessoas que tenham o turno nesta contratante.
campo "Tipo Pessoa" é o tipo de pessoa do GT
campo "Tipo Pessoa Integração" é o tipo de pessoa do Akita
Quando a pessoa do GT tem o "Tipo Pessoa" igual ao deste cadastro, e turno nessa contratante, a integração vai inserir ela no Akita com o "Tipo Pessoa Integração" especificado.

GT0810:
Nessa tela fica salvo alguns dados usados pelas APIs da integração.
Cada contratante que precisa integrar seus prestadores com o Akita precisam dos atributos USUARIO_API_AKITA, SENHA_API_AKITA e URL_WEBHOOK_SISTEMA_INTEGRADO cadastrados aqui nesta tela.

campo "Nome Parametro" com valor "USUARIO_API_AKITA"
campo "Tipo Parametro" com valor "Texto"
campo "Valor Parametro" com valor relativo ao login de usuário usado para a integração. Utilizar um login do tipo admin e que tenha o tipo de usuário como "Integração".
campo "Nome Parametro" com valor "SENHA_API_AKITA"
campo "Tipo Parametro" com valor "Texto"
campo "Valor Parametro" com valor relativo a senha do login usado em USUARIO_API_AKITA.
campo "Nome Parametro" com valor "URL_WEBHOOK_SISTEMA_INTEGRADO"
campo "Tipo Parametro" com valor "Texto"
campo "Valor Parametro" com valor relativo a url da akitasoft-rest-api. Aqui deve-se usar o mesmo valor salvo no GT0110 para a contratante.

GT0280:
Nesta tela ficam salvos os turnos das contratantes e os cod_perfil que eles representam no Akita.
Ou seja, cada turno do GT representa um perfil de acesso para a pessoa no akita. Diferentes turnos podem apontar para um mesmo cod_perfil do Akita, não há problemas nisso.

GT0815:
Nesta tela ficam salvos os de-paras de motivos de afastamentos. O codMotivo 1 do GT poderá ser o codMotivo 2 do Akita, conforme o necessário no cliente. Sempre levando em conta a contratante.

-> Não precisa de configuração específica no application.yml

gtsoft-rest-api

Configurações do application.yml:

conexão de banco com a base do GT
plugin.insoftApiSecurity.authenticator.url: 'http://insoft-lnx26.insoft.local:8880/insoft-auth' # Url do insoft-auth do GT
akita.urlBase: 'http://localhost:8680/gtsoft-rest-api' # Url da própria API. Esse valor é enviado ao akitasoft-rest-api para ele conseguir acionar esta API de novo. Aqui não pode ter barra no final da url. Possivelmente só precisa trocar a porta da url quando aplicado em produção.
akita.delayRepeatPonteiro: 15 # Repetição em segundos para excussão do JOB que manda as ponteiros_integracoes_acessos para o akitasoft-rest-api integrar
akita.qtdRegistro: Quantidade de registros da ponteiros_integracoes_acessos enviados por job ao akitasoft-rest-api

akitasoft-rest-api

Configurações do application.yml:

conexão de banco com a base do Akita/Ponto
plugin.insoftApiSecurity.authenticator.url: 'http://insoft-lnx25.insoft.local:7280/insoft-auth' # Url do insoft-auth do Akita
gt.url: 'http://localhost:8080/gtsoft-rest-api/'
gt.username: 'admin' # usuário do GT que é admin, pode ser um dos cadastrados em USUARIO_API_AKITA do GT0810
gt.password: 'admin' # senha salva em SENHA_API_AKITA para o USUARIO_API_AKITA escolhido
Obs: o usuário informado em gt.username precisa estar cadastrado na GT0500 do GT (tabela in4fw_usuarios da base do GT)

Fluxo da integração GT -> Akita

A integração funciona somente no sentido GT envia dados ao Akita.
O Akita não altera dados cadastrais do prestador/empresa no GT.

Etapa 1 - Alterações de dados em tabelas do GT, por meio do uso das telas do sistema e procedimentos feitos pelo banco. As seguintes tabelas do GT disparam a integração:

dados da Empresa Prestadora:
AFASTAMENTOS_EMPRESAS -> TRIG_AF_RW_AE_ATZ_PNT_INT_AC
EMPRESAS_PESSOAS -> TRIG_AF_RW_EP_ATZ_PNT_INT_AC
PERIODOS_DOCUMENTOS_EMPRESAS -> TRIG_AF_RW_PDE_ATZ_PNT_INT_AC
RELACOES_SERVICOS_EMPRESAS -> TRIG_AF_RW_RSE_ATZ_PNT_INT_AC
dados do Prestador de Serviço:
AFASTAMENTOS_PESSOAS -> TRIG_AF_RW_AP_ATZ_PNT_INT_AC
CONTROLES_PESSOAS -> TRIG_AF_RW_CP_ATZ_PNT_INT_AC
PERIODOS_DOCUMENTOS_PESSOAS -> TRIG_AF_RW_PDP_ATZ_PNT_INT_AC
RELACOES_PESSOAS_CONTRATANTES -> TRIG_AF_RW_RPC_ATZ_PNT_INT_AC
SOLICITACOES_LIBER_PESSOAS -> TRIG_AF_RW_SLP_ATZ_PNT_INT_AC
TIPOS_CONTROLES_PESSOAS -> TRIG_AF_RW_TCP_ATZ_PNT_INT_AC

Alterações nessa tabela criam um registro na tabela ponteiros_integracoes_acessos.

Etapa 2 - Coleta destes dados da ponteiros e envio ao akitasoft-rest-api. A gtsoft-rest-api executa o Job e coleta os registros da ponteiros_integracoes_acessos que estão com 'situacao' = 1, 'tipo_integracao_api' = 'W', ordenada por 'tipo_dado' 'ASC'.

Para cada registro encontrado nessa coleta, a gtsoft-rest-api realiza:

login na akitasoft-rest-api
com o token da autenticacao, envia uma request POST para 'akitasoft-rest-api/v1/AlteracaoGT', conforme a url base presente na coluna url_webhook_sistema_integrado deste registro da ponteiros_integracoes_acessos
se a integração for de dados de empresa prestadora, enviará o seguinte conjunto de dados:
{
id : ponteiros_integracoes_acessos.id,
tipoDado : ponteiros_integracoes_acessos.tipoDado,
identificador: [
cnpj : ponteiros_integracoes_acessos.cnpj,
cpf : ponteiros_integracoes_acessos.cpf,
outroDocumento: ponteiros_integracoes_acessos.outroDocumento
],
urlDados : urlBase + '/v1/empresa' -> urlBase é o valor do atributo 'akita.urlBase' do application.yml do gtsoft-rest-api
}
se a integração for de dados do prestador de serviço, enviará o conjunto de dados:
{
id : ponteiros_integracoes_acessos.id,
tipoDado : ponteiros_integracoes_acessos.tipoDado,
identificador : [
rg : ponteiros_integracoes_acessos.rg,
ufRg : ponteiros_integracoes_acessos.ufRg,
cpf : ponteiros_integracoes_acessos.cpf,
outroDocumento: ponteiros_integracoes_acessos.outroDocumento,
tcpId : ponteiros_integracoes_acessos.tcpId
],
urlDados : urlBase + '/v1/pessoa', -> urlBase é o valor do atributo 'akita.urlBase' do application.yml do gtsoft-rest-api
tipoOperacaoIntegracao: ponteiros_integracoes_acessos.tipoOperacaoIntegracao
}
dentro da akitasoft-rest-api/v1/AlteracaoGT, será feito o login no gtsoft-rest-api com o login e senha configurados no atributo gt.username e gt.password do application.tml do akitasoft-rest-api
com o token da autenticacao, quando for integraão da empresa, o akitasoft-rest-api fará uma request para ponteiros_integracoes_acessos.urlBase(gtsoft-rest-api) + '/v1/empresa' passando os identificadores da empresa(cpf, cnpj, outro_documento) e o id da ponteiro como parametros
a gtsoft-rest-api recebe a request v1/empresa e devolverá o conjunto:
codEmpresa : empresaPessoa.id,
identificador : [
cnpj : empresaPessoa.cnpj,
cpf : empresaPessoa.cpf,
outroDocumento: empresaPessoa.codIdentificador
],
nomeEmpresa : empresaPessoa.nomeEmpresa,
statusAcesso : resultado de as_bloq_empresa(empresaPessoa.id),
inscricaoEstadual: empresaPessoa.inscricaoEstadual,
tipoEmpresa : empresaPessoa.tipoEmpresa,
tipoPessoa : empresaPessoa.tipoPessoa,
telefone : empresaPessoa.telefone,
email : empresaPessoa.email,
contato : empresaPessoa.contato,
endereco : empresaPessoa.endereco,
cep : empresaPessoa.cep,
dataDesativacao : empresaPessoa.dataEmpresaDesativada?.format(DATE_FORMATTER),
dataInclusao : empresaPessoa.dataInclusao.format(DATE_FORMATTER),
observacao : empresaPessoa.observacao,
documentos : docEmpresa,
afastamentos : afastamentosEmpresas(empresaPessoa.id, contratantes)

docEmpresa são os registros da consulta:

select distinct vde.cod_documento coddocumento 
           , tda.descr_documento descrdocumento 
           , as_bloq_documento_empresa(vde.cod_empresa, vde.cod_documento) statusdocumento 
           , as_bloq_empresa(vde.cod_empresa) statusacesso 
        from v_documentos_empresas    vde 
           , tipos_documentos_acessos tda 
       where vde.cod_empresa   = ${codEmpresa} 
         and tda.cod_documento = vde.cod_documento 
         and as_bloq_documento_empresa(vde.cod_empresa, vde.cod_documento) not in ('N','R','I')  
         and vde.emp_cnt_id is null 
 union 
select distinct vde.cod_documento coddocumento 
           , tda.descr_documento descrdocumento 
           , as_bloq_documento_empresa(vde.cod_empresa, vde.cod_documento) statusdocumento 
           , as_bloq_empresa(vde.cod_empresa, vde.emp_cnt_id) statusacesso 
        from v_documentos_empresas    vde 
           , tipos_documentos_acessos tda 
       where vde.cod_empresa   = ${codEmpresa} 
         and tda.cod_documento = vde.cod_documento 
         and as_bloq_documento_empresa(vde.cod_empresa, vde.cod_documento) not in ('N','R','I')  
         and vde.emp_cnt_id in (select rse.emp_cnt_id 
                                  from relacoes_servicos_empresas rse 
                                 where rse.cod_empresa = ${codEmpresa} 
                                   and rse.emp_cnt_id in (${contratantes.id.join(',')})
                                   and rse.data_inicial <= trunc(sysdate) 
                                   and ( rse.data_final >= trunc(sysdate) or rse.data_final is null ) ) 
         and vde.emp_cnt_id is not null;

afastamentosEmpresas são os registros da consulta:
select to_char(ae.data_inicial,'yyyy-mm-dd') dataInicial
, to_char(ae.data_final,'yyyy-mm-dd') dataFinal
, rse.cod_empresa
, mai.cod_motivo_integracao codMotivo
from afastamentos_empresas ae
, relacoes_servicos_empresas rse
, motivos_afast_integracoes mai
where ae.rlc_srv_em_id = rse.id
and ae.maa_cod_motivo = mai.cod_motivo
and mai.ec_id = rse.emp_cnt_id
and ae.data_inicial <= trunc(sysdate)
and (ae.data_final is null or ae.data_final >= trunc(sysdate))
and rse.emp_cnt_id in (${contratantes.id.join(',')})
and rse.cod_empresa = ${codEmpresa}
o objeto contratantes, usando tanto para buscar os docs e afastamentos da empresa, são as contratantes retornadas na consulta:
select id from empresas_contratantes where url_webhook_sistema_integrado = ponterios.url_webhook_sistema_integrado (url salva no ponteiro que está sendo integrado)
com a gtsoft-rest-api retornando estes dados da empresa, a akitasoft-rest-api vai fazer:
- insert/update da empresas_pessoas:
  - se não houver uma empresas_pessoas com os identificadores do GT, vai fazer o insert:
    - id -> neste insert será sempre o código disponível pela function pack_proximo_codigo.empresa_pessoa
    - cnpj -> este e demais campos conforme o que foi cadastrado no GT
    - cpf
    - codIdentificador
    - nomeEmpresa
    - inscricaoEstadual
    - telefone
    - email
    - contato
    - endereco
    - cep
    - se já houver empresa cadastrada com os identificadores do GT, vai fazer o update nos campos:
      - nomeEmpresa -> este e demais campos conforme o que foi cadastrado no GT. Com isso, percebe-se que a integração da empresa não vai integrar os identificadores. Ou seja, se for necessário atualizar o cnpj, cpf ou cod_identificador no GT, será criada uma nova empresa no Akita nesta alteração do GT.
      - inscricaoEstadual
      - telefone
      - email
      - contato
      - endereco
      - cep
- delete em documentos_empresas_integracao para esse cod_empresa
- inserir em documentos_empresas_integracao cada documento com seu status de acesso conforme recebido em docEmpresa, quando status_acesso deste doc é diferente de 'N' - Liberado
- refazer os afastamentos de pessoas da empresa:
  - se não tiver afastamentos, remove todos os afastamentos para as pessoas dessa empresa que estão com afastamentos de tipo_origem com vaor 'E'
  - pesquisa tipos_controles_pessoas sem data de desligamento na empresa em questão
  - pesquisa afastamentos de cada tipos_controles_pessoas encontrado, filtrando pelo codMotivo de cada afastamento
  - se localizar o afastamento no Akita que veio do GT, vai atualizar a data final caso esteja presente desta vez
  - se não localizar o afastamento no AKita que veio do GT, vai criar o afastamento dessa vez.
  - estes afastamentos de integração oriundos do cadastro da empresa, possuem o campo tipo_origem com valor 'E'
se for integração de pessoa, com o token da autenticacao, o akitasoft-rest-api fará uma request para ponteiros_integracoes_acessos.urlBase(gtsoft-rest-api) + '/v1/pessoa' passando os identificadores da pessoa(cpf, rg/uf_rg, outro_documento) e o id da ponteiro como parametros
a gtsoft-rest-api recebe a request v1/pessoa e devolverá o conjunto:
{
codPessoa : pessoa.id,
identificador : [
rg : pessoa.rg,
ufRg : pessoa.ufRg,
cpf : pessoa.cpf,
outroDocumento: pessoa.outroDocumento
],
nomePessoa : pessoa.nomePessoa,
sexo : pessoa.sexo,
dataNascimento : pessoa.dataNascimento?.format(DATE_FORMATER),
nroCtps : pessoa.nroCtps,
serieCtps : pessoa.serieCtps,
ufCtps : pessoa.ufCtps,
cnhPessoa : pessoa.cnhPessoa,
validadeCnh : pessoa.validadeCnh?.format(DATE_FORMATER),
telefoneCelular : pessoa.telefoneCelular,
contatoFamiliar : pessoa.contatoFamiliar,
telefoneFamiliar: pessoa.telefoneFamiliar,
cidade : pessoa.cidade?.nome,
endereco : pessoa.endereco,
bairro : pessoa.bairro,
obsDocumentos : pessoa.obsDocumentos,
codIntegracao : pessoa.codIntegracao,
nroSite : packIntegracaoDao.getPlantaPadrao() -> "select to_number(valor_parametro) nroSite from parametros_gerais where nome_parametro = 'NRO_SITE_PADRAO_AKITA'"
empresas : historicosPessoa
}
historicosPessoa são os registros retornados da consulta:
select * from tipos_controles_pessoas
where exists(select 1
from relacoes_servicos_empresas rse,
relacoes_pessoas_contratantes rpc,
turnos_contratantes tuc
where rse.cod_empresa = this_.cod_empresa
and rse.data_inicial <= trunc(sysdate)
and (rse.data_final >= trunc(sysdate) or rse.data_final is null )
and rse.emp_cnt_id = tuc.emp_cnt_id
and rpc.tur_cnt_id = tuc.id
and rpc.tcp_id = this_.id
and rpc.data_inicial <= trunc(sysdate)
and (rpc.data_final >= trunc(sysdate) or rpc.data_final is null )
and rse.emp_cnt_id in (pcontratantes) )
o objeto pcontratantes, usa na consulta dos históricos, são as contratantes retornadas na consulta:
select id from empresas_contratantes where url_webhook_sistema_integrado = ponterios.url_webhook_sistema_integrado (url salva no ponteiro que está sendo integrado)
ou seja, só retorna os históricos com turno ativo e contrato de serviço ativo na contratante que integra dados
continuando, o objeto historicosPessoa é uma lista com os históricos da pessoa. Cada histórico possui o seguinte conjunto:
{
codEmpresa : tcp.codEmpresa,
cnpj : ep.cnpj, -> dado da empresa do histórico
cpf : ep.cpf, -> dado da empresa do histórico
outroDocumento : ep.codIdentificador, -> dado da empresa do histórico
tcpId : tcp.id,
tipoPessoa : packIntegracaoDao.trataTipoPessoa(tcp.tipoPessoa.id, contratantes), -> com base no tipo de pessoa do histórico, usa o valor da consulta: select tpi.tipo_pessoa_integracao codTipo from tipos_pessoas_integracoes tpi where tpi.tipo_pessoa = ${tcp.tipoPessoa.id} and tpi.ec_id in (${pcontratantes}). Ou seja, este atributo vai conter o valor do tipo_pessoa lá do Akita, baseado no cadastro do de-para da tela GT0115.
email : tcp.email,
dataCadastro : tcp.dataCadastro.format(DATE_FORMATER),
dataAdmissao : tcp.dataAdmissao.format(DATE_FORMATER),
dataDesligamento : tcp.dataDesligamento?.format(DATE_FORMATER),
statusAcesso : statusAcesso, -> resultado da consulta: select as_bloq_pessoa(cod_pessoa, tcp_id) status from dual
documentos : documentos,
afastamentos : packIntegracaoDao.trataAfastamentoPessoa(afastamento, contratantes),
turnos : turnos,
liberacoesExtraTurno: liberacoes
}
o objeto documentos, presente em cada historicoPessoa, será o resultado da consulta:
select distinct tda.cod_documento coddocumento
, tda.descr_documento descrdocumento
, as_bloq_documento_pessoa(pdp.cod_pessoa,tda.cod_documento, pdp.tcp_id,null,null) statusdocumento
, as_bloq_pessoa(pdp.cod_pessoa,pdp.tcp_id) statusacesso
from v_periodos_documentos_pessoas pdp
, tipos_documentos_acessos tda
where pdp.cod_documento = tda.cod_documento
and as_bloq_documento_pessoa(pdp.cod_pessoa,tda.cod_documento, pdp.tcp_id,null,null) not in ('N','R','I')
and pdp.cod_pessoa = ${codPessoa}
and pdp.tcp_id = ${tcpId}
and pdp.id_empresa_contratante is null
union
select distinct tda.cod_documento coddocumento
, tda.descr_documento descrdocumento
, as_bloq_documento_pessoa(pdp.cod_pessoa,tda.cod_documento, pdp.tcp_id,null,null) statusdocumento
, as_bloq_pessoa(pdp.cod_pessoa,pdp.tcp_id,pdp.id_empresa_contratante) statusacesso
from v_periodos_documentos_pessoas pdp
, tipos_documentos_acessos tda
where pdp.cod_documento = tda.cod_documento
and as_bloq_documento_pessoa(pdp.cod_pessoa,tda.cod_documento, pdp.tcp_id,null,null) not in ('N','R','I')
and pdp.cod_pessoa = ${codPessoa}
and pdp.tcp_id = ${tcpId}
and pdp.id_empresa_contratante in ( select rse.emp_cnt_id
from relacoes_servicos_empresas rse
where rse.cod_empresa = ${codEmpresa}
and rse.emp_cnt_id in (${pcontratantes})
and rse.data_inicial <= trunc(sysdate)
and ( rse.data_final >= trunc(sysdate) or rse.data_final is null ) )
and pdp.id_empresa_contratante is not null;
o objeto packIntegracaoDao.trataAfastamentoPessoa(afastamento, contratantes) vem de um processamento dos afastamentos vigentes do histórico:
Pesquisa os afastamentos que estão ativos para a pessoa, e cada um desses afastamentos tem o codMotivo trocado pelo codMotivo que está configurado no de-para de motivos de afastamentos. Sendo assim, se a pessoa tem afastamento com codMotivo 1, mas o codMotivo 1 é codMotivo 2 no Akita, conforme o de-para, este afastamento listado aqui terá o codMotivo 2 sendo exibido. Esse de-para sempre leva em conta as contratantes do objeto pcontratantes.
o objeto turnos vem da consulta:
select to_char(rpc.data_inicial, 'dd/mm/yyyy') data_inicial
, to_char(rpc.data_final, 'dd/mm/yyyy') data_final
, rpc.utiliza_refeitorio
, rpc.utiliza_transporte
, tc.cod_perfil_akita
, tc.id codTurno
from relacoes_pessoas_contratantes rpc
, turnos_contratantes tc
where rpc.tur_cnt_id = tc.id
and tc.emp_cnt_id in (${pcontratantes})
and (rpc.data_final >= trunc(sysdate)
or rpc.data_final is null)
and rpc.data_inicial >= (select max(rpc2.data_inicial)
from relacoes_pessoas_contratantes rpc2
, turnos_contratantes tc2
where rpc2.tur_cnt_id = tc2.id
and rpc2.tcp_id = rpc.tcp_id
and tc2.emp_cnt_id in (${pcontratantes}))
and rpc.tcp_id = ${tcpId}
o objeto liberacoes vem da consulta:
select slp.tcp_id
, to_char(sl.data_inicial, 'yyyy-mm-dd')
, to_char(sl.data_final, 'yyyy-mm-dd')
, to_char(sl.hora_final,'hh24:mi') horaFinal
, to_char(sl.hora_inicial,'hh24:mi')
from solicitacoes_liber_pessoas slp
, solicitacoes_liberacoes sl
where sl.id = slp.slc_lbr_id
and sl.data_inicial >= trunc(sysdate)
and sl.status = 'A'
and slp.aprovado = 'S'
and slp.tcp_id = $tcpId
order by sl.data_inicial
com a gtsoft-rest-api retornando estes dados da pessoa, a akitasoft-rest-api vai fazer para cada histórico recebido (cada conjunto de turnos, liberacoes etc. dentro do objeto da pessoa):
- insert na intfol_cadastros_pessoas com os dados da pessoa e do historico
- atualiza os dados da empresa do histórico direto no cadastro de empresas_pessoas, para a empresa sempre estar sincronizada entre gt e akita
- busca o cadastro da pessoa na base do akita. Se a pessoa ainda não existe para o cpf, rg e outro_documento informado no GT, vai inserir a pessoa no akita e junto o histórico conforme os dados recebidos do gtsoft-rest-api
- se a pessoa já existe, caso o tipo_operacao_integracao da ponteiros tiver o valor 'H', a akitasoft-rest-api vai buscar o histórico no akita conforme os dados do histórico do GT. Se não houver histórico cadastrado, que pode ser o caso de uma inclusão de histórico no GT para uma controles_pessoas já cadastrada, a API vai inserir este novo histórico no akita.
- se a pessoa já existe, o histórico do GT já existe no Akita, os unicos dados do histórico que são atualizados serão a data_desligamento, tipo_pessoa e email quando necessário.
- durante a atualização do histórico, os dados da controles_pessoas que foram alterados no GT também já são atualizados no Akita.
- se a tipo_operacao_integracao tiver valor 'C', vai apenas atualizar a controles_pessoas e ignorar as verificações e atualizações da tipos_controles_pessoas.
caso o tipo_operacao_integracao for igual a 'T', os turnos serão sincronizados. Isto é, cada turno do GT será um perfis_acessos_pessoas para o histórico da pessoa integrada.
caso o tipo_operacao_integracao for igual a 'A', os afastamentos serão sincronizados. Isto é, se não há afastamentos vindos do GT, os afastamentos do Akita são removidos. Cada afastamento vindo do GT ou será incluído no Akita, caso ainda não esteja na base, ou atualizado, setando a dataFinal do Akita conforme a que foi atualizada no GT. Aqui é levado em conta o codMotivo do de-para.
caso o tipo_operacao_integracao for igual a 'L', as liberações de acesso serão sincronizadas.
- as liberações sincronizadas levarão em conta o codMotivo da liberação conforme o retorno do select: select cod_motivo motivo from motivos_liberacoes d where indica_integracao_terceiro = 'S'. Então somente as liberações de integração de terceiro que são sincronizadas entre as duas bases.
- a sincronização remove o que já existe de liberação para a pessoa nas datas vindas do GT e reinsere com essas datas corretas conforme o GT. Aqui será sempre delete seguido de insert, sem ocorrer updates.
caso o tipo_operacao_integracao for igual a 'D', os documentos do histórico da pessoa serão integrados.
faz delete em documentos_pessoas_integracao para os registros da tcp_id deste histórico sendo integrado
para cada documento do objeto documentos vindos da integração, será um insert na documentos_pessoas_integracao com a situação atual desse documento, caso o status de acesso for diferente de 'N' - Liberado.
agora, já quase no final do fluxo, a API sincroniza a informação de "Utiliza Refeitório" do histórico integrado.
- faz uma request para gtsoft-rest-api/v1/tiposControlesPessoas, passando codPessoa e codEmpresa. Essa request vai devolver os históricos do GT dessa pessoa e empresa, com a informação do campo utilizaRefeitório do histórico no GT.
- cada histórico dessa request também é um histórico no akita, então caso esse histórico do GT usa refeitório, será feito um insert na setores_Acessos_pessoas, garantindo acesso aos refeitórios da planta deste histórico, com data inicial igual a data de cadastro deste histórico e também tipoLiberacao = 'I'.
por fim, após ter realizado todas as integrações necessárias, executa a proc_atz_perfil_pessoa com o cod_pessoa que foi sincronizado no akita.
caso tenha chego até aqui, a ponteiro do GT será atualizada com a situação 2 de Ok.
durante os fluxos da integração, caso ocorra erro, a ponteiro é atualizada com situação 2 de Erro, junto com o campo descricao_erro e data_hora_processamento para facilitar a identificação do problema ocorrido.