Gerencie Vendas

Nova Página


 Softensistemas Logo

 Projeto/Sistema:
MVP Gerencie Vendas		 Versão do Template:
1.2
Processo:
Sincronização de tabelas de complementos e variações		 Versão do Documento:
1.0
Responsável(eis): 
Jalile Cornachioni

Data: 

26/08/2025
1. Introdução

Hoje, a sincronização de produtos do Gerencie Aqui (GA – retaguarda) para o Gerencie Vendas (GV – mobile) considera apenas a tabela principal de produtos, o que impede o usuário do app de selecionar corretamente variações (grades) e complementos.
Além disso, a busca via código de barras e a organização da listagem por categorias não atendem plenamente às necessidades de varejo, atacado e food-service.

O objetivo desta melhoria é:

  1. Ampliar a sincronização GA → GV para incluir ProdutoVariacaoItem e ProdutoComplemento.

  2. Permitir no GV a seleção de variações e complementos no fluxo de venda.

  3. Garantir a volta das vendas GV → GA com consistência.

  4. Viabilizar emissão de documentos fiscais no GA a partir das vendas sincronizadas.

  5. Registrar logs completos, tratar erros e exceções.

  6. Ajustar usabilidade: busca, código de barras e listagem por categorias.

2. Processo

Fluxograma - adaptação totem.jpg

 

Processo

Envolvidos

Dados de Entrada

Dados de Saída
Sincronização de Produtos (GA → GV) GA (Retaguarda), GV (Mobile) Produtos, Variações, Complementos Tabelas locais do GV atualizadas, Logs
Venda no GV (Mobile) Usuário (Vendedor), GV Produto selecionado, variação, complementos Pedido registrado no GV
Sincronização de Vendas (GV → GA) GV, GA Pedidos com produtos + variações + complementos Pedidos integrados no GA, Logs
Emissão Fiscal (GA) GA, SEFAZ Pedidos recebidos NF-e ou NFC-e emitidas, Logs
Cenários de Erro e Exceção GA, GV Erros de sincronização, inconsistências Mensagens ao usuário, Logs, Marcações de inconsistência

Especificação Funcional

Protótipo de Tela:

 

Descrição dos Campos:

Campo

Tipo

Tamanho

Obrig. ?

Máscara

Observações

Campo

Texto

100

Sim

-

-
Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

1. Sincronização de Produtos (GA → GV)

2. Venda no GV (Mobile)

3. Sincronização de Vendas (GV → GA)

4. Emissão Fiscal (GA)

5. Cenários de Erro e Exceção

Questões Técnicas:

GA (Retaguarda)

GV (Mobile)

GA (Recebimento das Vendas)

Cenários de Teste

  1. Food-Service: Pizza Média + borda recheada → venda no GV, sincronização, edição no GA, emissão de NFC-e.

  2. Atacado: Cerveja pack 12 unid → venda no GV, sincronização, alteração de preço no GA, emissão de NF-e.

  3. Varejo: Camiseta Polo G Azul → venda no GV, sincronização, alteração de forma de pagamento no GA, emissão de NFC-e.

  4. Erros:

    1. Produto sem NCM → rejeição fiscal.

    2. Código de barras duplicado → exibir lista de escolha.

    3. Venda offline → reenvio após reconexão.

©SOFTEN SISTEMAS 2025

 

 

 

 

Modo de Venda

Modo de Venda

Configuração dos modos de vendas


 Softensistemas Logo

 Projeto/Sistema:
GERENCIAMENTO DE PROJETOS		 Versão do Template:
1.2
Processo:
Configuração dos modos de vendas		 Versão do Documento:
1.2
Responsável(eis): 
Jalile Cornachioni

Data: 

05/09/2025
1. Introdução

O aplicativo de vendas mobile GV será reformulado para atender diferentes cenários de operação comercial, desde representantes externos até pontos de venda em mercados, feiras e quiosques. Para isso, o sistema passará a contar com modos de venda específicos, que se adaptam ao perfil de cada cliente, e com a possibilidade de ativar o Modo Ficha, recurso que permite a impressão de fichas individuais por produto para retirada posterior.
Essa evolução tem como objetivo oferecer mais flexibilidade, padronização dos fluxos e atender tanto operações assistidas por vendedores quanto modelos de autoatendimento.

Comportamento Atual

Atualmente, o app GV possui um fluxo único de vendas, voltado ao uso por representantes comerciais. Nesse modelo, o usuário precisa selecionar cliente e vendedor, buscar produtos por listagem ou código de barras, montar o carrinho, aplicar descontos e finalizar a venda com diferentes opções de pagamento.
Esse comportamento não atende adequadamente cenários como mini-mercados, feiras, eventos, quiosques ou autoatendimento, onde a jornada do usuário precisa ser mais simples, rápida e sem etapas adicionais. Além disso, não existe a funcionalidade de emissão de fichas individuais por produto, recurso essencial em operações de consumo imediato, como bares, lanchonetes e eventos.

Comportamento Esperado

Com a reformulação, o app GV contará com três modos de venda configuráveis:

  1. Representante – fluxo completo, com seleção de cliente e vendedor, carrinho editável, descontos e múltiplas formas de pagamento.

  2. PDV – fluxo rápido para mercados de condomínio ou pequenos varejos, sem cliente, com inclusão de produtos apenas via código de barras, pagamento direto no TEF e sem divisão de pagamento.

  3. Touch (Catálogo/Autoatendimento) – fluxo visual em grade, ideal para quiosques e autoatendimento, sem cliente e sem descontos, com tela de descanso personalizada.

Além disso, o Modo Ficha poderá ser ativado em qualquer fluxo, permitindo a emissão de fichas individuais por produto junto com o comprovante, atendendo especialmente operações de feiras, eventos e quiosques.

O resultado esperado é um aplicativo mais versátil, escalável e alinhado às diferentes necessidades de operação dos clientes, permitindo maior adoção e competitividade do produto.

2. Processo

Fluxo config modo venda.jpg

Especificação Funcional

Protótipo de Tela: 

Android.png   Android (1).png

Regras de Interface:
Configurações do App GV

1. Modo de Venda (obrigatório)

Define o fluxo principal que será carregado ao abrir o app:

(No caso de feiras/eventos, o administrador escolhe Representante ou Touch, dependendo da operação)

2. Modo Ficha (opcional, pode ser combinado)

3. Venda /Orçamento

4. Parâmetros do sistema

Define configurações que serão utilizadas durante a venda

5. Métodos de Pagamento Permitidos (opcional por fluxo)

(Exemplo: no PDV de mercadinho → só cartão TEF; no Representante → todos; no Touch → só cartão/PIX)

6. Configuração de Impressão (por dispositivo)

7. Tela de Descanso

(Ex.: PDV e Touch voltam sempre para tela de descanso; Representante não precisa.)

 

Configurações do App GV

Modo venda = representante
Modo ficha = desativado
Vendedor padrão para o aparelho = vazio
Percentual max de desconto = zerado para a situação em que o vendedor não pode aplicar desconto e diferente de zero quando ele puder dar desconto na venda.

Permissões referentes a ações do sistema

Métodos de Pagamento
Selecione os métodos de pagamento permitidos:

Permitir divisão de pagamento
Permite que o pagamento seja dividido em múltiplas formas.

Integração com POS Smart
Configurações de pagamento terceiros:

Tela de descanso = não

 

Critérios de Aceitação
Regras de Negócio:

1. Modo Representante

2. Modo PDV

3. Modo Touch (Catálogo / Autoatendimento)

4. Modo Ficha (configuração aplicável a qualquer fluxo)

Questões Técnicas:

1. Descrição de mudanças na base de dados, ou integração de API, ou arquivo que deva ser gerado.

©SOFTEN SISTEMAS 2025

 

 

 

 

Modo de Venda

Sincronizar tabela de complementos e variações de produtos

1. Introdução

Hoje, a sincronização de produtos do Gerencie Aqui (GA – retaguarda) para o Gerencie Vendas (GV – mobile) considera apenas a tabela principal de produtos, o que impede o usuário do app de selecionar variações (grades) e/ou complementos.

O objetivo desta melhoria é: Ampliar a sincronização GA → GV para incluir as tabelas ProdutoVariacaoItem e ProdutoComplemento na sincronização e garantir que a busca via código de barras e listagem por categorias sejam aprimoradas para atender às necessidades específicas dos segmentos de varejo, atacado e food-service.

2. Processo

 

Processo

Envolvidos

Dados de Entrada

Dados de Saída
Sincronização de Produtos (GA → GV) GA (Retaguarda), GV (Mobile) Produtos, Variações, Complementos Tabelas locais do GV atualizadas, Logs

Especificação Funcional

Protótipo de Tela:

Não há

Regras de Negócio:

1. Sincronização de Produtos (GA → GV)

Questões Técnicas:

GA (Retaguarda)

GV (Mobile)

  1.  

©SOFTEN SISTEMAS 2025

 

 

 

 

Modo de Venda

Incluir complementos durante o fluxo da venda


 Softensistemas Logo

 Projeto/Sistema:
MVP Gerencie Vendas		 Versão do Template:
1.2
Processo:
Sincronização de tabelas de complementos e variações		 Versão do Documento:
1.0
Responsável(eis): 
Jalile Cornachioni

Data: 

26/08/2025
1. Introdução

O objetivo desta melhoria é: Permitir no GV a seleção de variações e complementos no fluxo de venda.

2. Processo

Fluxograma - adaptação totem.jpg

 

Processo

Envolvidos

Dados de Entrada

Dados de Saída
Venda no GV (Mobile) Usuário (Vendedor), GV Produto selecionado, variação, complementos Pedido registrado no GV

Especificação Funcional

Protótipo de Tela:

 

Descrição dos Campos:

Campo

Tipo

Tamanho

Obrig. ?

Máscara

Observações

Campo

Texto

100

Sim

-

-
Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

1.Venda no GV (Mobile)

Questões Técnicas:

GV (Mobile)

Cenários de Teste

  1. Food-Service: Pizza Média + borda recheada → venda no GV, sincronização, edição no GA, emissão de NFC-e.

  2. Atacado: Cerveja pack 12 unid → venda no GV, sincronização, alteração de preço no GA, emissão de NF-e.

  3. Varejo: Camiseta Polo G Azul → venda no GV, sincronização, alteração de forma de pagamento no GA, emissão de NFC-e.

  4. Erros:

    1. Produto sem NCM → rejeição fiscal.

    2. Código de barras duplicado → exibir lista de escolha.

    3. Venda offline → reenvio após reconexão.

©SOFTEN SISTEMAS 2025

 

 

 

 

Cadastro de cliente pelo app

Cadastro de cliente pelo app

Tela de formulário de cadastro de clientes

 


 Softensistemas Logo

 Projeto/Sistema:
CADASTRO DE CLIENTE PELO APP		 Versão do Template:
1.2
Processo:
Tela de formulário de cadastro de cliente		 Versão do Documento:
1.0
Responsável(eis): 
Pâmela Munhoz, Jalile Cornachioni, Gustavo Evaristo

Data: 

05/09/2025
1. Introdução

O aplicativo mobile é utilizado por representantes de vendas que realizam a visita aos clientes para registro de pedidos. Atualmente o aplicativo sincroniza apenas clientes cadastrados previamente no GerencieAqui (GA), não havendo a possibilidade de realizar cadastros novos durante as visitas.

A limitação afeta o processo de prospecção, já que representantes não conseguem abrir carteira de um novo cliente no momento da venda.

2. Processo

image-1760527894387.jpg

 

Solução esperada

A implementação do cadastro de clientes diretamente no App Mobile (Representante de vendas) possui como maior objetivo a eliminação do processo de dependência de envio manual de cadastro para o responsável pela utilização do GerencieAqui (retaguarda), permitindo assim que o representante registre o cliente no momento da venda ou do orçamento, com sincronização posterior para o sistema de retaguarda. O processo deverá:

 

Especificação Funcional

CADASTRO DE CLIENTE POR NOVO ORÇAMENTO E NOVA VENDA:

Protótipo de tela:

image-1760621174671.png

CADASTRO DE CLIENTE POR CLIENTES:

Protótipo de tela:

image-1760621228766.png

TELA DE CONFIGURAÇÃO:

Protótipo de tela:

image-1760621292306.png

TELA DE SINCRONIZAÇÃO:

Protótipo de tela:

image-1760621350028.png

 

 Descrição dos Campos:

Campo

Tipo

Tamanho

Obrig. ?
CPF (Seleção de pessoa física)

Número

11

Não
CNPJ (Seleção de pessoa jurídica)

Número

14

Não

Nome/Razão Social

Número

60

Sim

Nome fantasia (Seleção de pessoa jurídica)

Texto

60

Não

Tipo de Contribuinte

Dropdown

-

Não

IE (Seleção de pessoa jurídica)

Número

 20

Não

RG (Seleção de pessoa física)

Número

9

Não

E-mail

Texto

100

Não

Telefone (Com DDD)

Número

11

Não

CEP

Número

8

Sim

Endereço

Texto

60

Sim

Número

Número

20

Sim

Complemento

Texto

50

Não

Bairro

Texto

60

Sim

Município e UF

Texto

50

Sim

Vendedor

Texto

-

Não

Observação interna

Texto

5000

Não
 
Regras de Interface:

1. Campo CPF/CNPJ:

O campo "CNPJ/CPF" deverá ser preenchido corretamente com a quantidade de dígitos necessários.

Comportamento esperado:

Cenários negativos e possíveis erros:

2. E-mail:

Embora o campo não seja obrigatório a inclusão de e-mail no cadastro do cliente possibilita o envio de relatórios e pedidos de venda/orçamento, com isso é necessário que o campo possua um endereço de e-mail válido caso tenha sido preenchido.

Comportamento esperado

3. Telefone:

O campo não é obrigatório e caso preenchido deverá ter um formato válido com DDD. O telefone é um campo obrigatório devido a possibilidade de ser encaminhado relatório de venda/orçamento diretamente pelo WhatsApp do cliente

Comportamento esperado

4. Campo CEP:

Os dados serão importados para dentro do banco do APP.

Comportamento esperado:

Cenário negativos e possíveis erros:

REGRA DE NEGÓCIO TELA DE CADASTRO:
  1. O sistema mobile não deve permitir edição de clientes que já estão cadastrados ou importados na retaguarda.
  2. A edição será permitida somente para clientes novos, ainda não exportados. Regras de exibição:
    • Exibir ícone de edição na tela de listagem e de detalhes somente para clientes novos (não sincronizados).
    • Não exibir o ícone de edição para clientes já exportados.
  3. Durante o cadastro de um novo cliente:
    • O sistema deve verificar se já existe um cliente com o mesmo CPF/CNPJ:
      • Caso exista exibir mensagem: Já existe registros associados a este CNPJ ou CPF.". O sistema permitirá a criação mesmo assim.
      • Caso não exista, seguir normalmente o fluxo de cadastro.
  4. O sistema deverá consultar o serviço de CEP já utilizado pela retaguarda para preencher automaticamente logradouro, município e UF no formulário de cadastro
    • Caso CEP não seja encontrado, o sistema deverá permitir que o usuário selecione manualmente a cidade a partir da base local sincronizada de municípios.
  5. Os valores de município e UF deverão ser concatenados em um único campo no formulário de cadastro.
  6. O Campo vendedor deverá ser preenchido automaticamente e respeitar a configuração de permissão para alteração.
  7.  O sistema mobile e o retaguarda deverão manter um campo de origem para identificar se o cliente foi cadastrado pelo mobile ou pelo retaguarda.
REGRA DE NEGÓCIO TELA DE CONFIGURAÇÃO:
  1. O sistema deve oferecer uma configuração para determinar se o usuário poderá ou não realizar cadastro de novos clientes pelo aplicativo mobile. O valor padrão dessa configuração deverá ser inativo para todos os dispositivos.
    • Quando a opção estiver habilitada, o sistema deverá:
      • Exibir o ícone ➕ para criação de novo cliente nas telas de listagem de clientes.
      • Exibir o ícone ➕ no campo cliente das telas de nova venda e novo orçamento, permitindo o cadastro direto a partir dessas telas.
    • Quando opção estiver desabilitada, o sistema deverá:
      • Ocultar completamente o ícone que permite o cadastro de novos clientes em todas as telas e campos.
      • Impedir o usuário de iniciar o fluxo de cadastro de cliente.
  2. A configuração de permissão para alteração de vendedor também deverá ser respeitada:
    • Se habilitada, o usuário poderá alterar o vendedor no cadastro de cliente, venda e orçamento.
    • Se desabilitada, o vendedor permanecerá fixo, sem permissão de alteração.
REGRA DE NEGÓCIO TELA DE SINCRONIZAÇÃO
  1. O sistema retaguarda deverá enviar, durante a sincronização de clientes:
    • E-mail e telefone dos clientes
    • Vendedor vinculado ao cliente
    • Todos os municípios para atualização da base local de cidades no app, com frequência de sincronização configurável.
  2. O sistema deverá permitir sincronização manual de clientes, vendas e orçamentos entre o mobile e o retaguarda.
  3. Durante o processo:
    • A exportação de clientes deverá ser travada como sempre ativa, impedindo que o usuário desmarque essa opção.
    • Caso a permissão de cadastro de cliente esteja desabilitada, o sistema deverá ocultar a opção de exportar clientes para o retaguarda.
    • A sincronização do mobile deverá desconsiderar a data de cadastro e se basear apenas no indicador de cliente exportado da base local.
    • O sistema mobile deverá enviar o cadastro de clientes obrigatoriamente antes da venda ou orçamento.
    • A sincronização deverá ocorrer mesmo que não haja vendas ou orçamentos pendentes.
    • Durante o envio, o sistema deverá atribuir o nome do cliente ao contato padrão no retaguarda e garantir que o vendedor responsável seja incluído no envio.
Questões Técnicas:

Estrutura de Integração Exemplo da estrutura atual do payload de envio do mobile para o retaguarda. Deve ser incluído no Payload tipo de contribuínte, vendedor, e-mail e telefone:

{ "originId": 0,
"name": "name_a10cbf024d58",
"tradeName": "tradeName_26ad41df96b3",
"personType": "0",
"cpfCnpj": "999.999.999-99",
"zipCode": "99999999",
"ieRg": "ieRg_bcaf3a4888d2",
"address": "address_e78947a13cd5",
"complement": "complement_21df26977603",
"neighborhood": "neighborhood_be1610630a66",
"city": "city_1040a05de6da",
"sellerOriginId": 0,
"internalNotes": "internalNotes_62e1372c5096",
"image": "image_1cbed78b9b46"
"appId": "069d3be4-fbed-4663-a3de-00c9be6af151"
}

personType: 0-CLIENTE, 1-FORNECEDOR
imagem: base64
appId: Novo campo que vai ser criado, para preenchimento do id gerado no aplicativo e vínculo na venda quando for um cadastro novo

2. Persistência e Base de Dados:

3. Lógica de Sincronização:

4. Testes Técnicos:

©SOFTEN SISTEMAS 2025