Onboarding e Inicialização da Base de Dados

O que é o onboarding do SiversaERP

O onboarding é o processo que transforma uma instalação ou subscrição recém-preparada num ambiente SiversaERP utilizável. Ele envolve identificar o modo de operação, disponibilizar a base de dados correcta, configurar a empresa, estabelecer o primeiro acesso administrativo e validar que o utilizador entra no contexto certo.

Local e Remote em uma frase

TruthSource: a origem operacional

A configuração TruthSource determina se a instância trabalha no modelo Local ou Remote. Para o utilizador final isto não é uma opção quotidiana; é uma decisão de implantação/configuração do ambiente.

O que este manual cobre, e o que fica no CRM

Este manual cobre o lado ERP do onboarding: filosofia Local/Remote, Assistente de Inicialização, ligação/criação da BD, dados iniciais da empresa, primeiro acesso, tenant Remote e comportamento esperado após provisionamento.

No modo Remote, o processo comercial e administrativo que antecede a criação do tenant: cliente no CRM, subscrição, aprovação, acções de provisionamento, estado da integração e demais operações próprias do CRM: deve ser aprofundado no Manual do CRM.

Mapa do processo

Quando o Assistente de Inicialização aparece

Quando o ambiente Local não possui uma ligação válida/pronta para a base de dados, o SiversaERP pode encaminhar para o Assistente de Inicialização. O objectivo é impedir que o utilizador continue para áreas operacionais sem uma BD ERP válida.

As duas opções do Assistente

Na primeira etapa escolha entre:

• Ligar base de dados existente: utiliza uma BD Siversa já criada e com o esquema necessário.
• Criar nova empresa: cria uma nova BD, aplica o esquema disponível na distribuição e executa a inicialização de dados/configurações.

Antes de começar

• ☐ Servidor SQL acessível.
• ☐ Credenciais SQL autorizadas para a operação pretendida.
• ☐ Para BD existente: nome correcto da BD Siversa.
• ☐ Para nova empresa: nome oficial da empresa/instituição.
• ☐ NUIT e contactos, quando disponíveis.
• ☐ País, cidade e endereço.
• ☐ Logotipo, se desejar configurá-lo já no onboarding.

Etapa 1: Escolher existente ou nova

Esta decisão é a mais importante do assistente. Existente significa reaproveitar dados e estrutura já preparados. Nova empresa significa construir um novo ambiente empresarial.

Etapa 2: Servidor SQL

Informe o servidor SQL e as credenciais solicitadas pelo assistente. O SiversaERP testa a conectividade antes de avançar.

Uma mensagem de ligação estabelecida confirma apenas que o servidor pode ser alcançado com os dados informados; a validação da BD ocorre na etapa apropriada.

Falha ao ligar ao servidor

Se o teste falhar, confirme o nome/instância do servidor, disponibilidade do SQL Server, rede, credenciais e permissões. Não avance repetindo tentativas aleatórias.

Etapa 3A: Ligar uma BD existente

Seleccione ou informe a base de dados que já contém o SiversaERP. O assistente executa uma validação para confirmar que a BD possui elementos estruturais esperados de uma instalação Siversa.

Quando a validação for bem-sucedida, o ambiente pode prosseguir para a ligação/configuração final.

Como o ERP reconhece uma BD válida

O sistema verifica elementos essenciais do esquema para distinguir uma BD ERP válida de uma base arbitrária. Esta validação protege o onboarding contra a selecção acidental de uma BD sem a estrutura Siversa necessária.

Etapa 3B: Criar nova empresa

Ao escolher Criar nova empresa, preencha os dados institucionais. O assistente suporta, entre outros, Tipo de empresa/instituição, Nome, NUIT, E-mail, Telefone, Website, País, Cidade e Endereço.

O nome da base de dados é proposto automaticamente a partir da empresa e o sistema evita colisões quando já existe uma BD com o mesmo nome proposto.

Tipo de empresa / instituição

Seleccione o tipo que melhor representa a organização. Esta informação faz parte da configuração institucional inicial e pode influenciar a forma como o ambiente é apresentado/configurado.

Quando não existir uma classificação mais específica, utilize a opção genérica prevista pelo sistema em vez de escolher uma categoria incorrecta.

Dados da empresa

Preencha dados reais e consistentes. Nome e NUIT devem corresponder à entidade que utilizará o ERP; e-mail e telefone devem ser contactos controlados pela organização.

Logotipo no onboarding

O assistente permite carregar opcionalmente o logotipo da empresa. Utilize uma imagem oficial, legível e de boa qualidade. O logotipo pode ser alterado posteriormente na administração da empresa.

Nome da base de dados gerado

Na criação de nova empresa, o sistema propõe um nome técnico para a BD. Se já existir uma base com o nome calculado, é gerada uma variante para evitar colisão.

O utilizador não precisa transformar o nome da BD numa identificação comercial; o nome oficial da organização é configurado separadamente.

Etapa 4: Rever antes de configurar

O passo Pronto para configurar resume as escolhas. Antes de iniciar:

• confirme se escolheu BD existente ou nova;
• confirme servidor e BD;
• em nova empresa, confirme nome e dados institucionais;
• certifique-se de que não está prestes a criar um ambiente duplicado.

Etapa 5: A configuração

Ao confirmar, o ERP executa o pipeline de inicialização. Numa nova empresa, isso inclui a criação da BD, aplicação do esquema e configuração dos dados/defaults necessários. O ecrã mostra progresso e pode demorar alguns minutos.

O que significa aplicar o esquema

O esquema é a estrutura de dados necessária ao ERP: tabelas e demais objectos que permitem aos módulos persistir informação. O utilizador não precisa executar SQL manualmente durante o fluxo normal do assistente.

Se a distribuição não possuir o artefacto de esquema necessário, o assistente informa que a preparação técnica precisa ser concluída antes da inicialização.

O que é initializeData

Depois da estrutura, o sistema executa a inicialização de dados essenciais. Em termos de onboarding, pense nisso como a criação dos dados-base e configurações mínimas para que uma nova empresa deixe de ser uma BD vazia e se torne um ambiente ERP utilizável.

Defaults configurados automaticamente

A inicialização também prepara configurações e entidades padrão necessárias ao funcionamento de áreas do ERP, incluindo defaults operacionais que evitam obrigar o utilizador a construir toda a fundação manualmente no primeiro login.

Etapa 6: Configuração concluída

Quando o assistente apresenta Configuração concluída, a BD está pronta para o primeiro acesso. No fluxo Local actual, o assistente orienta para a conta administrativa inicial preparada pela inicialização.

Depois do primeiro login

1. Confirme a identidade da empresa.
2. Reveja dados institucionais.
3. Confirme os módulos necessários.
4. Crie/ajuste Grupos de Utilizadores.
5. Crie contas individuais.
6. Reveja permissões.
7. Configure parâmetros funcionais de cada módulo.
8. Faça um teste operacional controlado antes de entrada em produção.

Religar uma instalação a uma empresa existente

Quando os dados empresariais já existem numa BD Siversa válida, o objectivo é ligar o ERP a essa BD, não recriar a empresa. Depois da validação, confirme no primeiro acesso se a empresa, utilizadores e dados esperados estão presentes.

O que muda no Remote

No modo Remote, o ERP trabalha como plataforma multi-tenant. Cada cliente é resolvido para o seu próprio contexto de dados e o utilizador deve entrar através do tenant correcto.

A criação desse tenant não é conduzida pelo assistente Local. Ela é tratada pelo fluxo de provisionamento externo integrado ao CRM.

CRM como origem do onboarding comercial

No Remote, o CRM concentra o contexto comercial/administrativo que determina quando uma empresa está pronta para ser provisionada. A integração existente prevê que o provisionamento seja uma acção controlada a partir do CRM.

Provisionamento: conceito

Provisionar significa preparar automaticamente o tenant ERP de um cliente: criar/associar o ambiente de dados, inicializar a estrutura necessária, criar identidades administrativas previstas e registar o vínculo que permitirá ao ERP resolver aquele cliente posteriormente.

Para o cliente, isso substitui a necessidade de preencher manualmente o Assistente Local.

O que o CRM solicita ao ERP

Em termos funcionais, a integração transmite ao ERP os dados necessários para criar ou reconhecer o tenant. O ERP valida o pedido, prepara o ambiente e devolve ao CRM apenas o resultado necessário para continuar a gestão da integração.

A operação é desenhada para ser repetível de forma segura: uma repetição legítima do mesmo pedido não deve criar outra empresa/BD por acidente.

Empresa e identidades administrativas

O provisionamento Remote prepara a empresa e as identidades administrativas necessárias ao arranque. O desenho separa a identidade administrativa de plataforma/integrador da identidade administrativa do cliente.

Código do cliente / Short Code

Depois de provisionado, o tenant possui um Código do cliente que permite ao SiversaERP identificar qual organização deve ser activada antes do login.

O utilizador pode receber um acesso que já incorpora esse contexto ou informar o código no ecrã de entrada quando solicitado.

Entrada no tenant

1. Aceda ao endereço de entrada fornecido pela organização/Siversa.
2. O ERP resolve o Código do cliente.
3. Quando o tenant é válido e acessível, o contexto da empresa é activado.
4. O utilizador é encaminhado para o Login.
5. As credenciais são validadas no contexto da empresa seleccionada.

Código inválido ou indisponível

Se o código não puder ser resolvido, o ERP apresenta uma mensagem genérica de código inválido ou indisponível. Confirme o código recebido e o estado da empresa no CRM com o suporte autorizado.

A mensagem é deliberadamente genérica para não expor informação sobre organizações a partir de tentativas de códigos.

Sem contexto de tenant

No modo Remote, páginas operacionais não devem ser utilizadas sem que o tenant esteja definido. Quando falta esse contexto, o ERP encaminha o utilizador para a entrada da empresa.

Isso evita que uma sessão “sem empresa” seja usada como se fosse uma instalação Local.

Isolamento entre empresas

O princípio central do Remote é: o tenant activo determina a base de dados usada pelo pedido. Utilizadores de empresas diferentes não devem misturar dados entre si.

Troca de empresa e sessão

A sessão autenticada está vinculada ao contexto do tenant. Uma troca de empresa não deve simplesmente reaproveitar uma autenticação pertencente a outro tenant. O sistema protege essa fronteira e pode exigir nova autenticação.

Estado do provisionamento no CRM

O CRM mantém o acompanhamento do vínculo ERP e pode apresentar estados de integração/provisionamento, informação de saúde/conectividade e acções administrativas. Esses estados são a referência para saber se o tenant está pendente, em preparação, activo ou se ocorreu uma falha.

Consulte o Manual do CRM para a operação detalhada desses ecrãs e regras.

Falha durante o provisionamento

Uma falha no provisionamento não deve ser resolvida pelo cliente tentando abrir o Assistente Local. O operador autorizado deve consultar o estado no CRM, identificar a falha sanitizada e repetir/corrigir o processo pelo fluxo de integração apropriado.

Provisionamento repetido / retry

A integração foi concebida para evitar duplicação quando o mesmo provisionamento é repetido de forma legítima. Isso é particularmente importante em falhas de rede, duplo clique ou respostas incertas.

Acesso administrativo a partir do CRM

A integração prevê mecanismos para que operadores de alto privilégio do CRM possam entrar no ERP de forma controlada, sem transformar o fluxo normal num intercâmbio permanente de passwords entre aplicações.

Os detalhes operacionais e permissões desse acesso pertencem ao Manual do CRM; o utilizador comum deve entrar pelo fluxo normal do tenant.

Licenciamento e módulos no onboarding

No Cloud, provisionar a BD e licenciar a utilização são responsabilidades relacionadas, mas distintas. O tenant precisa de um contexto de licença/subscrição coerente para que os módulos e capacidades contratados estejam disponíveis.

Se a empresa entra no ERP mas determinado módulo não está disponível, a análise deve considerar tanto subscrição/licença como permissões do utilizador.

Local vs Remote: responsabilidades

O que é comum aos dois modos

Depois de inicializado correctamente, ambos os modos convergem no objectivo: empresa identificada, BD válida, utilizadores autenticáveis, módulos/configurações disponíveis e operações ERP persistidas no contexto correcto.

O que nunca deve ser confundido

• Modo de implantação não é perfil de utilizador.
• Tenant não é login.
• Código do cliente não é senha.
• Provisionamento não é licenciamento.
• Licença/módulo activo não substitui privilégio do utilizador.
• BD criada não significa onboarding funcional concluído.

Onboarding técnico vs onboarding funcional

Ter a BD pronta é apenas a fundação. O onboarding funcional começa depois: dados fiscais/institucionais, séries/documentos, armazéns, caixas, contas, artigos, clientes, fornecedores, utilizadores, grupos, parâmetros financeiros e configurações específicas dos módulos contratados.

Sequência recomendada depois da inicialização

1. Validar empresa e dados institucionais.
2. Validar licença/subscrição e módulos.
3. Configurar utilizadores, Grupos e privilégios.
4. Configurar parâmetros de Facturação.
5. Configurar Stock e centros/armazéns.
6. Configurar Tesouraria/Contabilidade conforme utilização.
7. Importar/cadastrar dados mestres.
8. Testar fluxos principais.
9. Treinar utilizadores.
10. Entrar em produção com checklist aprovado.

Dados mestres antes das transacções

Antes de emitir documentos reais, garanta que artigos, impostos, clientes, fornecedores, contas, centros de stock e demais dados mestres necessários estão coerentes. Corrigir fundações depois de muitas transacções é mais difícil do que validar antes do go-live.

Criar contas individuais

Não mantenha toda a equipa a operar com a conta administrativa de bootstrap. Crie contas individuais, associe Grupos funcionais e conceda apenas os privilégios necessários.

Teste de aceitação

Antes do go-live, execute uma pequena bateria de testes: login de utilizador regular, abertura dos módulos contratados, criação/consulta de dados de teste, fluxo de documento, movimento de stock quando aplicável, tesouraria quando aplicável e relatórios essenciais.

Go-live

Considere o onboarding concluído quando a empresa não apenas consegue entrar, mas consegue executar com segurança os processos reais previstos, com utilizadores, permissões, dados mestres e configurações validados.

Assistente aparece inesperadamente

Em ambiente Local, isso normalmente significa que o ERP não reconheceu uma ligação válida/pronta para a BD. Não crie uma nova empresa imediatamente. Primeiro confirme se deveria existir uma BD anterior e investigue a conectividade/configuração.

A BD existente é rejeitada

Confirme se seleccionou a BD correcta e se ela possui o esquema Siversa esperado. Uma BD SQL acessível não é necessariamente uma BD ERP válida.

Criação da nova BD falhou

Registe a etapa e mensagem apresentada. Verifique disponibilidade/permissões do servidor e se os artefactos necessários à inicialização estão presentes. Evite executar scripts manuais improvisados numa tentativa de “terminar” o processo.

Remote pede Código do cliente

Isso é esperado quando o ERP precisa determinar o tenant antes da autenticação. Informe o código atribuído à organização ou utilize o acesso específico fornecido pela Siversa/administrador.

Remote diz que não consegue ligar à BD do cliente

A mensagem indica que o tenant foi identificado, mas a sua base de dados não pôde ser utilizada naquele momento. O operador deve verificar conectividade/estado da integração. O utilizador não deve tentar criar uma BD Local como alternativa.

Empresa provisionada mas login não funciona

Separe as hipóteses: tenant correcto, conta activa, credencial correcta e estado da integração/licença. Se o código abre a empresa correcta mas a credencial falha, trate como problema de autenticação, não como nova inicialização.

Módulo não aparece depois do onboarding

Verifique três dimensões: módulo contratado/activo, configuração funcional e permissão do utilizador. Não recrie a BD para corrigir ausência de menu.

Dados parecem pertencer à empresa errada

Pare a operação imediatamente e confirme o tenant/empresa apresentado. Não grave novas transacções até o contexto estar esclarecido. Em Remote, reporte o caso ao administrador/suporte com o código da empresa e o que foi observado, sem enviar credenciais.

Quem deve executar o onboarding Local

A inicialização Local exige conhecimento do servidor SQL e pode criar/ligar bases de dados. Deve ser executada por técnico ou administrador autorizado, não por qualquer utilizador operacional.

Quem deve provisionar Remote

O provisionamento Remote é uma operação administrativa controlada pela integração CRM-ERP. As permissões e condições exactas para executá-lo devem ser tratadas no Manual do CRM.

Não partilhar segredos durante suporte

Ao pedir ajuda, forneça empresa, modo, etapa, mensagem de erro e horário aproximado. Não envie passwords SQL, passwords de utilizadores, tokens, chaves, connection strings ou ficheiros de configuração sensíveis.

Backups antes de mudanças estruturais

Quando estiver a religar, migrar ou alterar uma implantação existente, siga a política de backup da organização antes de mudanças de alto impacto. O onboarding não deve ser tratado como substituto de uma estratégia de backup.

Checklist Local: nova empresa

• ☐ Modo Local confirmado.
• ☐ Servidor SQL validado.
• ☐ “Criar nova empresa” escolhido conscientemente.
• ☐ Dados institucionais revistos.
• ☐ Nome da BD proposto revisto.
• ☐ Resumo confirmado.
• ☐ Inicialização concluída sem erro.
• ☐ Primeiro login realizado.
• ☐ Contas individuais criadas.
• ☐ Configuração funcional e testes concluídos.

Checklist Local: BD existente

• ☐ BD anterior identificada.
• ☐ Servidor correcto.
• ☐ BD validada como Siversa.
• ☐ Não foi criada BD duplicada.
• ☐ Login existente testado.
• ☐ Empresa e dados históricos conferidos.
• ☐ Testes funcionais essenciais executados.

Checklist Remote

• ☐ Cliente/subscrição preparados no CRM conforme processo comercial.
• ☐ Provisionamento solicitado pelo fluxo autorizado.
• ☐ Tenant criado/associado sem duplicação.
• ☐ Estado da integração confirmado.
• ☐ Código do cliente disponível.
• ☐ Empresa correcta abre no ERP.
• ☐ Admin do cliente consegue autenticar.
• ☐ Licença/módulos confirmados.
• ☐ Utilizadores e privilégios configurados.
• ☐ Teste funcional concluído.

Glossário de onboarding

Onboarding

Processo de preparar tecnicamente e funcionalmente uma organização para utilizar o ERP.

TruthSource

Configuração que determina o modelo Local ou Remote da implantação.

Local

Modo em que a inicialização da BD pode ser conduzida pelo próprio ERP.

Remote

Modo multi-tenant em que o ambiente do cliente é resolvido/provisionado centralmente.

Tenant

Contexto isolado de uma organização dentro da plataforma Remote.

Provisionamento

Criação/preparação automatizada do ambiente ERP de um cliente.

Código do cliente

Identificador usado para seleccionar o tenant antes do login.

Esquema

Estrutura de dados necessária para o funcionamento do ERP.

initializeData

Inicialização dos dados/configurações essenciais de uma nova BD.

CRM

Sistema que, no fluxo Remote, gere o contexto comercial/administrativo e dispara operações de integração ERP quando autorizado.

Onde continuar a leitura