🛠️ Criação do Projeto do Aplicativo Este guia explica como utilizar o script automático responsável por criar toda a estrutura do aplicativo do cliente.

Este guia explica como utilizar o script automático responsável por criar toda a estrutura do aplicativo do cliente. O processo é simples e elimina diversas etapas manuais de configuração.

📍 Localização do Script

O script está localizado na mesma pasta do app base.

No macOS, o caminho padrão é:

Para acessar a pasta utilizando o Terminal:

▶️ Executando o Script

Dentro da pasta correta, execute:

O script solicitará três informações:

• Cliente: nome do provedor

• URL Portal: endereço completo do portal do cliente

• Slug: identificador curto usado para gerar builds Android e iOS

  • Também é usado como identifier do app nas lojas

🧩 O Que o Script Faz

Após inserir os dados, o script executa automaticamente diversas ações:

• Cria a pasta do novo app dentro de Projects

• Copia o projeto base para a nova estrutura

• Realiza ajustes internos para permitir a build em Android e iOS

• Gera todas as imagens necessárias para publicação (ícones, splashes etc.)

Um detalhamento completo dos processos executados pelo script está disponível aqui .

🖼️ Ajustando a Logo (se necessário)

Caso as imagens geradas não fiquem adequadas — seja por baixa resolução ou qualidade insuficiente — basta:

1. Substituir o arquivo logo.png dentro da pasta do projeto do cliente

2. Pelo terminal, navegue até a pasta do projeto do cliente:

1. Rode o comando node make.js images

O script vai regenerar automaticamente todas as imagens.

🔁 Atualização de Projetos Já Publicados

Se o cliente já tem um app publicado, o slug deve ser exatamente o mesmo que está sendo usado nas lojas.

Exemplo:
O app da Atos Telecom tem identifier: br.com.pixelmidia.appatosnet

Portanto, o slug correto é: atosnet

Se o projeto for criado com slug incorreto, é possível ajustar manualmente posteriormente, porém isso pode impactar a atualização do app já publicado.

⚙️ Build do Projeto

O script também realiza as builds de Android e iOS, com um processo igualmente simples.

▶️ Gerando Builds

1. Pelo terminal, navegue até a pasta do projeto do cliente:

2. Execute:

O script fará automaticamente:

• Build do Android

• Build do iOS

Os arquivos gerados podem ser encontrados na pasta builds do projeto.

Para atualização do sistema, o comando build aceita parâmetros para atualizar a versão de build do android ou ios, no seguinte formato:

node make.js build android {versao} ios {versao}

📦 Onde Encontrar os Arquivos Gerados

Após a conclusão, os arquivos serão criados na raiz da pasta do cliente:

• Android: release.aab

• iOS: {nomeDoCliente}.iap

Publicação

• O arquivo Android (.aab) deve ser enviado para a Play Store através do Google Console

• O arquivo iOS (.iap) pode ser aberto diretamente para envio no processo da App Store

As instruções detalhadas de publicação estão disponíveis nas páginas:

• Android

• iOS

Glossário

Pegadinhas frequentes

FAQ

Quem pode acessar essa funcionalidade?

Depende da permissão do usuário. Confira com o administrador do Quaza se você não vê a opção.

O que fazer se aparecer um erro?

Anote a mensagem completa, screenshot, e abra um chamado no suporte do Quaza com esses dados.

Esta funcionalidade tem versão para cliente final?

Algumas funcionalidades têm Portal do Cliente. Verifique no módulo Portal .

Posso integrar via API?

Sim — a maioria das funcionalidades do Quaza expõe endpoints REST. Consulte a documentação técnica.

Quaza tem treinamento oficial?

Sim — equipe de suporte oferece sessões de onboarding sob agendamento.

Ciclo completo da operação

Boas práticas operacionais

Para tirar o máximo desta funcionalidade, observe os pontos abaixo. São práticas que provedores experientes adotam para evitar erros recorrentes e maximizar valor extraído do Quaza.

Antes de operar

• Confirme permissão de acesso: nem todo operador tem permissão para todas as funcionalidades. Verifique com o administrador do Quaza se algo não aparece como esperado. Permissões são vinculadas a papéis (operador, supervisor, admin).
• Cadastros pré-requisitos completos: muitas funcionalidades dependem de outros cadastros estarem completos antes. Por exemplo, antes de criar um contrato você precisa ter o cliente cadastrado, plano de vendas configurado, e regras de cobrança definidas.
• Treine pelo menos 2 operadores: redundância previne paralisação por ausência. Funcionário pode sair, ficar doente, ter dia ruim. Mantenha conhecimento distribuído entre múltiplas pessoas.
• Documente procedimentos internos: crie checklist próprio para operações recorrentes. Quem opera amanhã agradece — especialmente se for funcionário novo.

Durante a operação

• Documente decisões não óbvias: se você ajustou algo de forma diferente do default, anote o porquê. Próximo operador agradece e evita refazer análise.
• Operações em massa pedem cuidado: antes de aplicar a 100+ registros, teste com 5 e revise resultado completo. Se possível, exporte CSV antes para ter como rollback.
• Backup antes de mudanças grandes: cancelar/desfazer pode não ser possível em todas as ações. Em dúvida, faça export ou imprima tela antes.
• Comunique alterações: mudanças que impactam outras equipes (atendimento, financeiro) devem ser anunciadas com antecedência. Surpresa gera retrabalho.

Acompanhamento e revisão

• Revisão semanal de 30 minutos: dedique tempo regular para revisar o que rodou, falhou, ficou pendente neste módulo. Anomalia detectada cedo custa 10x menos que descoberta tarde.
• Defina KPIs próprios: 2-3 indicadores que medem saúde da operação. Acompanhe tendências, não só valores absolutos. Variação maior que 20% merece investigação.
• Auditoria mensal: revise sample de operações do mês passado. Use logs para confirmar que tudo aconteceu como esperado, sem desvios silenciosos.
• Compare com período anterior: "Vendi R$ 100k" — é bom? Compare com mês anterior, mesmo mês ano passado. Contexto importa mais que número absoluto.

Resolução de problemas

• Anote a mensagem de erro completa: copie o texto exato. Captura de tela ajuda. Anote quais passos levaram ao problema — facilita diagnóstico.
• Tente reproduzir em ambiente de teste: se possível, simule o erro com dado dummy antes de pedir suporte. Isso acelera resolução.
• Procure no histórico: provavelmente alguém já viu erro similar. Veja log de auditoria para entender o que mudou recentemente.
• Abra chamado bem documentado: equipe de suporte do Quaza resolve mais rápido com contexto: o que esperava, o que aconteceu, frequência, screenshots.

Indicadores típicos a acompanhar

Cada provedor define seus próprios indicadores, mas alguns são quase universais para qualquer operação no Quaza:

• Volume mensal processado (registros/transações/eventos)
• Taxa de erro (% de operações que falharam)
• Tempo médio de processamento
• Cobertura (% da carteira atendida pela funcionalidade)
• Satisfação operacional (feedback da equipe que usa)

Compare valores atuais com média dos últimos 3 meses. Variação maior que 20% em qualquer direção merece investigação — pode ser melhoria sustentável ou degradação silenciosa.

Recursos relacionados no Quaza

Este recurso se conecta com outros módulos do sistema. Conhecer essas conexões ajuda no troubleshooting e em decisões operacionais:

• Cadastro de cliente — base de tudo no Quaza. Cliente bem cadastrado evita problemas downstream.
• Plano de Contas — onde o impacto financeiro é classificado contabilmente.
• Logs de auditoria — histórico de quem fez o quê e quando, essencial para diagnóstico.
• Permissões e papéis — definem quem pode operar o quê.
• Tarefas crontab — automações que tocam neste recurso periodicamente.

Referência rápida

Atalhos e shortcuts para operação eficiente:

• Busca avançada: use filtros de data, status, responsável para reduzir lista. Filtro padrão pode esconder registros antigos.
• Exportação: a maioria das listas exporta para CSV/Excel. Útil para análise externa ou backup pré-mudança.
• Histórico: cada registro tem timeline de modificações. Acesse via botão "Histórico" ou aba lateral.
• Atalhos de teclado: Ctrl+F (busca), Ctrl+S (salvar), Esc (cancelar) na maioria das telas.
• Permissão restrita: se botão estiver cinza, é falta de permissão — não bug.