Tela de formulário de cadastro de clientes

 

	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

 

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á:

• Permitir cadastrar novos clientes diretamente ao aplicativo mobile, respeitando a configuração de permissão de cadastro definida na tela de configurações, com valor padrão inativo para todos os dispositivos.
• Exibir o ícone de adição "➕" para criação de novo cliente nas telas: listagem de clientes, campo de cliente em nova venda e novo orçamento. Somente quando a configuração estiver habilitada.
• Ocultar completamente o ícone de adição caso a configuração estiver desabilitada.
• Garantir que os clientes importados da retaguarda não possam ser editados, permitindo edição apenas para clientes novos recém criados e que ainda não foram exportados.
• Exibir ícone de edição na tela de listagem e detalhes somente para clientes novos (não sincronizados).

---

 

Especificação Funcional

---

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

Protótipo de tela:

CADASTRO DE CLIENTE POR CLIENTES:

Protótipo de tela:

TELA DE CONFIGURAÇÃO:

Protótipo de tela:

TELA DE SINCRONIZAÇÃO:

Protótipo de tela:

 

 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:

• • Ao realizar o preenchimento corretamente e após a validação, os campos subsequentes serão liberados para preenchimento dos dados.
  • Validar duplicidade de CPF/CNPJ na base local do aplicativo:
    • Caso haja registro com o mesmo dado, exibir a mensagem "Já existem registros associados a este CNPJ ou CPF", permitindo ainda assim a criação de mais um cliente com o mesmo documento.
    • Caso não haja duplicidade, seguir normalmente o fluxo de cadastro.

Cenários negativos e possíveis erros:

• • Ao digitar um CPF/CNPJ com a quantidade de dígitos inválidos deverá aparecer uma mensagem com o texto sugerido "CPF/CNPJ inválido".

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

• • Ao realizar o cadastro do e-mail do cliente com formato inválido, ao tentar prosseguir deverá aparecer uma mensagem com o texto sugerido "O e-mail informado não está em um formato válido".

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

• • Ao realizar o cadastro do telefone do cliente com formato inválido, ao tentar prosseguir deverá aparecer uma mensagem com o texto sugerido "Digite um número de telefone válido".

4. Campo CEP:

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

Comportamento esperado:

• • Consultar o serviço de CEP já utilizado pelo retaguarda para preencher automaticamente logradouro, município e UF no formulário de cadastro.
  • Caso não seja possível localizar o CEP, o sistema deverá permitir a seleção manual de cidade a partir da base local de município sincronizada com o app.
  • Concatenar os valores de município e UF em um único campo no formulário.

Cenário negativos e possíveis erros:

• • Ao realizar o preenchimento com quantidade de dígitos inválida, deverá aparecer uma mensagem  "CEP inválido".

•  

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:

• Alterações ou novos campos criar um bit para indicar cliente sincronizado;,
• Regras de atualização: “campo sincronizado deve ser atualizado para true após confirmação do servidor”.

3. Lógica de Sincronização:

• Fluxo e prioridade de envio: clientes sempre antes de vendas/orçamentos.,
• Tratamento de falhas: caso sincronização não tenha concluído por algum motivo (pode ser timeout, falhas diversas), o sistema deve executar rollback e não atualizar o bit "sincronizado" na tabela local fazendo com que a sync leia esse cliente e tente enviá-lo novamente posteriormente.,

4. Testes Técnicos:

• Estratégia de teste automatizado (mock de API, payloads simulados).,
• Cenários de integração (cliente duplicado, falha de rede, permissão desabilitada).

©SOFTEN SISTEMAS 2025