Sistema de Gerenciamento Ejonere

1. Visão geral

O Sistema de Gerenciamento Ejonere será uma plataforma própria para administrar a operação da Floricultura Ejonere de ponta a ponta:

Atendimento → Cliente → Pedido → Pagamento → Produção → Cartão → Entrega/Retirada → Pós-venda → Financeiro → Relatórios → Auditoria

O sistema será desenvolvido prioritariamente para utilização em celular, mas também deverá funcionar em computador e tablet.

Máxima simplicidade para as operações do dia a dia e máximo rigor para operações financeiras, administrativas e críticas.

Cada funcionário terá login individual. As ações importantes serão vinculadas automaticamente ao usuário, evitando a necessidade de digitar o próprio nome.

2. Objetivos

• agilizar o atendimento;
• reduzir digitação e tarefas repetitivas;
• centralizar pedidos;
• melhorar o controle financeiro;
• organizar produção;
• organizar entregas e rotas;
• integrar WhatsApp;
• utilizar IA de forma controlada;
• preservar histórico;
• aumentar a segurança;
• facilitar consultas;
• gerar relatórios;
• permitir auditoria completa;
• reduzir erros operacionais;
• facilitar o trabalho dos funcionários.

A interface deverá ser limpa, objetiva e intuitiva, evitando excesso de telas, menus e cliques.

3. Perfis de acesso

• A — Administração
• F — Financeiro
• E — Entregas
• B — Atendimento

Um mesmo usuário poderá possuir mais de um perfil simultaneamente. Também será possível conceder permissões individuais manualmente a usuários.

4. Administrador Master

Haverá um Administrador Master responsável pelas configurações de maior nível.

• usuários;
• perfis;
• permissões;
• configurações;
• integrações;
• parâmetros;
• segurança;
• auditoria;
• demais recursos administrativos.

Permissão administrativa não elimina regras estruturais do sistema. Exemplo: Pedido entregue → dados originais permanecem bloqueados.

5. Usuários

• nome;
• login;
• senha protegida;
• status ativo/inativo;
• perfis;
• permissões individuais;
• histórico.

Usuários não deverão ser apagados fisicamente quando já possuírem histórico operacional. Ao sair da empresa, o acesso será desativado, preservando as ações antigas.

6. Permissões

As permissões serão granulares. Exemplos:

• criar pedido;
• editar pedido;
• cancelar pedido;
• receber pagamento;
• visualizar financeiro;
• autorizar desconto;
• autorizar cortesia;
• alterar produção;
• administrar entregas;
• alterar rota;
• consultar auditoria;
• administrar usuários;
• emitir nota fiscal.

A aplicação verificará as permissões no servidor. Esconder um botão não será considerado mecanismo de segurança suficiente.

7. Clientes

O sistema diferenciará claramente:

O cliente poderá possuir nome, CPF, CNPJ quando aplicável, e-mail, múltiplos telefones, múltiplos endereços, observações e histórico de pedidos. CNPJ será opcional.

8. Telefones

Um cliente poderá ter vários telefones. Cada telefone poderá indicar número, país, WhatsApp, principal e ativo/inativo.

O número de WhatsApp poderá ser utilizado para reconhecer automaticamente um cliente existente.

9. Endereços

Um cliente poderá possuir diversos endereços, como Casa, Trabalho, Empresa ou Outro. Cada endereço poderá possuir apelido.

Durante o pedido, o endereço efetivamente utilizado será copiado para o pedido, garantindo que alteração futura no cadastro não modifique pedidos antigos.

10. Pedidos

O pedido será o centro operacional do sistema.

• número;
• comprador;
• destinatário;
• produtos;
• valores;
• desconto;
• taxa;
• pagamento;
• data;
• período;
• entrega ou retirada;
• cartão/bilhete;
• produção, quando aplicável;
• histórico.

A numeração seguirá YY0001. Exemplo: 260001. A numeração será reiniciada a cada ano.

11. Produtos

O sistema terá catálogo de produtos, como Buquê, Orquídea, Cesta, Pelúcia, Chocolate, Arranjo e produtos personalizados.

Cada produto poderá possuir nome, descrição, categoria, preço, foto e status ativo/inativo.

12. Produto livre

O funcionário não será obrigado a escolher um produto do catálogo. Poderá utilizar DESCRIÇÃO LIVRE e combinar produtos cadastrados com complementos personalizados.

13. Estoque

O sistema não terá estoque tradicional obrigatório. Poderá controlar estatísticas de venda: quantidade vendida, faturamento, produto mais vendido, vendas por período, loja e funcionário.

14. Fotos de produtos disponíveis

O atendente poderá fotografar diretamente uma opção existente na loja.

Tirar foto → IA trata imagem → atendente confere → enviar ao cliente

A IA poderá remover fundo, melhorar enquadramento e iluminação, deixar fundo branco e produzir aparência profissional. A foto original poderá ser preservada.

15. Produtos personalizados

A IA poderá auxiliar na criação de produtos personalizados, perguntando conforme a necessidade sobre flores, cores, estilo, embalagem, laço, tamanho, ocasião, orçamento e características especiais. As perguntas serão adaptativas.

16. Referências visuais

A IA poderá gerar até três referências visuais. O cliente poderá escolher, solicitar alteração, gerar nova proposta, aprovar ou encaminhar para análise da Ejonere. A referência aprovada ficará vinculada ao pedido.

17. Produção

Aguardando produção → Em produção → Produto confeccionado → Aguardando aprovação → Aprovado

Se o cliente solicitar alterações: Ajustes solicitados → Em produção → Nova foto → Nova aprovação. Cada versão será preservada.

18. Fotos da produção

Após a confecção, o produto real será fotografado. O cliente receberá a fotografia e poderá APROVAR ou SOLICITAR ALTERAÇÃO. A solicitação poderá ser enviada por texto ou áudio, com possibilidade de transcrição.

19. Cartão e bilhete

Durante o pedido, o sistema perguntará se o cliente deseja cartão, bilhete ou nenhum.

O cliente poderá escrever ou enviar áudio. A IA poderá transcrever. O sistema fará automaticamente escolha/configuração da fonte, tamanho, espaçamento, margens, alinhamento, quebra de linhas e diagramação.

Visualiza → Imprime

20. Pagamentos

Formas previstas: Pix, cartão de crédito/débito, link de pagamento, dinheiro e futuras modalidades quando integradas.

Status possíveis: aguardando pagamento, pago, recusado, expirado, cancelado, estornado e pendente.

21. Pix

O Pix será individualizado por pedido/cobrança. O sistema deverá permitir QR Code, código copia e cola, validade, aviso próximo da expiração, confirmação automática e nova cobrança quando necessário.

Não será necessário anexar comprovante manualmente quando a confirmação vier automaticamente do provedor.

22. Cartão

Serão registradas tentativas, resultado, retorno técnico e data/hora. Não serão armazenados dados completos de cartão ou CVV. Em caso de recusa, o cliente receberá informação genérica.

23. Descontos

Pedidos sem desconto não precisam de aprovação especial.

Atendente solicita → Financeiro/Administração autoriza → desconto aplicado → auditoria

O desconto poderá ser informado por porcentagem ou valor.

24. Cortesias

Quando um item for lançado a R$ 0,00, o sistema deverá exigir autorização.

A autorização será realizada preferencialmente por reconhecimento facial, identificando se a pessoa possui autorização. As pessoas autorizadas são Financeiro e Administração.

A câmera deverá capturar uma foto no momento da autorização. O registro ficará vinculado ao item específico.

25. Entrega

Cada pedido terá:

UMA ÚNICA ENTREGA

Uma nova tentativa não será registrada como uma segunda entrega independente.

26. Períodos de entrega

Períodos principais: Manhã e Tarde. Não haverá necessidade de horários fixos para todas as entregas. Quando houver horário específico, poderá ser registrado. Domingos não terão entregas.

27. Rotas

O sistema organizará automaticamente as rotas considerando os endereços. Poderá organizar sequência, visualizar mapa, reordenar, acompanhar entregador, recalcular rota e criar nova rota quando necessário.

28. Rota em andamento

Quando uma rota estiver em andamento, ela não poderá receber novos pedidos. Pedidos posteriores serão direcionados à próxima rota ou a uma nova rota, quando necessário.

29. Entregador

Cada entregador terá login próprio. O sistema saberá automaticamente quem está utilizando o aparelho e registrará o usuário sem seleção manual.

30. Tela do entregador

A tela será extremamente simples e apresentará produto, destinatário, telefone, endereço, nome/telefone do comprador e observações.

Ações: CHEGUEI · CONFIRMAR ENTREGA · NÃO CONSEGUI REALIZAR A ENTREGA

31. Entrega não realizada

Motivos oficiais:

• Ninguém em casa;
• Endereço não encontrado;
• Outro motivo.

Poderá registrar observação por texto ou áudio. O áudio poderá ser transcrito.

32. Reprogramação

Quando a entrega não puder ser realizada, o comprador será informado sobre o motivo e poderá sugerir novo horário, nova data quando aplicável ou outro endereço.

Quando permitido: aprovação automática → sem taxa adicional → atualização da logística.

33. Decisão automática de rota

Depois de uma alteração, o sistema analisará a logística.

O entregador também receberá a atualização.

34. Rastreamento

O rastreamento ficará disponível somente quando o pedido estiver EM ROTA. O comprador poderá acompanhar a localização do entregador. O sistema poderá enviar aviso próximo da chegada.

35. Surpresa para o destinatário

Quando apropriado, o destinatário receberá mensagem preservando a surpresa. A comunicação não deverá revelar desnecessariamente quem enviou o presente.

36. WhatsApp integrado

O WhatsApp será incorporado ao Sistema Ejonere. O atendente não precisará utilizar o WhatsApp Web separadamente para o atendimento operacional.

• receber e enviar mensagens;
• responder;
• receber e enviar fotos;
• receber e enviar áudios;
• receber documentos;
• visualizar histórico;
• assumir conversas;
• transferir conversas;
• consultar pedidos e clientes.

37. Central de conversas

A tela terá três áreas principais: Conversas | Mensagens | Dados do cliente/pedido. O funcionário poderá visualizar o pedido relacionado sem sair do atendimento.

38. IA no WhatsApp

A IA poderá reconhecer clientes, entender intenções, consultar pedidos, apresentar produtos, conduzir vendas, coletar dados, gerar referências, solicitar aprovação, acompanhar produção, comunicar etapas, tratar solicitações de entrega e encaminhar para humano.

A IA não terá acesso irrestrito ao banco. Utilizará funções previamente autorizadas.

39. Transferência para humano

Quando necessário: IA → fila → atendente. Ao assumir, a IA deixa de responder. Depois poderá devolver a conversa para a IA. Todo o histórico permanece.

40. Transferência entre setores

Conversas poderão ser encaminhadas entre Atendimento, Financeiro, Entregas e Administração. A transferência ficará registrada.

41. Origem das mensagens

Cada mensagem poderá indicar Cliente, IA, Atendimento, Financeiro, Entregas, Administração ou integração automática.

42. Notificações

O sistema terá central de notificações. O sino mostrará a quantidade disponível. Ao abrir: contador → zero. Mensagens ainda não abertas permanecerão visualmente destacadas.

43. Retirada

Pedidos de retirada terão fluxo próprio. Quando estiverem prontos: Pronto para retirada. O sistema poderá gerar QR Code.

O QR Code terá validade, poderá ser reenviado ou substituído, ficará inválido após uso e não finalizará sozinho a retirada. Após leitura: CONFIRMAR RETIRADA. Usuário, data e horário serão registrados.

44. Avaliações

Depois da entrega ou retirada, o cliente poderá avaliar.

45. Reclamações

Ocorrências poderão possuir responsável, prioridade, status, solução, histórico e reabertura.

Status: Pendente · Em atendimento · Resolvido · Reaberto.

Prioridades: Normal · Alta · Urgente.

46. Pedido após entrega

Quando o pedido estiver ENTREGUE, os dados originais ficarão bloqueados. Não será permitida alteração retroativa.

Entretanto, será possível adicionar informações pós-entrega, como texto, áudio, transcrição, foto ou documento.

Cada inclusão registrará automaticamente usuário, setor, data e horário.

47. Auditoria

A auditoria registrará ações relevantes: criação de pedido, alteração, cancelamento, desconto, cortesia, pagamento, estorno, alteração de endereço/rota, produção, aprovação, entrega, retirada, mudança de permissão e informação pós-entrega.

O registro deverá indicar: quem → o quê → quando → antes → depois → origem.

48. Banco de dados

O banco será organizado por módulos.

49. Integridade do banco

1. Um pedido possui uma única entrega.
2. Número do pedido não pode duplicar.
3. Preço histórico do pedido não muda quando o catálogo muda.
4. Endereço histórico do pedido não depende do cadastro atual.
5. Pedido entregue não permite alteração dos dados originais.
6. Avaliações anteriores não são apagadas por novas avaliações.
7. Fotos de produção são versionadas.
8. Pix anteriores permanecem registrados.
9. QR Codes cancelados/usados não podem ser reutilizados.
10. Eventos externos duplicados não podem gerar operações duplicadas.

50. Relatórios

O sistema terá relatórios de vendas, pedidos, financeiro, pagamentos, pendências, produção, entregas, rotas, avaliações, reclamações, notas fiscais e fechamento.

Filtros poderão incluir data, período, loja, funcionário, produto, forma de pagamento, status, cliente e outros critérios pertinentes.

51. Fechamento diário

O sistema deverá realizar fechamento automático nos horários configurados. O fechamento poderá apresentar quantidade de pedidos, vendas brutas, cancelamentos, estornos, vendas líquidas, Pix, cartão, dinheiro, entregues, pendentes, ticket médio e detalhamento por funcionário, loja e produto.

52. PDF do fechamento

O fechamento poderá gerar automaticamente um PDF, por exemplo Fechamento_Ejonere_03-09-2026.pdf, que ficará armazenado no sistema.

53. Envio do fechamento

O fechamento poderá ser encaminhado automaticamente para o Financeiro através dos canais configurados, incluindo e-mail e WhatsApp, conforme as integrações disponíveis.

54. Notas fiscais

O Financeiro terá acesso ao fluxo fiscal: solicitação, emissão, número, chave, XML, PDF, eventos, cancelamentos e histórico.

55. Pesquisa global

Será possível pesquisar por número do pedido, comprador, destinatário, telefone, endereço, data, funcionário, entregador e informações permitidas em mensagens e registros. Os resultados respeitarão as permissões.

56. Segurança

• autenticação individual;
• senha protegida;
• sessões seguras;
• autorização no servidor;
• proteção contra SQL Injection;
• proteção contra XSS;
• proteção contra CSRF;
• validação de arquivos;
• proteção de APIs;
• credenciais protegidas;
• tokens seguros;
• auditoria.

57. Dados de cartão

O Sistema Ejonere não deverá armazenar número completo de cartão, CVV ou outros dados sensíveis que pertençam ao provedor de pagamento. Serão armazenados apenas identificadores seguros necessários à operação e auditoria.

58. Arquivos

Fotos, áudios e documentos serão armazenados fora das estruturas principais do banco quando tecnicamente adequado. O banco manterá referência, nome, tipo, tamanho, localização, hash, data e vínculo.

59. Backups

A estratégia de backup deverá considerar banco de dados, arquivos importantes, proteção de acesso, restauração e testes de restauração. A diretriz atual é retenção de 90 dias.

60. Automações

O sistema poderá executar automaticamente notificações, expiração e lembrete de Pix, fechamento diário, lembrete de NF, comunicação de pedido/produção/entrega, reprogramação, recalculação de rotas, geração de relatórios e manutenção técnica.

As tarefas deverão ser projetadas para não gerar duplicidades.

61. Motor de regras

O sistema terá uma camada responsável por validar regras de negócio:

• Desconto → exigir autorização.
• Cortesia R$ 0,00 → exigir autorização específica.
• Pedido entregue → bloquear alteração original.
• Rota em andamento → impedir novo pedido.
• Usuário sem permissão → bloquear.
• Novo endereço durante entrega → analisar e atualizar logística.

62. Integrações

A arquitetura deverá manter integrações separadas do núcleo.

• WhatsApp;
• pagamentos;
• IA;
• mapas;
• geolocalização;
• tratamento de imagens;
• emissão fiscal;
• armazenamento.

63. API

Os módulos conversarão através de serviços internos.

/clientes
/produtos
/pedidos
/pagamentos
/producao
/entregas
/rotas
/whatsapp
/avaliacoes
/relatorios

Toda operação deverá passar por validações.

64. Webhooks

Integrações externas poderão enviar eventos ao sistema. Exemplo: Provedor confirma Pix → sistema valida evento → identifica pagamento → atualiza pagamento → atualiza pedido → notifica cliente → registra auditoria.

Eventos repetidos deverão ser identificados para impedir duplicidade.

65. Interface

A interface deverá ser limpa, rápida, responsiva, intuitiva, adaptada ao perfil, com poucos campos obrigatórios e poucos cliques.

Se o sistema já sabe uma informação, o funcionário não deverá digitá-la novamente.

66. Menu principal

• Início;
• Pedidos;
• WhatsApp;
• Produção;
• Entregas;
• Clientes;
• Financeiro;
• Relatórios;
• Notificações;
• Administração, quando autorizado.

Módulos sem permissão não deverão ser apresentados.

67. Dashboard

68. Princípio de interface

Mostrar primeiro o que precisa ser feito.

Esconder complexidade técnica do funcionário.

Uma operação simples deverá permanecer simples mesmo que internamente o sistema execute dezenas de processos.

69. Arquitetura técnica

A aplicação será estruturada em camadas:

Interface → API → Regras de negócio → Banco → Integrações

Isso permitirá manutenção e evolução sem misturar responsabilidades.

70. Estrutura de módulos

autenticacao
usuarios
clientes
produtos
pedidos
pagamentos
producao
cartoes
entregas
retiradas
whatsapp
avaliacoes
notificacoes
relatorios
fiscal
auditoria
configuracoes
integracoes
tarefas

A estrutura exata de arquivos dependerá da tecnologia escolhida após confirmação do ambiente de hospedagem.

71. Desenvolvimento

O desenvolvimento será feito módulo por módulo:

Planejamento → Estrutura → Código → Teste → Correção → Aprovação

Não serão produzidos grandes blocos de código sem antes explicar o que será desenvolvido.

72. Ordem de desenvolvimento

1. Fundação, banco, autenticação e segurança.
2. Clientes.
3. Produtos.
4. Pedidos.
5. Pagamentos.
6. Cartões e bilhetes.
7. Produção.
8. WhatsApp + IA.
9. Entregas + rotas.
10. Retiradas.
11. Avaliações e pós-venda.
12. Relatórios.
13. Integrações.
14. Testes.
15. Publicação.

73. Testes

Antes da implantação serão testados login, permissões, pedidos, pagamentos, descontos, cortesias, produção, fotos, cartões, WhatsApp, IA, rotas, rastreamento, retirada, avaliações, relatórios, auditoria e backups.

Também serão simulados erros e situações excepcionais.

74. UOL Host

A implantação será preparada para a UOL Host. Não serão presumidas características específicas do plano.

Antes da configuração definitiva serão confirmados: linguagem/versão, banco de dados, armazenamento, SSL, domínio, execução de tarefas automáticas, acesso técnico, limites de processamento, integrações externas, backups e demais recursos necessários.

A arquitetura deverá evitar dependência desnecessária de um único fornecedor.

75. Regra de ouro do projeto

Poucos campos → poucos cliques → automação

mas:

Login → permissão → autorização → registro → auditoria quando a operação for sensível.

76. Fluxo completo

CLIENTE
   ↓
WHATSAPP / ATENDIMENTO
   ↓
IDENTIFICAÇÃO
   ↓
PEDIDO
   ↓
PRODUTO
   ↓
CARTÃO/BILHETE
   ↓
PAGAMENTO
   ↓
PRODUÇÃO
   ↓
FOTO REAL
   ↓
APROVAÇÃO
   ↓
ROTA / RETIRADA
   ↓
ENTREGA
   ↓
AVALIAÇÃO
   ↓
PÓS-VENDA
   ↓
RELATÓRIOS
   ↓
AUDITORIA

77. Fonte oficial das regras

Este Manual será a referência principal para o desenvolvimento.

Quando uma nova decisão for tomada:

Manual V1 → alteração aprovada → nova versão

Nenhuma alteração importante deverá ser incorporada ao código sem antes atualizar a especificação correspondente.

Se surgir conflito entre uma regra antiga e uma nova decisão, deverá ser identificada a divergência e definida qual regra prevalece.

78. Status atual do projeto

Neste estágio, o Sistema Ejonere possui uma base definida para:

• visão geral;
• usuários;
• perfis;
• permissões;
• clientes;
• produtos;
• pedidos;
• pagamentos;
• descontos;
• cortesias;
• cartões;
• produção;
• WhatsApp;
• IA;
• entregas;
• rotas;
• retirada;
• avaliações;
• relatórios;
• auditoria;
• banco de dados;
• segurança;
• automações;
• integrações;
• arquitetura;
• implantação.

Próxima etapa oficial: transformar esta especificação em documentação técnica detalhada do banco de dados e da API, antes da programação do primeiro módulo.