CONTEÚDO
01. RECOMENDAÇÕES PROCEDIMENTO RECONHECIMENTO FACIAL
Este capítulo descreve algumas recomendações para melhorar o fluxo do Clock-In em dispositivos Mobile e dispositivos Kiosk.
- 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.
02. 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.
| Produto | Tabela (Staging Table) |
|---|---|
| TOTVS RM | A tabela "pfcompl" está disponível para ser mapeada com o Data Model "User" para determinar regra de criação dos usuários. |
| TOTVS Protheus | A tabela "sra_employee" está disponível para ser mapeada com o Data Model "User" para determinar regra de criação dos usuários. |
| TOTVS Datasul | Mapeamento para o Data Model de usuários (user) liberado por padrão pelo TOTVS RH Clock-In. A tabela "carol_func" do produto Datasul é integrada automaticamente com a plataforma Carol, criando os usuários automaticamente. |
| TOTVS Pims | Mapeamento para o Data Model de usuários (user) liberado por padrão pelo TOTVS RH Clock-In. A tabela "aut_critica" do produto Pims é integrado automaticamente com a plataforma Carol, criando os usuários automaticamente. |
| Senior | Nenhuma tabela preparada. Deve ser efetuado a sincronização da tabela com os dados dos usuários a serem criados. |
Tabela especifica para criação de usuários
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.
Um usuário por dispositivo
O produto TOTVS RH Clock-In possui uma restrição não permitindo o mesmo usuário com login em múltiplos dispositivos. Desta forma, deverá ser criado um usuário para cada dispositivo (e funcionário) utilizado.
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):
Depois clique em "Map & Cleanse":
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:
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:
Mapeamentos de exemplo
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.
No último passo, vamos clicar em "Confirm", assim poderemos iniciar a definição das regras para criação dos usuários:
Na tela de confirmação, vamos clicar em "Add Mapping Rules" para iniciar a definição das regras:
Nos próximos passos vamos revisar os atributos necessários para criação e um usuário na plataforma Carol:
| Atributo | Sugestão mapeamento (RM) | Considerações |
|---|---|---|
| Name | nomecracha | Atributo para definir o nome do usuário na plataforma Carol. |
| User Roles | <não necessário definir> | 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. |
| Locale | nomecracha | O valor padrão é "en_US", por isso é necessário alterar o valor para "pt_BR" (veja o exemplo após essa tabela em como efetuar a definição deste valor). |
| Should Send Welcome Email | <não necessário definir> | Valor padrão não enviará o e-mail de boas vindas. Se for necessário o envio, defina o valor para "true" conforme mencionado no passo anterior. |
| Groups | <não necessário definir> | 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. Aqui é informado o grupo utilizado para restringir acesso ao Backoffice e para a segmentação de dados para os dispositivos. |
| Login | 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: 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. | |
| Password | telefone | 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:
|
| Should Create User | nomecracha | Deve ser alterado o valor deste atributo para "true", assim o usuário será criado. |
| Phone Number | <não necessário definir> | Este atributo é obrigatório apenas caso o envio dos recibos seja por SMS, caso contrário não é necessário mapear. |
| Is Active | nomecracha | Deve ser alterado o valor deste atributo para "true", assim o usuário estará ativo. |
| Tax ID | codcoligada | 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. |
| Country | <não necessário definir> | País do usuário que será criado. |
| Enable Self Clock-In | <não necessário definir> | Caso o self clockin seja configurado por usuário, essa configuração no usuário vai sobrescrever a configuração definida no Carol App Setting. |
| Disable Team Clock-In | <não necessário definir> | Caso o team clockin seja configurado por usuário, essa configuração no usuário vai sobrescrever a configuração definida no Carol App Setting. |
| Enable Geofence Employee Level | <não necessário definir> | Configuração a nível do usuário para informar que a Geo Localização (Cerca virtual) será tratada para este usuário pelo endereço da empresa (empresa ligada ao dispositivo). |
| Enable Geofence Location Level | <não necessário definir> | Configuração a nível do usuário para informar que a Geo Localização (Cerca virtual) será tratada para este usuário pelos endereços definidos no local de acesso ligado ao dispositivo. |
| Enable Geofence Company Level | <não necessário definir> | Configuração a nível do usuário para informar que a Geo Localização (Cerca virtual) será tratada para este usuário pelo endereço do funcionário |
| Cost Center | <não necessário definir> | Importante caso seja utilizado para privacidade de dados (Data Access Level). |
| Person Id | <não necessário definir> | |
| Data Admissão | data de admissão | Necessário para determinar o contrato mais ativo do funcionário, caso ele tenha transferências ou contratos inativos. |
| Employee Code | chapa | Matrícula do funcionário. |
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.
Ao término do mapeamento, podemos clicar em "Map Summary" para visualizar o mapeamento como um todo:
Após podemos clicar em "Publish" para publicar o mapeamento:
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:
Depois clique em "Users":
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.
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.
rm_dm_user_ppessoafunc.jsonrm_dm_user_pfcompl.jsonprotheus_dm_user.jsonpims_dm_user.jsondatasul_dm_user.json
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:
- 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:
- 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:
- Acesse a Plataforma Carol
- Acessar em Explorer a tabela Tabela Users.
- Incluir um filtro através do e-mail ou telefone do funcionário para localizar o registro anterior.
- Clicar no botão Editar
- No Campo Ativo, desmarcá-lo para Inativo
- Clicar no botão Salvar
- 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:
- 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
- Selecionar o registro que está com o mesmo telefone que será está sendo atualizado no registro que foi rejeitado.
- Ao acessar o registro retirar o telefone do usuário que foi inativado e salvar o registro
- Acessar a consulta do registro rejeitado
- Selecionar o registro do usuário que foi rejeitado na consulta
- Clicar no botão reprocessar
- Clicar no botão Copying to Staging.
- O registro será salvo com sucesso na Golden Record do Usuário
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas