MIV007-Declaração de Escopo

Portal de Orçamento

Page 1 of 15
 MIV007-Declaração de Escopo

SUMÁRIO
1. DADOS GERAIS .............................................................................................. 3
2. ETAPAS DO PROJETO ..................................................................................... 3
3. DESCRIÇÃO DO ESCOPO DO PROJETO ............................................................ 3
4. OBJETIVOS DO PROJETO ............................................................................. 13
5. JUSTIFICATIVA DO PROJETO ....................................................................... 14
6. PRODUTO DO PROJETO ................................................................................ 14
7. EXPECTATIVAS DO CLIENTE ........................................................................ 14
8. RISCOS DO PROJETO ................................................................................... 14
9. FATORES DE SUCESSO DO PROJETO ............................................................ 14
10. PREMISSAS DO PROJETO ........................................................................... 14
11. RESTRIÇÕES/LIMITES DO PROJETOS ........................................................ 15
12. EXCLUSÕES ESPECÍFICAS DO PROJETO ..................................................... 15
13. ENTREGAS DO PROJETO ............................................................................. 15
14. CRONOGRAMA MACRO DO PROJETO .......................................................... 15
15. ESTRUTURA ANALÍTICA DO PROJETO (EAP) .............................................. 15

Page 2 of 15
 MIV007-Declaração de Escopo

1. DADOS GERAIS
Cliente: V. Pereck Auto Peças Ltda
Produto: Protheus 12
Projeto: Portal Orçamento
Consultor: Marcos Borck
Coordenador: Maycon Robson Branco / Edinei Sanchez Milek
Processo: Desenvolvimento de Portal de Orçamento

2. ETAPAS DO PROJETO
As etapas do projeto foram definidas em reunião específica com cliente, conforme
abaixo:
 Portal de Orçamentos
 Cadastros
1. Integração
2. Consultas
 Orçamento (inclusão, alteração, exclusão, consulta)
1. Etapas do Orçamento
2. Orçamento
3. Integrações
4. Controle de logs
 Faturamento – Integração
1. Pedidos
2. Cupom
3. Danfe
4. Boleto
5. Guias
6. Exclusão

3. DESCRIÇÃO DO ESCOPO DO PROJETO

3.1 Parâmetros do Sistema

 A serem definidos

Page 3 of 15
 MIV007-Declaração de Escopo

3.2 Cadastros
Rotinas de cadastro envolvidas no projeto.
Desenvolver rotina para integração e consulta dos seguintes cadastros:
 Filiais
 Clientes (SA1)
 Produtos (SB1)
 Vendedores (SA3)
 Equipe Técnica (VAI)
 Produtos Alternativos (VB1)
 Produtos Relacionados (VPD)
 Fórmulas (SM4)
 Aplicação da Peça (VV1)
 Mapas de Resultado (VS5)
 Outros Cadastros e serem utilizados

3.3 Cadastro de Etapas do Orçamento

Rotina de cadastro de fases de orçamento:
 Desenvolver rotina de cadastro de fases de orçamento, contemplando as
seguintes opções:
 Inclusão
 Alteração
 Exclusão
 Consulta
 Controle de Logs
 Contemplando as seguintes fases:
1. Aguardando Sincronização
2. Digitado
3. Aguardando Avaliação de Crédito / Desconto
4. Aguardando Separação
5. Aguardando Faturamento
6. Faturado
7. Cancelado
 Permitir alteração de status:
1. Ativo

Page 4 of 15
 MIV007-Declaração de Escopo

2. Inativo

3.4 Orçamento Por Etapas

Rotina de orçamento por etapas contemplando as seguintes funcionalidades:
 Desenvolver rotina para inclusão do orçamento de peças, contemplando os
seguintes campos:
 Número do orçamento
 Tipo do Orçamento (peças)
 Cliente/Loja
 Tipo de Cliente
 Vendedor 1,2,3,4,5 (avaliar regra de desconto)
 Transportadora
 Tipo do Frete (CIF/FOB)
 Modalidade Orçamento (Cupom/Nota)
 Peso liquido
 Peso Bruto
 Código do Produto
 Quantidade Requisitada
 Valor
 % Desconto
 Valor Desconto
 Valor Total
 Tipo de Operação
 Cfop
 Presencial
 Outros campos a serem levantados
Conceitos:
 Tanto o vendedor 1 como o vendedor 2 podem visualizar e/ou editar um
orçamento na qual estejam relacionados.
 Supervisores podem visualizar e editar orçamentos nas quais pertencem
aos seus vendedores, seja ele vendedor 1 ou vendedor 2.
 Diretores e gerentes podem visualizar e editar todos os orçamentos.
 Um orçamento/pedido não poderá ser editado após a emissão de uma
nota fiscal ou se houver uma separação de produtos. Do contrário o
orçamento/pedido poderá sofrer alterações. Para cada alteração realizada
todo o ciclo de validações do orçamento devem ser refeitos, podendo
bloquear um orçamento/pedido já liberado.

Page 5 of 15
 MIV007-Declaração de Escopo

 Validação entre cupom e nota fiscal.

o Ao selecionar um cliente padrão e o valor do orçamento for menor
que o valor parametrizado para a venda (criar parâmetro) habilitar
somente o faturamento por cupom fiscal.
o Se o valor for maior que o valor do parâmetro, deve ser informado
um cliente.
o Se um cliente for informado, obrigatoriamente deve ser faturado
como nota fiscal.
o Ao selecionar cupom o direcionamento da integração do sistema
deve ser ao módulo SigaLoja. Ao selecionar nota fiscal o
direcionamento da integração do sistema deve ser ao módulo de
faturamento.
 Disponibilizar na interface de orçamento a impressão da DANFE.
 Desenvolver um job na qual envie ao vendedor os orçamentos pendentes
com prazo a expirar
o Configurar a quantidade de dias que o e-mail deve ser enviado em
relação ao prazo de validade do orçamento.
 Permitir a alteração do prazo de validade do orçamento.
o Isso ajudará a diminuir o volume de orçamentos cancelados que
estavam parados devido alguma regra de bloqueio por motivo de
prazo de validade.
o O vendedor poderá alterar o prazo do orçamento caso esteja
configurado com privilégios de alteração. Se alterado as validações
do orçamento devem ser refeitas.
o OBS: A alteração do prazo de validade é permitida para clientes em
branco. Verificar a regra de validação 90 dias de limite.
 Ao selecionar a forma de pagamento Boleto o realizar a integração com o
faturamento um boleto será gerado.
 Desenvolver rotina para cálculo de preço de venda com base regras de Markup e
grupo de produtos (avaliar customização existente).
Conceitos:
 Preço de venda não deve ser alterado na interface orçamento. Apenas
descontos deve ser definidos para diminuir o valor total do produto.
 Utilização de campos de tabelas como variáveis para definições de
fórmulas.
 Aplicação de fórmulas para definição de preço de venda. As fórmulas
podem ser configuradas a partir do grupo do produto ou do próprio
produto. Onde a regra do produto sobressai sobre a regra do grupo.
 Atualização de preços de venda. Para orçamentos em aberto, manter os
preços de venda já estabelecidos no orçamento. Se possuir novo preço,

Page 6 of 15
 MIV007-Declaração de Escopo

perguntar ao usuário se deseja atualizar os preços. Para novos

orçamentos utilizar os novos preços.
 As variáveis custo médio, créditos e difal devem receber valores ou uma
atribuição de uma função para obter o valor para cálculo da fórmula. As
funções para obter os valores ainda é um ponto questionável visto que a
forma de buscar a informação não está clara ou definida. O campo ICMS
deve receber um valor.
 Desenvolver consulta de produto, contemplando:
 Filial
 Código do produto
 Armazém
 Endereços
 Quantidade em estoque
 Quantidade em reserva
 Desenvolver e/ou adaptar regra para comissão de vendedores, contemplando:
 Vendedor 1, do cadastro de cliente
 Vendedor 2, operador do orçamento
 Vendedor 3, gerente de operador
 Vendedor 4, gerente do vendedor 1
Regras definidas com o cliente relacionadas a comissão:
 Permitir a configuração do percentual de comissão no produto. O cenário atual
do cliente é de 1% para todos os produtos, porém o sistema deve permitir
que o produto seja configurado caso o usuário deseje modificar este
percentual devido a uma característica do produto.
 Configuração do percentual de comissão por cliente e vendedor. O cenário
atual do cliente é de 70% para o vendedor 1 do orçamento e 30% do vendedor
2 para o total do orçamento. O cliente deseja que o sistema calcule o
percentual produto a produto respeitando a configuração de comissão do
produto pelo valor líquido e calcule as comissões dos vendedores a partir da
configuração no cliente.
 O vendedor 1 é o vendedor que está associado ao cliente, no caso pertence a
carteira do vendedor.
 O vendedor 2 é o vendedor que está registrando o orçamento.
 Adicionar na interface de orçamento as comissões calculadas.

 Validação 90 dias de limite, senão tiver venda perde o vendedor do cadastro

Conceito:
 Um vendedor possui um cliente em sua carteira, este é considerado como
vendedor 1. Porém se este vendedor não concretizar um pedido, no caso,

Page 7 of 15
 MIV007-Declaração de Escopo

faturar uma nota fiscal para este cliente dentro de 90 dias após a última
compra efetivada, o vendedor pode perder este cliente de sua carteira.
Portanto um outro vendedor pode se tornar o vendedor 1 desse cliente, na
qual atribui este cliente a sua carteira. Para isso existem algumas regras
para essa mudança.
Regras definidas com o cliente:
 O cliente passa a ter um status a ser controlado ao conceito de 90 dias.
1. Em branco. O cliente possui um compra efetivada dentro de 90 dias
após a última compra efetiva. Na interface de orçamento o campo de
vendedor 1 permanece bloqueado sendo atribuído ao campo o valor
do vendedor que possui o cliente em sua carteira.
2. Em amarelo. O cliente não possui uma compra efetivada dentro de 90
dias. Neste caso o cliente passa a ter o vendedor 1 como em aberto.
Isso permitirá que o campo de vendedor 1 na interface de orçamento
fique em aberto, permitindo que o vendedor 2 seja atribuído também
como vendedor 1. Foi idealizado adicionar um indicador de cor ao
cliente para que o usuário possa identificar que o cliente está sem
vendas a mais de 90 dias.
3. Em azul. Neste caso um vendedor realizou um orçamento para um
cliente que está sem vendas a mais de 90 dias. Neste caso é
considerado que o vendedor reservou este cliente em sua carteira.
Caso o pedido seja efetivado, emita uma nota fiscal este vendedor
será atribuído como o novo vendedor 1 para o cliente. Adicionando
este cliente a sua carteira.
 Definições:
1. Venda efetiva. Quando o pedido é faturado e possui uma nota fiscal.
2. Devolução de venda. Quando uma nota de devolução é emitida, é
anulada a venda na qual foi considerada como efetiva. Portanto neste
caso o cálculo para o status de 90 dias será modificado. EX: Um
cliente está a 60 dias sem compra efetiva. Um vendedor concretizou
uma venda, este cliente passa a estar a 0 dias sem compra efetiva.
Porém 7 dias após a venda o cliente devolveu, aqui deve ser
considerado a devolução completa, caso seja realizada uma devolução
parcial o pedido continua valendo. Com essa devolução o cliente volta
a ficar 67 dias sem venda efetiva.
3. Prazo do orçamento. O prazo do orçamento deve ser configurado de
acordo com o status do cliente.
 Em branco: o cenário atual do cliente é de 7 dias para o prazo.
Este prazo pode ser prorrogado pelo supervisor ou se o
vendedor possuir privilégio de alteração.
 Em azul: o cenário idealizado foi de 1 dia para o prazo. Para que
o vendedor não fique com o cliente reservado por mais tempo.
Para este caso a prorrogação do prazo deve ser realizada apenas

Page 8 of 15
 MIV007-Declaração de Escopo

pelo supervisor. O vendedor não pode alterar o prazo mesmo

que em seu cadastro possua privilégio.
4. Reserva do cliente. Para clientes em amarelo, ao possuir um
orçamento pendente de efetivação este se torna azul, reservado para
o vendedor que realizou o orçamento. Neste caso outros vendedores
não poderão realizar orçamentos para este cliente até que o
orçamento pendente seja concluído como efetivo ou como cancelado
após o vencimento do prazo do orçamento.
 Desenvolver rotina para geração de relatório de comissões.
Atualmente o cliente não possui cadastros de metas e vínculos entre os
vendedores e supervisores em relação as suas metas e metas da loja. O que
dificulta a apuração de valores e potencializa erros de cálculos.
Conceitos:
 Desenvolver um cadastro de metas onde seja configurado as metas da loja,
e o supervisor responsável pela loja. Metas dos vendedores e qual o
supervisor responsável.
 Desenvolver um dashboard com três visões:
1. Vendedor. Para o vendedor serão ilustrados os dados de:
 Meta e Valor efetuado com percentual
 Valores de comissões. Realizar o agrupamento entre filais (loja),
vendedor 1 e vendedor 2. Visualizar o totalizador dos valores por
agrupamento e geral. Considerar para comissão apenas notas
emitidas.
 Visualizar os clientes da sua carteira sem vendas a mais de 90
dias.
 Visualizar o total de devoluções com possibilidade de expandir a
visualização em detalhes.
2. Supervisor. Para o supervisor serão ilustrados os dados de:
 Meta da loja em que é responsável (filial)
 Para a meta da loja deve ser agrupado entre vendas
internas e externas. Venda interna é quando o vendedor
de sua carteira efetua uma venda para a sua loja. Venda
externa é quando um vendedor de outra loja ou fora de
sua carteira efetua uma venda para sua loja. Trazer a
informação em valores e percentuais.
 Agrupamento das comissões dos vendedores que pertencem a
sua carteira.
 Visualizar os clientes dos vendedores da sua carteira sem
vendas a mais de 90 dias.
 Visualizar os vendedores da sua carteira que mais venderam

Page 9 of 15
 MIV007-Declaração de Escopo

 Visualizar o total de devoluções com possibilidade de expandir a

visualização em detalhes.
3. Gerente/Diretor
 A visualização de todos os supervisores agrupadas.
 Desenvolver rotina para sugerir a melhor opção de transportadora
 Obs: Funcionalidade deixada para um segundo momento. Para este
desenvolvimento será adicionado apenas valor informativo da
transportadora.
 Desenvolver rotina para rateio de frete CIF nos itens do orçamento:
 Ativação da regra no cadastro de cliente, informar se pode ter o frete CIF
rateado nos itens do orçamento (sim/não).
Conceito: Muitos clientes não gostam de pagar o frete, então o valor deve ser
adicionado no valor do item do orçamento. Portanto ao marcar a flag sim para
frete CIF no cadastro do cliente, automaticamente o sistema deve ratear o
valor do frete e adicionar ao preço final do item, correspondendo ao percentual
de cada item ao emitir um orçamento.
 Desenvolver rotina para mostrar itens relacionados na manutenção do Orçamento
por Fases.
 Na interface de orçamento o sistema deve permitir a visualização dos itens
relacionados a compra do item baseado no cadastro de itens relacionados.
Isso facilita ao vendedor identificar produtos na qual precisam de um outro
produto para aplicação.
 Desenvolver uma pesquisa customizada do item do orçamento.
 Ao inserir um item do orçamento e clicar para localizar um produto o
sistema deve permitir localizar um produto não apenas pelos dados de
cadastro do produto, mas também permitir localizar os produtos por um
código e/ou descrição alternativos, baseados no cadastro de produtos
alternativos. Estes códigos alternativos podem por exemplo especificar um
part number de uma peça ou uma palavra chave que identifique a peça
independentemente da marca.
 Desenvolver rotinas para regras de desconto, % mínimo de desconto e % mínimo
de margem.
Conceitos:
 Formas de descontos: Nesta interface são configurados as regras de
desconto, margem e promoções para produtos.
1. Promoções:
 Definir a forma de promoção para o produto e/ou grupo. Esta
regra seria definida entre % de desconto, valor de venda ou
margem de lucro. Trazer na interface para selecionar apenas
uma das opções.

Page 10 of 15
 MIV007-Declaração de Escopo

 A configuração de quantidade de ser combinatória com a forma

de promoção definida. Ao realizar um compra para o item
promocional deve ser validado se quantidade mínima do item,
caso esteja configurado como 0 a validação da quantidade é
desprezada.
 Ao definir uma promoção esta configuração sobressai a regra do
grupo do produto. No caso as restrições de % de desconto e %
de margem são ignoradas na validação do orçamento.
 As promoções serão consideradas como válidas de acordo com o
prazo. Caso o prazo da promoção tenha expirado, a promoção
não será mais válida.
2. Por Grupo:
 % de desconto para o grupo e/ou produto. O sistema valida no
orçamento que o % de desconto não pode ser maior que o
configurado.
 % margem mínima para o grupo e/ou produto. O sistema valida
no orçamento que a margem de lucro no produto não pode ser
menor que o percentual configurado.
3. Visualização: Ao localizar um produto no orçamento e este estiver com
configuração de promoção ativa, um indicador de cor deve ser
visualizado para que o vendedor saiba que o item está em promoção e
que descontos podem ser aplicados. Outra visualização no orçamento
seria um grid ou interface de visualização de itens promocionais, na
qual facilite ao vendedor sugerir ao cliente durante o orçamento algum
item que esteja em promoção.
 Desenvolver rotina para consulta de planilha financeira, com os dados do
orçamento. Utilizar rotina do Protheus.
 Desenvolver rotina de avaliação prévia de crédito, cliente sem limite, mas
condição de pagamento for a Vista então pode passar direto pela avaliação de
crédito.
Conceitos:
 Clientes do risco “E” devem ser desconsiderados dessa regra. Portanto
orçamentos para clientes de risco “E” sempre devem ser bloqueados para
liberação de crédito independentemente da forma de pagamento
selecionada.
 Para os demais clientes, caso a forma de pagamento seja definida como
“cartão de crédito”, “cartão de débito” ou em “dinheiro”, e o sistema
considere o cliente sem limite de crédito ou com o crédito vencido, os
orçamentos destes clientes devem receber uma liberação automática via
sistema informando o motivo “Liberação automática de crédito – Pagamento
a vista”. Este motivo será utilizado como indicador para localização de
orçamentos realizados com liberação automática de crédito.

Page 11 of 15
 MIV007-Declaração de Escopo

 Desenvolver rotina para condição de pagamento tipo 9, onde operador irá

informar valores e vencimentos.
Conceitos:
 O vendedor não pode alterar a quantidade de parcelas definidas pela forma
de pagamento selecionada, porém o vendedor pode alterar os prazos e
valores das parcelas. Quando isso acontecer o orçamento sempre deve cair
para bloqueio de regra de validação de crédito, solicitando uma liberação.
 Desenvolver rotina para avançar avaliação de crédito, somente pessoas
autorizadas poderão efetuar procedimentos.
 Conceitos definidos:
1. Devem ser validados os campos de risco do cliente, limite de crédito e
vencimento do limite.
2. Para o limite de crédito devem ser considerados os orçamentos em
aberto, não somente os faturados para cálculo do saldo.
 Visualização:
1. Na interface do orçamento ao selecionar um cliente devem ser
exibidas algumas informações do cliente. Configurar campos de
apresentação. A necessidade do cliente atualmente seriam dos campos
de risco e observação.
2. Na interface do orçamento visualizar o limite crédito do cliente divido
em:
 Limite de crédito e vencimento
 Total faturado
 Total em aberto
 Saldo para utilização
 Pessoas autorizadas a liberação: respeitar o cadastro de equipe técnica.
 Desenvolver rotina para consulta de resultado, com base em consulta padrão de
Mapa de Resultados Protheus.
 Desenvolver rotina para solicitação de transferência de produtos para filiais.
 Ao selecionar um produto no orçamento e este não possuir saldo em
estoque. Habilitar uma consulta de saldo para visualização das demais filiais.
Caso o produto possua estoque em outra filial, o vendedor poderá realizar
uma solicitação de transferência. O orçamento continuará com bloqueio de
saldo até que uma nova checagem de saldo em estoque do produto seja
realizada.
 Validar estoque na SB2.
 Criar uma job de verificação de saldo de estoque baseado nos orçamentos
com bloqueio de saldo de estoque, desde que o orçamento esteja dentro do
prazo de validade. Assim o vendedor receberá um e-mail avisando que o
produto na qual estava pendente pode passar da validação de estoque. Caso

Page 12 of 15
 MIV007-Declaração de Escopo

o orçamento esteja fora do prazo de validade cancelar o orçamento com o

motivo “Produto sem saldo em estoque.”
 OBS: Está validação vai ocorrer no sistema Protheus após a sincronização.
Portanto mesmo que o portal já tenha validado o estoque pela SB2, e
passado por todos os processos de validações, no momento da sincronização
com o Protheus esta validação será executada podendo barrar a emissão da
nota. Para as outras validações é possível passar parâmetros para não
realizarem as validações novamente visto que já foram executadas no
portal.
 Desenvolver rotina para integração de Orçamento com Pedido de Vendas.
 Desenvolver rotina para integração com controle de loja.
 Orçamentos definidos com emissão cupom fiscal devem ser integrados ao
loja
 Desenvolver rotina genérica de integração para controle de status.
 Desenvolver interface de controle de validações do orçamento.
 Definir ordem da validação
 Definir se a validação permite salvar ou bloqueio na interface.
 Definir se a validação possui processo de liberação.
 Validações pré-cadastradas e suas respectivas ordens:
1. Validação de limite de crédito. Permite salvar e possui processo de
liberação.
2. Validações de desconto e margem de lucro. Permite salvar e possui
processo de liberação.
3. Saldo em estoque. Permite salvar mas não tem processo de liberação.
A liberação acontecerá somente quando o produto for reservado para
o orçamento.
4. Condições de pagamento. Permite salvar e possui processo de
liberação.
 O orçamento será sincronizado apenas quando todas as validações serem
atendidas.
 Caso todas as validações sejam atendidas o pedido deve ser gerado
automaticamente.

4. OBJETIVOS DO PROJETO
Maximizar utilização de portal de orçamentos, visando:
 Aumentar agilidade no atendimento a balcão
 Aumentar número de vendedores utilizando portal
 Facilitar tomada de decisões com informações precisas e rápidas

Page 13 of 15
 MIV007-Declaração de Escopo

5. JUSTIFICATIVA DO PROJETO
As justificativas do projeto são:
 Dificuldades da utilização do atual sistema
 Limitação de licenças do atual sistema

6. PRODUTO DO PROJETO
Os produtos do projeto são:
 Portal para Manutenção de Orçamentos
 Rotinas customizadas p/ integração com ERP Protheus
 Usuários chaves treinados para utilização do Portal

7. EXPECTATIVAS DO CLIENTE
Destaca-se:
 Maior agilidade no processo
 Informações gerenciais rápidas e seguras
 Aumento de vendas com processo ágil

8. RISCOS DO PROJETO
Os principais riscos do projeto são:
 Integração com ERP Map
 Testes e validações de usuários chaves

9. FATORES DE SUCESSO DO PROJETO

Fator de sucesso de um projeto é considerado o ponto chave para que todo trabalho
tenha êxito ao seu final, abaixo destaca-se os principais:
 Engajamento de usuários chaves (testes e validações)
 Integração com ERP Protheus

10. PREMISSAS DO PROJETO

As principais premissas do projeto são:
 Disponibilização de usuários chaves para os processos de análise/levantamento,
desenvolvimento, validação e implantação.

Page 14 of 15
 MIV007-Declaração de Escopo

11. RESTRIÇÕES/LIMITES DO PROJETOS

As principais restrições do projeto são:
 Desenvolvimento de rotinas em linguagem ADVPL na versão Protheus 12 release
12.1.25.
 Desenvolvimento específico para plataforma web.
 Utilização de navegadores homologados.

12. EXCLUSÕES ESPECÍFICAS DO PROJETO

As exclusões do projeto são:
 Adequações para outras versões do Erp Protheus que não seja 12.1.25
 Adequações para sistemas mobile
 Replicação de treinamentos além de usuários chaves
 Tratamento de erros após o prazo de garantia de 30

13. ENTREGAS DO PROJETO

A ser definido após aprovação do projeto.

14. CRONOGRAMA MACRO DO PROJETO

A ser definido após aprovação do projeto.

15. ESTRUTURA ANALÍTICA DO PROJETO (EAP)

A ser definido após aprovação do projeto.

Page 15 of 15