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: O sistema mobile não deve permitir edição de clientes que já estão cadastrados ou importados na retaguarda. 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. 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. 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. Os valores de município e UF deverão ser concatenados em um único campo no formulário de cadastro. O Campo vendedor deverá ser preenchido automaticamente e respeitar a configuração de permissão para alteração. 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: 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. 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 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. O sistema deverá permitir sincronização manual de clientes, vendas e orçamentos entre o mobile e o retaguarda. 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