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

Pedido Retorno no GeoMind

2018-08-23T20:45:07Z

Luan Lima: /* GeoSales */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 22/08/2018 || Ana Júlia || Criação do documento
|-
|}

== Necessidade ==

Alguns vendedores tiram pedido pelo ERP, e não pelo GeoSales, ou seja, não utilizam as funcionalidades de tiragem de pedido que o GeoSales disponibiliza, devido a região que atendem.

Atualmente os pedidos que são retirados no ERP, voltam para o GeoSales na tabela que comporta os dados de retorno do pedido (PEDIDO_RETORNO).

Onde as funcionalidades disponibilizadas no Geomind, como o cenário, não disponibiliza dados do retorno do pedido, ou seja, não são exibidas informações de pedido tirados no ERP, havendo a necessidade de exibição dessas informações.

== Solução ==

As consultas do Geomind deverão levar em considerarão os pedidos retirados no ERP, ou seja, deverão levar em consideração as informações de retorno de pedidos (PEDIDO_RETORNO).

O controle deverá ser feito através de uma configuração, que quando ativada deverá verificar além dos pedidos retirados no GeoSales, os pedidos do ERP.

== Implementação ==

=== Desenvolvimento ===

Atualmente as informações do Geomind que trazem informações de pedido, como por exemplo o cenário, consultam e exibem somente pedidos tirados no GeoSales.

As consultas de Geomind, referentes a exibição de cenários e relatórios, devem apresentar os pedidos retirados no GeoSales e os pedidos que foram retirados no ERP.

O fluxo de exibição de pedidos retirados no GeoSales e do ERP, devem ser controlados pela configuração ID_EXIBE_PED_ERP_GEOMID, onde quando ativada os pedidos que foram tirados no ERP, serão exibidas no Cenário e no relatório do Geomind.

Para que a configuração ID_EXIBE_PED_ERP_GEOMID esteja ativada deverá receber o valor 'S', para que não seja utilizada a funcionalidade de exibição de pedido retirado no ERP no canário e no relatório do Geomind, a configuração ID_EXIBE_PED_ERP_GEOMID deverá receber valores 'N' ou 'NULL', ou seja, a configuração ID_EXIBE_PED_ERP_GEOMID, onde deverá receber valores 'S', para ativar, 'N' ou 'NULL' para desativar.

== Regras de Negócios ==

'''[RN1] - ''' Os pedidos retirados no ERP, só serão exibidos na funcionalidade de Geomind, sendo eles cenário e relatórios.

'''[RN2] - ''' O pedido retirado no ERP, para ser exibido na funcionalidade Geomind, só ficará visível se a informação consta na base do GeoSales.

== Resultados Esperados ==

=== Fluxos Padrão ===

[[Arquivo:Geomind - Gart.JPG]]

== 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
! style="width:200px" |Assinatura
|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000 || Luan Lima
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000 ||
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
! style="width:200px" |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 ||
|-
|}

Projeto/Reflexa/Documentação/Alerta Validação de controle de limite de credito

2018-08-20T17:09:14Z

Luan Lima: /* Histórico de Revisões */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/06/2018 || Renato Lima || Criação do Documento
|-
| 12/06/2018 || Marcus Fabio Salviano || Validado pelo desenvolvimento
|-
| 14/06/2018 || Renato Lima || Ajuste em alerta, no momento que o limite de credito for excedido.
|-
| 03/07/2018 || Renato Lima || Remover referencia para configuração ID_VALIDA_LIMITE_CREDITO_ITEM.
|-
| 17/08/2018 || Ana Júlia || Alteração da documentação.
|-
| 20/08/2018 || Luan Lima || Aprovação de Ajustes.
|-
|}

== Necessidade ==
Cliente solicitou que no momento de inserir um item no pedido e que ele tenha excedido o limite de crédito do cliente, seja apresentado alerta ao vendedor apresentando a informação, sem que seja necessário o vendedor venha finalizar o pedido para que o alerta seja apresentado.

Sendo necessário também exibir um alerta, quando o somatório do pedido passar do limite de crédito do cliente e questionar ao usuário se deseja salvar o pedido, se o pedido tiver ultrapassado o limite de crédito.

== Solução ==
No momento em que o vendedor estiver adicionando os itens do pedido, o sistema validará o limite de credito, antes do vendedor realizar o processo de salvar pedido. Assim o vendedor terá retorno se o limite foi excedido ou não antes de salvar o pedido.

Deverá ser criado uma configuração para que seja controlado o alerta no momento da ultrapassagem do limite de credito do cliente.

Para os pedidos que ultrapassarem o limite de crédito, deverá ser exibida uma mensagem, confirmando a ação de salvar um pedido que ultrapasse o limite de crédito disponível para o cliente.

== Implementação ==

'''-Limite de crédito Atingido'''

O Geosales no momento de inserção dos itens, ao atingir o limite de credito do cliente, apresentará uma mensagem informando que o limite de credito foi atingido. O sistema irá verificar se ID_ATUALIZA_SALDO está como "S" e irá realizar a validação no momento de inserir o item e de salvar, quando o campo estiver com "N" ou NULL, não acontecerá está validação.

Mensagem:Limite de crédito disponível, foi excedido em R$ Valor.

O Sistema irá verificar o limite e o valor do pedido e apresentar a diferença onde está o valor.

'''-Limite de credito ultrapassa valor cadastrado - Inserção de Item'''

Será exibida uma mensagem de alerta ao vendedor quando o valor/somatório dos itens passar do limite de crédito cadastrada para o cliente.

Mensagem: O saldo de limite de crédito está insuficiente. Excedido em R$ .

'''Limite de crédito ultrapassa - Salvar pedido'''

Deverá ser criada uma validação no sistema GeoSales, na hora de salvar um pedido, onde se um pedido ultrapassar o valor de limite de crédito disponível para o cliente, deverá ser exibido um pop-up, questionando ao usuário com a mensagem 'Pedido ultrapassou limite de crédito, deseja continuar?' dando as opções de 'Sim' e 'Não'

Caso o usuário selecione a opção 'Sim', o sistema deverá salvar o pedido com o limite de crédito ultrapassado , ou seja, o pedido mesmo passando do limite de credito poderá ser salvo sem pendencia, se a opção selecionada for 'Não', o sistema não deverá salvar o pedido, continuando assim na tela de cadastro de pedido.

O controle do pop-up será feita através da configuração ID_EXIBE_MENSAGEM_CREDITO, onde deverá receber valor 'S', para quando tiver ativada, 'N' ou NULL para desativar.

==Regras de Negócio==

'''RN1 - ''' O sistema irá verificar se ID_ATUALIZA_SALDO da tipo_movimento pedido está como "S" e irá realizar a validação no momento de inserir o item e de salvar.

'''RN2 - ''' Validação deverá ser usada, quando o cliente optar em realizar o controle de limite de credito.

'''RN3 - ''' O controle por item pode acontecer, mesmo que tenha o controle de limite de credito ao salvar o pedido.

'''RN4 - ''' Ao final da criação do pedido, ou seja, ao salvá-lo, será exibida uma pop-up informando ao usuário acerca do excedente de limite de crédito, questionando-o se deseja salvar o pedido mesmo assim, ou alterá-lo.

== Aprovação ==

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

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:200px" |Data
! style="width:300px" |Assinatura
|-
| Gerente TI
|
|
|
|-
| Gerente Projeto
|
|
|
|-
| Gerente Comercial
|
|
|
|}

Cadastro de cliente prospect

2018-08-16T19:14:43Z

Luan Lima: /* GeoSales */

== Histórico de Revisões ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 12/06/2018 || Ryvane Maria || Criação do Documento
|-
| 15/06/2018 || João Felipe Maciel || Ajustes no Documento
|-
| 20/06/2018 || Ryvane Maria || Ajustes e finalização do Documento
|-
| 21/06/2018 || Leonardo Sousa || Aprovação de documentação
|-
| 03/08/2018 || Ana Júlia || Atualização da documentação
|-
| 16/08/2018 || Ana Júlia || Atualização da documentação
|}

== Necessidade ==

Atualmente uma ficha cadastral de novos clientes é preenchida manualmente. Esta ficha contém algumas informações que não estão contidas no atual cadastro de prospect do Geosales. Essas informações, por sua vez, são primordiais à análise dos novos clientes cadastrados.

É importante, também, que este novo cliente tenha seu cadastro enviado ao ERP e que este cadastro seja inserido com o status 'Bloqueado'. Além disso, é necessário identificar que o cliente está com o status bloqueado por se tratar de um novo cliente, ou seja, clientes prospect devem entrar no ERP com status de bloqueado, e identificados com o motivo do bloqueio (no caso, cliente prospect).

== Solução ==

Para que este cadastro de clientes prospect do GeoSales receba as informações que são cadastradas pela empresa atualmente, será feita uma adequação na plataforma GeoSales de forma que esta possa vir a receber (por meio de cadastro no portal ou no aplicativo mobile) as informações utilizadas no cadastro de clientes prospect. Com esta finalidade, serão criados novos campos para cadastro dessas informações,e ,ao passo deste cadastro, os campos serão salvos e enviados ao ERP no momento da integração de cadastro de clientes prospect.

É também no momento da integração que o cliente terá seu status setado como 'bloqueado', bem como será inserida uma flag com a finalidade de identificar o tipo de bloqueio daquele cliente, que, neste caso, é por ser um cliente prospect.

== Integração ==

As tabelas contendo a informação de cadastro de cliente prospect deverão ser enviadas ao ERP, como já ocorre atualmente, incluindo-se todos os campos que serão adicionados.

Além disso é no momento da integração que o status do cliente deverá ser salvo como 'Bloqueado' no ERP. Para setar esse status, deve-se inserir o valor '1' no campo 'A1_MSBLQL', que significa que o cliente está bloqueado pelo tipo '1', novo cliente.

Deve ser setado, também, o campo 'A1_XGRUPO' com o valor 'PC', informando assim, que o cliente é um cliente prospect (Pré-Cadastro).

Os campos que possuem ListBox setado para 'SIM', terão que ser integrados, caso não exista em nossa base. Outros serão populados automaticamente em nossa base, ou seja, não havendo necessidade de integração. Segue abaixo tabelas que serão integradas e as que não precisam ser integradas.

O campo DS_REGIAO será tratado na integração, onde será classificado as regiões do Brasil (Norte, Nordeste, Centro-Oeste, Sudeste e Sul) de acordo com o estado que o vendedor selecionou na hora do cadastro de cliente novo.

'''Observação''': O campo 'Integração' é composto por dois valores, 'Integrada' e 'Não Integrada'. O valor 'Integrada' significa que já está sendo enviada ao Geosales, e o valor 'Não Integrada' significa que não está sendo enviada ao GeoSales. As que possuem o valor 'Não Integrada', será necessário traze-las ao GeoSales, ou seja, integrar.

{| class="wikitable"
! colspan="6" | INTEGRAÇÃO
|-
! |CAMPO GEOSALES
! |TABELA GEOSALES
! |INTEGRAÇÃO

|-
| CD_COND_PGTO_PADRAO || CONDICAO_PAGAMENTO|| Integrada
|-
| CD_GRUPO || GRUPO_CLIENTE || Não é Integrada
|-
| CD_ROTA || CLIENTE_ROTA_APROVACAO || Integrada
|-
| CD_SETOR_VENDA || SETOR_VENDA || Não é Integrada
|-
| DS_REGIAO || * || Não é Integrada
|-
| SEGMENTACAO || CD_SEGMENTO || Não é Integrada
|-
| TIPO_CLIENTE || CD_TIPO_CLIENTE || Não é Integrada
|-
| CATEGORIA_CLIENTE || CD_CATEGORIA || Não é Integrada
|-
| ID_TIPO_FRETE_PADRAO || TIPO_FRETE || Integrada
|-
| NM_MUNICIPIO || MUNICIPIO || Integrada
|-
| CD_UF || UNIDADE_FEDERATIVA || Integrada
|}

As tabelas SEGMENTACAO, TIPO_CLIENTE e CATEGORIA_CLIENTE devem ser populadas pela tabela que representam o segmento cadastrado no ERP do cliente, devendo ser integradas ao GeoSales, conforme informado na tabela acima.

{| class="wikitable"
! colspan="6" | SEGMENTO ERP
|-
! |TABELA GEOSALES
! |TABELA ERP
! |DESCRIÇÃO ERP

|-
| SEGMENTACAO || SX5 (T3) || Segmento 1
|-
| TIPO_CLIENTE || SX5 (T3) || Segmento 2
|-
| CATEGORIA_CLIENTE || SX5 (T3) || Segmento 3
|}

== Desenvolvimento ==

As telas de cadastro de prospect, tanto do mobile quanto do portal, deverão ser alteradas de forma a contemplar o cadastro dos novos campos que serão criados (vide tabela abaixo).

Os campos ficarão disponíveis no mobile e portal, para os campos que são lista de seleção (selectbox), será necessário conter dados nas tabelas, caso as tabelas estejam sem informações, o mobile retornara a mensagem 'Não há dados para seleção'.

Será criada a tabela SETOR_VENDA, que conterá os campos de descrição do setor de venda (DS_SETOR) e o código de cada setor de venda (CD_SETOR).

{| class="wikitable"
! colspan="6" | SETOR_VENDA
|-
! |COLUNA
! |TIPO
! |OBRIGATÓRIO
! |CHAVE PRIMARIA
! |DESCRIÇÃO
|-
| DS_SETOR || Varchar(50) || SIM|| NÃO || Setor de Venda
|-
| CD_SETOR || Int || SIM || SIM || Código do setor de venda
|}

Deverá ser criada a tabela SEGMENTACAO.

{| class="wikitable"
! colspan="6" | SEGMENTACAO
|-
! |COLUNA
! |TIPO
! |OBRIGATÓRIO
! |CHAVE PRIMARIA
! |DESCRIÇÃO
|-
| DS_SEGMENTACAO || Varchar(50) || SIM|| NÃO || Descrição da segmentação
|-
| CD_SEGMENTACAO || Int || SIM || SIM || Código da segmentação
|}

As tabelas TIPO_CLIENTE e CATEGORIA_CLIENTE, já possuem estrutura, mas precisa ser criada as chaves primárias.
Sendo necessário criar as estruturas de vinculação

{| class="wikitable"
! colspan="6" | SEGMENTACAO_TIPO
|-
! |COLUNA
! |TIPO
! |OBRIGATÓRIO
! |CHAVE PRIMARIA
! |DESCRIÇÃO
|-
| CD_CATEGORIA || Int || SIM|| SIM || Código da categoria
|-
| CD_SEGMENTAÇÃO || Int || SIM || SIM || Código da segmentação
|}

{| class="wikitable"
! colspan="6" | TIPO_CATEGORIA
|-
! |COLUNA
! |TIPO
! |OBRIGATÓRIO
! |CHAVE PRIMARIA
! |DESCRIÇÃO
|-
| CD_CATEGORIA || Int || SIM|| SIM || Código da categoria
|-
| CD_TIPO_CLIENTE || Int || SIM || SIM || Código do tipo do cliente
|}

As tabelas TIPO_CLIENTE, CATEGORIA_CLIENTE e SEGMENTACAO devem estar ligadas de maneira consigam ser preenchidas inversamente.

Por exemplo: Tenho respectivamente as tabelas SEGMENTACAO (1), TIPO_CLIENTE(2) e CATEGORIA_CLIENTE (3), o vendedor poderá preencher o campo de duas maneiras, podendo ser preenchido na 1, 2 e 3 ou 3,2 e 1. Fazendo com que puxe os dados de acordo com os vinculos.

A forma de preenchimento dos segmentos, tipo de cliente e categoria de cliente deve sempre puxar uma a outra, ou seja, a seleção de informações devem ficar visíveis de acordo com o selecionado.

Por exemplo: O vendedor está fazendo o cadastro de cliente novo, e começa a preencher os dados de segmento, no segmento 1 o vendedor seleciona o primeiro segmento; estarão disponíveis para seleção uma sequencia de dados previamente cadastradas no ERP; em que estarão visíveis na tela as opções 'Varejistas' e 'Atacadistas', o vendedor selecionou a opção 'Varejista'. No segmento 2, será exibido as opções 'Varejista comercial' e 'Varejista Local', o vendedor seleciona a opção 'Varejista comercial'. No segmento 3, será exibido as opções 'Depósito de Bebidas' e 'Supermercado', o vendedor seleciona a opção 'Supermercado', dessa maneira o cadastro de segmento está concluído.

No mobile os campos de segmento terão os nomes:

* Segmento 1: Segmentação;
* Segmento 2: Tipo
* Segmento 3: Categoria;

É importante salientar que, após selecionar todos os segmentos, caso o usuário deseje alterar o segmento de venda, todos os segmentos de vendas seguintes a este deverão ser selecionados novamente. Por exemplo: caso o usuário altere o segmento 1, os segmentos 2 e 3 terão sua escolha limpa, e deverão ser selecionados novamente. Caso o usuário altere o segmento 2, apenas o segmento 3 deverá ser selecionado novamente.

Com a finalidade de armazenar as informações de cliente prospect, serão criados novos campos na tabela 'CLIENTE_APROVACAO', alguns desses campos já existem, não havendo a necessidade de cria-los novamente. Os dados de cliente prospect serão integrados no ERP, de acordo com o que foi cadastrado e salvo na tabela de CLIENTE_APROVACAO.

Os campos que possuem 'ListBox', sinalizados na tabela abaixo, deverão ser integrados para o ambiente GeoSales, tornando-se então disponíveis para o vendedor selecionar os dados, previamente cadastrados no ERP, no cadastro do cliente prospect.

Segue abaixo tabela com informações dos campos que precisam ser incluídos:

{| class="wikitable"
! colspan="9" | CLIENTE_APROVACAO
|-
! NOME
! TIPO
! OBRIGATÓRIO
! CHAVE PRIMÁRIA
! OBSERVAÇÃO
! CAMPO ERP
! TABELAS DE SELEÇÃO
! VALIDAÇÃO
! CAMPOS LISTBOX
|-
| CD_COND_PGTO_PADRAO || Int || NÃO|| NÃO || Condição de pagamento padrão || A1_COND || SE4 ||E4_CODIGO cujo o valor inicie com a letra "C" || SIM
|-
| CD_GRUPO || Varchar(20) || NÃO || NÃO || Código do grupo de clientes || A1_GRPVEN || ACY || || SIM
|-
| CD_ROTA || Int || NÃO || NÃO || Código da rota || A1_XROTA || SZ3 || || SIM
|-
| CD_SETOR_VENDA || Varchar(30) || NÃO|| NÃO || Código do setor de venda || A1_XSETOR || SZ2 || || SIM
|-
| CD_TAB_PRECO_PADRAO || Int || NÃO|| NÃO || Tabela de preço de venda || A1_TABELA || || DA0 || SIM
|-
| CD_VENDEDOR || Varchar(20) || NÃO|| NÃO || Código do vendedor responsável || A1_VEND || || || NÃO
|-
| DS_CONTATO || Varchar (30) || NÃO|| NÃO|| Nome do contato da empresa cliente || A1_CONTATO || || Caracteres em caixa alta || NÃO
|-
| DS_ENDERECO || Varchar (70) || NÃO|| NÃO || Endereço do cliente || A1_END || || Caracteres em caixa alta || NÃO
|-
| DS_HOMEPAGE || Varchar(300) || NÃO || NÃO || HomePage do cliente || A1_HPAGE || || || NÃO
|-
| DS_REGIAO || Varchar(20) || NÃO || NÃO || Região de vendas do cliente || A1_REGIAO || SX5 || tabela = A2 || SIM
|-
| CD_SEGMENTACAO || Int || SIM || NÃO || O 1o. segmento de negócio da empresa || A1_SATIV1 || SX5 || tabela = T3 || SIM
|-
| CD_TIPO_CLIENTE || Int || SIM || NÃO || O 2o. segmento de negócio da empresa || A1_SATIV2 || SX5 || tabela = T3 || SIM
|-
| CD_CATEGORIA || Int || SIM || NÃO || O 3o. segmento de negócio da empresa || A1_SATIV3 || SX5 || tabela = T3 || SIM
|-
| DT_NASCIMENTO || Datetime || NÃO|| NÃO || Data de nascimento do cliente || A1_DTNASC || || || NÃO
|-
| DS_EMAIL || Varchar (200) || NÃO|| NÃO || E-mail do Cliente || A1_EMAIL || || Validar se a sintaxe do e-mail digitado é válido || NÃO
|-
| ID_TIPO_FRETE_PADRAO || Char(1) || NÃO || NÃO || Tipo de frete do cliente (C para CIF, F para FOB) || A1_TPFRET || Buscar informações do tipo de frete CIF/FOB || || SIM
|-
| NM_BAIRRO || Varchar (40) || NÃO|| NÃO || Bairro do cliente || A1_BAIRRO || || || NÃO
|-
| NM_CLIENTE || Varchar (100) || NÃO|| NÃO || Nome ou razão social do cliente || A1_RAZAO || || Caracteres em caixa alta || NÃO
|-
| NM_MUNICIPIO || Varchar (80) || NÃO|| NÃO || Municipio do cliente || A1_MUN || CC2 || || SIM
|-
| NR_CNPJ_CPF || varchar (25) || SIM || NÃO || CNPJ/CPF do cliente || A1_CGC || || Validar se código do CPF e CNPJ são válidos || NÃO
|-
| NR_FREQUENCIA_VISITA || Int || NÃO|| NÃO|| Intervalo de dias entre as visitas ao cliente || A1_TEMVIS || || || NÃO
|-
| NR_IDENTIDADE || Varchar(30) || NÃO || NÃO || Número do RG do cliente || A1_PFISICA || || || NÃO
|-
| NR_CGF || Varchar(30) || NÃO || NÃO || Inscrição estadual do cliente || A1_INSCR || || || NÃO
|-
| NR_INSCRICAO_MUNICIPAL || Varchar(30) || NÃO || NÃO || Inscrição municipal do cliente || A1_INSCRM || || || NÃO
|-
| NR_SEQ_ATEND || Int || NÃO|| NÃO || Ordem do percurso de atendimento do cliente na rota || A1_XXPERCU || || || NÃO
|-
| NR_TELEFONE || Varchar(25) || NÃO || NÃO || Número de Celular para contato || A1_XCELULA || || || NÃO
|-
| NM_ESTADO || varchar (2) || NÃO || NÃO || Unidade federativa do cliente || A1_EST || || || SIM
|-
| VR_LIMITE || Decimal || NÃO || NÃO || Limite de crédito do cliente || A1_LC || || || NÃO
|}

É importante salientar que os dados de rota serão tratados através da tabela CLIENTE_ROTA_APROVAÇÃO.

A coluna 'validação' define quais validações o sistema terá que fazer na hora do preenchimento do cadastro de cliente prospect.

A coluna 'LISTBOX', determina quais os campos que o usuário deverá selecionar a informação ao invés de digitá-la. Caso a coluna 'LISTBOX' esteja preenchido com o valor 'SIM', as opções que o usuário poderá selecionar como reposta, para este item do cadastro de prospect, estarão cadastradas na tabela contidas na coluna 'TABELAS DE SELEÇÃO'.

As tabela contidas na coluna 'TABELAS DE SELEÇÃO' serão trazidas do ERP via integração e salvas no GeoSales.

Por exemplo:
Quando o usuário estiver cadastrando um cliente prospect, e selecionar a opção 'Condição de Pagamento', o sistema exibirá um campo do tipo selectbox, tendo como possibilidades de repostas as informações contidas na tabela SE4, o dado selecionado neste campo será salvo no campo CD_COND_PGTO_PADRAO da tabela CLIENTE_APROVACAO.

Não será necessário criar no mobile ou portal campo com informações de região (DS_REGIAO), pois a informação de região será tratada na integração.

*Deverá ser criadas configurações para que seja controlada a obrigatoriedade dos campos citados na tabela abaixo. A configuração terá como padrão a nomenclatura, tendo sufixo 'CAMPO_OBR:' mais o prefixo sendo o nome da coluna que será obrigatória. As configurações poderão receber o valor 'S', para ativar a exibição dos campos ou 'N' para desativar. Caso essa configuração não seja ativada, será setado o valor NULL como padrão, neste caso, os campos estarão desabilitados.

#CD_COND_PGTO_PADRAO
#CD_GRUPO
#CD_ROTA
#CD_SETOR_VENDA
#CD_TAB_PRECO_PADRAO
#CD_VENDEDOR
#DS_CONTATO
#DS_ENDERECO
#DS_SEGMENTO_1
#DS_SEGMENTO_2
#DS_SEGMENTO_3
#NM_BAIRRO
#NM_CLIENTE
#NM_MUNICIPIO
#NR_CNPJ_CPF
#NR_FREQUENCIA_VISITA
#NR_SEQ_ATEND
#UF

==Regras de Negócio==

'''RN1 - ''' Não será criado nenhum outro campo além dos que estão contemplados neste documento.

'''RN2 - ''' Para que seja inserida a informação "PC" no campo “A1_XGRUPO”, é necessário que esteja sendo aplicado o modelo Claudus de integração.

'''RN3 - ''' Deverá ser habilitado o status 'bloqueado' aos clientes prospect que forem recém cadastrados.

'''RN4 - ''' Não será realizada nenhuma outra validação fora as que se encontram neste documento.

'''RN5 - ''' O campo DS_REGIAO, será alimentada diretamente na integração, onde o vendedor não irá precisar selecionar a região, de acordo com o estado que for selecionado a integração setará para a região de destino.

==Regras de Integração==

'''RI1 - ''' O campo A1_PESSOA da tabela SA1, deverá ser preenchido, no momento da integração, com o valores 'J' caso se trate de uma pessoa jurídica e 'F' caso se trate de uma pessoa física.

'''RI2 - ''' A tabela ACY do ERP, que alimenta a tabela GRUPO_CLIENTE terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI3 - ''' A tabela SZ2 do ERP , que alimenta a tabela SETOR_VENDA terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI4 - ''' A tabela de seleção SX5 do ERP da tabela A2, que alimenta a tabela 'DS_REGIAO' terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI5 - ''' A tabela de seleção SX5 do ERP da tabela T3, que alimenta a tabela 'SEGMENTO 1' (SEGMENTACAO) terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI6 - ''' A tabela de seleção SX5 do ERP da tabela T3, que alimenta a tabela 'SEGMENTO 2' (TIPO_CLIENTE) terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI7 - ''' A tabela de seleção SX5 do ERP da tabela T3, que alimenta a tabela 'SEGMENTO 3' (CATEGORIA_CLIENTE) terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI8 - ''' Os campos CD_COND_PGTO_PADRAO, CD_ROTA e ID_TIPO_FRETE_PADRAO já se encontram sendo enviadas ao GeoSales, não havendo necessidade de integrá-las novamente.

'''RI9 - ''' A tabela de seleção CC2 do ERP, que alimenta a tabela 'MUNICIPIO' terá que ser enviado pela Reflexa, caso contrário não terá informações no selectbox.

'''RI10 - ''' Não será integrado nenhuma outra informação que não se encontre neste documento.

'''RI11 - ''' Será necessário tratar os dados de DS_REGIAO, onde levará a informação de região de acordo com o estado selecionado para o cliente novo.

'''RI12 - ''' Os campos que possuem zero a esquerda no ERP, deverão ser tratados na integração.

'''RI13 - ''' Os campos da da tabela CLIENTE_APROVACAO que possuem validações de caixa alta, devem ser tratados na integração, para que sejam transformados em caixa alta ao serem enviados ao 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"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
|-
| Desenvolvimento - GeoSales || Anderson Gomes || 07/08/2018
|-
| Desenvolvimento - GeoSales || Luan Lima || 16/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:200px" |Data
! style="width:300px" |Assinatura
|-
| Gerente TI
|
|
|
|-
| Gerente Projeto
|
|
|
|-
| Gerente Comercial
|
|
|
|}

Rota por Filial

2018-08-16T19:05:54Z

Luan Lima: /* GeoSales */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 14/08/2018 || Ana Júlia || Criação da documentação
|-
|}

== Necessidade ==

Atualmente não existem parametrizações para o uso de rota ou não, ou seja, a rota funciona para todas as filiais e seus representantes, conforme cadastrado.

Será necessário criar uma parametrização, de tal maneira que o sistema entenda quando utilizar rota ou não.

== Solução ==

A rota funciona para todos os vendedores, independente de trazer dados ou não, basta apenas que a tabela CLIENTE_ROTA e ROTA estejam sendo integradas.

O usuário precisa de distinções de utilização de rota, essa distinção será feita quando o usuário não possuir dados de rota nas tabelas CLIENTE_ROTA e ROTA. O sistema GeoSales deverá compreender que não se utiliza rota e, quando o usuário tiver dados de rota, o GeoSales entenda que se utiliza rota.

Deverá ser feita uma consulta nos dados de rota para atender a necessidade, onde quando a tabela de CLIENTE_ROTA possuir dados o sistema entender que será utilizado rota ou quando não tiver dados na tabela de CLIENTE_ROTA, não será utilizado rota.

== Implementação ==

=== Desenvolvimento ===

Atualmente a rota é controlada pela tabela CLIENTE_ROTA e ROTA, sendo necessário informações para que fique disponível para o vendedor os dados de rota, caso não possua rota cadastrada o mobile mostra a seguinte mensagem 'Não há rotas para este vendedor'.

Deverá ser refeita a consulta de rota, onde o sistema deverá entender que se o vendedor não tiver informações nas tabelas CLIENTE_ROTA e ROTA, não será utilizado rota e quando possuir dados de rota, significa que o vendedor utilizará rota.

Por exemplo: temos o vendedor 'A' e 'B'. O vendedor 'A' possui dados na tabela CLIENTE_ROTA, ou seja, possui rota, significa que para o vendedor o 'A' o sistema terá que trazer rota. Para o vendedor 'B', não possui dados na tabela CLIENTE_ROTA, nessa situação o sistema não deverá trazer rota.

Dessa maneira deixará de existir a validação no mobile por rota, a mensagem 'Não há rotas para este vendedor', deixará de ser exibida.

=== Integração ===

Para que as informações de rota sejam integradas, terão que ser disponibilizados os dados de rota, dias de rota, vendedor, cliente, sequencia de atendimento, através das tabelas:

* DA5 (Cadastro de Zonas);
* DA7 (Cadastro de clientes por setor);
* DA8 (Cadastro das rotas);
* DA9 (Cadastro de zona por rota);

Deverá ser feito uma ''view'' de rota e cliente rota, contendo os filtros e tabelas abaixo:

Por exemplo: Terá que ser feito um filtro na view com a tabela DA7 e a coluna DA7_CLIENT diferente (<>) de vazio (' ').

{| class="wikitable"
! colspan="6" | Filtros
|-
! |Tabela ERP
! |Coluna ERP
|-
| DA7 || DA7_CLIENT <> ' ' (vazio)
|-
| DA6 || D_E_L_E_T_ = ' ' (vazio)
|-
| DA7 || D_E_L_E_T_ = ' ' (vazio)
|-
| DA7 || DA7_CLIENT <> ' ' (vazio)
|-
| DA8 || D_E_L_E_T_ = ' ' (vazio)
|-
| DA8 || DA8_ATIVO = '1'
|-
| DA9 || D_E_L_E_T_ = ' ' (vazio)
|-
|}

== Regras de Negócios ==

'''RN1 -''' A rota só funcionará para o usuário que tiver informações na tabela de CLIENTE_ROTA, tendo a rota cadastrada também na tabela ROTA.

'''RN2 -''' É de responsabilidade do usuário realizar o cadastro de rota no ERP, para que seja integrado e exibido no GeoSales.

== Regras de Integração ==

'''RI1 -''' As tabelas DA5, DA9, DA7 e DA8 deverão ser disponibilizadas para que seja integrado os dados de rota.

== Resultados Esperados ==

=== Fluxos Padrão ===

[[Arquivo:Fluxograma Rota.JPG]]

== 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
! style="width:200px" |Assinatura
|-
| Desenvolvimento - GeoSales || Luan Lima || 16/08/2018 ||
|-
| Integração - GeoSales || Pessoa que aprovou || 14/08/2018 || Carlos Robson
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
! style="width:200px" |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 ||
|-
|}

Relatório de Faturamento

2018-08-16T19:05:15Z

Luan Lima: /* GeoSales */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 13/08/2018 || Ana Júlia || Criação do documento
|-
|}

== Necessidade ==

Os supervisores e vendedores precisam ter um controle maior dos pedidos faturados, sendo necessário a visualização dos pedidos que possuem nota fiscal.

Os pedidos que possuírem nota fiscal, ou seja, tiveram sido faturados, devem estar presentes nesse conjunto de pedidos faturados.

== Solução ==

O relatório de faturamento, funciona atualmente pela consulta de nota fiscal, fazendo com que exiba no relatório os pedidos que tiverem esse status, ou seja, pedidos que não possuem nota fiscal.

É necessário que seja feita uma validação pela nota fiscal, onde pedidos e itens que tiverem nota fiscal, devem fazer parte do relatório de faturamento.

== Implementação ==

=== Desenvolvimento ===

Deverá ser feito um ajuste no relatório de faturamento, que permitirá ao vendedor e supervisor a visualização dos pedidos que possuam itens que tenham sido faturados.

As informações do relatório de faturamento, devem ser baseadas nas tabelas NOTA_FISCAL, PEDIDO_NOTA_FISCAL, PEDIDO_RETORNO, CLIENTE, VENDEDOR e PRODUTO, onde, no relatório de faturamento deverá ter os pedidos que tiverem nota fiscal (faturados)

Por exemplo: O vendedor tirou 1 (um) pedido 'X' com 5 (cinco) itens, sendo eles respectivamente 'A,B,C,D,E', tendo como data de emissão o dia 12 de outubro. O pedido 'X' entrou no ERP com os 5 (cinco) itens no dia 12 de outubro, e retornou para o GeoSales com o status em 'aberto' no dia 12 de outubro. Por instancia, o pedido 'X' com seus 5 (cinco) itens não devem ficar visíveis no relatório, já que não houve faturamento
No dia 13 de outubro o pedido 'X' teve os itens 'A,B e C' faturados, ou seja, no relatório de faturamento deverá ficar visível o pedido 'X' e os itens 'A,B e C'.

Alguns itens podem ser entregues em partes, devido a unidade de medida utilizada.

Por exemplo: O vendedor tirou o pedido 'X' tendo os itens 'Y' e 'Z', onde o 'Y' teve o valor 1.980000 e o 'Z' 0.960000 de quantidade solicitada, e só foi faturado de 'Y' 1.000000 e 'Z' 0.000000, ou seja, quantidade entregue.

Caso o item não tenha sido faturado totalmente, deverá ser exibido no relatório de faturamento, a nota fiscal e a quantidade já faturada.

Deverá ser criada um novo campo na tabela de item nota fiscal, onde receberá a data em que o item foi faturado.

O relatório de faturamento terá os seguintes campos, pegando como base as seguintes tabelas:

Onde o campo 'Informação do Relatório' é referente ao campo que ficará disponível no relatório de faturamento, o campo 'Tabelas que serão consultadas' e 'Campos' é referente as tabelas que serão consultadas para que fique visível as informações de pedidos faturados.

{| class="wikitable"
! colspan="6" | RELATÓRIO DE FATURAMENTO
|-
! |Informação do Relatório
! |Tabelas que serão consultadas
! |Campos
|-
| Código Cliente || CLIENTE || CD_CLIENTE
|-
| Descrição Cliente || CLIENTE || NM_CLIENTE
|-
| Código Produto || PRODUTO || CD_PRODUTO
|-
| Descrição Produto || PRODUTO || NM_PRODUTO
|-
| Organização venda (Filial) || CD_ORG_VENDA || NOTA_FISCAL
|-
| Numeração da nota fiscal || ITEM_NOTA_FISCAL || CD_NOTA_FISCAL
|-
| Serie da nota fiscal || ITEM_NOTA_FISCAL || NM_SERIE
|-
| Data de emissão da nota fiscal || NOTA_FISCAL || DT_EMISSAO
|-
| Quantidade de Produto Entregue || ITEM_NOTA_FISCAL|| QT_ITEM
|-
| Valor Unitário || ITEM_NOTA_FISCAL || VR_UNITARIO
|-
| Valor Total || ITEM_NOTA_FISCAL || VR_TOTAL_ITEM
|-
| Código do vendedor || VENDEDOR || CD_VENDEDOR
|-
|}

=== Integração ===

O relatório de faturamento se baseia nas tabelas de pedido, nota fiscal e pedido nota fiscal. Onde a nota fiscal do pedido se baseia na tabela de item do ERP, ou seja, caso um mesmo pedido tenha itens em distintas notas fiscais, será exibido no relatório.

Por exemplo: o pedido 'X' possui 2 (dois) itens 'Y' e 'Z', possuindo 2 notas fiscais distintas no item, onde o item 'Y' possui a nota fiscal 1000048138 e o item 'Z' possui a nota fiscal 1000048142.

Mesmo os itens estando na situação exemplificada acima, deverá trazer no relatório de faturamento.

O campo de data de emissão, da tabela de nota fiscal do item, no ERP, deve ser enviada ao GeoSales. A tabela SD2010 no campo D2_EMISSAO, contem a data de emissão da nota fiscal, esse informação devera ser enviada ao GeoSales, na tabela ITEM_NOTA_FISCAL, coluna DT_EMISSAO.

{| class="wikitable"
! colspan="6" | TABELAS
|-
! |Tabela ERP
! |Campo ERP
! |Tabela GeoSales
! |Campo GeoSales
|-
| SD2010 || D2_EMISSAO || ITEM_NOTA_FISCAL || DT_EMISSAO
|-
|}

=== Estrutura de banco ===

{| class="wikitable"
! colspan="5" | ITEM_NOTA_FISCAL
|-
! style="width:200px" |Coluna
! Tipo
! style="width:200px" |Obrigatório
! style="width:300px" |Chave Primária
! style="width:300px" |Explicação
|-
| DT_EMISSAO
| datetime (8)
| NÃO
| NÃO
| Irá receber a data em que o item foi faturado
|-
|}

== Regras de Negócios ==

'''RN1 -''' Não será criado nenhum outro campo além dos que estão contemplados neste documento.

'''RN2 -''' Só poderão ser visualizados os pedidos que foram faturados para seus respectivos vendedores.

'''RN3 -''' Só poderão ser visualizados os pedidos faturados para o supervisor de acordo com a hierarquia cadastrada.

== Regras de Integração ==

'''RI1 -''' As informações de nota fiscal por item, serão consultadas na tabela de item do ERP (SC6) da coluna C6_NOTA.

== Resultados Esperados ==

=== Protótipos ===

[[Arquivo:Relatorio de faturamento.JPG]]

[[Arquivo:Relatorio.jpg]]

=== Fluxos Padrão ===

# Acessar com o usuário vendedor;
## Preencher o filtro de período;
## Clicar em 'Gerar PDF' ou 'Gerar XLS';
# Acessar com o usuário supervisor;
## Preencher o filtro de período;
## Escolher um vendedor;
## Clicar em 'Gerar PDF' ou 'Gerar XLS';

== 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
! style="width:200px" |Assinatura
|-
| Desenvolvimento - GeoSales || Luan Lima || 16/08/2018 ||
|-
| Integração - GeoSales || Pessoa que aprovou || 16/08/2018 || Carlos Robson
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
! style="width:200px" |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 ||
|-
|}

Relatório de Pedido Não Entregue

2018-08-16T19:02:44Z

Luan Lima: /* GeoSales */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 13/08/2018 || Ana Júlia || Criação do documento
|-
|}

== Necessidade ==

Os supervisores e vendedores precisam ter um controle maior dos pedidos não entregues, sendo necessário a visualização dos pedidos que não foram faturados.

Os pedidos que não tiverem nota fiscal, ou seja, não tiveram sido faturados, devem estar presentes nesse conjunto de pedidos não entregues.

== Solução ==

O relatório de pedidos não entregues, funciona atualmente pelo status 'Não Entregue', fazendo com que exiba no relatório os pedidos que tiverem esse status, ou seja, pedidos que não possuem nota fiscal.

É necessário que seja feita uma validação pela nota fiscal, onde pedidos que não tiverem nota fiscal, devem fazer parte do relatório de pedidos não entregues.

== Implementação ==

=== Desenvolvimento ===

Deverá ser feito um ajuste no relatório de pedidos não entregues, que permitirá ao vendedor e supervisor a visualização dos pedidos que possuam itens que não tenham sido entregues (faturados).

As informações do relatório de pedidos não entregues, devem ser baseadas nas tabelas ITEM_NOTA_FISCAL, PEDIDO_NOTA_FISCAL, NOTA_FISCAL, PEDIDO_RETORNO e ITEM_PEDIDO_RETORNO, onde, no relatório de pedidos não entregues deverá ter os pedidos que não tiverem nota fiscal (faturados)

Por exemplo: O vendedor tirou 1 (um) pedido 'X' com 5 (cinco) itens, sendo eles respectivamente 'A,B,C,D,E', tendo como data de emissão o dia 12 de outubro. O pedido 'X' entrou no ERP com os 5 (cinco) itens no dia 12 de outubro, e retornou para o GeoSales com o status em 'aberto' no dia 12 de outubro. Por instancia, o pedido 'X' com seus 5 (cinco) itens devem ficar visíveis no relatório.
No dia 13 de outubro o pedido 'X' teve os itens 'A,B e C' faturados, ou seja, no relatório de pedido não entregue deverá ficar visível o pedido 'X' e os itens D e E.

Alguns itens podem ser entregues em partes, devido a unidade de medida utilizada.

Por exemplo: O vendedor tirou o pedido 'X' tendo os itens 'Y' e 'Z', onde o 'Y' teve o valor 1.980000 e o 'Z' 0.960000 de quantidade solicitada, e só foi faturado de 'Y' 1.000000 e 'Z' 0.000000, ou seja, quantidade entregue.

Caso o item não tenha sido faturado totalmente, deverá ser exibido no relatório a nota fiscal, quantidade já faturada e a quantidade que falta para que seja faturado por completo.

O relatório de pedido não entregue terá os seguintes campos, pegando como base as seguintes tabelas:

Onde o campo 'Informação do Relatório' se referencia ao campo que ficará disponível no relatório de pedidos não entregues, o campo 'Tabelas que serão consultadas' e 'Campos' é referente as tabelas que serão consultadas para que fique visível as informações de pedidos não entregues no relatório.

{| class="wikitable"
! colspan="6" | RELATÓRIO DE PEDIDO NÃO ENTREGUE
|-
! |Informação do Relatório
! |Tabelas que serão consultadas
! |Campos
|-
| Código Cliente || CLIENTE || CD_CLIENTE
|-
| Descrição Cliente || CLIENTE || NM_CLIENTE
|-
| Descrição Produto || PRODUTO || NM_PRODUTO
|-
| Código do Pedido || PEDIDO_RETORNO || CD_PEDIDO_PALM
|-
| Código dos itens do Pedido || ITEM_PEDIDO_RETORNO || CD_PRODUTO
|-
| Data de Faturamento || NOTA_FISCAL || DT_EMISSAO
|-
| Numero da nota fiscal || ITEM_NOTA_FISCAL || CD_NOTA_FISCAL
|-
| Numero da nota fiscal || PEDIDO_NOTA_FISCAL || CD_NOTA_FISCAL
|-
| Quantidade de Produto Solicitado || ITEM_PEDIDO_RETORNO || QT_ITEM
|-
| Quantidade de Produto Entregue || ITEM_NOTA_FISCAL || QT_ITEM
|-
| Diferença de Quantidade Solicitado e Quantidade Entregue || O Calculo será realizado no Geosales || *
|-
|}

A tela de consulta do relatório de pedidos não entregues, será composta pelos seguintes campos:

A tabela 'filtros' é sobre os filtros disponibilizados no portal, para facilitar a busca do usuário.

{| class="wikitable"
! colspan="6" | FILTROS
|-
! |CAMPO
! |DESCRIÇÃO
|-
| Período || Espaço de tempo entre dois acontecimentos ou datas diferentes
|-
| Cliente|| Devem aparecer os clientes de acordo com a hierarquia, onde o vendedor só poderá ver seus próprios e o supervisor, poderá visualizar os clientes que estão vinculados aos vendedores abaixo.
|-
| Organização de venda|| Organizações de vendas disponíveis no GeoSales (Filial)
|-
| Supervisor || Supervisores cadastrados no Geosales, para os vendedores só deverá aparecer o supervisor que estiver vinculado, de acordo com a tela de pesquisa vendedor
|-
| Vendedor || Para o usuário vendedor, deverá aparecer ele mesmo, já para o usuário supervisor deverá aparecer todos os vendedores vinculados ao usuário de supervisor que estiver logado.
|-
|}

Contendo também na tela de pesquisa, os botões de 'Gerar PDF', 'Gerar XLS' e 'Limpar', tendo as seguintes funções:

* '''Gerar PRF:''' Será gerado um relatório em PRF com as informações de pedidos não entregues.
* '''Gerar XLS:''' Será gerado um relatório excel com as informações de pedidos não entregues.
* '''Limpar:''' Limpará os dados preenchidos na tela de consulta do relatório de pedidos não entregues.

=== Integração ===

Atualmente no banco SQL da Ferronorte, a tabela ITEM_NOTA_FISCAL tem o campo QT_ITEM trazendo valores inteiros, será necessário ajustar para que traga valores decimais.

== Regras de Negócios ==

'''RN1 -''' Não será criado nenhum outro campo além dos que estão contemplados neste documento.

'''RN2 -''' Só poderão ser visualizados os pedidos que não foram entregues para seus respectivos vendedores.

'''RN3 -''' Só poderão ser visualizados os pedidos não entregues para o supervisor de acordo com a hierarquia cadastrada.

== Regras de Integração ==

== Resultados Esperados ==

=== Protótipos ===

[[Arquivo:Consulta Pedido Não Entregue.JPG]]

[[Arquivo:Relatório de Pedido Não Entregue.jpg]]

=== Fluxos Padrão ===

# Acessar com o usuário vendedor;
## Preencher o filtro de período;
## Clicar em 'Gerar PDF' ou 'Gerar XLS';
# Acessar com o usuário supervisor;
## Preencher o filtro de período;
## Escolher um vendedor;
## Clicar em 'Gerar PDF' ou 'Gerar XLS';

== 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
! style="width:200px" |Assinatura
|-
| Desenvolvimento - GeoSales || Luan Lima || 16/08/2018 ||
|-
| Integração - GeoSales || Pessoa que aprovou || 14/08/2018 || Carlos Robson
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! style="width:200px" |Setor
! style="width:180px" |Aprovado Por
! style="width:100px" |Data
! style="width:200px" |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 ||
|-
|}