Regras de Vinculação

Histórico de Alterações

Data	Quem	Comentários
08/04/2021	Anderson Gomes	Criação do documento

Necessidade

É preciso permitir que seja mais fácil a vinculação dos clientes acessíveis a venda por um usuário. Isso permitirá a vinculação direta sem a necessidade de adicionar outros filtros para se adequar a estrutura atual da GeoSales.

Estruturas de banco de dados

• Tabelas de entidades já existentes

CLIENTE
CD_CLIENTE

USUARIO
CD_USUARIO

TABELA_PRECO
CD_TAB_PRECO

ORGANIZACAO_VENDA
CD_ORG_VENDA

GRUPO_MPGTO
CD_GRUPO_MPGTO

PERFIL
CD_PERFIL

TIPO_MOVIMENTO_PEDIDO
CD_TIPO

• Tabelas novas de vinculações

CLIENTE_USUARIO
CD_CLIENTE
CD_USUARIO

CLIENTE_TAB_PRECO
CD_CLIENTE
CD_TAB_PRECO

USUARIO_TAB_PRECO
CD_USUARIO
CD_TAB_PRECO

CLIENTE_GRUPO_MPGTO
CD_CLIENTE
CD_GRUPO_MPGTO

USUARIO_ORG_VENDA
CD_USUARIO
CD_ORG_VENDA

• Tabelas de filtragens de dados já existentes

PERFIL_CANAL_VENDA
CD_PERFIL
CD_CANAL

CLIENTE_CANAL_VENDA
CD_CLIENTE
CD_CANAL

PERFIL_ORGANIZACAO_VENDA
CD_PERFIL
CD_ORG_VENDA

PERFIL_TIPO_PEDIDO
CD_PERFIL
CD_TIPO

PERFIL_USUARIO
CD_PERFIL
CD_USUARIO

TIPO_PEDIDO_TAB_PRECO
CD_TIPO
CD_TAB_PRECO

TAB_PRECO_RESTRICAO
CD_TAB_PRECO
CD_ORG_VENDA
CD_CANAL

ORGANIZACAO_VENDA_TIPO_PEDIDO
CD_ORG_VENDA
CD_TIPO

- Regras de resgate de dados do cabeçalho de pedido =

Basicamente deve ser feito um resgate dos dados sequencialmente e removendo os registros que não se enquadram na filtragem que está vinculada ao usuário. A busca de cliente deve ir na OVC inicialmente como é feita originalmente. Complementarmente deve ser feita a consulta na tabela CLIENTE_USUARIO passando o código do usuário logado como parâmetro.

Hoje já existem algumas filtragens para a escolha de informações do cabeçalho do pedido. A mudança proposta nesse documento visa permitir uma vinculação alternativa a vinculação atual usando a tabela ORG_VENDA_CLIENTE:

ORG_VENDA_CLIENTE
CD_ORG_VENDA
CD_CLIENTE
CD_VENDEDOR
CD_TAB_PRECO
CD_GRUPO_MPGTO

Agora será possível fazer a vinculação de forma mais flexível a fim de evitar a necessidade de uma grande quantidade de registros numa tabela centralizada.

Então para a vinculação de organização de venda, ela será definida através do perfil do usuário que irá efetuar a venda. Isso é mapeado na tabela PERFIL_ORGANIZACAO_VENDA. Existe, porém, uma situação onde o usuário logado é um usuário do papel gestor. Nessa situação o usuário pode tirar um pedido escolhendo um usuário do papel vendedor e tirar um pedido para os clientes dele. Assim, esse filtro para definição de quais organizações de venda são elegíveis deve ser feita em 2 etapas. Primeiro devem ser filtradas as organizações de vendas que o perfil do usuário do vendedor escolhido tem acesso. Depois disso, deve ser aplicado o mesmo filtro só que agora será usado os dados da tabela que estão vinculados ao perfil do usuário logado. Obviamente, dependendo do cadastro, podem existir casos em que não haja interseção entre os dados dos dois usuários. No caso de ser um usuário do papel cliente, a regra deve ser aplicada da mesma forma, habilitando somente as organizações que o perfil tenha vinculação. Ainda falando sobre a organização de venda, existe um outro ponto de filtragem relacionado. Após a escolha da a organização de venda no cabeçalho, serão filtrados os tipos de pedidos válidos que são definidos na tabela ORGANIZACAO_VENDA_TIPO_PEDIDO.

Para a entidade de tabela de preço existirão as seguintes tabelas para filtragem dos dados:

1. CLIENTE_TAB_PRECO
2. USUARIO_TAB_PRECO
3. TIPO_PEDIDO_TAB_PRECO (JÁ EXISTE)
4. TAB_PRECO_RESTRICAO (JÁ EXISTE)

Basicamente cada uma delas atuará para definição de quais tabelas de preço são elegíveis para escolha durante a venda. É plausível ter uma personalização das tabelas de preço tanto por cliente como por usuário. Então deverão ser criadas as tabelas para vinculação com cliente e com usuário. Tendo isso como base, o sistema deve minerar nas duas tabelas quais são as elegíveis usando como parâmetro o usuário logado e o cliente selecionado para a venda. Nesse contexto, existe o cenário de um usuário com o papel gestor estar tirando um pedido para um cliente de um de seus vendedores supervisionados. Assim, deverá haver uma validação extra, onde as tabelas de preço também serão filtradas na tabela USUARIO_TAB_PRECO para o usuário do vendedor escolhido. Existe também a filtragem das tabelas de preço pelo tipo de pedido escolhido no cabeçalho. A tabela TIPO_PEDIDO_TAB_PRECO recebe as vinculações que definem as tabelas que se correlacionam com os tipos e vice versa. A tabela TAB_PRECO_RESTRICAO adiciona algumas restrições mais específicas. Nessa tabela, existem os filtros CD_ORG_VENDA, CD_CANAL, CD_PRACA.

Já para a escolha dos clientes que o usuário pode ver, deve ser preenchida a tabela CLIENTE_USUARIO. Então, aparecerão para a venda todos os clientes que estiverem vinculados ao usuário logado. Quando o usuário for um gestor, aparecerão para ele os clientes que estão vinculados aos usuários dos vendedores supervisionados por ele. Também é possível que um gestor tenha outros gestores subordinados a ele em sua hierarquia, a forma de trabalhar, vai ser semelhante, o usuário desse gestor vai poder ver todos os clientes vinculados aos usuários vendedores subordinados aos gestores subordinados ao gestor do usuário logado.

Com relação ao grupo de meio de pagamento, a navegação agora será definida através da tabela CLIENTE_GRUPO_MPGTO. Aqui existirá a definição de quais grupos de meio de pagamento o cliente terá acesso no momento da tiragem de pedido.

Essas novas regras de vinculação serão uma exceção, pois ainda manteremos a vinculação pela organização de venda. Então o algorito deverá olhar a tabela ORG_VENDA_CLIENTE (OVC) e seguir os passos citados acima para buscar as mesmas informações que eram obtidas pela OVC e agora também poderão ser buscadas por esse novo modelo. Isso permitirá que os clientes antigos não precisem alterar suas integrações e os clientes novos possam utilizar a nova forma de vinculação.

Para que essa alteração seja finalizada, grande parte do sistema deve ser modificada. A maior parte do sistema trabalha usando a OVC para analisar as vinculações. Permitir novas formas de vinculação, vai ocasionar que todo canto onde houver vinculação com a OVC, seja adicionado a nova vinculação dependendo do contexto. Na pesquisa de clientes, deve ser adicionada a tabela USUARIO_CLIENTE, na escolha de dados do cabeçalho, devem ser adicionadas todas as outras novas tabelas referentes a esse contexto.

Deve ser atentado alguns pontos:

• Funções de sincronismo (SYNC_TABELA_FUNCAO)
• Consultas de relatórios
• Validações no cabeçalho do pedido
• Validações nos cards e nas telas de gestão de equipe
• Pesquisa de cliente
• Pesquisa de pedidos
• Buscas em geral de dados de pedido

Uma outra preocupação pertinente nessa customização é sobre performance. As consultas modificadas devem seguir os padrões previamente estipulados, não trazendo colunas desnecessárias e utilizando o WITH (NOLOCK) quando for aplicável.

GeoSales

Setor	Aprovado Por	Data
Desenvolvimento - GeoSales	Pessoa que aprovou	00/00/0000
Integração - GeoSales	Pessoa que aprovou	00/00/0000
Configurações - GeoSales	Pessoa que aprovou	00/00/0000

Empresa solicitante

Setor	Aprovado Por	Data	Assinatura
Gerente TI - Cliente	Pessoa que aprovou	00/00/0000
Gerente de Projeto - Cliente	Pessoa que aprovou	00/00/0000
Gerente Comercial - Cliente	Pessoa que aprovou	00/00/0000