GeoSales - Contribuições do(a) usuário(a) [pt-br]

Arquivo:Relatocio camil.png

2017-08-18T18:29:44Z

Inaldofranca:

Nova Hierarquia de Aprovação

2017-07-10T22:42:26Z

Inaldofranca: /* 2 - Visão das alçadas inferiores */

Nova Hierarquia de Aprovação

2017-07-10T22:41:07Z

Inaldofranca: /* Visão da Alçada que irá Autorizar o Pedido */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_PLACAR_APROVACAO ''' estiver ativada, caso não exista a configuração, seguirá o fluxo normal já existente do Portal do Supervisor.

'''[RN2]''' - A Alçada inferior poderá dar o voto nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_TIPO_PLACAR. Se a alçada inferior der o voto negando o pedido, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_TIPO_PLACAR.

'''[RN3]''' - Os valores do campo '''CD_TIPO_PLACAR''' de cada pedido serão Contados e informados no placar que aparecerá somente para o supervisor de alçada correta para aprovar o pedido..

'''[RN4]''' - A alçada correta, além de ver o Placar de autorização daquele pedido, também precisa saber quais foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_USUARIO''' da tabela '''PEDIDO_TIPO_PLACAR'''.

'''[RN5]''' - A alçada correta para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_TIPO_PLACAR que fará o controle do placar.

== Protótipos ==

=== Visão da Alçada que irá Autorizar o Pedido ===

Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no voto das outras alçadas. Inclusive com o nome dos usuários

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:40:52Z

Inaldofranca: /* Visão da Alçada que irá Autorizar o Pedido */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_PLACAR_APROVACAO ''' estiver ativada, caso não exista a configuração, seguirá o fluxo normal já existente do Portal do Supervisor.

'''[RN2]''' - A Alçada inferior poderá dar o voto nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_TIPO_PLACAR. Se a alçada inferior der o voto negando o pedido, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_TIPO_PLACAR.

'''[RN3]''' - Os valores do campo '''CD_TIPO_PLACAR''' de cada pedido serão Contados e informados no placar que aparecerá somente para o supervisor de alçada correta para aprovar o pedido..

'''[RN4]''' - A alçada correta, além de ver o Placar de autorização daquele pedido, também precisa saber quais foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_USUARIO''' da tabela '''PEDIDO_TIPO_PLACAR'''.

'''[RN5]''' - A alçada correta para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_TIPO_PLACAR que fará o controle do placar.

== Protótipos ==

=== Visão da Alçada que irá Autorizar o Pedido ===
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no voto das outras alçadas. Inclusive com o nome dos usuários

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:39:56Z

Inaldofranca: /* 1 - Visão da Alçada de aprovação do pedido */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_PLACAR_APROVACAO ''' estiver ativada, caso não exista a configuração, seguirá o fluxo normal já existente do Portal do Supervisor.

'''[RN2]''' - A Alçada inferior poderá dar o voto nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_TIPO_PLACAR. Se a alçada inferior der o voto negando o pedido, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_TIPO_PLACAR.

'''[RN3]''' - Os valores do campo '''CD_TIPO_PLACAR''' de cada pedido serão Contados e informados no placar que aparecerá somente para o supervisor de alçada correta para aprovar o pedido..

'''[RN4]''' - A alçada correta, além de ver o Placar de autorização daquele pedido, também precisa saber quais foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_USUARIO''' da tabela '''PEDIDO_TIPO_PLACAR'''.

'''[RN5]''' - A alçada correta para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_TIPO_PLACAR que fará o controle do placar.

== Protótipos ==

=== Visão da Alçada que irá Autorizar o Pedido ===
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:38:43Z

Inaldofranca: /* Eventos */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_PLACAR_APROVACAO ''' estiver ativada, caso não exista a configuração, seguirá o fluxo normal já existente do Portal do Supervisor.

'''[RN2]''' - A Alçada inferior poderá dar o voto nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_TIPO_PLACAR. Se a alçada inferior der o voto negando o pedido, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_TIPO_PLACAR.

'''[RN3]''' - Os valores do campo '''CD_TIPO_PLACAR''' de cada pedido serão Contados e informados no placar que aparecerá somente para o supervisor de alçada correta para aprovar o pedido..

'''[RN4]''' - A alçada correta, além de ver o Placar de autorização daquele pedido, também precisa saber quais foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_USUARIO''' da tabela '''PEDIDO_TIPO_PLACAR'''.

'''[RN5]''' - A alçada correta para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_TIPO_PLACAR que fará o controle do placar.

== Protótipos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:38:23Z

Inaldofranca: /* Regras de Negócio */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_PLACAR_APROVACAO ''' estiver ativada, caso não exista a configuração, seguirá o fluxo normal já existente do Portal do Supervisor.

'''[RN2]''' - A Alçada inferior poderá dar o voto nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_TIPO_PLACAR. Se a alçada inferior der o voto negando o pedido, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_TIPO_PLACAR.

'''[RN3]''' - Os valores do campo '''CD_TIPO_PLACAR''' de cada pedido serão Contados e informados no placar que aparecerá somente para o supervisor de alçada correta para aprovar o pedido..

'''[RN4]''' - A alçada correta, além de ver o Placar de autorização daquele pedido, também precisa saber quais foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_USUARIO''' da tabela '''PEDIDO_TIPO_PLACAR'''.

'''[RN5]''' - A alçada correta para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_TIPO_PLACAR que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:32:42Z

Inaldofranca:

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Cenários ==

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:31:30Z

Inaldofranca: /* Solução */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

== Pré Condições ==
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:31:07Z

Inaldofranca: /* Fluxo de Eventos */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

=== Pré Condições ===
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:30:38Z

Inaldofranca: /* Pré Condições */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

=== Pré Condições ===
1. Habilitar Configuração:
:: DS_CHAVE = ID_UTILIZA_PLACAR_APROVACAO
:: DS_VALOR = 'S'

2. Criar a estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor que não tem permissão para aprovar o pedido votar a favor ou contra um determinado, essa informação será alimentada na tabela PEDIDO_TIPO_PLACAR vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o CD_PEDIDO_PALM na tabela PEDIDO_TIPO_PLACAR e CD_TIPO_PLACAR para montagem do placar, alem de trazer o nome do usuário que votou em cada situação, como mostra as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo já existente hoje, tanto para autorização do pedido, como para visualização.

==Fluxo de Eventos==

=== Fluxo 01 ===
Fluxo aprovação Diretor
 
#Vendedor entra no GeoSales
#Vendedor faz um pedido
#Um dos itens vendido foi aplicado desconto de 10%
#Pelo cadastro de alçadas, esse pedido ficará pendente de aprovação da Alçada Diretoria. '''''[RE1]'''''
#No entanto pela nova regra de Hierarquia qualquer aprovador, independente da alçada, conseguirá visualizar aquele pedido.
#O Diretor visualiza o item pendente, porém esta com dúvidas se deve ou não aprova-lo.
#Neste momento o Diretor consulta o resultado da analise feita pelos outros aprovadores.'''''[PROTÓTIPO 1]'''''
#Baseado nesse resultado o diretor tem duas opções: Aprovar o pedido ou Rejeitar.

=== Fluxo 02 ===
Fluxo de analise das alçadas inferiores(Gerente Regional) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada da Diretoria.
#Porém o Gerente Regional também consegue visualizar aquele pedido.
#Após analisar a venda ele tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda.'''''[PROTÓTIPO 2]'''''
#O aceite do Gerente Regional não implicará na aprovação do pedido.
#O resultado da analise do Gerente Regional será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente Regional aceita a venda.

=== Fluxo 03 ===
Fluxo de analise das alçadas inferiores(Gerente II) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada Diretoria.
#O Gerente Regional já fez a sua analise e o resultado esta a disposição do Diretor. '''''[PROTÓTIPO 1]'''''
#O Gerente II também visualiza o pedido e faz a analise do mesmo.
#Após analisar a venda ele também tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda. '''''[PROTÓTIPO 2]'''''
#O aceite do Gerente II não implicará na aprovação do pedido.
#O resultado da analise do Gerente II será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente II rejeita o desconto.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:23:55Z

Inaldofranca: /* Pré Condições */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

=== Pré Condições ===
HABILITAR CONFIGURACAO: ID_UTILIZA_PLACAR_APROVACAO = 'S'

Para atender essa demanda,será necessário construir uma estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || VARCHAR (30) || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor de alçada inferior do pedido der o aceite ou o negado daquele pedido, essa informação será alimentada na tabela PEDIDO_APROVACAO_TIPO vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o cd_pedido_palm na tabela PEDIDO_APROVACAO_TIPO e cd_aprovacao_tipo para montagem do placar, alem de trazer o nome do usuário que voltou em cada situação, como mostrar as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo ja existem hoje,tanto para autorização do pedido, como para visualização.

==Fluxo de Eventos==

=== Fluxo 01 ===
Fluxo aprovação Diretor
 
#Vendedor entra no GeoSales
#Vendedor faz um pedido
#Um dos itens vendido foi aplicado desconto de 10%
#Pelo cadastro de alçadas, esse pedido ficará pendente de aprovação da Alçada Diretoria. '''''[RE1]'''''
#No entanto pela nova regra de Hierarquia qualquer aprovador, independente da alçada, conseguirá visualizar aquele pedido.
#O Diretor visualiza o item pendente, porém esta com dúvidas se deve ou não aprova-lo.
#Neste momento o Diretor consulta o resultado da analise feita pelos outros aprovadores.'''''[PROTÓTIPO 1]'''''
#Baseado nesse resultado o diretor tem duas opções: Aprovar o pedido ou Rejeitar.

=== Fluxo 02 ===
Fluxo de analise das alçadas inferiores(Gerente Regional) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada da Diretoria.
#Porém o Gerente Regional também consegue visualizar aquele pedido.
#Após analisar a venda ele tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda.'''''[PROTÓTIPO 2]'''''
#O aceite do Gerente Regional não implicará na aprovação do pedido.
#O resultado da analise do Gerente Regional será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente Regional aceita a venda.

=== Fluxo 03 ===
Fluxo de analise das alçadas inferiores(Gerente II) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada Diretoria.
#O Gerente Regional já fez a sua analise e o resultado esta a disposição do Diretor. '''''[PROTÓTIPO 1]'''''
#O Gerente II também visualiza o pedido e faz a analise do mesmo.
#Após analisar a venda ele também tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda. '''''[PROTÓTIPO 2]'''''
#O aceite do Gerente II não implicará na aprovação do pedido.
#O resultado da analise do Gerente II será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente II rejeita o desconto.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:21:24Z

Inaldofranca: /* Pré Condições */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

=== Pré Condições ===
HABILITAR CONFIGURACAO: ID_UTILIZA_PLACAR_APROVACAO = 'S'

Para atender essa demanda,será necessário construir uma estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do Tipo do Placar
|-
| DS_TIPO_PLACAR || Varchar || Não || Sim || Descrição do Tipo de Placar
|-
|}

Tabela: '''PEDIDO_TIPO_PLACAR'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || bigint || Sim || Sim || Código do pedido
|-
| CD_USUARIO || INT || Sim || Sim || Código do usuário que está relacionado ao supervisor
|-
| CD_TIPO_PLACAR || INT || Sim || Sim || Código do tipo de placar do pedido
|-
| DS_OBS_PLACAR || VARCHAR(300) || Não || Não || Observação do Voto
|-
| DT_PLACAR || DATETIME || Não || Sim || Data e hora que foi registrado o Placar.
|}

Desta forma cada vez que um supervisor de alçada inferior do pedido der o aceite ou o negado daquele pedido, essa informação será alimentada na tabela PEDIDO_APROVACAO_TIPO vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o cd_pedido_palm na tabela PEDIDO_APROVACAO_TIPO e cd_aprovacao_tipo para montagem do placar, alem de trazer o nome do usuário que voltou em cada situação, como mostrar as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo ja existem hoje,tanto para autorização do pedido, como para visualização.

==Fluxo de Eventos==

=== Fluxo 01 ===
Fluxo aprovação Diretor
 
#Vendedor entra no GeoSales
#Vendedor faz um pedido
#Um dos itens vendido foi aplicado desconto de 10%
#Pelo cadastro de alçadas, esse pedido ficará pendente de aprovação da Alçada Diretoria. '''''[RE1]'''''
#No entanto pela nova regra de Hierarquia qualquer aprovador, independente da alçada, conseguirá visualizar aquele pedido.
#O Diretor visualiza o item pendente, porém esta com dúvidas se deve ou não aprova-lo.
#Neste momento o Diretor consulta o resultado da analise feita pelos outros aprovadores.'''''[PROTÓTIPO 1]'''''
#Baseado nesse resultado o diretor tem duas opções: Aprovar o pedido ou Rejeitar.

=== Fluxo 02 ===
Fluxo de analise das alçadas inferiores(Gerente Regional) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada da Diretoria.
#Porém o Gerente Regional também consegue visualizar aquele pedido.
#Após analisar a venda ele tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda.'''''[PROTÓTIPO 2]'''''
#O aceite do Gerente Regional não implicará na aprovação do pedido.
#O resultado da analise do Gerente Regional será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente Regional aceita a venda.

=== Fluxo 03 ===
Fluxo de analise das alçadas inferiores(Gerente II) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada Diretoria.
#O Gerente Regional já fez a sua analise e o resultado esta a disposição do Diretor. '''''[PROTÓTIPO 1]'''''
#O Gerente II também visualiza o pedido e faz a analise do mesmo.
#Após analisar a venda ele também tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda. '''''[PROTÓTIPO 2]'''''
#O aceite do Gerente II não implicará na aprovação do pedido.
#O resultado da analise do Gerente II será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente II rejeita o desconto.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Nova Hierarquia de Aprovação

2017-07-10T22:14:53Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
| 27/06/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 28/06/2017 || Leonardo Garcez || Alteração conforme solicitado - Inclusão dados Pré Condições
|-
| 04/07/2017 || Leonardo Garcez || Alteração conforme solicitado - Modificações nos dados Pré Condições
|-
| 10/07/2017 || Leonardo Sousa || Revisão Arquitetura
|-
| 10/07/2017 || Inaldo França || Ajustes realizados
|}

==Necessidade==

Atualmente a cadeia de aprovação não tem visão do pedido e um acompanhamento do restante dos supervisores. Com isso dificulta a aprovação e analise do pedido. O sistema deixa visível o pedido apenas para os supervisores com alçada que possa autorizar, supervisores com menor alçada não tem essa visão e não participam do processo de avaliação de forma direta, mas de forma indireta eles são consultados por telefone colaborando com a avaliação.

== Solução ==

O GeoSales possibilitara uma visão do pedido pendente para toda a cadeia de aprovação, mesmo para supervisores que não podem autoriza-los.
Para supervisores que não puderem aprovar, o sistema possibilitará que o mesmo possa colaborar com a analise do pedido. Essa colaboração será através de um sistema de votos, onde o supervisor sem alçada poderá apenas votar pela aprovação ou rejeição.
Para supervisores com alçada para aprovar o sistema exibirá o placar com o resultados dos votos, auxiliando na tomada de decisão.

=== Pré Condições ===
HABILITAR CONFIGURACAO: ID_UTILIZA_PLACAR_APROVACAO = 'S'

Para atender essa demanda,será necessário construir uma estrutura para receber os dados. A estrutura deve conter as informações abaixo:

Tabela: '''APROVACAO_TIPO'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_TIPO || INT || Sim || Sim || Código do Tipo de Aprovação
|-
| DS_TIPO_APROVACAO || Varchar || Não || Sim || Descrição do tipo de Aprovação (ACEITO OU NEGADO)
|-
|}

Tabela: '''PEDIDO_APROVACAO_TIPO'''

{| class="wikitable"
! DESCRIÇÃO
! TIPO
! CHAVE
! OBRIGATÓRIO
! DESCRIÇÃO
|-
| CD_PEDIDO_PALM || Varchar || Sim || Sim || Código do pedido
|-
| CD_APROVADOR || Varchar || Sim || Sim || Código do aprovador do pedido
|-
| CD_APROVACAO_TIPO || INT || Sim || Sim || Código do tipo de aprovação do pedido
|-
|}

Desta forma cada vez que um supervisor de alçada inferior do pedido der o aceite ou o negado daquele pedido, essa informação será alimentada na tabela PEDIDO_APROVACAO_TIPO vinculando o pedido através do Código do Pedido.

Para montar o placar em que o Supervisor irá analisar para liberar o pedido, o desenvolvedor irá verificar o cd_pedido_palm na tabela PEDIDO_APROVACAO_TIPO e cd_aprovacao_tipo para montagem do placar, alem de trazer o nome do usuário que voltou em cada situação, como mostrar as imagens na Visão da Alçada de aprovação do pedido que está neste documento.

Na ausência da configuração ID_UTILIZA_PLACAR_APROVACAO ou a mesma igual a N, o funcionamento da hierarquia de aprovação seguirá o fluxo padrão e nativo ja existem hoje,tanto para autorização do pedido, como para visualização.

==Fluxo de Eventos==

=== Fluxo 01 ===
Fluxo aprovação Diretor
 
#Vendedor entra no GeoSales
#Vendedor faz um pedido
#Um dos itens vendido foi aplicado desconto de 10%
#Pelo cadastro de alçadas, esse pedido ficará pendente de aprovação da Alçada Diretoria. '''''[RE1]'''''
#No entanto pela nova regra de Hierarquia qualquer aprovador, independente da alçada, conseguirá visualizar aquele pedido.
#O Diretor visualiza o item pendente, porém esta com dúvidas se deve ou não aprova-lo.
#Neste momento o Diretor consulta o resultado da analise feita pelos outros aprovadores.'''''[PROTÓTIPO 1]'''''
#Baseado nesse resultado o diretor tem duas opções: Aprovar o pedido ou Rejeitar.

=== Fluxo 02 ===
Fluxo de analise das alçadas inferiores(Gerente Regional) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada da Diretoria.
#Porém o Gerente Regional também consegue visualizar aquele pedido.
#Após analisar a venda ele tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda.'''''[PROTÓTIPO 2]'''''
#O aceite do Gerente Regional não implicará na aprovação do pedido.
#O resultado da analise do Gerente Regional será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente Regional aceita a venda.

=== Fluxo 03 ===
Fluxo de analise das alçadas inferiores(Gerente II) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada Diretoria.
#O Gerente Regional já fez a sua analise e o resultado esta a disposição do Diretor. '''''[PROTÓTIPO 1]'''''
#O Gerente II também visualiza o pedido e faz a analise do mesmo.
#Após analisar a venda ele também tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda. '''''[PROTÓTIPO 2]'''''
#O aceite do Gerente II não implicará na aprovação do pedido.
#O resultado da analise do Gerente II será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente II rejeita o desconto.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores, mas somente quando a configuração '''ID_UTILIZA_NOVA_HIERARQUIA''' estiver ativada.

'''[RN2]''' - Na ausência da configuração '''ID_UTILIZA_NOVA_HIERARQUIA = 'S'''', o comportamento de visualização dos pedidos permanece o atual, apenas o supervisor que tem alçada, poderá visualizar.

'''[RN3]''' - A Alçada inferior poderá dar o “OK” nesse pedido através do botão '''''AUTORIZAR ITENS'''''. Esse processo não fará com que o pedido seja aprovado. Todavia será populado na tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 1.

'''[RN4]''' - Se a alçada inferior não der o “OK”, ou seja, clicando no botão '''''NEGAR ITENS'''''. Esse processo não vai rejeitar o pedido, porém irá popular a tabela PEDIDO_APROVACAO_TIPO o valor CD_APROVACAO_TIPO = 2.

'''[RN5]''' - Os valores do campo '''CD_APROVACAO_TIPO''' de cada pedido serão somados e informados no placar que aparecerá somente para a ALÇADA verdadeira do pedido.

'''[RN6]''' - A alçada original além de ver o Placar de autorização daquele pedido, também precisa saber quem foram os aprovadores que votaram. Isso pode ser realizado através do campo '''CD_APROVADOR''' da tabela '''PEDIDO_APROVACAO_TIPO'''.

'''[RN7]''' - A alçada com permissão para autorizar ou rejeitar o pedido, ao fazer um dos processos irá modificar o '''ID_AUTORIZADO''' da tabela '''pedido''' e não a tabela PEDIDO_APROVACAO_TIPO que fará o controle do placar.

==Eventos ==

=== 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Página principal

2017-06-29T17:43:30Z

Inaldofranca:

[[softsite|Sobre a SoftSite]]

'''Sessões'''
*[[Integração]]
*[[Arquitetura]]
*[[Suporte]]
*[[Infraestrutura]]
*[[Processos]]
*[[Projetos]]
*[[Comercial]]
*[[Marketing]]
*[[Qualidade]]
*[[Desenvolvimento]]
*[[Operações]]
*[[Sugestões do produto]]
*[[Produto]]
*[[Scritps Úteis]]
*[[Tópicos Interessantes]]
*[[Treinamentos]]
*[[Funcionalidades]]
*[[Template Funcionalidade]]
*[[Ramais]]
Veja as [[versões]]

Veja as [http://10.0.0.32/wiki/index.php/Categoria:Funcionalidade funcionalidades]

O Anderson vai preencher [[configuração GitLab|a marmota para receber emails no novo GitLab]].

Destaques sobre [[novo sincronismo]]

Células

2017-06-29T17:43:21Z

Inaldofranca: Limpou toda a página

Jericoacoara

2017-06-29T17:43:04Z

Inaldofranca: Limpou toda a página

Processo Padrão de Gerenciamento de Projetos

2017-06-29T17:39:52Z

Inaldofranca: /* Fluxo do Processo */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 29/06/2017 || Inaldo França || Criação do Documento
|-
| 29/06/2017 || Victor César || Desenho do Processo
|-
|}

=== Fluxo do Processo ===

[[Arquivo:Processo de Gestão de Projetos - SoftSIte.png]]

=== Dicionário do Processo ===
'''1. Processo Comercial'''
:Será enviado para a célula todas as informações que foram negociadas com o cliente.

* Documentos de Entrada:
:::i. Formulário de Aderência
:::ii. Ficha do Projeto
:::iii. Proposta aceita pelo Cliente

* Documentos de Saída:
:::i. Ficaha do Projeto Atualizada

'''2. Reunião de Abertura'''
:Será realizada a apresentação da metodologia Softsite como também como será a condução do projeto de implantação GeoSales.

*Documentos de Entrada:
:::i. Apresentação Padrão de Reunião de Abertura

*Documentos que devem ser enviados para o cliente:
:::i. Documento de Infraestrutura
:::ii. Documento de Análise Técnica

'''3. Reunião de Levantamento de Requisitos (GeoSales Padrão)'''
:Reunião com o cliente para validar as informações contidas do documento de Análise Técnica e tirar todas as dúvidas que possam existir. Essa etapa é crítica, pois nessa etapa definirá o ESCOPO do projeto.

* Documentos de Entrada
:::i. Análise Técnica pré preenchido pelo cliente.

*Documentos que devem ser gerados:
:::i. Análise Técnica
:::ii. Atualização da Ficha do Projeto

'''4. Reunião de Levantamento de Requisitos (Customizações)'''
:Reunião com o cliente para entendimento das customizações que foram identificadas nas etapas, Processo Comercial e no documento de Análise Técnica.
* Documento que devem ser gerados e aprovados
:::i. Documentação da Funcionalidade na Wiki
::::::a. Essa documentação deve ter o aceite da Arquitetura como também do Cliente
:::ii. Atualização da Ficha do Projeto

'''5. Definir Escopo e Cronograma'''

* Documentos de Entrada
:::i. Análise Técnica
:::ii. Ficha do Projeto

* Documentos que devem ser gerados e aprovados:
:::i. Documento de Escopo do Projeto
:::ii. Cronograma do Projeto
:::iii. Ficha do Proejeto Atualizada

'''6. Execução'''
:Nesse processo será onde o projeto será desenvolvido. O Líder Técnico deve validar se todos os itens que foram levantados na Ficha Técnica foram desenvolvidos/integrados.

* Documentos de Entrada:
:::i. Escopo do Projeto
:::ii. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Atualização da Ficha do Projeto
:::ii. E-mail com o OK do Líder Técnico

'''7. Validação'''
:Nesse processo será onde o cliente validará o projeto. O Líder Técnico deve acompanhar e apoiar a homologação junto ao cliente.

*Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Plano de Ação dos Ajustes concluído
:::ii. Documento de Aceite da Homologação

'''8. Realizar Virada'''
:Nesse processo será realizada todas as configurações necessárias para a virada para o ambiente de produção do cliente.

* Documentos de Entrada
:::i. Ficha do Projeto

* Documentos que devem ser Gerados
:::i. Atualização da Ficha do Projeto

'''9. Aplicar Treinamento'''
:Nesse processo o Líder técnico viaja até o cliente para aplicar o treinamento de forma remota. O Treinamento de preferência deve ser realizado com todo o ambiente em produção já Configurada.

* Documentos de Entrada:
:::i. Solicitação de Viagem

* Documentos que devem ser gerados:
:::i. Documento de Encerramento do Projeto
:::ii. Relatório de Visita ao Cliente

'''10. Repasse Suporte'''
:Nesse processo a célula informará ao cliente que o mesmo será atendido pela equipe de suporte.

* Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. E-mail enviado ao cliente formalizando entrada ao Suporte.

Processo Padrão de Gerenciamento de Projetos

2017-06-29T17:38:32Z

Inaldofranca: /* Dicionário do Processo */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 29/06/2017 || Inaldo França || Criação do Documento
|-
| 29/06/2017 || Victor César || Desenho do Processo
|-
|}

=== Fluxo do Processo ===
[[Arquivo:Processo de Gestão de Projetos - SoftSIte.png]]

=== Dicionário do Processo ===
'''1. Processo Comercial'''
:Será enviado para a célula todas as informações que foram negociadas com o cliente.

* Documentos de Entrada:
:::i. Formulário de Aderência
:::ii. Ficha do Projeto
:::iii. Proposta aceita pelo Cliente

* Documentos de Saída:
:::i. Ficaha do Projeto Atualizada

'''2. Reunião de Abertura'''
:Será realizada a apresentação da metodologia Softsite como também como será a condução do projeto de implantação GeoSales.

*Documentos de Entrada:
:::i. Apresentação Padrão de Reunião de Abertura

*Documentos que devem ser enviados para o cliente:
:::i. Documento de Infraestrutura
:::ii. Documento de Análise Técnica

'''3. Reunião de Levantamento de Requisitos (GeoSales Padrão)'''
:Reunião com o cliente para validar as informações contidas do documento de Análise Técnica e tirar todas as dúvidas que possam existir. Essa etapa é crítica, pois nessa etapa definirá o ESCOPO do projeto.

* Documentos de Entrada
:::i. Análise Técnica pré preenchido pelo cliente.

*Documentos que devem ser gerados:
:::i. Análise Técnica
:::ii. Atualização da Ficha do Projeto

'''4. Reunião de Levantamento de Requisitos (Customizações)'''
:Reunião com o cliente para entendimento das customizações que foram identificadas nas etapas, Processo Comercial e no documento de Análise Técnica.
* Documento que devem ser gerados e aprovados
:::i. Documentação da Funcionalidade na Wiki
::::::a. Essa documentação deve ter o aceite da Arquitetura como também do Cliente
:::ii. Atualização da Ficha do Projeto

'''5. Definir Escopo e Cronograma'''

* Documentos de Entrada
:::i. Análise Técnica
:::ii. Ficha do Projeto

* Documentos que devem ser gerados e aprovados:
:::i. Documento de Escopo do Projeto
:::ii. Cronograma do Projeto
:::iii. Ficha do Proejeto Atualizada

'''6. Execução'''
:Nesse processo será onde o projeto será desenvolvido. O Líder Técnico deve validar se todos os itens que foram levantados na Ficha Técnica foram desenvolvidos/integrados.

* Documentos de Entrada:
:::i. Escopo do Projeto
:::ii. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Atualização da Ficha do Projeto
:::ii. E-mail com o OK do Líder Técnico

'''7. Validação'''
:Nesse processo será onde o cliente validará o projeto. O Líder Técnico deve acompanhar e apoiar a homologação junto ao cliente.

*Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Plano de Ação dos Ajustes concluído
:::ii. Documento de Aceite da Homologação

'''8. Realizar Virada'''
:Nesse processo será realizada todas as configurações necessárias para a virada para o ambiente de produção do cliente.

* Documentos de Entrada
:::i. Ficha do Projeto

* Documentos que devem ser Gerados
:::i. Atualização da Ficha do Projeto

'''9. Aplicar Treinamento'''
:Nesse processo o Líder técnico viaja até o cliente para aplicar o treinamento de forma remota. O Treinamento de preferência deve ser realizado com todo o ambiente em produção já Configurada.

* Documentos de Entrada:
:::i. Solicitação de Viagem

* Documentos que devem ser gerados:
:::i. Documento de Encerramento do Projeto
:::ii. Relatório de Visita ao Cliente

'''10. Repasse Suporte'''
:Nesse processo a célula informará ao cliente que o mesmo será atendido pela equipe de suporte.

* Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. E-mail enviado ao cliente formalizando entrada ao Suporte.

Processo Padrão de Gerenciamento de Projetos

2017-06-29T17:37:27Z

Inaldofranca: /* Dicionário do Processo */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 29/06/2017 || Inaldo França || Criação do Documento
|-
| 29/06/2017 || Victor César || Desenho do Processo
|-
|}

=== Fluxo do Processo ===
[[Arquivo:Processo de Gestão de Projetos - SoftSIte.png]]

=== Dicionário do Processo ===
1. Processo Comercial
:Será enviado para a célula todas as informações que foram negociadas com o cliente.

* Documentos de Entrada:
:::i. Formulário de Aderência
:::ii. Ficha do Projeto
:::iii. Proposta aceita pelo Cliente

* Documentos de Saída:
:::i. Ficaha do Projeto Atualizada

2. Reunião de Abertura
:Será realizada a apresentação da metodologia Softsite como também como será a condução do projeto de implantação GeoSales.

*Documentos de Entrada:
:::i. Apresentação Padrão de Reunião de Abertura

*Documentos que devem ser enviados para o cliente:
:::i. Documento de Infraestrutura
:::ii. Documento de Análise Técnica

3. Reunião de Levantamento de Requisitos (GeoSales Padrão)
:Reunião com o cliente para validar as informações contidas do documento de Análise Técnica e tirar todas as dúvidas que possam existir. Essa etapa é crítica, pois nessa etapa definirá o ESCOPO do projeto.

* Documentos de Entrada
:::i. Análise Técnica pré preenchido pelo cliente.

*Documentos que devem ser gerados:
:::i. Análise Técnica
:::ii. Atualização da Ficha do Projeto

4. Reunião de Levantamento de Requisitos (Customizações)
:Reunião com o cliente para entendimento das customizações que foram identificadas nas etapas, Processo Comercial e no documento de Análise Técnica.
* Documento que devem ser gerados e aprovados
:::i. Documentação da Funcionalidade na Wiki
::::::a. Essa documentação deve ter o aceite da Arquitetura como também do Cliente
:::ii. Atualização da Ficha do Projeto

5. Definir Escopo e Cronograma

* Documentos de Entrada
:::i. Análise Técnica
:::ii. Ficha do Projeto

* Documentos que devem ser gerados e aprovados:
:::i. Documento de Escopo do Projeto
:::ii. Cronograma do Projeto
:::iii. Ficha do Proejeto Atualizada

6. Execução
:Nesse processo será onde o projeto será desenvolvido. O Líder Técnico deve validar se todos os itens que foram levantados na Ficha Técnica foram desenvolvidos/integrados.

* Documentos de Entrada:
:::i. Escopo do Projeto
:::ii. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Atualização da Ficha do Projeto
:::ii. E-mail com o OK do Líder Técnico

7. Validação
:Nesse processo será onde o cliente validará o projeto. O Líder Técnico deve acompanhar e apoiar a homologação junto ao cliente.

*Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. Plano de Ação dos Ajustes concluído
:::ii. Documento de Aceite da Homologação

8. Realizar Virada
:Nesse processo será realizada todas as configurações necessárias para a virada para o ambiente de produção do cliente.

* Documentos de Entrada
:::i. Ficha do Projeto

* Documentos que devem ser Gerados
:::i. Atualização da Ficha do Projeto

9. Aplicar Treinamento
:Nesse processo o Líder técnico viaja até o cliente para aplicar o treinamento de forma remota. O Treinamento de preferência deve ser realizado com todo o ambiente em produção já Configurada.

* Documentos de Entrada:
:::i. Solicitação de Viagem

* Documentos que devem ser gerados:
:::i. Documento de Encerramento do Projeto
:::ii. Relatório de Visita ao Cliente

10. Repasse Suporte
:Nesse processo a célula informará ao cliente que o mesmo será atendido pela equipe de suporte.

* Documentos de Entrada:
:::i. Ficha do Projeto

* Documentos que devem ser gerados:
:::i. E-mail enviado ao cliente formalizando entrada ao Suporte.

Arquivo:Processo de Gestão de Projetos - SoftSIte.png

2017-06-29T17:31:21Z

Inaldofranca:

Frete Padrão

2017-06-14T21:08:15Z

Inaldofranca: /* Histórico de Revisões */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|-
| 14/06/2017 || Leonardo Sousa || Aprovação do Produto
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE_PADRAO da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário
:'''RN2''' - Se o campo do Frete Padrão não estiver preenchido aparecerá os dois tipos de frete normalmente seguindo a ordenação padrão do Sistema.

== Cenários ==

=== Cenário com Frete Padrão===
:Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

=== Cenário sem Frete Padrão===
:Tipo de Frete Padrão do Cliente não está preenchido

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: Vazio

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será o primeiro da tabela

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T21:06:22Z

Inaldofranca: /* Cenário com frete padrão */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE_PADRAO da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário
:'''RN2''' - Se o campo do Frete Padrão não estiver preenchido aparecerá os dois tipos de frete normalmente seguindo a ordenação padrão do Sistema.

== Cenários ==

=== Cenário com Frete Padrão===
:Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

=== Cenário sem Frete Padrão===
:Tipo de Frete Padrão do Cliente não está preenchido

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: Vazio

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será o primeiro da tabela

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T21:04:58Z

Inaldofranca: /* Regras de Negócio */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE_PADRAO da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário
:'''RN2''' - Se o campo do Frete Padrão não estiver preenchido aparecerá os dois tipos de frete normalmente seguindo a ordenação padrão do Sistema.

== Cenários ==

=== Cenário com frete padrão===
:Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T21:04:02Z

Inaldofranca: /* Integração */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE_PADRAO da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário com frete padrão===
:Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Ramais

2017-06-14T18:24:45Z

Inaldofranca: /* Ramais */

== Ramais ==
{| class="wikitable"
! ADM
! RAMAL
|-
| Jaqueline || 0464
|-
| Armando || 0462
|-
| Daniele || 0471
|-
| Camila Nunes || 0470
|-
| Sala de Reunião 2º Andar || 0461
|-
! COMERCIAL
! RAMAL
|-
| Isabelle || 0466
|-
| Jéssica || 0473
|-
| Ricardo || 0469
|-
! OPERAÇÕES
! RAMAL
|-
| Inaldo || 0475
|-
| Victor || 0476
|-
| Sala de Reunião 1º Piso || 0458
|-
! MARKETING
! RAMAL
|-
| Victoria / Henrique || 0467
|-
! SUPORTE
! RAMAL
|-
| Ellen || 0459
|-
| Jardel || 0456
|-
| Fábio José || 0455
|-
| Darlan || 0454
|-
! COPA
! RAMAL
|-
| Dº Lúcia || 0474
|-
! LEMBRETES
!
|-
| Puxar Ligação || 55
|-
| Verificar Ramal || *87*
|-
| Passar Ligação || Flash + Nº ramal
|-
| Voltar Ligação || Flash + #0
|}

Ramais

2017-06-14T18:24:04Z

Inaldofranca: /* Ramais */

== Ramais ==
{| class="wikitable"
! ADM
! RAMAL
|-
| Jaqueline || 0464
|-
| Armando || 0462
|-
| Daniele || 0471
|-
| Camila Nunes || 0470
|-
| Sala de Reunião 2º Andar || 0461
|-
! COMERCIAL
! RAMAL
|-
| Isabelle || 0466
|-
| Jéssica || 0473
|-
| Ricardo || 0469
|-
! OPERAÇÕES
! RAMAL
|-
| Inaldo || 0475
|-
| Shady || 0476
|-
| Sala de Reunião 1º Piso || 0458
|-
! MARKETING
! RAMAL
|-
| Victoria / Henrique || 0467
|-
! SUPORTE
! RAMAL
|-
| Ellen || 0459
|-
| Jardel || 0456
|-
| Fábio José || 0455
|-
| Darlan || 0454
|-
! COPA
! RAMAL
|-
| Dº Lúcia || 0474
|-
! LEMBRETES
!
|-
| Puxar Ligação || 55
|-
| Verificar Ramal || *87*
|-
| Passar Ligação || Flash + Nº ramal
|-
| Voltar Ligação || Flash + #0
|}

Incluir informações para aprovação no portal

2017-06-14T18:16:47Z

Inaldofranca: /* Detalhes da Solução */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/03/2017 || Leonardo Garcez || Criação do Documento
|-
| 07/06/2017 || Inaldo França || Ajustes após alinhamento com o cliente.
|-
| 14/06/2017 || Inaldo França || Ajustes Solicitados pelo Produto.
|-
|}

== Necessidade ==

Ter uma visibilidade melhor do pedido e dos itens no momento da aprovação, como o custo e o lucro bruto de cada item, passando para o gestor mais informações para a aprovação do pedido.

== Solução ==
Será habilitado a nova tela de análise de pedido no Portal GeoSales e será inserido a informação de custo para análise do item pendente.

=== Detalhes da Solução ===
Mostrar demais informações como:
:1. Código de Referência (Campo CD_REFERENCIA da Tabela ITEM_PEDIDO)
::* Código produto original do ERP
:2. Valor unitário
:3. Valor total
:4. Custo, Representará o Preço Sellin
:5. Margem de Lucro Bruto, Representará o MKP

===Integração===
* Para obtenção de algumas informações é necessário os seguintes ajustes na integração

: Sellin = Esta cadastrado na TABELA SZL do PROTHEUS, e deve ser integrada na tabela PRODUTO_CUSTO
: MKP = Será calculada no GeoSales precisa ser preenchida a tabela FAMILIA_PRODUTO_RENTABILIDADE

==== Detalhes das Assertivas ====

* Sellin - É uma taxa usada por categoria de pneus
* MKP - MarkUP é outra taxa interna da Campneus por categorias.

== Protótipos ==

1. Botão de Análise do Pedido no Relatório de Pedido

[[Arquivo:tela_aprovacao_botão.png]]

2. Informações de Cabeçalho do Pedido

[[Arquivo:tela_aprovação_cabeçalho.png]]

3. Informações de Itens do Pedido

[[Arquivo:tela_itens.png]]

Frete Padrão

2017-06-14T11:56:14Z

Inaldofranca: /* Cenário CIF */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário CIF ===
:Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T11:55:46Z

Inaldofranca: /* Solução */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

:Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
:Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

:Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário CIF ===
Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T11:55:28Z

Inaldofranca: /* Necessidade */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

:Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário CIF ===
Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T11:55:19Z

Inaldofranca: /* Regras de Negócio */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
:'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário CIF ===
Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T11:55:08Z

Inaldofranca: /* Solução */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

=== Regras de Negócio ===
'''RN1''' - Com o Frete padrão já selecionado o sistema não irá bloquear o usuário de alterar o frete caso necessário

== Cenários ==

=== Cenário CIF ===
Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Frete Padrão

2017-06-14T11:46:41Z

Inaldofranca: /* Implementação */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/06/2017 || Inaldo França || Criação do Documento
|}

== Necessidade ==

Ao selecionar o Cliente o sistema deve já preencher o Frete com o seu tipo de Frete Padrão preenchido em seu cadastro.

== Solução ==

Ao selecionar um cliente para atendimento, e criar um novo pedido para o mesmo, o sistema irá abrir a tela de cabeçalho do pedido e no campo de Frete já irá trazer preenchido o Frete Padrão que contém em seu cadastro.

=== Implementação ===
Para atender essa demanda, será necessário criar uma coluna na tabela CLIENTE chamada ID_TIPO_FRETE_PADRAO que receberá do ERP a informação do Frete padrão de cada cliente.

Após a informação está integrada será alterado a regra de negócio de seleção do frete para selecionar o frete padrão do cliente no momento do pedido.

=== Integração ===

# Preencher o campo ID_TIPO_FRETE da tabela CLIENTE com a informação do campo A1_TPFRET do cadastro de clientes do Protheus.

== Cenários ==

=== Cenário CIF ===
Tipo de Frete Padrão do Cliente é CIF

==== Dados ====
Vendedor: Carlos
Organização de Venda: 1
Cliente: João
Produto: 987
Tipo Frete Padrão: CIF

==== Operação ====

Carlos cria um novo pedido de venda para o cliente João

==== Assertiva ====

O tipo de frete que será exibido na tela será CIF

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| '''''Tecnologia da Informação'''''
| ''Marcello Campos''
|
|
|}

Incluir informações para aprovação no portal

2017-06-14T11:43:53Z

Inaldofranca: /* Histórico de Revisões */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/03/2017 || Leonardo Garcez || Criação do Documento
|-
| 07/06/2017 || Inaldo França || Ajustes após alinhamento com o cliente.
|-
| 14/06/2017 || Inaldo França || Ajustes Solicitados pelo Produto.
|-
|}

== Necessidade ==

Ter uma visibilidade melhor do pedido e dos itens no momento da aprovação, como o custo e o lucro bruto de cada item, passando para o gestor mais informações para a aprovação do pedido.

== Solução ==
Será habilitado a nova tela de análise de pedido no Portal GeoSales e será inserido a informação de custo para análise do item pendente.

=== Detalhes da Solução ===
Mostrar demais informações como:
:1. Código de Referência (Campo CD_REFERENCIA da Tabela ITEM_PEDIDO)
::* Código produto original do ERP
:2. Valor unitário
:3. Valor total
:4. Sellin (Custo)
:5. MKP (Margem de Lucro Bruto)

===Integração===
* Para obtenção de algumas informações é necessário os seguintes ajustes na integração

: Sellin = Esta cadastrado na TABELA SZL do PROTHEUS, e deve ser integrada na tabela PRODUTO_CUSTO
: MKP = Será calculada no GeoSales precisa ser preenchida a tabela FAMILIA_PRODUTO_RENTABILIDADE

==== Detalhes das Assertivas ====

* Sellin - É uma taxa usada por categoria de pneus
* MKP - MarkUP é outra taxa interna da Campneus por categorias.

== Protótipos ==

1. Botão de Análise do Pedido no Relatório de Pedido

[[Arquivo:tela_aprovacao_botão.png]]

2. Informações de Cabeçalho do Pedido

[[Arquivo:tela_aprovação_cabeçalho.png]]

3. Informações de Itens do Pedido

[[Arquivo:tela_itens.png]]

Incluir informações para aprovação no portal

2017-06-14T11:42:31Z

Inaldofranca: /* Pré Requisitos */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/03/2017 || Leonardo Garcez || Criação do Documento
|-
| 07/06/2017 || Inaldo França || Ajustes após alinhamento com o cliente.
|-
|}

== Necessidade ==

Ter uma visibilidade melhor do pedido e dos itens no momento da aprovação, como o custo e o lucro bruto de cada item, passando para o gestor mais informações para a aprovação do pedido.

== Solução ==
Será habilitado a nova tela de análise de pedido no Portal GeoSales e será inserido a informação de custo para análise do item pendente.

=== Detalhes da Solução ===
Mostrar demais informações como:
:1. Código de Referência (Campo CD_REFERENCIA da Tabela ITEM_PEDIDO)
::* Código produto original do ERP
:2. Valor unitário
:3. Valor total
:4. Sellin (Custo)
:5. MKP (Margem de Lucro Bruto)

===Integração===
* Para obtenção de algumas informações é necessário os seguintes ajustes na integração

: Sellin = Esta cadastrado na TABELA SZL do PROTHEUS, e deve ser integrada na tabela PRODUTO_CUSTO
: MKP = Será calculada no GeoSales precisa ser preenchida a tabela FAMILIA_PRODUTO_RENTABILIDADE

==== Detalhes das Assertivas ====

* Sellin - É uma taxa usada por categoria de pneus
* MKP - MarkUP é outra taxa interna da Campneus por categorias.

== Protótipos ==

1. Botão de Análise do Pedido no Relatório de Pedido

[[Arquivo:tela_aprovacao_botão.png]]

2. Informações de Cabeçalho do Pedido

[[Arquivo:tela_aprovação_cabeçalho.png]]

3. Informações de Itens do Pedido

[[Arquivo:tela_itens.png]]

Incluir informações para aprovação no portal

2017-06-14T11:41:51Z

Inaldofranca: /* Detalhes da Solução */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/03/2017 || Leonardo Garcez || Criação do Documento
|-
| 07/06/2017 || Inaldo França || Ajustes após alinhamento com o cliente.
|-
|}

== Necessidade ==

Ter uma visibilidade melhor do pedido e dos itens no momento da aprovação, como o custo e o lucro bruto de cada item, passando para o gestor mais informações para a aprovação do pedido.

== Solução ==
Será habilitado a nova tela de análise de pedido no Portal GeoSales e será inserido a informação de custo para análise do item pendente.

=== Pré Requisitos ===
# Habilitar a configuração ID_RENTABILIDADE

=== Detalhes da Solução ===
Mostrar demais informações como:
:1. Código de Referência (Campo CD_REFERENCIA da Tabela ITEM_PEDIDO)
::* Código produto original do ERP
:2. Valor unitário
:3. Valor total
:4. Sellin (Custo)
:5. MKP (Margem de Lucro Bruto)

===Integração===
* Para obtenção de algumas informações é necessário os seguintes ajustes na integração

: Sellin = Esta cadastrado na TABELA SZL do PROTHEUS, e deve ser integrada na tabela PRODUTO_CUSTO
: MKP = Será calculada no GeoSales precisa ser preenchida a tabela FAMILIA_PRODUTO_RENTABILIDADE

==== Detalhes das Assertivas ====

* Sellin - É uma taxa usada por categoria de pneus
* MKP - MarkUP é outra taxa interna da Campneus por categorias.

== Protótipos ==

1. Botão de Análise do Pedido no Relatório de Pedido

[[Arquivo:tela_aprovacao_botão.png]]

2. Informações de Cabeçalho do Pedido

[[Arquivo:tela_aprovação_cabeçalho.png]]

3. Informações de Itens do Pedido

[[Arquivo:tela_itens.png]]

Incluir informações para aprovação no portal

2017-06-14T11:41:35Z

Inaldofranca: Desfeita a edição 4229 de 10.0.0.107 (Discussão)

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 08/03/2017 || Leonardo Garcez || Criação do Documento
|-
| 07/06/2017 || Inaldo França || Ajustes após alinhamento com o cliente.
|-
|}

== Necessidade ==

Ter uma visibilidade melhor do pedido e dos itens no momento da aprovação, como o custo e o lucro bruto de cada item, passando para o gestor mais informações para a aprovação do pedido.

== Solução ==
Será habilitado a nova tela de análise de pedido no Portal GeoSales e será inserido a informação de custo para análise do item pendente.

=== Pré Requisitos ===
# Habilitar a configuração ID_RENTABILIDADE

=== Detalhes da Solução ===
1. Mostrar demais informações como:
:1. Código de Referência (Campo CD_REFERENCIA da Tabela ITEM_PEDIDO)
::* Código produto original do ERP
:2. Valor unitário
:3. Valor total
:4. Sellin (Custo)
:5. MKP (Margem de Lucro Bruto)

===Integração===
* Para obtenção de algumas informações é necessário os seguintes ajustes na integração

: Sellin = Esta cadastrado na TABELA SZL do PROTHEUS, e deve ser integrada na tabela PRODUTO_CUSTO
: MKP = Será calculada no GeoSales precisa ser preenchida a tabela FAMILIA_PRODUTO_RENTABILIDADE

==== Detalhes das Assertivas ====

* Sellin - É uma taxa usada por categoria de pneus
* MKP - MarkUP é outra taxa interna da Campneus por categorias.

== Protótipos ==

1. Botão de Análise do Pedido no Relatório de Pedido

[[Arquivo:tela_aprovacao_botão.png]]

2. Informações de Cabeçalho do Pedido

[[Arquivo:tela_aprovação_cabeçalho.png]]

3. Informações de Itens do Pedido

[[Arquivo:tela_itens.png]]

Nova Hierarquia de Aprovação

2017-06-13T21:01:21Z

Inaldofranca: /* Solução */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Leonardo Garcez || Criação do Documento
|-
|}

==Necessidade==

Tornar o processo de aprovação mais ágil, fazendo com que os supervisores de nível maior não precisem ligar para os supervisores de nível menor para saber se pode ou não aprovar um pedido, atualmente quando um pedido cai para uma alçada maior esse pedido não aparece para nenhum outro supervisor, forçando o supervisor a ter que ligar para os outros supervisores para saber se deve ou não aprovar um pedido.

== Solução ==
Será criado um novo controle de hierarquia para autorização dos pedidos pendentes onde '''TODOS''' os pedidos pendentes de aprovação ficarão disponíveis para visualização para '''TODAS''' as alçadas, inclusive aqueles de menor hierarquia.

Os aprovadores das alçadas menores só poderão dar o '''ACEITE''' ou '''REJEIÇÃO''' dos descontos praticados naquela venda e somente a alçada original do pedido terá a permissão de '''APROVAR''' ou '''REJEITAR''' o pedido como um todo.

Para a alçada original daquele pedido, será disponibilizado para ele um placar onde será possível consultar o resultado baseado nas respostas dos demais aprovadores.

== Características Gerais do Caso de Uso ==
=== Nome ===
Nova Hierarquia de aprovação dos pedidos
=== Descrição ===
Nova alçada para a Diretoria não precisar entrar em contato com supervisor para aprovar determinado pedido.

=== Atores ===
# Vendedores
# Gerente I
# Gerente II
# Gerente Regional
# Diretoria

=== Pré Condições ===

==Fluxo de Eventos==

=== Fluxo 01 ===
Fluxo aprovação Diretor
 
#Vendedor entra no GeoSales
#Vendedor faz um pedido
#Um dos itens vendido foi aplicado desconto de 10%
#Pelo cadastro de alçadas, esse pedido ficará pendente de aprovação da Alçada Diretoria. '''''[RE1]'''''
#No entanto pela nova regra de Hierarquia qualquer aprovador, independente da alçada, conseguirá visualizar aquele pedido.
#O Diretor visualiza o item pendente, porém esta com dúvidas se deve ou não aprova-lo.
#Neste momento o Diretor consulta o resultado da analise feita pelos outros aprovadores.'''''[PROTÓTIPO 1]'''''
#Baseado nesse resultado o diretor tem duas opções: Aprovar o pedido ou Rejeitar.

=== Fluxo 02 ===
Fluxo de analise das alçadas inferiores(Gerente Regional) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada da Diretoria.
#Porém o Gerente Regional também consegue visualizar aquele pedido.
#Após analisar a venda ele tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda.'''''[PROTÓTIPO 2]'''''
#O aceite do Gerente Regional não implicará na aprovação do pedido.
#O resultado da analise do Gerente Regional será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente Regional aceita a venda.

=== Fluxo 03 ===
Fluxo de analise das alçadas inferiores(Gerente II) baseado no Fluxo 01
 
#O pedido citado no fluxo 01 é da alçada Diretoria.
#O Gerente Regional já fez a sua analise e o resultado esta a disposição do Diretor. '''''[PROTÓTIPO 1]'''''
#O Gerente II também visualiza o pedido e faz a analise do mesmo.
#Após analisar a venda ele também tem duas opções: Concordar ou não concordar com o desconto praticado naquela venda. '''''[PROTÓTIPO 2]'''''
#O aceite do Gerente II não implicará na aprovação do pedido.
#O resultado da analise do Gerente II será enviado ao Diretor. '''''[PROTÓTIPO 1]'''''
#Neste caso o Gerente II rejeita o desconto.

==Regras de Negócio==

'''[RN1]''' - Os pedidos pendentes ficarão disponíveis para todas as alçadas, inclusive para as inferiores.

'''[RN2]''' - A Alçada inferior poderá dar um “OK” nesse pedido. Esse processo não fará com que o pedido seja aprovado. É somente uma ciência e o pedido voltará para a alçada correta.

'''[RN3]''' - Se a alçada inferior não der o “OK”, o pedido NÃO voltará para o vendedor corrigir. Voltará para a Alçada correta decidir o que fazer com esse pedido.

'''[RN4]''' - A alçada original deverá ver qual foi o supervisor que Aprovou ou Rejeitou o pedido.

==Requisitos Especiais ==

'''[RE1]''' – ALÇADAS CADASTRADAS PARA USO DOS FLUXOS:

# Diretoria – 100%
# Gerente Regional – 4%
# Gerente II – 3 %
# Gerente I – 2%

==Protótipos==

=== Protótipo 1 - Visão da Alçada de aprovação do pedido ===
:O Diretor que tem a maior alçada entra no portal de aprovação.
:Localiza o pedido que irá autorizar.
:Para fazer a consulta de aprovação das outras alçadas ele localiza e clica em '''PLACAR AUTORIZAÇÃO'''. Conforme imagem abaixo.

[[Arquivo:CAMIL-001.jpg|1000px]]

:Depois de clicar no botão o portal de aprovação irá disponibilizar o Placar atual de autorização baseado no aceite ou não das alçadas inferiores. Inclusive com o nome dos usuários que deram o '''OK''' ou o '''REJEITADO'''.

[[Arquivo:CAMIL-002.jpg|1000px]]

=== Protótipo 2 - Visão das alçadas inferiores ===
:Nesse Protótipo iremos mostrar a visão das alçadas inferiores a de aprovação do pedido onde o aprovador irá analisar o desconto dado no pedido e concordar ou negar com o que foi praticado. Esse voto irá gerar resultado na tela do placar de Autorização.
:Será disponibilizado ao aprovador dois botões:
* Autorizar Itens
* Negar Itens

NOTA: A AUTORIZAÇÃO NÃO IMPLICARÁ NO PEDIDO TODO APROVADO, ASSIM COMO O NEGADO NÃO IRÁ REJEITAR O PEDIDO.

[[Arquivo:CAMIL-003.jpg|1000px]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Rosana Chimabuco
|
|
|-
|
| Marcus Castellani
|
|
|}

Pedido de Remessa Futura

2017-06-13T20:09:47Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Início da Documentação
|-
| 13/06/2017 || Inaldo França || Finalização da Documentação
|-
| 13/06/2017 || Renato Lima || Revisão do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===
* Será preenchida a tabela ITEM_PED_REMESSA_FUTURA com as informações da tabela ADB (Contém informações dos Itens de Venda Futura)
** VR_SALDO é a informação do que foi vendido na VENDA FUTURA, será preenchida com a informação do campo ADB.ADB_QUANT.
** VR_SALDO_CONSUMIDO é a informação do que já foi usado da VENDA FUTURA, será preenchida com a informação do ADB.ADB_QTDEMP

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Venda Futura

2017-06-13T20:09:41Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 06/06/2017 || Inaldo França || Criação do Documento
|-
| 13/06/2017 || Inaldo França || Finalização da Documentação
|-
| 13/06/2017 || Renato Lima || Revisão do Documento
|-
|}

==Necessidade==
Ter disponível a opção do vendedor tirar um pedido para um determinado cliente e os itens desse pedido serem consumidos aos poucos de acordo com a necessidade do cliente. Esse tipo de pedido é caracterizado como Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado VENDA FUTURA onde ao ser selecionado o sistema irá realizar tratativas diferenciadas assim como a integração.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# O sistema deve possuir o tipo de venda futura previamente cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com o campo ID_TIPO_PEDIDO marcado com "VM".
# O parâmetro “ID_VALIDADE_PEDIDO_VENDA_FUTURA” parametrizado com a validade dos pedidos de venda futura

=== Happy Day ===
# O usuário inicia um pedido
# O sistema exibe os dados do cabeçalho do pedido
# Seleciona o tipo de pedido VENDA FUTURA
# O usuário insere itens no pedido
# O usuário salva o pedido realizado.
# O sistema exibe mensagem de pedido salvo com sucesso.

===Fluxo de Eventos===
[[Arquivo:fluxograma.png]]

===Regras de Negócio===
'''RN1''' – Os Pedidos de Venda futura deverão servir de base para os pedidos de remessa futura.

'''RN2''' – O tipo de venda futura irá ter as mesmas validações de um pedido comum.

'''RN3''' – Os pedidos de venda futura irão gerar títulos de acordo com as negociações com o cliente.
Ex: se na negociação o representante define que o cliente vai usar a condição de pagamento 30/60 o ERP vai gerar dois títulos a receber.

'''RN4''' – O parâmetro “ID_VALIDADE_PEDIDO_VENDA_FUTURA” define quantidade de meses que o pedido de venda futura vai valer a partir do dia em que o pedido foi feito, dessa forma todos os pedidos de remessa futura para esse pedido vão ter que ser realizados até o período determinado.
Ex: caso o parâmetro for definido com 12 o pedido de venda futura inserido no dia 15/05/2017 terá validade até 15/05/2018

'''RN5''' – Não deve permitir uma nova venda de venda futura enquanto estiver saldo a entregar do mesmo produto e mesmo cliente.
Ex: o sistema não pode fazer dois pedidos iguais enquanto um deles não for totalmente entregue. O sistema pode gerar pedidos de outros tipos de operações bonificações venda comum ou outra venda futura desde que não tenha os mesmos itens de outro pedido.

'''RN6''' – O parâmetro ID_NAO_VENDA_FUTURA_REPETICAO vai ser criado para definir tipos de repetição de pedidos de venda futura ‘I’ não permitirá repetições de itens, ‘P’ não permitira repetição de pedido, ‘N’ não haverá restrições

=== Protótipos ===
[[Arquivo:tela_mobile.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Venda Futura

2017-06-13T18:13:13Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 06/06/2017 || Inaldo França || Criação do Documento
|-
| 13/06/2017 || Inaldo França || Finalização da Documentação
|-
|}

==Necessidade==
Ter disponível a opção do vendedor tirar um pedido para um determinado cliente e os itens desse pedido serem consumidos aos poucos de acordo com a necessidade do cliente. Esse tipo de pedido é caracterizado como Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado VENDA FUTURA onde ao ser selecionado o sistema irá realizar tratativas diferenciadas assim como a integração.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# O sistema deve possuir o tipo de venda futura previamente cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com o campo ID_TIPO_PEDIDO marcado com "VM".
# O parâmetro “ID_VALIDADE_PEDIDO_VENDA_FUTURA” parametrizado com a validade dos pedidos de venda futura

=== Happy Day ===
# O usuário inicia um pedido
# O sistema exibe os dados do cabeçalho do pedido
# Seleciona o tipo de pedido VENDA FUTURA
# O usuário insere itens no pedido
# O usuário salva o pedido realizado.
# O sistema exibe mensagem de pedido salvo com sucesso.

===Fluxo de Eventos===
[[Arquivo:fluxograma.png]]

===Regras de Negócio===
'''RN1''' – Os Pedidos de Venda futura deverão servir de base para os pedidos de remessa futura.

'''RN2''' – O tipo de venda futura irá ter as mesmas validações de um pedido comum.

'''RN3''' – Os pedidos de venda futura irão gerar títulos de acordo com as negociações com o cliente.
Ex: se na negociação o representante define que o cliente vai usar a condição de pagamento 30/60 o ERP vai gerar dois títulos a receber.

'''RN4''' – O parâmetro “ID_VALIDADE_PEDIDO_VENDA_FUTURA” define quantidade de meses que o pedido de venda futura vai valer a partir do dia em que o pedido foi feito, dessa forma todos os pedidos de remessa futura para esse pedido vão ter que ser realizados até o período determinado.
Ex: caso o parâmetro for definido com 12 o pedido de venda futura inserido no dia 15/05/2017 terá validade até 15/05/2018

'''RN5''' – Não deve permitir uma nova venda de venda futura enquanto estiver saldo a entregar do mesmo produto e mesmo cliente.
Ex: o sistema não pode fazer dois pedidos iguais enquanto um deles não for totalmente entregue. O sistema pode gerar pedidos de outros tipos de operações bonificações venda comum ou outra venda futura desde que não tenha os mesmos itens de outro pedido.

'''RN6''' – O parâmetro ID_NAO_VENDA_FUTURA_REPETICAO vai ser criado para definir tipos de repetição de pedidos de venda futura ‘I’ não permitirá repetições de itens, ‘P’ não permitira repetição de pedido, ‘N’ não haverá restrições

=== Protótipos ===
[[Arquivo:tela_mobile.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-13T18:13:03Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Início da Documentação
|-
| 13/06/2017 || Inaldo França || Finalização da Documentação
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===
* Será preenchida a tabela ITEM_PED_REMESSA_FUTURA com as informações da tabela ADB (Contém informações dos Itens de Venda Futura)
** VR_SALDO é a informação do que foi vendido na VENDA FUTURA, será preenchida com a informação do campo ADB.ADB_QUANT.
** VR_SALDO_CONSUMIDO é a informação do que já foi usado da VENDA FUTURA, será preenchida com a informação do ADB.ADB_QTDEMP

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-13T18:12:10Z

Inaldofranca: /* Histórico de Revisões */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 13/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===
* Será preenchida a tabela ITEM_PED_REMESSA_FUTURA com as informações da tabela ADB (Contém informações dos Itens de Venda Futura)
** VR_SALDO é a informação do que foi vendido na VENDA FUTURA, será preenchida com a informação do campo ADB.ADB_QUANT.
** VR_SALDO_CONSUMIDO é a informação do que já foi usado da VENDA FUTURA, será preenchida com a informação do ADB.ADB_QTDEMP

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-13T18:10:19Z

Inaldofranca: /* Controle de Saldo */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===
* Será preenchida a tabela ITEM_PED_REMESSA_FUTURA com as informações da tabela ADB (Contém informações dos Itens de Venda Futura)
** VR_SALDO é a informação do que foi vendido na VENDA FUTURA, será preenchida com a informação do campo ADB.ADB_QUANT.
** VR_SALDO_CONSUMIDO é a informação do que já foi usado da VENDA FUTURA, será preenchida com a informação do ADB.ADB_QTDEMP

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-13T18:10:03Z

Inaldofranca: /* Integração */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

=== Controle de Saldo ===

===Integração===
* Será preenchida a tabela ITEM_PED_REMESSA_FUTURA com as informações da tabela ADB (Contém informações dos Itens de Venda Futura)
** VR_SALDO é a informação do que foi vendido na VENDA FUTURA, será preenchida com a informação do campo ADB.ADB_QUANT.
** VR_SALDO_CONSUMIDO é a informação do que já foi usado da VENDA FUTURA, será preenchida com a informação do ADB.ADB_QTDEMP

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-09T14:28:42Z

Inaldofranca: /* Regras de Negócio */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

=== Controle de Saldo ===

===Integração===

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-09T14:27:20Z

Inaldofranca: /* Regras de Negócio */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
'''RN1''' – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

'''RN2''' - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

'''RN3''' – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

'''RN4''' – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

'''RN5''' – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

'''RN6''' – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

'''RN7''' – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-09T14:23:01Z

Inaldofranca: /* Regras de Negócio */

=== Histórico de Revisões ===
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 09/06/2017 || Inaldo França || Criação do Documento
|-
|}

==Necessidade==
O Sistema precisa emitir pedidos de Remessa Futura, consumindo o saldo dos itens que foram vendidos no pedido de Venda Futura.

== Solução ==
Será criado um novo Tipo de Movimento chamado REMESSA FUTURA, Esse tipo de pedido só poderá ser selecionado se para aquele mesmo cliente existir um pedido de VENDA FUTURA. Após selecionar o tipo correto, o sistema irá carregas automaticamente as informações do pedido de VENDA FUTURA para o usuário escolher as quantidades dos itens que irão compor o pedido de REMESSA FUTURA.

=== Pré Condições ===
# O sistema deve possuir os clientes previamente cadastrados;
# O sistema deve possuir os produtos previamente cadastrados;
# O sistema deve possuir os vendedores previamente cadastrados e devidamente associados aos seus clientes;
# Tipo de pedido Remessa futura cadastrado na tabela TIPO_MOVIMENTO_PEDIDO com coluna ID_TIPO_PEDIDO marcado com ‘VF’;
# O sistema deve ter pedidos de VENDA FUTURA já cadastrados para o cliente para servir de base para o de REMESSA FUTURA;

=== Happy Day ===
# O usuário cria um novo pedido;
# O usuário seleciona o tipo pedido REMESSA FUTURA;
# O Sistema Carrega todas as informações do pedido de Venda Futura daquele Cliente.
# O Sistema preenche as informações do cabeçalho do pedido iguais o da VENDA FUTURA;
# O sistema abre tela já com os itens propostos do pedido de VENDA FUTURA selecionado
# O usuário modifica a quantidade ou remove itens.
# O usuário clica em salvar pedido
# O sistema salva o pedido.

===Fluxo de Eventos===
[[Arquivo:fluxograma_remessa1.png]]

===Regras de Negócio===
RN1 – O tipo de pedido Remessa Futura irá carregar todas as informações de cabeçalho do pedido de Venda Futura automaticamente, se o cliente tiver somente um pedido de Venda Futura ao selecionar o tipo remessa futura serão carregadas automaticamente todas as informações do pedido de venda futura em questão, incluindo os preços e produtos consumindo o saldo gerado no pedido de Venda Futura.

RN2 - Se o cliente tiver mais de um pedido de Venda Futura ao selecionar o tipo remessa futura os sistema vai exibir uma nova tela com todos os pedidos de venda futura que o cliente possui para o vendedor selecionar. Após definir o pedido de venda futura correto o sistema vai inseri o código desse pedido no campo pedido pai.

RN3 – Os pedidos de Remessa futura não gera Fatura: os preços dos itens praticados serão definidos pelo pedido de Venda Futura selecionado.

RN4 – Somente poderão ser inseridos no pedido de remessa futura, os itens e quantidades negociados no pedido de venda futura, ou seja, só poderão ser vendidos os itens no máximo até a quantidade que foi incluída no pedido pai.

RN5 – Serão exibidos na tela dos itens somente os itens vendidos no pedido de venda futura selecionado No código do pedido pai utilizando a quantidade vendida no venda futura como estoque.

RN6 – Um pedido de venda futura irá gerar um ou mais pedidos do tipo “Remessa Futura”

RN7 – Pedido de remessa futura não gera Duplicata, pois elas já foram geradas pelo pedido de venda futura.

===Integração===

=== Protótipos ===
[[Arquivo:prototipo1_remessa.png]]

== Aprovação ==

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

{| class="wikitable"
! style="width:200px" |Setor
! Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
|
| Leandro Pacheco
|
|
|-
|
| Marcelo Pacheco
|
|
|}

Pedido de Remessa Futura

2017-06-09T14:20:39Z

Inaldofranca: /* Regras de Negócio */