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

Discussão:Produtos Medicados

2021-06-24T19:25:50Z

Jeffque: Limpou toda a página

Precificação

2021-04-08T20:16:01Z

Jeffque: /* Campos de cadastro */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio usuário consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''' (a mesma lógica de cálculo das calculadoras HP 12 C), ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço tenha uma data inicial posterior à data atual, essa tabela de preço específica não deverá ser exibida para seleção no cadastro do pedido;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.

[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

=== Declaração de variáveis ===

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e está limitada ao máximo de 8 caracteres, sendo todos minúsculos obrigatoriamente, seguindo o padrão <code>[a-z0-9]</code>.
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
* As variáveis fs, fmm e fmx, especificamente, não poderão ser utilizadas, por tratarem-se de variáveis protegidas em uso no sistema.

==== Campos de cadastro ====

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

[[Arquivo:Tela2.jpg|500px]]

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.
* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

[[Arquivo:Tela3.jpg|500px]]

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

Sempre que uma das variáveis for alterada, para que ocorra atualização de valores da faixa de preço baseados na alteração, deve ser feito um reprocessamento baseado nos valores atualizados das variáveis.

Na aba de reprocessamento, sempre que houver uma solicitação de processamento devemos salvar as informações para eventual consulta. Ao entrar no detalhe podemos acompanhar o status do processamento.

[[Arquivo:Tela4.jpg|500px]]

== Cenários ==

===DICIONÁRIO DE DADOS ===

Considere tabela abaixo com as seguintes tabelas cadastradas e suas respectivas vigências:
{|class = "wikitable"
! TABELA
! DESCRIÇÃO
! INICIO DA VIGÊNCIA
! FINAL DA VIGÊNCIA
|-
| '''01''' || TABELA SP || 01/05/2020 || 01/01/2022
|-
| '''02''' || TABELA RJ || 01/05/2020 || 01/01/2022
|-
| '''03''' ||TABELA RS ||01/05/2020 || 01/01/2022
|-
| '''04''' || TABELA SP - CARREFU || 01/05/2020 || 01/01/2022
|-
| '''05''' || TABELA BA || 01/05/2020 || 01/01/2022
|-
| '''06''' || TABELA ES || 01/05/2020 || 01/01/2022
|-
| '''07''' || TABELA SP - CAPITAL ||01/05/2020 || 01/01/2022
|}

Selecionada a tabela desejada, o próximo passo é fazer a declaração das variáveis.
{|class = "wikitable"
! CHAVE
! DESCRIÇÃO DA VARIÁVEL
! TABELA / PRODUTO
! VALOR
|-
| '''pp''' || Preço de Partida || Tabela - 01 || R$ 106,00
|-
| '''fc''' || Cor / Tamanho || Produto - 001 || 1,5
|-
| '''ce''' ||Custo de Embalagem || Tabela - 01 || R$ 12,20
|-
| '''fr''' || Frete || Tabela - 01 || - 5
|-
| '''pr''' || Promotor || Tabela - 01 || 1,02
|-
| '''ou''' || Fator Quebra || Tabela - 01 || 3,5
|-
| '''cf''' || Contrato de Fidelidade || Tabela - 01 || 1,02
|}

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001' por um período de 6 meses.

No portal GeoSales, na tela de variáveis, serão utilizadas as seguintes informações:

'''Enumeração das variáveis''' 

Pelo exposto, temos que 7 variáveis foram declaradas. As fórmulas que devemos gerar (Fórmula de valor mínimo, fórmula de valor Sugerido e Fórmula de Valor Máximo) serão derivadas destas variáveis que apontamos.

Supondo que, para a fórmula de valor Sugerido, iremos adotar a seguinte fórmula:

<code>p = pp fc / * qu * cf *</code>

Com esta composição, o valor Sugerido do produto será '''''R$ 252,28'''''.

Supondo que, para a fórmula de valor Mínimo, iremos adotar a seguinte fórmula:

<code>p = pp fc /</code>

Com esta composição, o valor mínimo do produto será '''''R$ 70,66'''''.

Supondo que, para a fórmula de valor Máximo, iremos adotar a seguinte fórmula:

<code>p = pp fc / ce + fr + pr * qu * cf * </code>

Com esta composição, o valor máximo do produto será ''''' R$ 283,54'''''.



=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T20:02:39Z

Jeffque: /* Declaração de variáveis */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio usuário consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''' (a mesma lógica de cálculo das calculadoras HP 12 C), ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

=== Declaração de variáveis ===

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e está limitada ao máximo de 8 caracteres, sendo todos minúsculos obrigatoriamente, seguindo o padrão <code>[a-z0-9]</code>.
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
* As variáveis fs, fmm e fmx, especificamente, não poderão ser utilizadas, por tratarem-se de variáveis protegidas em uso no sistema.

==== Campos de cadastro ====

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.
* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

Sempre que uma das variáveis for alterada, para que ocorra atualização de valores da faixa de preço baseados na alteração, deve ser feito um reprocessamento baseado nos valores atualizados das variáveis.

Na aba de reprocessamento, sempre que houver uma solicitação de processamento devemos salvar as informações para eventual consulta. Ao entrar no detalhe podemos acompanhar o status do processamento.

== Cenários ==

===DICIONÁRIO DE DADOS ===

Considere tabela abaixo com as seguintes tabelas cadastradas e suas respectivas vigências:
{|class = "wikitable"
! TABELA
! DESCRIÇÃO
! INICIO DA VIGÊNCIA
! FINAL DA VIGÊNCIA
|-
| '''01''' || TABELA SP || 01/05/2020 || 01/01/2022
|-
| '''02''' || TABELA RJ || 01/05/2020 || 01/01/2022
|-
| '''03''' ||TABELA RS ||01/05/2020 || 01/01/2022
|-
| '''04''' || TABELA SP - CARREFU || 01/05/2020 || 01/01/2022
|-
| '''05''' || TABELA BA || 01/05/2020 || 01/01/2022
|-
| '''06''' || TABELA ES || 01/05/2020 || 01/01/2022
|-
| '''07''' || TABELA SP - CAPITAL ||01/05/2020 || 01/01/2022
|}

Selecionada a tabela desejada, o próximo passo é fazer a declaração das variáveis.
{|class = "wikitable"
! CHAVE
! DESCRIÇÃO DA VARIÁVEL
! TABELA / PRODUTO
! VALOR
|-
| '''Pp''' || Preço de Partida || Tabela - 01 || R$ 106,00
|-
| '''Fc''' || Fator de Conversão || Tabela - 01 || 1,5
|-
| '''Ce''' ||Custo de Embalagem || Tabela - 01 || R$ 12,20
|-
| '''Fr''' || Frete || Tabela - 01 || - 5
|-
| '''Pr''' || Promotor || Tabela - 01 || 1,02
|-
| '''Qu''' || Fator Quebra || Tabela - 01 || 3,5
|-
| '''Cf''' || Contrato de Fidelidade || Tabela - 01 || 1,02
|}

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001' por um período de 6 meses.

No portal GeoSales, na tela de variáveis, serão utilizadas as seguintes informações:

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}

Pelo exposto, temos que 7 variáveis foram declaradas. As fórmulas que devemos gerar (Fórmula de valor mínimo, fórmula de valor Sugerido e Fórmula de Valor Máximo) serão derivadas destas variáveis que apontamos.

Supondo que, para a fórmula de valor Sugerido, iremos adotar a seguinte fórmula:

<code>P = PpFc/*Qu*Cf*</code>

Com esta composição, o valor mínimo do produto será

Supondo que, para a fórmula de valor Mínimo, iremos adotar a seguinte fórmula:

<code>P = PpFc/</code>

Supondo que, para a fórmula de valor Máximo, iremos adotar a seguinte fórmula:

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T20:01:37Z

Jeffque: /* Solução */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio usuário consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''' (a mesma lógica de cálculo das calculadoras HP 12 C), ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

=== Declaração de variáveis ===

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e está limitada ao máximo de 8 caracteres, sendo todos minúsculos obrigatoriamente, seguindo o padrão [a-z0-9].
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
* As variáveis fs, fmm e fmx, especificamente, não poderão ser utilizadas, por tratarem-se de variáveis protegidas em uso no sistema.

==== Campos de cadastro ====

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.
* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

Sempre que uma das variáveis for alterada, para que ocorra atualização de valores da faixa de preço baseados na alteração, deve ser feito um reprocessamento baseado nos valores atualizados das variáveis.

Na aba de reprocessamento, sempre que houver uma solicitação de processamento devemos salvar as informações para eventual consulta. Ao entrar no detalhe podemos acompanhar o status do processamento.

== Cenários ==

===DICIONÁRIO DE DADOS ===

Considere tabela abaixo com as seguintes tabelas cadastradas e suas respectivas vigências:
{|class = "wikitable"
! TABELA
! DESCRIÇÃO
! INICIO DA VIGÊNCIA
! FINAL DA VIGÊNCIA
|-
| '''01''' || TABELA SP || 01/05/2020 || 01/01/2022
|-
| '''02''' || TABELA RJ || 01/05/2020 || 01/01/2022
|-
| '''03''' ||TABELA RS ||01/05/2020 || 01/01/2022
|-
| '''04''' || TABELA SP - CARREFU || 01/05/2020 || 01/01/2022
|-
| '''05''' || TABELA BA || 01/05/2020 || 01/01/2022
|-
| '''06''' || TABELA ES || 01/05/2020 || 01/01/2022
|-
| '''07''' || TABELA SP - CAPITAL ||01/05/2020 || 01/01/2022
|}

Selecionada a tabela desejada, o próximo passo é fazer a declaração das variáveis.
{|class = "wikitable"
! CHAVE
! DESCRIÇÃO DA VARIÁVEL
! TABELA / PRODUTO
! VALOR
|-
| '''Pp''' || Preço de Partida || Tabela - 01 || R$ 106,00
|-
| '''Fc''' || Fator de Conversão || Tabela - 01 || 1,5
|-
| '''Ce''' ||Custo de Embalagem || Tabela - 01 || R$ 12,20
|-
| '''Fr''' || Frete || Tabela - 01 || - 5
|-
| '''Pr''' || Promotor || Tabela - 01 || 1,02
|-
| '''Qu''' || Fator Quebra || Tabela - 01 || 3,5
|-
| '''Cf''' || Contrato de Fidelidade || Tabela - 01 || 1,02
|}

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001' por um período de 6 meses.

No portal GeoSales, na tela de variáveis, serão utilizadas as seguintes informações:

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}

Pelo exposto, temos que 7 variáveis foram declaradas. As fórmulas que devemos gerar (Fórmula de valor mínimo, fórmula de valor Sugerido e Fórmula de Valor Máximo) serão derivadas destas variáveis que apontamos.

Supondo que, para a fórmula de valor Sugerido, iremos adotar a seguinte fórmula:

<code>P = PpFc/*Qu*Cf*</code>

Com esta composição, o valor mínimo do produto será

Supondo que, para a fórmula de valor Mínimo, iremos adotar a seguinte fórmula:

<code>P = PpFc/</code>

Supondo que, para a fórmula de valor Máximo, iremos adotar a seguinte fórmula:

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T19:55:53Z

Jeffque: /* Necessidade */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio usuário consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

=== Declaração de variáveis ===

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e está limitada ao máximo de 8 caracteres, sendo todos minúsculos obrigatoriamente, seguindo o padrão [a-z0-9].
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
* As variáveis fs, fmm e fmx, especificamente, não poderão ser utilizadas, por tratarem-se de variáveis protegidas em uso no sistema.

==== Campos de cadastro ====

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

Sempre que uma das variáveis for alterada, para que ocorra atualização de valores da faixa de preço baseados na alteração, deve ser feito um reprocessamento baseado nos valores atualizados das variáveis.

== Cenários ==

===DICIONÁRIO DE DADOS ===

Considere tabela abaixo com as seguintes tabelas cadastradas e suas respectivas vigências:

{|class = "wikitable"
! TABELA
! DESCRIÇÃO
! INICIO DA VIGÊNCIA
! FINAL DA VIGÊNCIA
|-
| '''01''' || TABELA SP || 01/05/2020 || 01/01/2022
|-
| '''02''' || TABELA RJ || 01/05/2020 || 01/01/2022
|-
| '''03''' ||TABELA RS ||01/05/2020 || 01/01/2022
|-
| '''04''' || TABELA SP - CARREFU || 01/05/2020 || 01/01/2022
|-
| '''05''' || TABELA BA || 01/05/2020 || 01/01/2022
|-
| '''06''' || TABELA ES || 01/05/2020 || 01/01/2022
|-
| '''07''' || TABELA SP - CAPITAL ||01/05/2020 || 01/01/2022
|}

Selecionada a tabela desejada, o próximo passo é fazer a declaração das variáveis.

{|class = "wikitable"
! CHAVE
! DESCRIÇÃO DA VARIÁVEL
! TABELA / PRODUTO
! VALOR
|-
| '''Pp''' || Preço de Partida || Tabela - 01 || R$ 106,00
|-
| '''Fc''' || Fator de Conversão || Tabela - 01 || 1,5
|-
| '''Ce''' ||Custo de Embalagem || Tabela - 01 || R$ 12,20
|-
| '''Fr''' || Frete || Tabela - 01 || - 5
|-
| '''Pr''' || Promotor || Tabela - 01 || 1,02
|-
| '''Qu''' || Fator Quebra || Tabela - 01 || 3,5
|-
| '''Cf''' || Contrato de Fidelidade || Tabela - 01 || 1,02
|}

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001' por um período de 6 meses.

No portal GeoSales, na tela de variáveis, serão utilizadas as seguintes informações:

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}

Pelo exposto, temos que 7 variáveis foram declaradas. As fórmulas que devemos gerar (Fórmula de valor mínimo, fórmula de valor Sugerido e Fórmula de Valor Máximo) serão derivadas destas variáveis que apontamos.

Supondo que, para a fórmula de valor Sugerido, iremos adotar a seguinte fórmula:

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Supondo que, para a fórmula de valor Mínimo, iremos adotar a seguinte fórmula:

<code>P = PpFc/*Qu*Cf*</code>

Supondo que, para a fórmula de valor Máximo, iremos adotar a seguinte fórmula:

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:55:28Z

Jeffque: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

=== Declaração de variáveis ===

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

==== Campos de cadastro ====

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenários ==

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:54:17Z

Jeffque: /* Cenário 3 */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenários ==

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+</code>

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:54:01Z

Jeffque: /* Cenário 2 */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenários ==

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação:

<code>P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:53:26Z

Jeffque: /* Cenário 1 */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenários ==

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

<code>P = PpFc/Ce+Fr+Pr*Qu*Cf*</code>

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:52:45Z

Jeffque: /* Cenário 1 */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenários ==

=== Cenário 1 ===

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:48:03Z

Jeffque: /* Processar tabela */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:47:46Z

Jeffque: /* Campos de cadastro */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

=== Definição da formula de preço ===

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:47:10Z

Jeffque: /* Campos de cadastro */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

==== Definição da formula de preço ====

* Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.
* Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.
* Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.

* Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:46:23Z

Jeffque: /* Cadastro tabela de preço */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.

Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:45:55Z

Jeffque: /* Campos de cadastro */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Chave''' - Campo de texto de 8 caracteres;
* '''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;
* '''Valor''' - Campo numérico(18:6);

A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:45:29Z

Jeffque: /* Declaração de variáveis */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:

* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres
* A variável deve estar associada a um produto ou uma tabela de preço
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>

==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:45:10Z

Jeffque: /* Declaração de variáveis */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
* O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
* A variável deve estar associada a um produto ou uma tabela de preço</li>
* Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
* Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.

=== Campos de cadastro ===

<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>

==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:44:35Z

Jeffque: /* Campos de cadastro */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

* Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;
* Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;
* Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;
* Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.
</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 

==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:43:56Z

Jeffque: /* Cadastro tabela de preço */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
* '''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;
* '''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;
* '''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:43:27Z

Jeffque: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

# Criação de Tabela;

# Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela);
# Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos;
# Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços.

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:42:49Z

Jeffque: /* Cadastro tabela de preço */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

1. Criação de Tabela; 

2. Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela); 
3. Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos; 
4. Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços. 

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

==== Campos de cadastro ====
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:42:29Z

Jeffque: /* Declaração de variáveis */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

1. Criação de Tabela; 

2. Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela); 
3. Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos; 
4. Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços. 

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

<dd>
==== Campos de cadastro ====
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
==== Definição da formula de preço ====

<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

=== Processar tabela ===

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:41:53Z

Jeffque: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

1. Criação de Tabela; 

2. Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela); 
3. Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos; 
4. Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços. 

=== Cadastro tabela de preço ===
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

<dd>
==== Campos de cadastro ====
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
==== Declaração de variáveis ====

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
'''Definição da formula de preço'''
 
<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

'''Processar tabela'''

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>

== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:41:11Z

Jeffque: /* Solução */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.

== Implementação ==

O processo terá como bases os seguintes passos: 

1. Criação de Tabela; 

2. Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela); 
3. Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos; 
4. Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços. 

'''Cadastro tabela de preço'''
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

<dd>
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
'''Declaração de variáveis'''

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
'''Definição da formula de preço'''
 
<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

'''Processar tabela'''

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>
== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Precificação

2021-04-08T18:40:53Z

Jeffque: /* Necessidade */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 01/10/2020 || Ana Júlia || Criação do documento
|-
| 01/04/2021 || João Ramon || Atualização do documento
|-
|}

== Necessidade ==

No processo de formação de preços, conta-se com um número definido de variáveis que irão fazer a composição do valor final que será apresentado ao cliente final. Informações como custos operacionais, inclusão de markups, fatores de compensação por quebra e/ou comissionamento de venda devem estar contemplados na composição dos preços. A empresa deseja fazer esta composição dentro da Plataforma GeoSales EVO, inserindo todas as informações de custo, taxas e demais dados customizáveis, permitindo que o próprio cliente consiga fazer esta composição.

O cenário de precificação atual não possui um processo uniformizado para cada cliente. Portanto, a necessidade de criar um processo padronizado para composição de preços, assim como a atualização customizável de algumas dessas variáveis, por se tratarem de variáveis cujos valores podem oscilar por motivos externos (oscilações de mercado, variação na política de preços, etc), é imperativa.

== Solução ==

Visto que a formação de preços, e seu processo de elaboração, devem ser totalmente customizáveis pelo cliente, primeiramente deve ser possível que ele não apenas determine quais as variáveis e seus respectivos valores devem ser atribuídos na plataforma para precificação, mas também como estas variáveis se relacionarão matematicamente, a fim de formular um preço baseado nas entradas fornecidas pelo cliente. Além disso, tais variáveis, uma vez inseridas no cadastro de preços, deverão ser passíveis de edição, feitas pelo próprio cliente, de forma manual.

Como instrumento de parametrização das fórmulas contendo as variáveis criadas e seus operadores apropriados, será utilizada a '''''notação polonesa reversa (RPN)''''', ferramenta de uso familiar a pessoas ligadas ao trabalho que envolva matemática financeira. Assim, a formação de preço deverá ser mais flexível e intuitiva na sua formação, além de facilitar em eventuais futuras modificações. As formulas serão definidas dentro de uma tabela de preço para um determinado grupo de produto facilitando o cadastro.

Também visando a facilidade da manutenção dos valores de cada variável da fórmula, iremos construir o preço por um conjunto de parâmetros, podendo ser definido de forma atrelada às seguintes dimensões: produto e tabela de preço.

Após a definição dos parâmetros, a fórmula será construída por meio da utilização destes. Finalizando esta etapa, basta pedir para processar a tabela, onde a mesma passará a ser vigente para a equipe de venda.
</dd>

== Implementação ==

O processo terá como bases os seguintes passos: 

1. Criação de Tabela; 

2. Definição de Variáveis que deverão compor a fórmula de criação de preço, além da definição do atributo a qual tal variável está vinculada (produto ou Tabela); 
3. Definição de fórmula de formação de preços, utilizando RPN, e vinculações a grupos de produtos; 
4. Concluída a fórmula, com as relações operacionais entre as variáveis, os valores gerados devem ser processados para compor a Tabela de Preços. 

'''Cadastro tabela de preço'''
<dd> Para criação da tabela de preço, será criada uma tela onde o usuário irá fazer o cadastro da tabela de preço. Nela será possível fazer a inserção e edição de cadastros, não sendo possível excluir qualquer cadastro de tabela de preço já realizado, mas, apenas desativa-los.
<dd>Ao entrar na tela o sistema deve apresentar campos de filtros, os quais, o usuário poderá localizar um cadastro já inserido ou realizar edição dos campos descrição e datas inicial e final de vigência. Além, disso no rodapé da tela, terá o acesso para fazer um novo cadastro. na qual, o usuário vai preencher os seguintes campos.</dd>

<dd>
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Data inicial vigência''' - Campo de data, onde definirá o inicio da vigência da tabela;</li>
<li>'''Data final vigência''' - Campo de data, onde definirá o final da vigência da tabela;</li>
 

<li>Uma tabela de preço não poderá ser excluída, só poderá ser desativada ou ativada através dos campos de data inicial e data final. Para desativar, basta colocar a data final inferior a data atual;</li>
<li>Caso uma tabela de preço esteja com a data final de vigência vencida, a tabela de preço não será exibida para seleção no cadastro do pedido;</li>
<li>Os campos de datas não serão obrigatórios. Quando não estiverem preenchidos, indica que aquela tabela estará disponível para uso;</li>
<li>Não será possível utilizar a integração e cadastro da tabela de preço ao mesmo tempo, sendo necessário que haja uma única escolha: Integrar a tabela de preço do ERP ao GeoSales ou cadastrar a tabela de preço no próprio GeoSales. Caso tentem utilizar os dois cadastros ao mesmo tempo ERP e GeoSales, a integração apagará todos os registros cadastrados no GeoSales.</li>

</dd>
[[Arquivo:Tabelapreco.jpg|500px]]

[[Arquivo:Tabelapreco2.jpg|500px]]

 
 
'''Declaração de variáveis'''

<dd>
Dentro da tela de Variáveis de preço, deve ser possível definir uma variável de forma livre, mas que atenda as seguintes regras:
<li> O campo chave, que será utilizado como referência na formula de preço, não deve conter caracteres especiais, espaço em branco e nao ser mais que 8 caracteres</li>
<li> A variável deve estar associada a um produto ou uma tabela de preço</li>
<li> Para valores do tipo '''numérico (18,6)''', serão aceitos como possibilidade, podendo ser positivos ou negativos.</li>
<li> Será criado um log de históricos de alterações de valores destas variáveis e passível de ser exportado em relatórios em excel.
 
'''Campos de cadastro:''' 
<li>'''Descrição''' - Campo de texto limitados ao máximo de 70 caracteres;</li>
<li>'''Chave''' - Campo de texto de 8 caracteres;</li>
<li>'''Produto / Tabela''' - A seleção de uma produto ou de uma tabela, dados previamente alimentados;</li>
<li>'''Valor''' - Campo numérico(18:6);</li>
 
A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

 
</dd>
'''Definição da formula de preço'''
 
<dd>
<li> Será necessário selecionar uma tabela de preço, a organização de venda e um ou mais produtos aos quais o preço deve ser inserido.</li>
<li> Para a regra de preço teremos que informar a '''formula''' do preço mínimo, sugerido e máximo com a quantidade mínima, que valida sua aplicação.</li>
<li> Nos campos de preço (mínimo, sugerido e máximo) teremos um espaço para a inserção da fórmula para composição de preço. Esta fórmula fará a relação matemática entre as variáveis criadas no processo anterior, por meio de '''operadores matemáticos (+, -, *, / )''', organizados em '''RPN''', notação comum para analistas financeiros, sendo bastante difundido, inclusive, na lógica de cálculo das calculadoras HP 12 C.</li>

<li>Será possível visualizar uma prévia da fórmula escrita, além do valor encontrado, a fim de que o usuário possa confirmar os valores que foram inseridos pelas variáveis e seus respectivos operadores.</li>

Como exemplo de notação polonesa reversa, tomemos a expressão '''''(A+B)*C'''''. Em RPN, a notação ficaria '''''AB+C*'''''.

'''Processar tabela'''

É importante frisar que os valores estão vinculados a uma tabela de preços, que consequentemente está vinculada a um cliente, organização de vendas, vendedores, e tabelas afins.

As variáveis comuns a todos os clientes deverão ter valores diferenciados de acordo com a cidade onde a organização de vendas está alocada.
Há dois grupos de variáveis: aquelas que são relacionadas ao '''produto''' em si (tamanho, cor, embalagem, Tipo) e aquelas relacionadas à '''Tabela''' (Valor de partida, comissão promotor, frete, por exemplo). É importante determinar corretamente para qual grupo tal variável estará vinculada.

Se mais de um produto possui a mesma característica, será possível fazer a precificação por grupos de produtos.
</dd>
== Cenário 1 ==

Elaborando o preço do produto 'P001' para o cliente 'C001':

Enumeração das variáveis 

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 106,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 0,00 || Tabela
|-
| Pr || Promotor || 1,02 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,02 || Tabela
|}


As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpFc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo, a fórmula irá apresentar o valor final: '''"R$ 86,21"'''.

=== Cenário 2 ===

Realizando o cadastro de preço do produto 'P002' para o cliente 'C002'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ 3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 12,20 || Produto
|-
| Fr || Frete || R$ 3,00 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1,11 || Tabela
|-
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Fr+Pr*Qu*Cf*'''''

Ao final do processo de cálculo da fórmula, o valor do preço será '''"R$ 100,86"'''.

=== Cenário 3 ===

Realizando o cadastro de preço do produto 'P003' para o cliente 'C003'

{|class = "wikitable"
! Variável
! Descrição da Variável
! Valor
! Tipo Grupo
|-
| Pp || Preço de Partida || R$ 110,50 || Tabela
|-
| P1 || Adicional de Preço || R$ -3,00 || Tabela
|-
| Fc || Fator de Conversão || 1,5 || Produto
|-
| Ce ||Custo de Embalagem || R$ 8,67 || Produto
|-
| Ce2 || Custo de Embalagem 2 || R$ 2,00 || Produto
|-
| Fr || Frete || R$ 2,5 || Tabela
|-
| Pr || Promotor || 1 || Tabela
|-
| Qu || Fator Quebra || 1 || Tabela
|-
| Cf || Contrato de Fidelidade || 1 || Tabela
|-
| K || Constante || 23,67 || Tabela
|}



As variáveis estão relacionadas matematicamente de acordo com a notação: 

'''''P= PpP1+Fc/Ce+Ce2+Fr+Pr*Qu*Cf*K+'''''

Ao final do cálculo da forma, o valor final do preço será: '''"R$ 108,50"'''.



A composição de preço tem como objetivo construir um preço de venda. Esse cadastro conta com tipos de variáveis para compor preço. Para que a composição de preço seja aplicada corretamente no cadastro do pedido, é necessário que as seguintes premissas sejam atendidas.

=== Composição de preço ===

Visto que há variação de preços de produtos para diferentes localidades, a formula criada para a composição de preços deverá, além de compor toda a regra de cálculo de precificação de determinado produto, a sua parametrização vinculada ao seu respectivo Estado, Cidade e Filial. 

Em outras palavras, através da composição de preço, o usuário poderá informar a fórmula que o sistema irá aplicar para definir o preço unitário do produto. Essa regra poderá ser parametrizado por: filial, estado e cidade.

== Regras de Negócios ==

'''[RN1] - ''' Não poderá conter a mesma regra para o mesmo estado e filial;

'''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta;

'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO.

'''[RN4] - ''' Durante o processo, o portal não deverá travar, ou seja, o batch irá apresentar os dados apenas referentes às variáveis relacionadas (via GSOload). A medida visa evitar um carregamento excessivamente pesado de dados para determinada função. 

'''[RN5] - ''' Os históricos do log de alterações das variáveis ficarão registrados por um período de 1 (um) ano.

'''[RN6] - ''' Um determinado produto poderá ser vinculado a mais de um grupo, mas a quantidade deve ser diferente.

'''[RN7] - ''' A chave poderá ser associada a mais de um produto/tabela, mas o valor é específico pela unidade de um destes dois atributos.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Discussão:Falta de Agrupamento de Pedidos

2021-03-23T16:36:58Z

Jeffque: /* Necessidade "não há filtro"? */ nova seção

* Apontamentos

Dei uma olhada aki
eu fico meio receoso com esse modelo de cenários que passaram para você
http://wiki.geosales.com.br:8000/index.php/Funcionalidade/Limite_de_cr%C3%A9dito
da uma olhada nesse documento
que tem uma pegada mais técnica
mas pode dar uma noção de como injetar informações no cenário
pq o cenário que tem na tua documentação só trás ações e não dados.
e tipo
tem uns 3 cenários de ações que fazem parte da correção que eu alinheir contigo que não tão ai
a execução dos relatórios
o fluxo de filtrar por rota
e o documento também não deixa condizente como ela fará a execução desse fluxo
" no caso de pedidos por rota e por vendedor, seja possível pela filtração na lista de visualização.

Implementação"

== Regras de negócio fora da solução? ==

A solução é onde se concentra a solução. Se algo faz parte da solução, precisa estar dentro dela. Se não faz parte da solução, então deveria ser um detalhe de implementação, um cenário ou a necessidade, ou algum trecho de conhecimento necessário para o entendimento de alguma dessas partes.

== Que informação o grafo carreia? ==

Não ficou claro para mim o porquê do grafo estar no documento.

Na descrição, não vi nada realmente referente a alguma espécie de fluxo.

Não há descrição das diferenças de cores entre os nós do grafo, apesar de que visualmente eles indicam nada além de um ponto de culminação do caminho, de onde o qual não há arestas de saída. Mesmo assim, essa conclusão é tirada assumindo que na real esse grafo seja direcionado, apesar de isto não estar claro.

== Resultados esperados estão muito fracos e carrega pouca informação para o desenvolvimento ==

Qual o significado de "a Plataforma GeoSales Evo irá buscar os dados relacionais referentes aos agrupamentos de Pedidos por Rota"?

Não é palpável para o programdor essa informação

E se o pedido 27 for do cliente 3, que está na rota 2, porém o pedido foi tirado fora da rota, ao agrupar por rotas devo mostrar que o pedido 27 está junto dos outros pedidos da rota 2?

== O que é uma "rota pré-filtrada" conforme descrita no resultado de cenário "Cenário para o agrupamento de Pedidos por Vendedor e por Rota"? ==

Pela definição solta das palavras, uma rota pré-filtrada pode ser a 15. Pronto.

Isso significa que, de acordo com a estrita especificação descrita no cenário, se forem exibidos os pedidos da rota 15, mesmo que esse 15 não seja a rota selecionada no campo de filtro, mostrar apenas os pedidos da rota 15 estará certo

== Necessidade "não há filtro"? ==

A não existência de filtro não faz parte da necessidade. É um desdobramento da problemática. A construção do primeiro parágrafo não está sintaticamente óbvio que a necessidade é agrupar, ou aplicar filtros.

Vamos para um exemplo da mesma estrutura sintaticamente porém voltada a alimentação de um persona, chamado de Marombado:

<blockquote>
Não há feijão verde nem baião de dois no Arretado. Ambos os pratos são importantes na dieta hiper-calórica do Marombado, dado que ele necessita das proteínas oferecidas no feijão e o carboidrato do baião de dois, pois o hipertrofismo é atendimento por mais de um macronutriente. Essas opções existiam na Til Nilva.
</blockquote>

Qual a necessidade do Marombado especificamente? Você consegue discernir facilmente isso? E que tal reformular do seguinte jeito:

<blockquote>
Marombado precisa de refeições hipercalóricas em suas refeições, com feijão verde e baião de dois sendo sua base dietética, para conseguir o efeito desejado do hipertrofismo muscular. Feijão verde fornece proteínas e o baião de dois fornece o carboidrato necessários para a composição adequada dos macronutrientes da dieta do Marombado. Esses pratos eram oferecidos pela Tia Nilva antes dela ser transformada em Arretado.
</blockquote>

Notou como a necessidade agora está enfática logo nas primeiras palavras? Que a oração principal da primeira frase contém o cerne da necessidade, sendo os adjuntos adverbiais de instrumento e finalidade nas orações subordinadas subsequentes especificidades da necessidade central?

Discussão:Falta de Agrupamento de Pedidos

2021-03-23T16:17:32Z

Jeffque: /* O que é uma "rota pré-filtrada" conforme descrita no resultado de cenário "Cenário para o agrupamento de Pedidos por Vendedor e por Rota"? */ nova seção

Discussão:Falta de Agrupamento de Pedidos

2021-03-23T16:11:27Z

Jeffque: /* Resultados esperados estão muito fracos e carrega pouca informação para o desenvolvimento */ nova seção

Discussão:Falta de Agrupamento de Pedidos

2021-03-23T12:54:19Z

Jeffque: /* Que informação o grafo carreia? */ nova seção

Discussão:Falta de Agrupamento de Pedidos

2021-03-23T12:01:00Z

Jeffque: /* Regras de negócio fora da solução? */ nova seção

Discussão:Estoque Reservado

2020-10-07T19:40:25Z

Jeffque: /* Integração */ Algumas correções ortográficas

== Desenvolvimento ==

# Será necessário criar um novo identificador de Json para enviar pedidos orçados. Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json.
# Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração. Esse parâmetro será configurado com a quantidade de dias corridos para definir quando o pedido poderá ser cancelado, após a emissão do pedido.

== Integração ==

# Será necessário criar um campo no ERP para informar se o pedido possui a situação orçada ou não. Essa tratativa tem como ação evitar pedidos duplicados no ERP (Essa é uma trativa que o Jardel solicitou que fosse colocada no documento, pois ele precisa garatir que o pedido não integre duas vezes no ERP);
# Será necessário identificar se o pedido teve alteração ou não. Dessa forma evitamos que o pedido seja enviado várias vezes ao ERP;
# Será necessário adequar o fonte para pegar o novo arquivo Json;
# Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados;
# Os pedidos orçados não deverão retornar nas tabelas pedido_retorno e item_pedido_retorno;
# Será necessário informar através da ack se a exportação de pedidos orçados foi realizada com sucesso ou falha.

== Questionamentos ==

==== Desenvolvimento ====

<blockquote>será necessário criar uma nova descrição na NM_TABLE na tabela ACK_TABELA_PROCEDURE</blockquote>

Em relação a o que é dito na tratativa do ACK, qual a tratativa que será feita com o ACK do orçamento enviado?

Digo isso porque o comportamento padrão é salvar para futura disponibilização os sucessos e erros. Tratativas especiais são feitas sob demanda; por exemplo, a tratativa do pedido é atualizar a data de exportação caso tenha sido enviada com sucesso. Assim, qual a necessidade dessa tratativa?

Então não vejo o porquê de ter algo desse tipo.

<blockquote>Será necessária criar um novo modelo de Json [...]</blockquote>

Tenho a impressão de que não era essa a intenção... O modelo será o mesmo do pedido, com um identificador distinto.

<blockquote>[...] Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json</blockquote>

Melhor separar em '''extração''' de dados essa questão.

<blockquote>Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração</blockquote>

Já há algo nesse sentido no Erp-Importer. No rodapé da documentação pública do Erp-Importer temos o seguinte dito:

<blockquote>Ainda existem os end-points <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> e <code>{host/contexto}/{tenant}/import-new</code>, serão documentados posteriormente.</blockquote>

No caso, o end-point específico <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> permite resgatar/alterar/deletar coisas da chave específica. Só foi implementado coisas relativas a tabelas de chave única (como é o caso de pedido). Detalhes do como fazer isso posso fornecer depois. O Protheus tem suporte aos detalhes necessários para fazer essa atualização específica.

Será feita a atualização na documentação em https://softsite.gitlab.io/tj2/erp-importer para falar especificamente sobre esse end-point e suas capacidades.

==== Integração ====

<blockquote>Será necessário adequar o fonte para pegar o novo arquivo Json</blockquote>

Será um novo consumo de serviço. Talvez nem tanto "adequar" um fonte pré-existente, talvez criar um novo. Não gosto de entrar tanto no mérito do '''como''' será feito, apenas o que espero do '''resultado final'''. Enfim, só um detalhe de comunicação

<blockquote>Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados</blockquote>

Aqui, novamente, conforme conversamos, indo para o ponto em que a nomenclatura é correta. É responsabilidade do ''cliente'' fornecer qual foi a última data ''através'' da URL. Detalhes precisos do como é feita essa informação será adicionada na documentação do erp-importer https://softsite.gitlab.io/tj2/erp-importer.

Esse dado será disponibilizado através da "tabela" de nome <code>VALIDADE_TJ</code>. Essa "tabela" conterá uma única linha com uma única coluna. Mais detalhes serão especificados em https://softsite.gitlab.io/tj2/protocolo-tj, assim como será mencionado adequadamente aqui https://softsite.gitlab.io/tj2/erp-integrator.

<blockquote>Será necessário salvar na ack a falha ou sucesso da exportação dos pedidos orçados</blockquote>

No caso, não deveria estar descrito "será necessário informar através do ACK se os orçamentos foram enviados com sucesso ou não"?

Discussão:Estoque Reservado

2020-10-07T19:35:54Z

Jeffque:

== Desenvolvimento ==

# Será necessário criar um novo identificador de Json para enviar pedidos orçados. Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json.
# Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração. Esse parâmetro será configurado com a quantidade de dias corridos para definir quando o pedido poderá ser cancelado, após a emissão do pedido.

== Integração ==

# Será necessário criar um campo no ERP para informar se o pedido possui a situação orçada ou não. Essa tratativa tem como ação evitar pedidos duplicados no ERP (Essa é uma trativa que o Jardel solicitou que fosse colocada no documento, pois ele precisa garatir que o pedido não integre duas vezes no ERP);
# Será necessário identificar se o pedido teve alteração ou não. Dessa forma evitamos que o pedido seja enviado várias vezes ao ERP;
# Será necessário adequar o fonte para pegar o novo arquivo Json;
# Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados;
# Os pedidos orçados não deverão retornar nas tabelas pedido_retorno e item_pedido_retorno;
# Será necessário informar através da ack se a esxportação de pedidos orçados doi realizada com sucesso ou falha.

== Questionamentos ==

==== Desenvolvimento ====

<blockquote>será necessário criar uma nova descrição na NM_TABLE na tabela ACK_TABELA_PROCEDURE</blockquote>

Em relação a o que é dito na tratativa do ACK, qual a tratativa que será feita com o ACK do orçamento enviado?

Digo isso porque o comportamento padrão é salvar para futura disponibilização os sucessos e erros. Tratativas especiais são feitas sob demanda; por exemplo, a tratativa do pedido é atualizar a data de exportação caso tenha sido enviada com sucesso. Assim, qual a necessidade dessa tratativa?

Então não vejo o porquê de ter algo desse tipo.

<blockquote>Será necessária criar um novo modelo de Json [...]</blockquote>

Tenho a impressão de que não era essa a intenção... O modelo será o mesmo do pedido, com um identificador distinto.

<blockquote>[...] Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json</blockquote>

Melhor separar em '''extração''' de dados essa questão.

<blockquote>Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração</blockquote>

Já há algo nesse sentido no Erp-Importer. No rodapé da documentação pública do Erp-Importer temos o seguinte dito:

<blockquote>Ainda existem os end-points <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> e <code>{host/contexto}/{tenant}/import-new</code>, serão documentados posteriormente.</blockquote>

No caso, o end-point específico <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> permite resgatar/alterar/deletar coisas da chave específica. Só foi implementado coisas relativas a tabelas de chave única (como é o caso de pedido). Detalhes do como fazer isso posso fornecer depois. O Protheus tem suporte aos detalhes necessários para fazer essa atualização específica.

Será feita a atualização na documentação em https://softsite.gitlab.io/tj2/erp-importer para falar especificamente sobre esse end-point e suas capacidades.

==== Integração ====

<blockquote>Será necessário adequar o fonte para pegar o novo arquivo Json</blockquote>

Será um novo consumo de serviço. Talvez nem tanto "adequar" um fonte pré-existente, talvez criar um novo. Não gosto de entrar tanto no mérito do '''como''' será feito, apenas o que espero do '''resultado final'''. Enfim, só um detalhe de comunicação

<blockquote>Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados</blockquote>

Aqui, novamente, conforme conversamos, indo para o ponto em que a nomenclatura é correta. É responsabilidade do ''cliente'' fornecer qual foi a última data ''através'' da URL. Detalhes precisos do como é feita essa informação será adicionada na documentação do erp-importer https://softsite.gitlab.io/tj2/erp-importer.

Esse dado será disponibilizado através da "tabela" de nome <code>VALIDADE_TJ</code>. Essa "tabela" conterá uma única linha com uma única coluna. Mais detalhes serão especificados em https://softsite.gitlab.io/tj2/protocolo-tj, assim como será mencionado adequadamente aqui https://softsite.gitlab.io/tj2/erp-integrator.

<blockquote>Será necessário salvar na ack a falha ou sucesso da exportação dos pedidos orçados</blockquote>

No caso, não deveria estar descrito "será necessário informar através do ACK se os orçamentos foram enviados com sucesso ou não"?

Aplicação de Desconto por Período Logístico

2019-05-17T12:22:08Z

Jeffque: Typo

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 13/11/2018 || Ryvane Maria || Criação do documento
|-
| 17/04/2019 || Ryvane Maria || Inclusão de solicitações do cliente
|-
|}

== Necessidade ==

É possível que seja aplicado, durante um determinado período de tempo, um percentual de desconto logístico faseado sob uma venda. Este desconto possibilita, por exemplo, alavancar as vendas antes do fechamento do fim do mês.

Esse percentual de desconto, chamado de desconto por período logístico, tendo como base de cálculo a data de faturamento do pedido, e varia de acordo com o período do mês. Este desconto deverá ser cadastrado diretamente no GeoSales, conforme previsto no documento [[Cadastro de Desconto por Período Logístico]].

== Solução ==

Será utilizada como data base de cálculo de desconto, a data de faturamento prevista para o pedido. No momento que a data de faturamento prevista for definida, o GeoSales irá informar ao vendedor que existe, para a organização de venda, canal de venda e grupo de cliente selecionados, um desconto para aquele período logístico, e perguntar se o vendedor deseja aplicar algum desconto ou não. É importante salientar que o percentual inserido será aplicado sob todos os itens do pedido.

É importante salientar, também, que este desconto será validado considerando a data de faturamento do pedido, ou seja, o desconto aplicado será referente o período em que se encaixa a data de faturamento do pedido. Caso haja um desconto a ser aplicado neste período, o vendedor será alertado e poderá decidir entre aplicar ou não, e qual valor aplicar, o desconto sob o valor final do pedido, ou seja, sob todos os seus itens.

== Implementação ==

'''- Parametrizar o desconto no GeoSales:'''

O usuário deverá, inicialmente, cadastrar o desconto de período logístico na sua respectiva tela de cadastro, conforme mencionado no documento de [[Cadastro de Desconto por Período Logístico]]. Nesta tela o usuário deverá inserir o dia inicial e final do período, organização de venda, canal de venda, grupo de clientes, data de vigência e o percentual de desconto a ser aplicado.

'''- Validar o período logístico:'''

Cadastradas as informações acima, que serão salvas na tabela DESCONTO_PERIODO, o GeoSales deverá validar, no momento do cadastro de pedido, logo após a definição da data de faturamento, se há um desconto a ser aplicado de acordo com a organização de venda, canal de venda, grupo de cliente e a data de faturamento cadastrada.

Essa validação deve ser feita tão logo a data de faturamento seja definida no pedido. Ou seja, quando o usuário selecionar a data de faturamento, o campo de aplicação de desconto logístico será liberado para inclusão do percentual de desconto, e o usuário poderá definir um desconto a ser aplicado para aquele período logístico. Portanto, o percentual definido nas regras de cadastro é o valor máximo que pode ser aplicado pelo vendedor. Por exemplo: caso tenha sido cadastrada uma regra de desconto no valor de 5%, o vendedor poderá aplicar qualquer desconto entre 0 e 5%.

É válido salientar que, caso essa data de faturamento seja alterada, o GeoSales deverá realizar uma nova validação. Ou seja, caso o vendedor opte por aplicar um desconto, e, logo depois, precise alterar a data de faturamento por qualquer motivo, o GeoSales deverá validar novamente se há desconto para a nova data de faturamento.

'''- Aplicar descontos no pedido:'''

Caso seja identificado que há um desconto para a data de faturamento cadastrada, e o vendedor opte por aplicar o desconto no pedido, o percentual de desconto contido no campo PR_DESCONTO_PERIODO da tabela DESCONTO_PERIODO poderá ser aplicado sob o valor final do pedido, ou seja, sob todos os itens, cabe então ao vendedor inserir o percentual de desconto a ser aplicado, respeitando o máximo parametrizado para este desconto. Neste caso, é importante salientar que a data de faturamento se trata da data prevista que o pedido será faturado, e não da data de criação do pedido.

É importante salientar que, caso o usuário insira novos itens, mesmo que isso não altere o LeadTime de faturamento, o desconto por período logístico aplicado anteriormente deverá ser aplicado também sob os novos itens inseridos.

== Regras de Negócios ==

'''[RN1] - ''' O vendedor poderá decidir se irá ou não aplicar o desconto logístico quando a data de faturamento for definida.

'''[RN2] - ''' A validação de desconto por período logístico será feita baseando-se na data de faturamento do pedido. Caso essa data de faturamento seja alterada, o GeoSales deverá realizar uma nova validação.

'''[RN3] - ''' O desconto por período logístico será aplicado sob o valor final do pedido, ou seja, sob todos os produtos inseridos.

'''[RN4] - ''' Caso, após definir uma data de faturamento, o vendedor queira inserir novos itens que alterem o leadtime de faturamento previsto, a data de faturamento será recalculada e será necessário selecionar uma nova data de faturamento, dentro do cenário de LeadTime atual.

'''[RN5] - ''' Os descontos aplicados em um pedido serão aplicados sob o valor atual do pedido, ou seja, sob o valor com descontos que possam já ter sido aplicados anteriormente. Por exemplo: em um pedido de 100 Reais, já foi aplicado 10% de desconto, resultando 90 reais, caso o vendedor deseje aplicar um desconto de período logístico de 10%, este desconto será aplicado sob o valor atual do pedido, ou seja, 90 reais. A partir daí, o pedido resultaria em 81 reais totais.

== Regras de Integração ==

'''[RI1] - ''' As informações de desconto por período logístico serão cadastradas diretamente no GeoSales e não serão trazidas do ERP.

'''[RI2] - ''' As informações de percentual de desconto por período logístico será salva no campo XXX do ERP.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Jefferson Quesado || 21/12/2019
|-
| Integração - GeoSales || ||
|-
| Configurações - GeoSales || ||
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! style="width:200px" |Aprovado Por
! style="width:200px" |Data

|-
| TI - Montana || ||
|-
| Gestor do Projeto - Montana || ||
|-
| Diretoria - Montana || ||
|}

Composição do preço de venda

2019-05-07T11:40:10Z

Jeffque:

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 02/04/2019 || Ana Júlia || Criação do documento
|-
| 06/05/2019 || Jefferson Quesado || Revisão do documento
|-
|}

== Necessidade ==

O preço da Famiglia Zanlorenzi dentro do ERP, é constituído pelo preço de tabela somado ao frete e divido pela alíquota do PIS, COFIN, ICMS. Além disso, para que o preço seja construído, o ERP considera também um percentual de acréscimo de contrato do cliente. Este percentual é definido por cliente e família de produto.

Desta forma, a Famiglia Zanlorenzi necessita que a composição de preço do produto, no GeoSales, seja feita pela soma do preço de tabela ao frete e divido pela alíquota do PIS, COFINS, ICMS, e o percentual do contrato com o cliente.

== Solução ==

No ERP da Famiglia Zanlorenzi o cliente possui um percentual de acréscimo por família de produto. Para que o percentual de acréscimo reflita no GeoSales, será necessário realizar a integração da tabela VERBA_CONTRATUAL. Além disso, para atender a necessidade de vinculação de cliente e família de produto, será necessário criar a coluna CD_FAMILIA na tabela VERBA_CONTRATUAL.

Para que o preço dentro do GeoSales EVO seja constituído pela soma do preço de tabela ao frete divido pela alíquota do PIS, COFINS, ICMS e Verba Financeira será necessário desenvolver uma regra de composição de preço.

== Implementação ==

=== Desenvolvimento ===

'''- Constituição do preço de venda'''

Para que no GeoSales EVO o preço seja composto pelo preço de tabela somado ao frete divido pelos percentuais do PIS, COFINS, ICMS e Verba Contratual, será necessário criar uma nova regra de composição de preço.

Para atender a necessidade da Famiglia Zanlorenzi, será necessário criar as tabelas COMPOSICAO_PRECO e FORMULA_COMPOSICAO_PRECO. Essas tabelas irão definir, como e o quê, irá compor o preço de venda. Além disso, será possível definir por organização de venda e pelo tipo do pedido. Vale salientar que a tabela COMPOSICAO_PRECO e FORMULA_COMPOSICAO_PRECO são preenchidas exclusivamente pelo GeoSales. A Famiglia Zanlorenzi utilizará da seguinte fórmula:

[[Arquivo:Zanlorenzi composicao preco venda calculo de demonstranação.PNG|center]]

=== Integração ===

'''- Percentual de contrato'''

Dentro do ERP o cliente possui um acréscimo no preço de tabela. Este acréscimo é definido por famílias de produtos. Para que esse percentual seja refletido no GeoSales, será necessário realizar a integração da tabela VERBA_CONTRATUAL, segue abaixo estrutura:

{| class="wikitable"
! colspan="5" | PERCENTUAL DE ACRÉSCIMO
|-
! Tabela ERP
! Coluna ERP
! Tabela GeoSales
! Coluna ERP
|-
| SA1 || A1_COD || VERBA_FINANCEIRA || CD_CLIENTE
|-
| SA1 || A1_COADFIN || VERBA_CONTRATUAL || PR_MAX_DESC
|-
| SA1 || A1_CONDFIN || VERBA_CONTRATUAL || PR_MAX_DESC
|-
| SA1 || A1_CONVERP || VERBA_CONTRATUAL || PR_MAX_DESC
|-
| SB1 || B1_SUBGRUP || VERBA_CONTRATUAL || CD_FAMILIA
|}

Por questões de estruturas, os percentuais de acréscimo devem vir integrados com o sinal de (-), como, por exemplo:

[[Arquivo:Exemplo zanlorenzi de acrescimo no produto porcliente e familia.PNG]]

A integração no exemplo dado acima deve ser de '''-4'''. Saliento que esses cenários ocorrem somente para acréscimos.

'''Observação:''' Dentro do GeoSales existe um cadastro de Verba Contratual, porém, não é possível cadastrar acréscimos. É de suma importância que o acréscimo seja integrado ao GeoSales.

== Regras de Negócios ==

'''[RN1] - ''' O sistema só irá aplicar o percentual de contrato se houver dados de vinculação de cliente e família de produto na tabela VERBA_CONTRATUAL.

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Aplicação de Desconto por condição de pagamento

2018-12-21T05:12:42Z

Jeffque: Deixando claro a estratégia do Null coalesce; reinserindo a coluna com o valor do desonto; corrigindo nome de alguma tabela perdida no texto

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 16/11/2018 || Ryvane Maria || Criação do documento
|-
|}

== Necessidade ==

Algumas condições de pagamento, por exemplo 'a vista', viabilizam a aplicação de descontos no processo de negociação. Este percentual de desconto por condição de pagamento deve ser aplicado de forma automática, diretamente sob o valor do pedido.

Diferente de alguns outros percentuais de descontos que podem ser aplicados em um pedido, o desconto por condição de pagamento não necessita de interferência do vendedor, e, conforme seja integrado do ERP junto a condição de pagamento, será devidamente aplicado sob o valor final do pedido.

== Solução ==

Aplicado de forma automática no pedido, de acordo com a organização de venda e a condição de pagamento selecionada, o desconto por condição de pagamento não precisa de interferência do vendedor e, conforme seja integrado do ERP junto a condição de pagamento, será aplicado sob o valor final do pedido.

Ao passo da seleção da condição de pagamento pelo vendedor, no momento da finalização do pedido, o GeoSales irá verificar se há um desconto cadastrado associado a condição de pagamento selecionada. Caso haja, este desconto será aplicado diretamente sobre o valor final do pedido, sem que se tenha a necessidade de que seja executada alguma ação de aplicação de desconto pelo usuário.

== Implementação ==

'''- Integrar informações de associação de desconto por condição de pagamento:'''

As informações de condição de pagamento serão trazidas da tabela XXX do campo YYY no ERP. Já as informações de organização de venda serão trazidas da tabela XXX do campo YYY no ERP.

'''- Salvar informações integradas no banco de dados do GeoSales:'''

Ao integrar as informações de condição de pagamento, o GeoSales irá integrar também o desconto a ser aplicado para cada condição de pagamento integrada.

O percentual de desconto por condição de pagamento deverá ser salvo no campo PR_DESCONTO da tabela CONDICAO_PAGAMENTO.
Para associar os dados de condição de pagamento a organização de venda a ser utilizada, será criada uma estrutura com finalizada de normatizar essas informações.

Caso não haja nenhum percentual de desconto associado a condição de pagamento no ERP, deverá ser integrado e salvo no campo PR_DESCONTO o valor 0 (zero).

{| class="wikitable"
! colspan="5" | ORG_VENDA_CONDICAO_PAGAMENTO
|-
! Coluna || Tipo || Obrigatório || Chave Primária || Explicação
|-
| CD_COND_PGTO || Int || SIM || NAO || Código da condição de pagamento
|-
| CD_ORG_VENDA || Varchar(20) || SIM || NAO || Código da organização de venda
|-
| PR_DESCONTO || Decimal(18,6) || SIM || NAO || Percentual de desconto
|-
|}

'''- Aplicar desconto no cadastro de pedido do Geosales:'''

Havendo um desconto diferente de zero salvo no campo PR_DESCONTO da tabela ORG_VENDA_CONDICAO_PAGAMENTO, o Geosales irá aplicar este valor, dado em percentual, sob o valor total do pedido.

Por exemplo: Um vendedor está cadastrando um pedido, que tem como valor total R$1000 (mil reais). Na finalização do pedido, o vendedor seleciona a condição de pagamento 'a vista', que tem desconto de 10% parametrizado na tabela CONDICAO_PAGAMENTO para a organização de venda selecionada. Ao passo da seleção dessa condição de pagamento, será aplicado 10% de desconto no pedido, que terá seu valor ajustado para R$900 (novecentos reais).

Caso haja cadastrado algum valor de desconto na coluna PR_DESCONTO da tabela CONDICAO_PAGAMENTO e, também, em ORG_VENDA_CONDICAO_PAGAMENTO para a condição de pagamento de mesmo código, prevalece a informação de ORG_VENDA_CONDICAO_PAGAMENTO.

Por exemplo: "à vista" tem, em seu cadastro, 5% de desconto. Porém, para a organização de venda 0101, há um cadastro na ORG_VENDA_CONDICAO_PAGAMENTO para a condição à vista com 10% de desconto; já para a organização de venda 0102, há um cadastro na ORG_VENDA_CONDICAO_PAGAMENTO para a condição à vista com 1% de desconto. Caso um vendedor realize um pedido de R$ 100,00 para a organização de venda 0101, ao selecionar a condição "à vista", o preço do pedido se tornará R$ 90,00; já, se for para a organização de venda 0102, esse preço seria de 99; para a organização de venda 0103, o preço do pedido será de R$ 95,00.

== Regras de Negócios ==

'''[RN1] - ''' O desconto por condição de pagamento será cadastrado e parametrizado exclusivamente no ERP.

'''[RN2] - ''' Além do desconto, será possível aplicar um acréscimo por condição de pagamento, também parametrizado no ERP no mesmo cadastro do desconto por condição de pagamento. Este acréscimo será aplicado caso o valor cadastrado no campo seja negativo.

== Regras de Integração ==

'''[RI1] - ''' Os dados de condição de pagamento serão trazidos da tabela XXXX do ERP.

'''[RI2] - ''' Caso não haja nenhum percentual de desconto associado a condição de pagamento no ERP, deverá ser integrado e salvo no campo PR_DESCONTO o valor 0 (zero).

== 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.

=== GeoSales ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data
! Assinatura
|-
| Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
| Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||
|-
|}

Discussão:Aplicação de Desconto por Período Logístico

2018-12-18T21:00:11Z

Jeffque: Criou página com 'A priori, o que estou vendo da UI é o seguinte (para o caso em que o usuário inserirá algum desconto de período logístico): # usuário seleciona uma data # sistema detec...'

A priori, o que estou vendo da UI é o seguinte (para o caso em que o usuário inserirá algum desconto de período logístico):

# usuário seleciona uma data
# sistema detecta que a data está no alcance do período logístico
# sistema informa ao usuário que existe o desconto de X%
# sistema pergunta ao usuário o quanto ele quer colocar dos X% de desconto
# usuário informa Y%, o desconto a ser aplicado (Y <= X)
# para cada item cadastrado no pedido, o sistema colocará Y% de desconto

Porém, isso tem alguns revezes...

# O que acontece com itens posteriormente inseridos? O sistema coloca o desconto informado neles?
# O desconto a ser inserido, entra como desconto adicional? Desconto padrão? Fica de algum jeito visível para o usuário?
# O sistema não impede que o usuário altere esse valor... entretanto, a única abertura possível para o usuário alterar esse desconto é setar uma nova data de faturamento... isso é certo?
# O que acontece quando algum dos itens já tiver algum desconto manual?

Faltaram-me cenários de exemplos também. Isso implica que não há uma validação fria, objetiva e 100% não-ambígua para alguns cenários. O ideal é sempre que possível fornecer cenários para que possamos automatizar os testes e garantir a parte da lógica da implementação.

Um cenário consiste de 3 partes:

* dados
* operações
* aferições

Isso deve ser fornecido da maneira mais fria e mecânica possível. Conforme um cenário voltado a TDD. Exemplos de como isso foi feito:

* http://10.0.0.32/wiki/index.php/Funcionalidade/Limite_de_cr%C3%A9dito#Fluxo_AEIL Note que nesse caso, os dados que foram feitos em comum estão separados, com a parametrização específica para cada cenário descrita em outro momento, sempre fazendo a menção de onde se busca essa informação
* http://10.0.0.32/wiki/index.php/Desconto_negociado#Prioridade_1_vence Note que, aqui, todos os cenários que começam com os mesmos dados, porém tem operações distintas (e, portanto, necessitam de suas próprias aferições), foram agrupados. Tem muitos detalhes técnicos que estão dentro das assertivas, como valor unitário do item, pendências, valor do pedido...

Taxa de câmbio por item

2018-09-13T17:47:13Z

Jeffque: Pequenas correções na descrição da tabela '''FAIXA_PRECO_MOEDA'''

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 14/05/2018 || Ryvane Maria || Criação do Documento
|-
| 23/05/2018 || Marcus Fábio Salviano || Aprovação Desenvolvimento
|-
| 03/08/2018 || Ryvane Maria || Alteração do Documento segundo solicitação do cliente
|-
| 13/09/2018 || Ryvane Maria || Incluindo a tabela FAIXA_PRECO_MOEDA.
|-
| 13/09/2018 || Jefferson Quesado || Pequenas correções na descrição da tabela '''FAIXA_PRECO_MOEDA'''.
|}

== Necessidade ==

São comercializados itens que podem ser convertidos em diferentes tipos de moedas, principalmente Euro e Dólar. É necessário que o sistema esteja apto a processar esse tipo de pedido, explicitando o valor, item a item, em várias moedas.

Alguns produtos tem seu valor de tabela de preço dado em moeda estrangeira, sendo assim, o GeoSales deve, após o vendedor informar o valor (dado em moeda estrangeira), converter este valor e inserir o valor do produto, em real, no pedido. Desta forma, o vendedor deverá digitar o valor do produto, que deve ser sinalizado a respeito da sua moeda, visualizando então o valor em moeda estrangeira, e realizando a negociação daquele produto.

No momento da tiragem do pedido, o sistema deve apresentar o valor total dos produtos, tanto em real, quanto em outras moedas, possibilitando que o usuário visualize os distintos valores, sob aplicação de diferentes taxas de câmbio, para aquele produto, de acordo com a cotação diária daquela moeda.

== Solução ==

Inicialmente, deverão ser cadastradas no ERP as informações de moedas e suas taxas de câmbio. Essas informações serão trazidas para o GeoSales através de integração. Nesse cadastro poderão ser inseridos dados como o nome da moeda, o seu símbolo e a sua taxa de câmbio. Essa situação permitirá a inclusão de outras moedas de forma fácil, colaborando na manutenção dos dados.

Serão integradas as informações da tabela de preço cadastradas na tabela padrão (DA1) de vendas do protheus, bem como o tipo da moeda que aquele produto será aplicado. No momento da criação do pedido, o valor trazido será utilizado como base para que, a partir do valor digitado (em moeda estrangeira) pelo vendedor, seja convertido para real, e inserido no pedido. O vendedor será informado, no momento da inserção do item, a respeito da moeda que aquele produto deve ser trabalhado.

É importante salientar que o valor trazido da tabela de vendas já deverá ser o valor correspondente a sua moeda de venda. (Por exemplo, um produto que cuja venda é feita em dólar, caso seu valor na tabela de venda seja 3,65 o Geosales entenderá que se trata de 3,65 dólares, e realizará a devida conversão ao inserir o item no pedido).

No momento da criação do pedido, na tela da decomposição do produto, o GeoSales irá mostrar o valor em dólar, em euro e em reais, para todos os produtos. O usuário poderá visualizar também a data e a hora da alteração da taxa de câmbio de cada moeda.

As informações do valor do produto em moeda estrangeira serão persistidas, de acordo com a moeda cadastrada para o produto, e enviadas ao ERP.

É importante salientar que valor final do pedido deve ser dado sempre em Real.

== Implementação ==

'''- Criação de uma configuração com a finalidade de informar a existência de diferentes moedas:'''

Será criada configuração para ativar a funcionalidade de visualização do valor dos itens por taxa de câmbio.

Caso esta configuração esteja ativa, o sistema deverá exibir informações de moeda na decomposição de preço.

A configuração, chamada de 'UTILIZA_MOEDA_ESTRANGEIRA', poderá receber os valores 'S', para ativá-la, ou 'N', para desativá-la. O valor default para essa configuração é 'N'.

'''- Integração das informações de taxa de câmbio cadastradas no ERP:'''

No ERP, a tabela SM2 será integrada com a finalidade de atualizar a taxa de câmbio. É desta tabela que o GeoSales irá trazer a informação de taxa de câmbio, para converter os valores emitidos em moeda estrangeira para real.

As informações de taxa de câmbio da tabela SM2 do ERP serão salvas na tabela TIPO_MOEDA do GeoSales.

Além disso, deverá ser criado um campo para salvar a data de atualização da taxa de câmbio para uma moeda específica. Este campo deverá ser atualizado sempre que a taxa de câmbio for integrada.

{| class="wikitable"
! colspan="5" | TIPO_MOEDA
|-
! style="width:200px" |Coluna
! Tipo
! style="width:200px" |Obrigatório
! style="width:300px" |Chave Primária
! style="width:300px" |Explicação
|-
| DT_ATUALIZACAO_MOEDA
| DATETIME
| NAO
| NAO
| Data da última atualização da taxa de câmbio.
|-
|}

'''- Integração das informações de moeda associada ao produto no ERP:'''

Serão integradas as informações da tabela de preço cadastradas na tabela padrão (DA1) de vendas do protheus, e, associada ao produto, deverá ser trazido o tipo da moeda que aquele produto será aplicado.

A informação da moeda, associada ao produto no campo DA1_MOEDA da tabela de vendas DA1 deverá ser salva no campo DS_SIGLA_MOEDA que será criado com esta finalidade da tabela FAIXA_PRECO_MOEDA, para determinar o preço daquele produto, na sua respectiva moeda.

{| class="wikitable"
! colspan="5" | FAIXA_PRECO_MOEDA
|-
! style="width:200px" |Coluna
! Tipo
! style="width:200px" |Obrigatório
! style="width:300px" |Chave Primária
! style="width:300px" |Explicação
|-
| CD_SEQUENCIAL || VARCHAR || SIM || SIM || Código do sequencial
|-
| QT_MIN_FAIXA || VARCHAR || SIM || SIM || Quantidade mínima dessa faixa de escalonamento
|-
| DS_SIGLA_MOEDA || VARCHAR || SIM || SIM || Moeda de venda
|-
| VR_PRECO_MINIMO || VARCHAR || SIM || NÃO || Valor mínimo dessa faixa de escalonamento
|-
| VR_PRECO_SUGERIDO || VARCHAR || SIM || NÃO || Valor sugerido dessa faixa de escalonamento
|-
| VR_PRECO_MAXIMO || VARCHAR || SIM || NÃO || Valor máximo dessa faixa de escalonamento
|-
|}

Veja os [http://sync.geosalesmobile.com:8185/erp-importer/sandbox/self-conscious/faixa_preco_moeda.json metadados da tabela]

'''- Converter o valor da moeda ao inserir o item no pedido:'''

Será informado ao vendedor no momento da inserção do item a moeda em que aquele produto deve ser trabalhado. Desta forma, o vendedor pode ter a ciência de que a quantidade inserida refletirá no valor do produto em dólar/euro.

É importante salientar que, apesar de ser inserido seu valor em moeda estrangeira, ao passo da inserção do item no pedido, esse valor será convertido, de acordo com a quantidade digitada, no valor total do produto em reais, e então inserido no pedido.

Por exemplo: O vendedor, na inserção dos dados do produto, seleciona um item, e este item tem como valor '4,50'. O campo DS_SIGLA_MOEDA da tabela FAIXA_PRECO_MOEDA define que este produto é vendido em dólar. Isso quer dizer que o valor deste produto é de 4,50 dólares. O vendedor digita então a quantidade desejada e, ao inserir este item no pedido seu valor é convertido para a moeda 'real' de acordo com a última taxa de câmbio cadastrada na tabela TIPO_MOEDA para a respectiva moeda do produto. Deste modo, o item inserido será visualizado no pedido sempre na moeda padrão 'real'.

É importante salientar que o valor do item só será convertido para real quando este item for inserido no pedido.

'''- Tratar a possibilidade de visualizar o valor dos itens em uma moeda estrangeira, uma na tiragem do pedido:'''

No momento da tiragem do pedido, o usuário irá realizar o fluxo usual de cadastro de cabeçalho de pedido e de inserção de itens, porém, ao selecionar um novo item para ser inserido no pedido, e definir a quantidade que será inserida, o sistema deverá realizar os seguintes passos:

1) As taxas de câmbio utilizadas serão integradas da tabela SM2 do ERP e cada moeda será associada a sua taxa de câmbio;
2) Deverá ser feita a conversão do valor de cada item, para todas as moedas cadastradas. Com a finalidade de exibir na pop-up de decomposição do preço.
3) Da decomposição de preço, deverão ser criados novos campos que sinalizem o valor daquele item convertido em cadas moeda cadastrada.

Deverão ser disponibilizadas para visualização as informações de descrição da moeda (por exemplo: Dólar), símbolo (Por exemplo: $), taxa de câmbio, sua data de atualização, e valor total daquele item convertido nesta moeda.

Para que isso ocorra, será necessário inserir alguns campos na tela de decomposição do preço, como pode-se visualizar no protótipo abaixo:

[[Arquivo:Decomposicao taxas cambio.png]]

Deve ser possível visualizar, nesta tela, as informações de moeda daquele item, além da data de atualização da taxa de câmbio.

É importante salientar que essas informações são exclusivamente informativas, ou seja não vão interferir no valor final do pedido, que será dado em real, como já ocorre atualmente.

Além disso deve ser possível, também, visualizar a decomposição de preço antes de inserir um item no pedido, tal qual o protótipo abaixo:

[[Arquivo:Decomposicao taxas cambio item.png]]

'''- Enviar ao ERP informação do valor de itens na sua moeda estrangeira: '''

Serão criados dois novos campos na tabela ITEM_PEDIDO, com a finalidade de persistir o valor de venda em moeda estrangeira do item, e qual a sua moeda de aplicação.

{| class="wikitable"
! colspan="5" | ITEM_PEDIDO
|-
! style="width:200px" |Coluna
! Tipo
! style="width:200px" |Obrigatório
! style="width:300px" |Chave Primária
! style="width:300px" |Explicação
|-
| DS_SIGLA_MOEDA || VARCHAR(50) || NAO || NAO || Descrição da moeda de venda do produto.
|-
| VR_ITEM_MOEDA || DECIMAL || NAO || NAO || Valor do item em moeda estrangeira.
|-
|}

{| class="wikitable"
! colspan="5" | ITEM_PEDIDO_RETORNO
|-
! style="width:200px" |Coluna
! Tipo
! style="width:200px" |Obrigatório
! style="width:300px" |Chave Primária
! style="width:300px" |Explicação
|-
| DS_SIGLA_MOEDA || VARCHAR(50) || NAO || NAO || Descrição da moeda de venda do produto.
|-
| VR_ITEM_MOEDA || DECIMAL || NAO || NAO || Valor do item em moeda estrangeira.
|-
|}

O campo DS_SIGLA_MOEDA irá salvar a informação da moeda estrangeira que foi aplicada para aquele item (a mesma associada ao item, cadastrada na tabela FAIXA_PRECO_MOEDA). O campo VR_ITEM_MOEDA irá persistir a informação de valor do item na moeda estrangeira respectiva, também cadastrado na tabela FAIXA_PRECO_MOEDA. É importante salientar que estes dados se tratam do valor aplicado naquela venda, ou seja, a moeda e o valor cadastrado na tabela FAIXA_PRECO_MOEDA no momento da inserção do item.

Essas informações serão integradas junto a tabela de ITEM_PEDIDO, e, quando a moeda do item for diferente de real, o valor do item (em moeda estrangeira) enviado será o contido no campo VR_ITEM_MOEDA.

O campo referente a moeda, DS_SIGLA_MOEDA será salvo no campo UB_MOEDKG do ERP. O campo referente a =o valor do item em moeda estrangeira VR_ITEM_MOEDA será salvo no campo UB_PRCKG do ERP.

'''Obs.: Todos os protótipos acima são meramente ilustrativos e, no momento do desenvolvimento, podem sofrer alguma alteração, em virtude de viabilidade técnica.'''

== Regras de Negócio ==

'''RN1 - ''' O valor final do final do pedido será calculado sempre na moeda padrão, ou seja, Real.

'''RN2 - ''' O campo DT_ATUALIZACAO_MOEDA deve ser setado com a data de cada atualização de taxa de câmbio.

'''RN3 - ''' A informação da tabela de preço será integrada sem necessidade de realizar conversão da moeda, ou seja, o valor cadastrado na tabela de preço do produto no ERP deve ser o valor já convertido para moeda estrangeira e será aplicado diretamente no preço do produto. Ao inserir o produto no pedido, o valor deste produto será convertido para real, caso ele seja um produto com moeda estrangeira.

'''RN4 - ''' Este levantamento não contempla alteração em nenhum relatório do Geosales. Portanto, os relatórios que envolvem informações a respeito dos valores do item do pedido serão dados em moeda local (real), e não serão exibidas informações a respeito de outras moedas ou de taxa de câmbio.

'''RN5 - ''' Após inserir o item no pedido, sob este item constará o valor em real convertido. Porém, o usuário poderá visualizar o valor em euro e dólar aplicado sob o item na tela de decomposição do preço.

'''RN6 - ''' A taxa de câmbio utilizada para conversão dos valores dos itens será data pela taxa vigente no dia da inserção do item.

'''RN7 - ''' Será possível que, num mesmo pedido, sejam incluídos produtos com diferentes moedas.

'''RN8 - ''' Um produto só poderá ser associado a uma única moeda. Isso significa que um produto não poderá ser vendido em duas moedas, mesmo que para clientes diferentes.

'''RN9 - ''' Caso o usuário deseje editar um item já inserido, o GeoSales trará o valor de tabela de preço atual para aquele item.

'''RN10 - ''' Só será exibido, na decomposição de preço, o valor em diferentes moedas, caso exista uma taxa de câmbio cadastrada para a respectiva moeda.

'''RN11 - ''' Caso o valor da taxa de câmbio da tabela SM2 do ERP seja igual a zero, este valor não deve ser integrado. Isso tem como finalidade preservar a ultima taxa de câmbio válida cadastrada.

== 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.

=== GeoSales ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
|-
| Desenvolvimento - GeoSales || Anderson Gomes || 06/08/2018
|-
| Integração - GeoSales || Carlos Robson || 06/08/2018
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
! style="width:200px" |Assinatura
|-
| Gerente TI - Cliente || || ||
|-
| Gerente de Projeto - Cliente || || ||
|-
| Gerente Comercial - Cliente || || ||
|-
|}

Discussão:Calculo Frete Peso total e ranger -ANHAMBI

2018-07-05T20:06:30Z

Jeffque:

== Mapeamento do campo '''ID_COMPOE_CALC_FRETE''' ==

Essa coluna deveria ser simplesmente auto-contida. Do jeito que está, o funcionamento dela depende de outra informação, que deveria ser paralela, que é o tipo de frete padrão do cliente.

Como está escrito, as duas colunas não tem funcionalidades ortogonais. Sugiro, então, fazer não um pareamento tosco 1:1 da fonte dos dados para cá. Sugiro fazer uma mineração semântica dessa coluna, assim então não entraremos com gambiarras absurdas no sistema as quais deveremos desfazer e manter a compatibilidade no futuro, quando for detectada a questão da ortogonalidade das informações.

Então, como atualmente quem está como frete padrão de FOB não compõe o cálculo de frete, que se traga assim da integração. Isso é um mapeamento semântico dos dados. Fazendo a mineração correta dos dados, teremos menor dor de cabeça, implementação mais simples, direta, aferível, automaticamente testável através de unidades menores de código e, também, menos manutenção e problemas futuros.

Não se esqueça de algo: o cliente não vai usar a nossa base, ele irá usar o sistema. Para ele, a questão semântica precisa fazer sentido, não a paridade 1:1 dos dados.

Discussão:Calculo Frete Peso total e ranger -ANHAMBI

2018-07-05T20:05:48Z

Jeffque: /* Mapeamento do campo **ID_COMPOE_CALC_FRETE** */ nova seção

== Mapeamento do campo **ID_COMPOE_CALC_FRETE** ==

Essa coluna deveria ser simplesmente auto-contida. Do jeito que está, o funcionamento dela depende de outra informação, que deveria ser paralela, que é o tipo de frete padrão do cliente.

Como está escrito, as duas colunas não tem funcionalidades ortogonais. Sugiro, então, fazer não um pareamento tosco 1:1 da fonte dos dados para cá. Sugiro fazer uma mineração semântica dessa coluna, assim então não entraremos com gambiarras absurdas no sistema as quais deveremos desfazer e manter a compatibilidade no futuro, quando for detectada a questão da ortogonalidade das informações.

Então, como atualmente quem está como frete padrão de FOB não compõe o cálculo de frete, que se traga assim da integração. Isso é um mapeamento semântico dos dados. Fazendo a mineração correta dos dados, teremos menor dor de cabeça, implementação mais simples, direta, aferível, automaticamente testável através de unidades menores de código e, também, menos manutenção e problemas futuros.

Não se esqueça de algo: o cliente não vai usar a nossa base, ele irá usar o sistema. Para ele, a questão semântica precisa fazer sentido, não a paridade 1:1 dos dados.

Novo sincronismo

2017-04-17T20:37:29Z

Jeffque: /* Ambiente de teste/beta */

O novo sincronismo é uma estratégia de marcação horizontal de dados, envio flexível e otimizado para compactação.

O nome do projeto do novo sincronismo é TamoJunto.

==Ambiente de teste/beta==
O host do TamoJunto é [http://beta.softsitemobile.com:8015 o host do beta]. Na versão <strike>[http://10.0.0.75:7070/job/GeoSales_Mobile/1081/ 4.0.1]</strike> <strike>[http://10.0.0.75:7070/job/GeoSales_Mobile/1085/ 4.0.2]</strike> <strike>[http://10.0.0.75:7070/job/GeoSales_Mobile/1095/ 4.0.3]</strike> [http://10.0.0.75:7070/job/GeoSales_Mobile/1116/ 4.0.6], o mesmo host usado para o SyncServer será usado para o TamoJunto, de tal sorte que o usuário não precisará entrar com dados novos no momento do sincronismo, e a porta está fixada como 8015 '''sempre'''.

No ambiente beta, existe um SyncServer e um TamoJunto configurado. O endereço do host é [http://beta.softsitemobile.com beta.softsitemobile.com], a porta do SyncServer é 8015.

A base HugoCini2 está configurada devidamente para o novo sincronismo.

===Teste comparativo===
A versão básica para comparação é a [http://10.0.0.75:7070/job/GeoSales_Mobile/965/ 3.22.9]. Ela é a base para ver se tem algum dado faltoso ou se tem algum comportamento distinto.

Por hora, a única tabela que está no novo esquema é <code>ORG_VENDA_CLIENTE</code>

==Criando novos ambientes==
O primeiro passo no novo sincronismo é subir o servidor do [https://http.cat/404 TamoJunto] na porta 8015. O TamoJunto roda sobre o Java 7, homologado no container Tomcat 8.

==Cadastro de novas empresas==
Dado um ambiente conhecido (no caso, Ares), vamos colocar uma empresa para esse novo sincronismo.

O primeiro ponto é travar totalmente a base. Importação, Claudus, Portal e qualquer outro serviço precisa ser parado para essa base, TOTALMENTE.

Aplique o [https://http.cat/404 script de migração] na base. Então faça as [[novo sincronismo/verificações|verificações]] de que tudo está no canto.

Depois dessa migração, religue TODOS os sistemas.

Cadastre a versão [http://10.0.0.75:7070/job/GeoSales_Mobile/1095/ 4.0.3] para sincronizar (ou a última versão 4.x.y) para a empresa. Coloque para [[novo sincronismo/cadastrar tabela|sincronizar as tabelas desejadas]]. As tabelas disponíveis são:

*<code>ORG_VENDA_CLIENTE</code>

==Códigos de erro==
Ao terminar um sincronismo mal sucedido, o sincronismo do TamoJunto lança um código na tela do usuário. O código tem o seguinte formato: <code>IXHHH</code>. A parte <code>I</code> se refere ao ''instante'', a parte <code>X</code> se refere ao ''erro'' lançado, e a parte <code>HHH</code> se refere ao retorno HTTP.

Os possíveis valores pra <code>I</code> são:
* 1 : autenticação <code>/auth</code>
* 2 : sincronismo <code>/sync</code>
* 3 : truncagem <code>/truncate</code>
* 8 : desconhecido
* 9 : não relacionado ainda

Os possíveis valores pra <code>X</code> são:
* 0 : erro de IO
* 1 : erro de HTTP; o código HTTP de erro segue na parte <code>HHH</code>
* 2 : erro de host
* 3 : erro de SQL
* 9 : erro desconhecido

Os códigos de erro HTTP podem ser encontrados [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes na página da Wikipedia], ou então tem ainda uma [https://http.cat/ lista rápida com gatos].

Caso alguma chamada do TamoJunto retorne um código HTTP diferente de [https://http.cat/200 200], o protocolo reconhece como erro.

Os erros HTTP mais comuns (e seus respectivos significados comuns) retornados pelo TamoJunto são:
* 000 : possivelmente não se conectou num servidor HTTP?
* 400 : o dispositivo falhou ao montar a requisição; deve-se contatar ''imediatamente'' o Anderson e reportar essa problema; também pode ser um sinal de que o usuário esqueceu de preencher o ID palm ou a senha
* 401 : erro de usuário e senha; o ID palm não confere com a senha para aquela empresa, ou o usuário colocou um ID palm errado
* 404 : empresa não cadastrada
* 500 : internal server error; deve-se contatar ''imediatamente'' o Anderson e reportar essa problema

== NÃO ESQUECER ==

* SEMPRE que for instalar o TJ em um servidor TROCAR o jdbc.properties no diretorio /WEB-INF/classes/jdbc.properties pelo jdbc de conexões apropriado.
Caso não seja feito esse passo, o TJ vai acessar uma base diferente.

==Passo a passo migração para o novo Sincronismo==

* Passo 1
* Executar os seguintes scripts
<pre>
/****** Object: Table [dbo].[TAMOJUNTO_TABELA_FUNCAO] Script Date: 26/01/2017 17:02:53 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[TAMOJUNTO_TABELA_FUNCAO](
[ID] [int] IDENTITY(-2147483648,1) NOT NULL,
[NM_TABLE] [varchar](256) NOT NULL,
[NM_FN] [varchar](256) NOT NULL,
[FL_ATIVA] [bit] NULL,
PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

</pre>

<pre>
CREATE TABLE [dbo].[tamojunto_auth](
[cd_vendedor] [int] NOT NULL,
[token] [varchar](255) NULL,
[dt_criacao] [datetime] NULL,
[dt_validade] [datetime] NULL
)
</pre>

<pre>
CREATE TABLE [dbo].[tamojunto_data_geracao_registro](
[id] [int] IDENTITY(-2147483648,1) PRIMARY KEY NOT NULL,
[dt_geracao] [datetime] NOT NULL,
[cd_vendedor] [int] NOT NULL
)
</pre>

<pre>

/****** Object: StoredProcedure [dbo].[sp_get_auth_token] Script Date: 10/11/2016 17:15:21 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

if exists (select top 1 1 from sys.sysobjects where name = 'sp_get_auth_token')
begin
drop proc [sp_get_auth_token]
end
go
CREATE PROCEDURE [dbo].[sp_get_auth_token] (@id_palm CHAR(10),
@ds_senha VARCHAR(20))
AS
BEGIN
;WITH mysource
AS (SELECT dv.cd_vendedor,
substring(convert(varchar, hashbytes('SHA1', Cast(dv.cd_vendedor AS VARCHAR)
+ CONVERT(VARCHAR, Getdate(), 126)), 1), 3, 128) AS token,
Getdate() AS dt_criacao,
Dateadd(hh, 1, Getdate()) AS dt_validade
FROM dados_vendedor dv
LEFT JOIN tamojunto_auth tau
ON ( dv.cd_vendedor = tau.cd_vendedor )
WHERE dv.id_palm = @id_palm
AND dv.ds_senha = @ds_senha)
MERGE tamojunto_auth AS mytarget
using mysource
ON mysource.cd_vendedor = myTarget.cd_vendedor
WHEN matched THEN
UPDATE SET token = mysource.token,
dt_criacao = mysource.dt_criacao,
dt_validade = mysource.dt_validade
WHEN NOT matched THEN
INSERT ( cd_vendedor,
token,
dt_criacao,
dt_validade )
VALUES ( mysource.cd_vendedor,
mysource.token,
mysource.dt_criacao,
mysource.dt_validade )
output mysource.token;
END
GO

</pre>

<pre>

/****** Object: UserDefinedFunction [dbo].[fn_STRING_JSON] Script Date: 10/11/2016 17:11:51 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE FUNCTION [dbo].[fn_STRING_JSON](@ID_VENDEDOR int, @DT_LAST_SINC datetime, @FN VARCHAR(256) )
RETURNS VARCHAR(MAX)
BEGIN
DECLARE @LIN INT = 0
DECLARE @I INT
DECLARE @NAME VARCHAR(256)
DECLARE @system_type_id tinyint
DECLARE @scale tinyint
DECLARE @CMD VARCHAR(MAX) = ' SELECT ''{'''
DECLARE @AUX TABLE (
NAME VARCHAR(256),
LIN SMALLINT,
system_type_id tinyint,
scale tinyint
)

INSERT INTO @AUX
SELECT C.NAME,
ROW_NUMBER() OVER(ORDER BY C.column_id) LIN,
C.system_type_id,
C.scale
FROM SYS.objects O
INNER JOIN SYS.COLUMNS C ON C.OBJECT_ID = O.OBJECT_ID
WHERE O.NAME = @FN

SET @I = ISNULL((SELECT MAX(LIN) FROM @AUX),0)

WHILE @I > @LIN
BEGIN

SET @LIN = @LIN + 1

SELECT @NAME = NAME, @system_type_id = system_type_id, @scale = scale
FROM @AUX
WHERE LIN = @LIN

SET @CMD = @CMD + ' +
CASE WHEN '+ @NAME +' IS NOT NULL THEN
''"'+lower(@NAME)+'"'' + '':"'' + ' +
case
when @system_type_id = 61 then
'convert(varchar, ' + @NAME + ', 126)'
when @scale > 0 then
'case when ' + @NAME + ' = 0 then ''0'' when abs(' + @NAME + ') - floor(abs(' + @NAME + ')) = 0 and ' + @NAME + ' >= -2147483648 AND ' + @NAME + ' <= 2147483647 then cast(cast(' + @NAME + ' as integer) as varchar(max)) else cast(' + @NAME + ' as varchar(max)) end'
else
'replace(rtrim(cast('+@NAME+' as varchar(max)) collate SQL_Latin1_General_CP1_CI_AI), ''"'', ''\"'')'
end
+ ' + ''"' + (case when @LIN = @I then '' else ',' end) +
'''ELSE ''''
END '

END

SET @CMD = @CMD + '+''},'' as json FROM ' + @FN + '('+CONVERT(VARCHAR(30),@ID_VENDEDOR)+','+ ISNULL(quotename(convert(varchar, @DT_LAST_SINC, 126),char(39)),'NULL')+')'

RETURN @CMD
END

GO
</pre>

* Passo 2
* Deve ser executado o programa ScriptGenerator do projeto TamoJunto. Na classe main devem ser especificado para quais tabelas devem ser gerados os scripts de migração.
<pre>
private final String[] tabelas = {
"org_venda_cliente",
"lista_produto",
"lista_produto_lote",
"faixa_preco_produto",
"valor_original_produto",
"produto_custo",
"produto_estoque",
"cliente_rota",
"rota",
"produto",
"tributacao",
"tributacao_produto",
"tributacao_cliente",
"cliente"
};
</pre>

*Nessa etapa pode acontecer uma exceção na hora da geração dos scripts devido a alguma trigger fora do padrão na tabela a ser migrada que pode gerar algum erro. Nessa situação será mostrada uma mensagem no console e o script não será gerado. Exemplos de mensagens:
<pre>
cliente_rota possui triggers que podem afetar a conversão: TR_DELETE_CLIENTE_ROTA, TR_INSERT_CLIENTE_ROTA
</pre>
<pre>
tributacao possui triggers que podem afetar a conversão: TRATAR_INSERT_TRIBUTACAO
</pre>

Nesses casos você deve analisar as triggers e verificar se isso pode ser corrigido ou se a triggers pode ser modificada por uma ação da integração.

Após efetuar os ajustes foi possível efetuar a geração de scripts para as tabelas solicitadas.

*Passo 3
Nesta etapa, deve-se aplicar os scripts gerados no passo anterior.

*Passo 4
Nesta etapa deve-se fazer as mudanças necessárias na procedure sp_gerar_registro e nas procedures correlacionadas de geração de registro. A primeira mudança é adicionar o seguinte trecho de código acima da instrução commit tran -- will release the lock:
<pre>
PRINT CONVERT(VARCHAR(MAX) ,GETDATE(),13) + ' - tamojunto_data_geracao_registro'
INSERT INTO tamojunto_data_geracao_registro (cd_vendedor, dt_geracao) VALUES (@CDVENDEDOR,GETDATE())
</pre>
Esta parte é muito importante e tem que ter bastante atenção por ser um processo manual. Você terá que retirar os inserts de log para todas as tabelas que estão no novo modelo de sincronismo. Basta comentar esses trechos.

*Passo 5
Nesta etapa deve-se aplicar as funções de consultas de dados das tabelas migradas e inserir na tabela de funções o nome das funções. As funções inseridas foram:
<ol>
<li>fn_registro_sync_validade_tj</li>
<li>fn_registro_sync_org_venda_cliente</li>
<li>fn_REGISTRO_SYNC_LISTA_PRODUTO</li>
</ol>
Devem ser inseridos os registros na tabela TAMOJUNTO_TABELA_FUNCAO com os seguintes exemplos
<pre>
INSERT INTO TAMOJUNTO_TABELA_FUNCAO (NM_TABLE, NM_FN, FL_ATIVA)
VALUES ('VALIDADE_TJ', 'fn_registro_sync_validade_tj', 1)

INSERT INTO TAMOJUNTO_TABELA_FUNCAO (NM_TABLE, NM_FN, FL_ATIVA)
VALUES ('ORG_VENDA_CLIENTE', 'fn_registro_sync_org_venda_cliente', 1)

INSERT INTO TAMOJUNTO_TABELA_FUNCAO (NM_TABLE, NM_FN, FL_ATIVA)
VALUES ('LISTA_PRODUTO', 'fn_REGISTRO_SYNC_LISTA_PRODUTO', 1)
</pre>

Versão/mobile/v4.1.0

2017-03-06T18:38:29Z

Jeffque: /* Detalhes */

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike> - deu erro de compilação
** <strike>(RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/</strike> - dá erro após falhar no sincronismo
** (RC3) http://homolog1.softsitemobile.com:7171/view/Jeff/job/GeoSales_Mobile/1201/

=Clientes atendidos=

* Agrosema
* Camil
* Makita
* Ourolux
* Reflexa

=Mudança na infraestrutura=

Remover cliente prospect que contenha pedido foi alterado o fluxo de interface. Precisa ver se ficou legal ou não.

Exclusão de pedidos foi ligeiramente modificada, não creio que afete a vida em nada, mas não tenha certeza.

O protocolo de geração de código do pedido foi alterado. Agora, o próximo <code>cd_pedido_palm</code> que é disponibilizado para o vendedor tem pouca relação com a hora atual. O protocolo de geração agora determina um número mínimo, esse por sua vez que é o momento atual (<code>YYMMDDhhmmss</code>), então ele pega sempre o próximo número disponível. Então, se o vendedor <code>509</code> iniciar o sistema as <code>8:40:12</code> da manhã do dia <code>2017-03-06</code>, não sincronizar nem desligar a aplicação, então realizar um pedido as <code>17:37:47</code>, o código gerado é <code>509170306084012</code> e o do pedido seguinte é <code>509170306084013</code>.

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

Nenhuma

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:24:23Z

Jeffque: /* Mudança na infraestrutura */

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Agrosema
* Camil
* Makita
* Ourolux
* Reflexa

=Mudança na infraestrutura=

Remover cliente prospect que contenha pedido foi alterado o fluxo de interface. Precisa ver se ficou legal ou não.

Exclusão de pedidos foi ligeiramente modificada, não creio que afete a vida em nada, mas não tenha certeza.

O protocolo de geração de código do pedido foi alterado. Agora, o próximo <code>cd_pedido_palm</code> que é disponibilizado para o vendedor tem pouca relação com a hora atual. O protocolo de geração agora determina um número mínimo, esse por sua vez que é o momento atual (<code>YYMMDDhhmmss</code>), então ele pega sempre o próximo número disponível. Então, se o vendedor <code>509</code> iniciar o sistema as <code>8:40:12</code> da manhã do dia <code>2017-03-06</code>, não sincronizar nem desligar a aplicação, então realizar um pedido as <code>17:37:47</code>, o código gerado é <code>509170306084012</code> e o do pedido seguinte é <code>509170306084013</code>.

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

Nenhuma

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:16:35Z

Jeffque: /* Clientes atendidos */

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Agrosema
* Camil
* Makita
* Ourolux
* Reflexa

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

Nenhuma

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:15:46Z

Jeffque:

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

Nenhuma

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:15:33Z

Jeffque: /* Mudanças gerais em funcionalidades */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

Nenhuma

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:13:12Z

Jeffque: /* Liberação de funcionalidade */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code>ID_UTILIZA_PRECO_MAXIMO</code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

PREENCHER

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:12:43Z

Jeffque: /* Liberação de funcionalidade */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Ourolux
** Ao carregar o item, ele já carrega com o valor máximo
** Configuração: <code></code>
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

PREENCHER

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:11:31Z

Jeffque: /* Liberação de funcionalidade */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Ourolux
** Um dia vai pra Wiki
* Utiliza peço máximo
** Perguntar ao Araújo
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

PREENCHER

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:08:15Z

Jeffque: /* Liberação de funcionalidade */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Perguntar para o Roseno
* Utiliza peço máximo
** Perguntar ao Araújo
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** http://10.0.0.32/wiki/index.php/Cadastro_Clientes_Vencidos
* Agenda de visita
** Agrosema
** http://10.0.0.32/wiki/index.php/Agenda_de_Visita
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** http://10.0.0.32/wiki/index.php/Widgets_da_Tela_Inicial

=Mudanças gerais em funcionalidades=

PREENCHER

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A

Versão/mobile/v4.1.0

2017-03-06T17:04:50Z

Jeffque: /* Liberação de funcionalidade */

=Público do documento=

* Desenvolvimento
* Suporte
* Teste

=Detalhes=

* Data de liberação
** <strike>RC1 08/03/2017</strike>
** RC2 08/03/2017
** previsão para 08/03/2017
* Nome da versão
** [[versão/mobile/v4.1.0|v4.1.0]]
* Versão pai
** [[versão/mobile/v4.0.18|v4.0.18]]
* Link para versão:
** <strike>(RC1) http://10.0.0.75:7070/job/GeoSales_Mobile/1198/</strike>
** (RC2) http://10.0.0.75:7070/job/GeoSales_Mobile/1199/

=Clientes atendidos=

* Todos
* Agrosema
* Alguns que eu preciso perguntar coisas

=Mudança na infraestrutura=

PREENCHER

=Branches utilizados para essa versão desde a versão anterior=
Núcleo:

* feature-rel-estoque-ausente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/717 717]
* feature-utiliza-preco-maximo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/726 726]
* bugfix-controle-tramitacoes-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/751 751]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/723 723]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/764 764]
* bugfix-filtro-fornecedor-cadastro-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/710 710]
* feature-camil-exibe-tipo-venda-pedido-conf [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/765 765]
* hotfix-melhorando-desempenho-arquivo-edi [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/766 766]
* bugfix-campanha-validacao-dt-entrega [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/731 731]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/769 769]
* bugfix-valor-fatura-frete-manual [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/768 768]
* bugfix-prioridade-vr-pedido-jug-cond-pgto-str [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/785 785]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/748 748]
* hotfix-configuracao-id-obriga-vencimento [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/789 789]
* bugfix-remover-dtCadastroDate-bean-cliente [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/790 790]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/771 771]
* bugfix-julgar-rentabilidade-pedido-familias-hidratadas [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/794 794]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/791 791]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/809 809]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/nucleo/merge_requests/811 811]

Mobile:

* hotfix-filtros-fornecedores-portal [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1036 1036]
* feature-camil-campos-obs [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1028 1028]
* feature-agrosema-widgets-tela-inicial [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/997 997]
* hotfix-valor-pedido-julgar-condicao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1037 1037]
* feature-agrosema-bloqueio-por-prazo [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/996 996]
* feature-agrosema-clientes-vencidos [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1038 1038]
* feature-agrosema-agenda-visita [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1050 1050]
* feature-cond-pgto-padrao [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/967 967]
* feature-controle-retorno-pedido [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1074 1074]
* improve-safesleep [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1077 1077]
* fix-testes [http://homolog1.softsitemobile.com:1232/geosales/mobile/merge_requests/1078 1078]

=Liberação de funcionalidade=

* Estoque ausente
** Perguntar para o Roseno
* Utiliza peço máximo
** Perguntar ao Araújo
* Condição de pagamento padrão
** Reflexa
** http://10.0.0.32/wiki/index.php/Projeto/Reflexa/Documentação/Condição_de_Pagamento_Padrão
* Sumir com os campos de observação
** Camil
** http://redmine.softsitemobile.com/issues/1594
* Oculta tipo de venda do item
** Camil
** http://redmine.softsitemobile.com/issues/1595
* Bloqueio por prazo
** Agrosema
** http://redmine.softsitemobile.com/issues/1238
** http://10.0.0.32/wiki/index.php/Bloqueio_de_Prazo
* Clientes vencidos
** Agrosema
** Procurar pelo doc na Wiki
* Agenda de visita
** Agrosema
** Procurar pelo doc na Wiki
* Controle de retorno do pedido
** Makita
** Em algum documento MID22 antigo perdido pelo mundo...
** Quantas vezes o pedido retornar ao vendedor
* Widgets da tela inicial
** Agrosema
** http://redmine.softsitemobile.com/issues/1237
** Procurar o documento na Wiki
*

=Mudanças gerais em funcionalidades=

PREENCHER

=Correção de bugs=

Correção
* Cliente afetado
** Empresa
* Versões onde o bug foi detectado
** Versão
* Possíveis side effects da correção
** side effects
* Link para issue tracker
** N/A