6.5 KiB

Raw Blame History

Head em relação a quem? — Investigação

Situação atual

O perfil Head no SGMP aprova rascunhos enviados por qualquer gestor: no dashboard, usuários com perfil HEAD veem todas as solicitações em status AGUARDANDO_HEAD, sem filtro por “seus” gestores.
Ou seja: não existe hoje nenhuma regra que vincule um Head a um conjunto de gestores. A pergunta “ele é Head em relação a quem?” ainda não está respondida no código.

O que precisamos para filtrar

Para que um Head só aprove solicitações dos gestores que estão sob sua responsabilidade, é necessário ter em algum lugar a relação Head ↔ Gestores. Por exemplo:

“Head (matrícula X) é superior dos gestores (matrículas A, B, C)”, ou
“Gestor (matrícula A) tem gestor imediato Head (matrícula X)”.

No SGMP:

Solicitação tem solicitante (FK para UsuarioSistema).
UsuarioSistema (gestor ou head) tem matricula e perfil.
Login é feito via Winthor; o username do Django é a matrícula vinda do Winthor, e o UsuarioSistema é identificado por essa matricula.

Ou seja: temos matrícula do gestor (solicitante) e matrícula do Head (usuário logado). Falta uma fonte de verdade que diga qual Head é responsável por qual gestor.

Fontes possíveis: RM e Winthor

1. TOTVS RM (SQL Server)

O RM tem conceitos de hierarquia e gestor imediato:
- Chefia tradicional: cadastro de chefes/supervisores (em algum campo ou tabela auxiliar).
- Hierarquia por posição (versões mais recentes): estrutura por posição/cargo.
Em muitos clientes RM, a tabela PFUNC (ou tabelas relacionadas) expõe o “gestor imediato” do funcionário, por exemplo:
- Campo do tipo CHAPAGERENTE (ou CHAPA_CHEFE, CODGERENTE, etc.) na PFUNC, ou
- Tabela específica de chefia (ex.: PSUPERV, ou tabelas de “Hierarquia por Posição”).
Hoje no SGMP: em intf_sqlserver.py a PFUNC é usada para listar colaboradores (CHAPA, NOME, CPF, CODSECAO, CODFUNCAO, etc.). Nenhuma coluna de gestor imediato / chefia é utilizada.
PessoaRM no SGMP guarda id_rm (CODCOLIGADA-CHAPA) e matricula (CHAPA). Não há campo “gestor imediato” ou “chapa do head”.

Conclusão RM:
É provável que o RM já tenha condições de dizer “este funcionário (CHAPA) tem gestor imediato (CHAPA do chefe)”, mas isso depende de:

(1) O cliente ter preenchido a chefia no RM (campo/tabela de gestor imediato ou hierarquia por posição).
(2) Sabermos o nome exato da coluna/tabela (ex.: CHAPAGERENTE na PFUNC, ou tabela de hierarquia). Isso só pode ser confirmado no banco do RM (lista de colunas da PFUNC ou documentação do ambiente).

Se existir, por exemplo, PFUNC.CHAPAGERENTE:

Dado o gestor (solicitante), precisamos obter a CHAPA dele no RM. O vínculo Gestor SGMP → RM pode ser: UsuarioSistema.matricula = CHAPA no RM (se a matrícula do Winthor for a mesma CHAPA), ou um mapeamento explícito (ex.: PessoaRM por matrícula/CPF).
Com a CHAPA do gestor, consultamos no RM o CHAPAGERENTE (ou equivalente) desse registro. Esse valor seria a “CHAPA do Head” no RM.
No SGMP, o Head logado tem UsuarioSistema.matricula. Se essa matrícula for a mesma que a CHAPA do gestor imediato no RM (ou houver mapeamento), podemos filtrar: “mostrar só solicitações cujo solicitante tem gestor imediato = usuário logado (Head)”.

2. Winthor (Oracle)

No SGMP, Winthor é usado para:
- Login: autenticar_usuario(login, senha) consulta PCEMPR (MATRICULA, USUARIOBD, NOME, EMAIL, CPF, CODFILIAL, SITUACAO).
- Dados do colaborador: buscar_colaborador_oracle(cpf) também em PCEMPR (MATRICULA, NOME, CPF, SITUACAO, ENDERECO, etc.).
No pipeline pipeline_rm_winthor_ad.json aparecem CODFILIAL, CODSETOR, SITUACAO; não há campo de gestor / superior / hierarquia.
Não foi encontrada na documentação consultada referência a campo de “gestor imediato” ou “superior” na tabela PCEMPR do Winthor. Seria necessário:
- Consultar o dicionário de dados ou DBA do Oracle do Winthor no seu ambiente, ou
- Confirmar com a TOTVS/equipe de sistemas se existe tabela/campo de hierarquia no Winthor que possa ser usada para “Head de quem”.

Conclusão Winthor:
Com o que o SGMP usa hoje (PCEMPR para login e busca por CPF), não há evidência de que já tenhamos condição de saber “Head em relação a quem” apenas pelo Winthor. Pode existir em outro schema/tabela; isso exige verificação no ambiente.

Resumo

Fonte	Hoje no SGMP	Possível usar para “Head de quem”?
RM	PFUNC sem campo de chefia	Sim, se existir e estiver preenchido um campo/tabela de gestor imediato (ex.: CHAPAGERENTE). Confirmar no banco do cliente.
Winthor	PCEMPR para login e dados básicos	Inconclusivo. Não há uso de hierarquia. Verificar se existe tabela/campo de superior no Oracle do Winthor.

Próximos passos recomendados

No banco RM (SQL Server)
- Listar as colunas da tabela PFUNC (ou consultar GCAMPOS onde TABELA = 'PFUNC') e procurar por colunas como CHAPAGERENTE, CHAPA_CHEFE, CODGERENTE, ou equivalente.
- Se existir: verificar se está preenchido para os gestores que devem ter Head; definir se a matrícula do Head no SGMP será a CHAPA do RM ou se será preciso mapear (ex.: por CPF ou por outro identificador).
No Winthor (Oracle)
- Verificar se PCEMPR ou outra tabela possui campo de “matrícula do superior” / “gestor imediato”.
- Se sim, definir como cruzar com UsuarioSistema (matrícula do Head) para filtrar solicitações.
No SGMP
- Manter por enquanto o comportamento atual (Head vê todas as solicitações AGUARDANDO_HEAD) até existir uma fonte confiável de “Head ↔ Gestores”.
- Quando houver essa fonte (RM e/ou Winthor):
  - Implementar função (ex.: em intf_sqlserver.py ou intf_winthor.py) que, dado o Head (matrícula ou id), retorne a lista de matrículas dos gestores sob sua responsabilidade (ou que, dado o gestor, retorne a matrícula do Head).
  - No dashboard_view (e onde mais listar solicitações para Head), filtrar: Solicitacao.objects.filter(status=AGUARDANDO_HEAD, solicitante__matricula__in=matriculas_dos_gestores_do_head) (ou equivalente).

Este arquivo pode ser usado como referência para a decisão e para a implementação futura do vínculo “Head em relação a quem”.

6.5 KiB Raw Blame History