Histórico da Página

CONTEÚDO

01.

...

VISÃO GERAL

Este

...

documento descreve algumas recomendações para melhorar o fluxo do Clock-In em dispositivos Mobile

...

.

02. RECOMENDAÇÕES PROCEDIMENTO RECONHECIMENTO FACIAL

Segue recomendações:

• Não utilizar vestimentas no rosto que cubra parte da boca e nariz, como máscaras.
• Evitar óculos (escuros, de leitura e de EPI). Os óculos de leitura/EPI podem refletir luminosidade e dificultar o reconhecimento facial.
• Enquadramento do rosco conforme orientação visual no dispositivo:
• A funcionalidade "Habilitar detecção de rostos" funciona como uma orientação de rosto detectado, mas o mesmo deve ser enquadrado conforme orientação visual no dispositivo.
• Ter apenas um rosto visível
• Principalmente em filas, se ambos rostos estiverem próximos o sistema não irá detectar qual rosto deve ser reconhecido e não irá reconhecer nenhum dos dois.

...

• .
• Ambientes não devem possuir luminosidade excessiva que impacte na rosto da pessoa (lâmpadas que efetuam reflexos no visor da câmera do aplicativo)
• Ambientes não devem possui pouca luminosidade onde não é possível identificar os trações da face para efetuar o reconhecimento facial.

03. CRIAÇÃO DE USUÁRIOS AUTOMATICAMENTE BASEADO NA TABELA DE FUNCIONÁRIOS

O TOTVS RH Clock-In permite a criação de usuários utilizando dados provenientes dos softwares de RH. Para isso, precisaremos efetuar um mapeamento de uma tabela proveniente do sistema de RH para o Data Model "User".

Para clarificação das diferentes soluções de RH, abaixo é listado uma tabela com as tabelas necessárias para mapeamento. As tabelas são sugestões, podendo ser integrado outra tabela especifica ou explorar outra tabela do produto para criação dos usuários automaticamente.

...

Mesmo que o produto (acima listado) já tenha um mapeamento para criação dos usuários, ainda assim é possível enviar outra tabela e efetuar o mapeamento.

Não é recomendado a alteração de mapeamentos padrão do produto pois os mesmos serão perdidos na próxima atualização do produto.

Agora vamos efetuar o mapeamento da tabela "pfcompl" com o Data Model "User" para criação dos usuários:

Vamos no menu "Connectors" no canto esquerdo (primeiro ícone) e selecione o seu produto (no meu caso eu selecionei o TOTVS RM). Após selecione a tabela com os usuários a serem criados (no meu caso pfcompl):

Image Removed

Depois clique em "Map & Cleanse":

Image Removed

O próximo passo é selecionar o Data Model "User" para que os dados da tabela selecionado sejam enviados para esse Data Model. Esse Data Model tem uma interface padrão com a plataforma Carol para criação/desativação de usuários na plataforma:

Image Removed

Na próxima tela, selecione a opção "Create a new set of mapping rules" para criarmos a regra customizada de criação dos usuários:

Image Removed

...

Ao final deste documento adicionamos exemplos de mapeamentos que podem ser carregados através da opção "Upload set of mapping rules". Os mapeamentos são arquivos Json que seguem o protocolo especificado pela Carol. Após carregado os mapeamentos pode ser efetuado ajustes nos mapeamentos.

Atente-se que não pode ser alterado mapeamentos padrões, para o Datasul e Pims - sendo que na próxima atualização do TOTVS RH Clock-In os mapeamentos padrões serão carregados.

Com a implantação das pipelines, que utiliza conversão de dados entre as camadas dos dados da Plataforma usando códigos SQL em vez de regras de mapeamentos, os usuários podem ser criados automaticamente quando um novo funcionário for incluído/integrado ao Clock-In. 

É possível habilitar a criação automática dos usuários à partir dos settings, na plataforma, assim como o modelo que deve ser utilizado para tal. 

Saiba mais aqui!

04. CRIAÇÃO DE USUÁRIOS POR INVITE NA PLATAFORMA CAROL 

No último passo, vamos clicar em "Confirm", assim poderemos iniciar a definição das regras para criação dos usuários:

Image Removed

Na tela de confirmação, vamos clicar em "Add Mapping Rules" para iniciar a definição das regras:

Image Removed

Nos próximos passos vamos revisar os atributos necessários para criação e um usuário na plataforma Carol:

...

Este atributo pode receber os seguintes valores (através do set value - veja image abaixo):

TENANT_ADMIN_ROLE, APP_ADMIN_ROLE e BUSINESS_USER_ROLE

Para entender o objetivo de cada um dos papéis acima, consulte a documentação aqui.

...

Apenas caso o ambiente tenha privacidade de dados (Data Access Level) este atributo deverá ser definido. O valor deste atributo deve ser uma lista, separado por virgula, dos grupos que o usuário deve possuir.

Deve ser informado o nome do grupo criado em Environment Admin.

...

Campo obrigatório, define o e-mail para o login.

Não recomendamos a utilização de e-mails fakes (inexistentes). Sugerimos a utilização de alias de e-mails no caso que a criação de e-mails para cada funcionário é impeditivo por custos. Dessa forma, será criado vários pseudo e-mails apontando para a mesma caixa de e-mail, por exemplo:

[email protected]

[email protected]

E esses alias apontando para a mesma caixa de e-mail: [email protected].

Essa caixa de e-mail pode ser gerenciada por um responsável por gerir os alias acima criados.

Verifique com o sei time de infraestrutura ou tecnologia da informação para buscar apoio na criação dos alias de e-mail.

...

Este atributo define a senha do usuário. Qualquer atributo pode ser mapeado para definir a senha, como: telefone, matricula, etc.

Abaixo um exemplo do processo:

Image Removed

1. Define o atributo para definir a senha
2. Aplicado uma regra para definir a senha como sendo os últimos digitos do telefone
3. Ambiente para testar a regra e ver como ela funcionará em tempo de processamento dos dados.

...

O atributo que possui o código da empresa. Caso a unicidade da matricula do funcionaro depende de outro dado (estabelecimento) deve ser considerado a concatenação de ambos atributos.

Veja nesta documentação como o código da empresa é definido para cada produto.

...

A imagem abaixo mostra como efetuar o mapeamento de um atributo para alterar o valor, efetuando a definição de um dos valores padrões.

Na etapa "1" é efetuado o mapeamento de um atributo, podendo ser qualquer um atributo "string" (texto). No passo "2" é efetuado a utilização de uma regra de limpeza (selecionado na aba "Functions") para alterar o valor e efetuar a definição do papel correto.

Image Removed

Ao término do mapeamento, podemos clicar em "Map Summary" para visualizar o mapeamento como um todo:

Image Removed

Após podemos clicar em "Publish" para publicar o mapeamento:

Image Removed

Após esse passo os dados serão processados e os usuários criados. Você pode conferir os usuários criados clicando no menu do usuário (canto superior direito) e depois em Environment Admin:

Image Removed

Depois clique em "Users":

Image Removed

Os três pontos próximos ao usuário indica que ele foi criado através da integração com o Data Model User, contendo meta informação associado ao usuário. A meta informação é utilizada principalnente em regras de privacidade de dados.

Image Removed

Ao término você terá os usuários criados automaticamente para todos os registros na tabela "Staging Table" mapeado para o Data Model User.

03. MAPEAMENTO DE EXEMPLO PARA OS PRODUTOS PROTHEUS, RM DATASUL E PIMS

Abaixo é disponibilizado os arquivos de exemplo para o mapeamento e criação de usuários.

04 CUSTOMIZAÇÕES NO CLOCKIN

Segue abaixo quais mapeamentos são customizáveis:

• Conector TOTVS RM - regras de mapeamento da ppessoafunc_user → User 
• Conector TOTVS Protheus - regras de mapeamento da sra_user → User
• Conector TOTVS Datasul - regras de mapeamento da carol_func → User
• Novas stagings poderão ser criadas para que seja possível realizar a integração de informações customizadas para o Clockin para campos já existentes no DATA MODELS.

O que não pode ser customizado:

• DATA MODELS não poderão ser customizados pois ao atualizar realizar uma atualização do Backoffice as informações serão sobrepostas. Ex: campos novos nos DM (neste caso nem na User é possível inserir campos customizados).
• Mapeamentos pré-existentes no Clockin não poderá ser customizado pelo cliente (exceto o User). Caso sejam ao realizar uma atualização de versão os mapeamentos customizados serão sobrepostos.

05. PROCESSO DE ALTERAÇÃO DE E-MAIL E TELEFONE NO ERP 

Conforme descrito nos demais tópicos, a criação de usuários automáticos no Clock-in ocorre através da integração com o ERP e considera-se 2 campos como chaves: 

• e-mail 
• telefone

A atualização de informações do funcionário e usuários ocorre através da integração do 2C em que realiza a leitura dos dados atuais do funcionário na Plataforma Carol, não considerando históricos de alterações de determinados campos. Desta forma, ao realizar a alteração destes campos chaves, a plataforma entende como sendo novos usuários a serem criados.  Observar os seguintes pontos:

1. Para realizar a alteração destes campos (e-mail ou telefone) é necessário definir um processo de desativação do usuário anterior na plataforma Carol. Após realizar a alteração destes campos no ERP, siga os passos a seguir: 
   1. Acesse a Plataforma Carol 
   2. Acessar em Explorer a tabela Tabela Users. 
   3. Incluir um filtro através do e-mail ou telefone do funcionário para localizar o registro anterior. 
   4. Clicar no botão Editar 
   5. No Campo Ativo, desmarcá-lo para Inativo 
   6. Clicar no botão Salvar 
2.  Quando o e-mail é alterado e o telefone não, o registro ficará como rejeitado no Clockin. É possível consultar através de Explore > User > Record Type Rejected Record, filtrar pelo usuário com a situação. Para ajustar a situação no Clockin é necessário seguir os passos a seguir:
   1. Consultar o registro do usuário que encontra-se inativo (Explore > User > Record Type - Golden Record > Realizar um filtro pelo nome do usuário na opção Filter e confirmar a consulta. Neste momento irá trazer todos os usuários com esse nome 
   2. Selecionar o registro que está com o mesmo telefone que será está sendo atualizado no registro que foi rejeitado.
   3. Ao acessar o registro retirar o telefone do usuário que foi inativado e salvar o registro
   1. Acessar a consulta do registro rejeitado 
   2. Selecionar o registro do usuário que foi rejeitado na consulta
   3. Clicar no botão reprocessar
   4. Clicar no botão Copying to Staging. 
   5. O registro será salvo com sucesso na Golden Record do Usuário