# Documentação Técnica — Website Nebix, APIs de Planos, Pedidos e Criação de Ambientes **Sistema:** Website Nebix / WAS ERP **Tecnologias:** PHP, CodeIgniter, MySQL e API Asaas **Objetivo:** Documentar como o site consulta e exibe os planos, processa a contratação, cadastra clientes, cria pedidos e cobranças, confirma pagamentos e inicia a ativação do plano e a criação do ambiente. --- ## 1. Visão geral do funcionamento O processo de contratação começa quando o visitante acessa o site e escolhe um plano. O site consulta os dados dos planos, apresenta os valores e encaminha o usuário para o checkout. Durante a contratação, o sistema verifica se o cliente já existe, cadastra o cliente no Asaas e no ERP, cria uma fatura e solicita a criação da cobrança. Depois, o Asaas envia eventos de pagamento ao webhook, que identifica o pedido e pode iniciar a ativação do plano e a criação do ambiente correspondente. ### Fluxo geral 1. O site consulta os planos disponíveis. 2. O usuário escolhe um plano e a modalidade de contratação. 3. O site reúne os dados do cliente, do plano e do pagamento. 4. O sistema verifica se o cliente já existe no ERP. 5. O cliente é cadastrado no Asaas e no ERP. 6. O ERP cria a fatura e seus itens. 7. O Asaas cria a cobrança ou assinatura. 8. O sistema associa os identificadores do Asaas à fatura. 9. O site recebe os dados para pagamento. 10. O webhook processa os eventos enviados pelo Asaas. 11. Após o processamento do pagamento, o sistema verifica se o plano já está ativo. 12. Quando aplicável, o sistema ativa o plano e inicia a criação do ambiente. **Importante:** criar uma fatura ou uma cobrança não significa que o pagamento foi confirmado. A confirmação e o provisionamento são etapas posteriores. --- ## 2. Consulta e exibição dos planos ### 2.1. Consulta de planos pela API **Arquivo:** controller `Planos.php` **Método:** `get_planos_post()` O método consulta os planos cadastrados no ERP por meio de `Planos_model`, aplicando os seguintes filtros: - `show_on_website = 1` - `deleted = 0` O resultado é convertido para JSON e retornado ao consumidor da API. Essa consulta retorna os registros e os campos disponibilizados pelo modelo, que podem incluir o nome, os valores e as informações do plano. **Limitação identificada:** o método não filtra pelo campo `mostrar_internet`. Portanto, a consulta apresentada não utiliza esse campo como condição para decidir quais planos serão retornados. ### 2.2. Funções utilizadas pelo site **Arquivo:** `conexao/functions.php` Foram identificadas as seguintes funções: | Função | Funcionamento | |---|---| | `get_planos()` | Faz uma requisição GET para `https://wascloud.com.br/was/index.php/api/get_planos`. | | `get_planos_interno()` | Consulta os planos localmente, filtrando `show_on_website = 1` e `deleted = 0`. | | `get_planos_interno_chat()` | Consulta os planos localmente, filtrando `show_on_website = 4` e `deleted = 0`. | | `get_plano_interno_dados($id)` | Consulta os dados de um plano pelo ID, considerando o campo `deleted`. | A função `get_plano_interno_dados($id)` não verifica, nos trechos analisados, se o plano está habilitado para determinada categoria ou se `mostrar_internet` está ativo. ### 2.3. Tipos de plano O campo `show_on_website` identifica a categoria do plano. | Valor | Tipo de plano | |---|---| | `0` | Não mostrar | | `1` | ERP / WhatsApp | | `2` | Hospedagem | | `3` | E-mail | | `4` | Chat / Atendimento | | `5` | Integração Hostinger | Esse campo é importante tanto para a organização dos planos no site quanto para determinar o tratamento realizado durante a ativação. ### 2.4. Controle administrativo `mostrar_internet` O ERP possui um controle de visibilidade chamado `mostrar_internet`, disponibilizado na listagem administrativa de planos. **Método:** `Planos.php::update_mostrar_internet()` O método: 1. Verifica o acesso do usuário. 2. Valida o ID do plano. 3. Recebe o valor de `mostrar_internet`. 4. Converte o valor para `1` ou `0`. 5. Salva a alteração no banco. 6. Retorna uma resposta JSON indicando sucesso ou falha. A interface administrativa utiliza o controle visual `marketplace-switch`, com a classe `js-mostrar-internet`. O JavaScript envia a alteração por AJAX para `planos/update_mostrar_internet`. **Diferença entre os campos:** - `show_on_website`: identifica a categoria do plano. - `mostrar_internet`: representa o controle administrativo de visibilidade. Nos métodos de consulta apresentados, `mostrar_internet` não é utilizado como filtro. Portanto, não se deve afirmar que desativar esse controle remove automaticamente o plano de todas as consultas do site. --- ## 3. Exibição dos planos e seleção da contratação ### 3.1. Página de planos **Arquivo:** `planos/index.php` A página utiliza a consulta interna para listar os planos. No trecho analisado, existe um limite de quatro planos na listagem. A interface apresenta informações como: - Nome do plano. - Valor mensal. - Valor anual. - Recursos e permissões disponíveis. - Ação para contratar ou continuar com o plano. O formulário de contratação encaminha o usuário para `planos/add_planos.php`, enviando o ID do plano selecionado. Também foi identificado um tratamento específico para o plano de demonstração, associado ao ID `5`. ### 3.2. Adição do plano ao carrinho **Arquivo:** `planos/add_planos.php` Esse arquivo registra no carrinho os dados básicos da seleção, incluindo: - Endereço IP do usuário. - ID do plano. - Data de inclusão. Depois, redireciona o usuário para o carrinho. ### 3.3. Carrinho **Arquivo:** `carrinho/index.php` O carrinho recupera o plano selecionado e calcula os itens conforme a modalidade de contratação. No fluxo analisado: - **Mensal:** utiliza o campo `valor` do plano e quantidade `1`. - **Anual:** utiliza `valor_anual / 12` como valor unitário e quantidade `12`. - **Implantação:** pode adicionar um item adicional, conforme a modalidade escolhida. Os dados da contratação são mantidos em cookies para serem utilizados na etapa de checkout. O plano de demonstração ID `5` possui um tratamento específico e encaminha o usuário para o fluxo de demonstração. ### 3.4. Checkout **Arquivo:** `checkout/index.php` O checkout reúne os dados do cliente e da contratação, incluindo: - Nome e documento. - Telefone e e-mail. - Endereço. - Senha e identificador de acesso. - Plano selecionado. - Modalidade mensal ou anual. - Quantidade e valor do plano. - Desconto e cupom, quando aplicáveis. - Implantação, quando aplicável. - Forma de pagamento. - Dados do cartão, quando aplicável. Essas informações são encaminhadas ao fluxo de cadastro e cobrança. --- ## 4. Processo de contratação no arquivo `functions_class.php` ### 4.1. Método `save_client()` **Arquivo:** `conexao/functions_class.php` Esse método coordena as principais etapas da contratação. #### Etapa 1 — Verificar se o cliente existe O método envia os dados do formulário para: `https://wascloud.com.br/was/index.php/api/website_exist_client` Se a API retornar `success` verdadeiro, o fluxo é interrompido e o site retorna a mensagem: `CPF/CNPJ já utilizado em outro cadastro.` Se a resposta indicar que o cliente não existe, o fluxo continua. #### Etapa 2 — Criar o cliente no Asaas O método chama: `asaas_save_client($name, $vat)` O retorno fornece o identificador do cliente no Asaas, que é armazenado em `id_asaas`. #### Etapa 3 — Cadastrar o cliente no ERP O método envia os dados para: `https://wascloud.com.br/was/index.php/api/website_client_save` Se o cadastro for concluído, recebe o `client_id` do ERP e adiciona os identificadores ao conjunto de dados da contratação. #### Etapa 4 — Criar o pedido O método chama `save_invoice()`, que utiliza a API `website_invoice_save`. Se a fatura for criada, o sistema recebe o `invoice_id` e incorpora os dados retornados ao fluxo. #### Etapa 5 — Criar a cobrança O método chama `save_conta_receber($post)`. Essa etapa solicita ao Asaas a criação de uma cobrança ou assinatura e registra os identificadores correspondentes na fatura do ERP. #### Etapa 6 — Retornar os dados ao site Se a cobrança for criada, o método monta a resposta JSON com informações para a interface de pagamento. Para PIX, busca o QR Code. Para boleto, retorna o link do documento bancário. Também retorna o link da fatura disponibilizado pelo Asaas. O método possui tratamentos de erro para as etapas de cadastro, criação da fatura e criação da cobrança. --- ## 5. Cadastro do cliente no Asaas ### Método `asaas_save_client()` Esse método envia os dados para o endpoint de clientes do Asaas: `https://www.asaas.com/api/v3/customers` Os campos enviados são: | Campo | Descrição | |---|---| | `name` | Nome do cliente | | `cpfCnpj` | CPF ou CNPJ | | `mobilePhone` | Telefone com espaços, parênteses e hífens removidos | | `notificationDisabled` | Definido como `true` | O envio é realizado por `asaas_post()`. Quando a resposta contém um ID de cliente, o método retorna `success = true` e os dados do cliente. Caso contrário, retorna `success = false` com uma mensagem de falha. Esse método cria o cadastro do cliente no Asaas. Não cria a fatura nem confirma o pagamento. --- ## 6. Cadastro do cliente no ERP ### Método `website_client_save_post()` **Local:** controller da API do ERP, `website_client_save`. Esse método recebe os dados enviados pelo site e realiza o cadastro na estrutura de clientes do ERP. ### 6.1. Normalização e verificação do documento O CPF/CNPJ é recebido pelo campo `vat`. O método remove pontos, traços, barras e espaços. Em seguida, consulta `Clients_model` para verificar a existência de um registro com o documento no campo `nome_fantasia`, considerando `deleted = 0`. Se encontrar um registro, retorna erro HTTP `400`, informando que o documento já está utilizado. ### 6.2. Cadastro de CNPJ Quando o documento possui mais de 11 caracteres após a normalização, o método consulta: `/assets/consulta-inteligente/ConsultaInteligente.php` A consulta é feita por cURL, enviando o CNPJ em JSON. Quando a consulta retorna os dados esperados, o cadastro utiliza informações como nome da empresa, data de abertura, e-mail, porte, capital social, endereço, município, estado, CEP e telefone. Para alguns campos, os dados enviados pelo site são utilizados como alternativa quando a consulta não fornece um valor. Se a consulta falhar ou retornar as condições de erro verificadas pelo método, o cadastro é interrompido e a API retorna erro HTTP `400`. ### 6.3. Cadastro de CPF Quando o documento possui exatamente 11 caracteres, o método utiliza os dados enviados pelo formulário, como nome, gênero, nascimento, e-mail, telefone e endereço. Documentos com comprimentos diferentes dos tratados pelo método são rejeitados como inválidos. ### 6.4. Cadastro como lead ou cliente O método diferencia os registros conforme `is_lead`. **Quando é lead:** - Exige telefone, e-mail e nome. - Define os campos de lead, incluindo status, origem e responsável. - Salva o registro e retorna `client_id`. **Quando não é lead:** - Salva o cliente no ERP. - Cria um usuário de contato vinculado ao cliente. - Define esse usuário como contato principal. - Retorna `client_id` quando o cadastro do cliente é concluído. A criação do usuário de contato é feita por `Users_model`. ### 6.5. Respostas | Situação | HTTP | Resultado | |---|---|---| | Cadastro concluído | 200 | `success = true`, `client_id` | | Documento já utilizado | 400 | Mensagem de duplicidade | | Falha na consulta do CNPJ | 400 | Mensagem de erro na consulta | | Documento inválido | 400 | Mensagem de documento inválido | | Falha no cadastro ou dados insuficientes | 400 | Mensagem de falha | --- ## 7. Criação da fatura e dos itens do pedido ### Método `website_invoice_save_post()` Esse método cria a fatura no ERP e adiciona os itens referentes ao plano contratado. ### 7.1. Dados recebidos Entre os campos utilizados estão: - `client_id`: identificador do cliente no ERP. - `plan_id`: identificador do plano. - `mensal_anual`: modalidade mensal ou anual. - `parcelas`: quantidade de parcelas. - `payment_method`: forma de pagamento. - `notes`: observações. - `discount`: desconto. - `coupon`: cupom. - `plano_qtd`: quantidade do item do plano. - `valor_plano`: valor unitário enviado pelo site. - `implantacao`: indica se há implantação. - `implantacao_value`: valor da implantação. ### 7.2. Data de emissão e vencimento A data de emissão é definida como a data atual. O primeiro vencimento da fatura é calculado para três dias depois. Quando há parcelas, o método monta `condicao_pagamento`, calculando a diferença em dias entre a data de emissão e os vencimentos previstos. ### 7.3. Fatura mensal Quando `mensal_anual = 'm'`, a fatura é criada com: - `recurring = 1`. - `repeat_every = 1`. - `repeat_type = 'months'`. - `no_of_cycles = 0`. - `next_recurring_date` calculada para o mês seguinte. - `parcelas = 1`. Isso caracteriza uma fatura recorrente mensal no ERP. ### 7.4. Fatura anual Para a modalidade diferente de `'m'`, a fatura é criada sem recorrência, com `recurring = 0`. O campo `parcelas` utiliza o valor enviado pelo site ou assume `1` como padrão. ### 7.5. Criação dos itens O método consulta o plano por `plan_id` e busca um item associado ao plano. O primeiro item da fatura representa o plano contratado. O título é definido conforme a modalidade: - `Assinatura - [nome do plano]`, para mensal. - `Pacote Anual - [nome do plano]`, para anual. O item recebe a descrição do plano, quantidade, valor unitário e total. Se `implantacao = 'yes'`, é adicionado um segundo item com o título `Implantação - [nome do plano]`. A fatura é criada inicialmente com o status `not_paid`. ### 7.6. Retorno Quando a fatura e o último item salvo atendem à condição de sucesso, o método retorna: - `success = true`. - Mensagem `Pedido criado com sucesso`. - `invoice_id`. - Dados recebidos no campo `post`. Caso contrário, retorna erro HTTP `400`. **Limitação identificada:** os valores utilizados nos itens incluem valores enviados pelo site. No trecho analisado, não há recálculo completo dos preços a partir dos valores oficiais do plano nem validação explícita de categoria ou visibilidade do plano nessa API. --- ## 8. Criação da cobrança ou assinatura no Asaas ### Método `asaas_create_conta()` Esse método monta a solicitação enviada ao Asaas de acordo com a modalidade de contratação e a forma de pagamento. Utiliza dois endpoints: - `/api/v3/payments`: cobrança individual ou parcelada. - `/api/v3/subscriptions`: assinatura recorrente. ### 8.1. Formas de pagamento | Valor recebido em `payment_method` | Tipo enviado ao Asaas | |---|---| | `boleto` | `BOLETO` | | `pix` | `PIX` | | `credito` | `CREDIT_CARD` | | `debito` | `DEBIT_CARD` | Para pagamentos com cartão, o código envia os dados do cartão e do titular, incluindo nome, número, validade, código de segurança, documento, e-mail, CEP, número do endereço e telefone. ### 8.2. Plano mensal sem implantação Para `mensal_anual = 'm'`, o método cria uma assinatura com ciclo `MONTHLY`. O valor recorrente corresponde ao valor do plano menos o desconto informado. O endpoint utilizado é `/api/v3/subscriptions`. O campo `nextDueDate` é definido conforme a forma de pagamento: o código utiliza a data atual acrescida de três dias para boleto e PIX e a data atual para cartão. ### 8.3. Plano anual Para a contratação anual, o método cria uma cobrança individual por meio de `/api/v3/payments`. A descrição utiliza o prefixo `WAS Software - Anual`. Para cartão de crédito com mais de uma parcela, são enviados `installmentCount` e `totalValue`. Nos demais casos, o código utiliza uma cobrança individual. Boleto e PIX utilizam vencimento calculado para três dias depois. Para cartão, o vencimento é definido como a data atual. ### 8.4. Plano mensal com implantação Quando `mensal_anual = 'm'` e `implantacao = 'yes'`, o método prepara duas operações: **Cobrança de adesão** - Utiliza `/api/v3/payments`. - Inclui o valor do plano, o valor da implantação e o desconto conforme a expressão utilizada no código. - A descrição começa com `WAS Software - Adesão`. **Assinatura mensal** - Utiliza `/api/v3/subscriptions`. - Define ciclo `MONTHLY`. - A descrição começa com `Assinatura WAS Software`. - O valor recorrente considera o plano menos o desconto. O método envia a cobrança principal e, nesse cenário, tenta enviar também a assinatura. ### 8.5. Multas e juros Nas configurações de boleto e PIX mostradas para algumas modalidades, são enviados os campos `fine` e `interest`, ambos com `value = 2`. ### 8.6. Retorno O método utiliza `curl_post()` para enviar os dados ao Asaas. Quando as condições de retorno são atendidas, devolve um array contendo: - `success`: resultado da cobrança principal. - `conta_info`: dados retornados pela cobrança principal. - `assin_success`: resultado da operação adicional de assinatura. - `assin_info`: dados retornados pela assinatura. Caso contrário, retorna o resultado de erro da solicitação. **Limitação identificada:** a condição de retorno do cenário com implantação aceita sucesso se a cobrança principal ou a operação adicional retornar sucesso. Isso não garante que ambas tenham sido concluídas. Também foram identificadas diferenças entre as expressões de cálculo do valor da implantação nas modalidades mensal e anual. A documentação descreve o comportamento observado, sem assumir que todos os cenários calculam o total da mesma maneira. --- ## 9. Associação da cobrança à fatura do ERP ### Método `save_conta_receber($post)` **Arquivo:** `conexao/functions_class.php` Esse método recebe os dados da contratação, chama `asaas_create_conta()` e atualiza os campos da tabela `invoices`. A associação é feita utilizando `post['invoice_id']`. | Tipo de retorno do Asaas | Campos atualizados | |---|---| | Pagamento com `installment` | `asaas_pay` e `asaas_installment` | | Pagamento sem `installment` | `asaas_pay` | | Assinatura (`subscription`) | `asaas_subscription` | Se `assin_success` estiver ativo, o método também processa `assin_info` e atualiza os identificadores da fatura conforme o tipo de objeto retornado. O método retorna o resultado original de `asaas_create_conta()` ao fluxo de contratação. **Observação:** o trecho analisado estabelece a associação entre a fatura e os identificadores do Asaas. Não foi apresentada uma API separada chamada `website_payment_save_post()` no fluxo compartilhado. --- ## 10. Retorno dos dados de pagamento ao site Depois da criação da cobrança, `save_client()` prepara o retorno para a interface do checkout. ### 10.1. Cobrança individual Quando o retorno representa um pagamento individual: - Para PIX, chama `asaas_recover_pix()` usando o ID do pagamento e retorna a imagem codificada do QR Code. - Para boleto, retorna `bankSlipUrl` em `pdf_link`. - Retorna `invoiceUrl` em `link`. - Disponibiliza as informações da cobrança no objeto de retorno. ### 10.2. Assinatura Quando o retorno representa uma assinatura: 1. Consulta os pagamentos da assinatura por `asaas_list_sub_payments()`. 2. Obtém o primeiro pagamento retornado. 3. Verifica se o tipo de cobrança é PIX ou boleto. 4. Recupera o QR Code ou o link do boleto. 5. Retorna o link da fatura e as informações obtidas. O retorno de sucesso dessa etapa indica que o sistema conseguiu criar a cobrança conforme a lógica de retorno implementada. Não significa que o pagamento foi confirmado. --- ## 11. Webhook do Asaas e processamento dos pagamentos ### Método `webhook_asaas_receive_post()` O webhook recebe eventos enviados pelo Asaas e processa os pagamentos relacionados às contratações originadas no site. ### 11.1. Identificação dos pagamentos do site O método utiliza descrições conhecidas para identificar cobranças relacionadas às contratações do site, incluindo prefixos como: - `Assinatura WAS Software -` - `Assinatura Nebix -` - `WAS Software - Adesão` - `Nebix - Adesão` - `WAS Software - Anual` - `Nebix - Anual` Se a descrição não corresponder às condições implementadas, o método pode ignorar o evento e retornar uma resposta indicando que a fatura provavelmente não foi originada do site. ### 11.2. Eventos tratados Foram identificados tratamentos para eventos como: | Evento | Comportamento observado | |---|---| | `PAYMENT_CREATED` | Atualiza a associação da fatura ao pagamento em determinados fluxos recorrentes. | | `PAYMENT_CONFIRMED` | Processa determinadas confirmações, com regras específicas para formas de pagamento. | | `PAYMENT_RECEIVED` | Processa pagamentos recebidos, incluindo cenários de assinatura, parcelamento e pagamento individual. | O código analisado ignora determinados eventos, incluindo situações de estorno, chargeback e outras condições específicas. ### 11.3. Associação à fatura O webhook utiliza informações do pagamento, como `externalReference`, identificadores do Asaas e dados de assinatura, para relacionar o evento à fatura correspondente. Em alguns cenários, também verifica se a cobrança está associada a um link de pagamento ou se já existe um registro relacionado em modelos do ERP. ### 11.4. Registro do pagamento e ativação Após processar o pagamento conforme as condições do evento, o webhook verifica se o cliente já possui um plano ativo, utilizando `exist_client_plan()`. Se não houver um plano correspondente, chama `website_active_plan_create_post($info)` para iniciar o fluxo de ativação. O código compartilhado não permite afirmar que todos os eventos de pagamento produzem a ativação imediatamente. Isso depende das condições e do caminho executado pelo webhook. --- ## 12. Verificação de plano ativo ### Método `Planos_ativos_model->exist_client_plan($id_asaas)` Esse método consulta a relação entre: - `planos_ativos`; - `planos`; - `clients`. A consulta utiliza o ID do cliente no Asaas e considera os registros de plano ativo que não estão marcados como excluídos. O resultado é utilizado pelo webhook para verificar se já existe um plano associado ao cliente antes de tentar ativá-lo novamente. No trecho analisado, não há um filtro explícito por tipo de plano ou status da ativação nessa consulta. --- ## 13. Ativação do plano e criação do ambiente ### Método `website_active_plan_create_post($info)` Esse método relaciona o pagamento recebido ao cliente, à fatura e ao plano contratado. Depois, utiliza os dados encontrados para registrar o plano ativo e iniciar o provisionamento correspondente. ### 13.1. Identificação do cliente e da fatura O cliente é localizado pelo identificador `payment.customer` no campo `id_asaas`. A fatura é localizada conforme o tipo de informação disponível: - Se o pagamento possui `installment`, busca a fatura por `asaas_installment`. - Caso contrário, busca a fatura por `asaas_pay`. O método obtém um item da fatura e utiliza a relação com o plano para identificar qual plano será ativado. ### 13.2. Identificação do ambiente O nome do banco de dados é montado com o prefixo `sig_` e o `web_nick` do cliente. O `web_nick` também é utilizado como identificador do ambiente em outras etapas do provisionamento. O método obtém as informações do plano e verifica o campo `show_on_website` para determinar o tratamento da ativação. ### 13.3. Registro do plano ativo O método salva o registro do plano ativo antes de concluir todas as etapas do provisionamento. O registro inclui informações do cliente, plano e ambiente, conforme os dados obtidos no fluxo. Esse comportamento é importante para compreender a ordem das operações: o registro de ativação pode existir antes que todas as etapas de criação do ambiente tenham sido concluídas. --- ## 14. Criação do ambiente ERP Para o tipo de plano ERP (`show_on_website = 1`), o método de ativação executa um conjunto de operações para preparar um ambiente individual. ### 14.1. Cópia dos arquivos **Método:** `create_new_environment_files($data)` O método copia o conteúdo do ambiente de homologação para o diretório do novo ambiente, utilizando `recurseCopy()`. O diretório de origem identificado é `../homologacao/`, enquanto o destino é formado a partir do `slug` do cliente. ### 14.2. Configuração do banco **Método:** `edit_database_file($data)` O método abre o arquivo: `../$slug/application/config/database.php` A lógica substitui a referência fixa ao banco `sig_homologacao` pelo nome do banco correspondente ao novo ambiente. Se o arquivo não for encontrado ou a substituição falhar, o método retorna falha. ### 14.3. Criação e importação do banco **Método:** `create_new_environment_database($data)` O método utiliza ferramentas de linha de comando do MySQL para criar a estrutura e os dados iniciais do novo banco. O processo inclui: 1. Gerar um arquivo SQL com a estrutura do banco de homologação. 2. Remover informações de `AUTO_INCREMENT` conforme a implementação. 3. Exportar os dados de um conjunto específico de tabelas de configuração. 4. Criar o banco de dados de destino. 5. Importar a estrutura. 6. Importar os dados iniciais. Entre as tabelas de configuração identificadas estão `config_nfe`, `dashboards`, `email_templates`, `notifications`, `notification_settings`, `payment_methods`, `roles`, `settings`, `taxes`, `ticket_templates`, `tipo_codigo_barras`, `url_nfe` e `users`. A operação depende dos parâmetros de conexão e das ferramentas de banco de dados disponíveis no servidor. ### 14.4. Criação do usuário inicial **Método:** `create_new_user($database, $usuario)` O método conecta ao banco de destino utilizando PDO e insere o usuário inicial, incluindo os dados necessários para acesso ao sistema. ### 14.5. Etapas complementares O fluxo de ativação também executa tarefas relacionadas a: - Configuração de tarefas agendadas (cron). - Atualização de permissões. - Associação do identificador do cliente. - Ajustes do plano, incluindo `set_plan_as_upgrade()`. A conclusão depende do resultado das operações de provisionamento. **Limitação identificada:** em alguns caminhos de falha da cópia, da configuração do banco ou da criação do banco, o código emite uma resposta JSON sem interromper explicitamente a execução naquele ponto. Por isso, não é possível garantir que todas as falhas interrompam o fluxo corretamente. --- ## 15. Criação de ambiente de hospedagem Para o tipo de plano de hospedagem (`show_on_website = 2`), o método de ativação utiliza a integração com o WHM para criar uma conta de hospedagem. O processo utiliza dados como: - Usuário derivado do e-mail do cliente. - Domínio formado a partir do identificador do ambiente. - Senha da conta. - Nome do plano de hospedagem. A criação é solicitada ao WHM por meio da integração disponível no código. O trecho analisado verifica o campo `errors` da resposta para avaliar o resultado da operação. A documentação confirma a existência desse caminho de integração, mas não confirma todos os detalhes do tratamento de erros, da validação da conta criada ou das configurações adicionais de hospedagem. --- ## 16. Tipos de plano e provisionamento A relação entre categoria e provisionamento identificado é a seguinte: | `show_on_website` | Categoria | Comportamento identificado | |---|---|---| | `0` | Não mostrar | Categoria utilizada para excluir o plano da consulta pública que filtra por tipo `1`; demais comportamentos dependem do caminho executado. | | `1` | ERP / WhatsApp | Fluxo de criação de ambiente ERP, incluindo arquivos, banco e usuário inicial. | | `2` | Hospedagem | Integração com WHM para criação de conta de hospedagem. | | `3` | E-mail | Há um caminho de processamento no método de ativação, mas a configuração completa não foi confirmada. | | `4` | Chat / Atendimento | A listagem interna possui uma consulta específica para planos desse tipo; o provisionamento completo não foi confirmado no método analisado. | | `5` | Integração Hostinger | Categoria identificada no cadastro de planos; o provisionamento correspondente não foi confirmado no trecho de ativação analisado. | O método `website_active_plan_create_post()` contém caminhos para alguns tipos, mas não foi identificada uma implementação completa de provisionamento para todas as categorias. --- ## 17. Criação do ambiente de demonstração ### Método `website_active_demo_plan_create_post()` Esse método executa um fluxo específico para a criação de um ambiente de demonstração. As etapas identificadas incluem: 1. Registrar o plano de demonstração. 2. Copiar os arquivos do ambiente de referência. 3. Atualizar a configuração do banco de dados. 4. Criar o banco e importar os dados iniciais. 5. Criar o usuário inicial. 6. Configurar tarefas agendadas. 7. Atualizar permissões e identificação do cliente. 8. Definir o prazo de validade da demonstração. O código analisado define o prazo de demonstração em sete dias e inclui operações relacionadas a avisos. Esse fluxo é separado do processo normal de contratação paga. --- ## 18. Resumo dos principais arquivos e métodos | Arquivo ou componente | Método / função | Responsabilidade | |---|---|---| | `conexao/functions.php` | `get_planos()` | Consultar planos pela API. | | `conexao/functions.php` | `get_planos_interno()` | Listar planos internos do tipo `1`. | | `conexao/functions.php` | `get_planos_interno_chat()` | Listar planos internos do tipo `4`. | | `conexao/functions.php` | `get_plano_interno_dados($id)` | Consultar os dados de um plano pelo ID. | | `Planos.php` | `get_planos_post()` | Retornar planos filtrados por tipo e exclusão lógica. | | `Planos.php` | `update_mostrar_internet()` | Alterar o controle administrativo de visibilidade. | | `conexao/functions_class.php` | `save_client()` | Coordenar o cadastro, a fatura e a cobrança. | | Classe de integração Asaas | `asaas_save_client()` | Criar cliente no Asaas. | | Controller da API do ERP | `website_client_save_post()` | Cadastrar cliente no ERP. | | Controller da API do ERP | `website_invoice_save_post()` | Criar a fatura e os itens do pedido. | | `conexao/functions_class.php` | `save_conta_receber()` | Criar a cobrança e associá-la à fatura. | | Classe de integração Asaas | `asaas_create_conta()` | Montar e enviar os dados de cobrança ou assinatura. | | Controller da API do ERP | `webhook_asaas_receive_post()` | Processar eventos enviados pelo Asaas. | | `Planos_ativos_model` | `exist_client_plan()` | Verificar se existe plano ativo para o cliente. | | Controller da API do ERP | `website_active_plan_create_post()` | Registrar a ativação e iniciar o provisionamento. | | Controller da API do ERP | `website_active_demo_plan_create_post()` | Criar ambiente de demonstração. | | Métodos auxiliares de provisionamento | `create_new_environment_files()` | Copiar os arquivos do ambiente. | | Métodos auxiliares de provisionamento | `edit_database_file()` | Atualizar a configuração do banco. | | Métodos auxiliares de provisionamento | `create_new_environment_database()` | Criar o banco e importar estrutura e dados iniciais. | | Métodos auxiliares de provisionamento | `create_new_user()` | Criar o usuário inicial no banco do ambiente. | --- ## 19. Limitações e observações da análise Esta documentação descreve o comportamento dos trechos de código compartilhados. As observações abaixo delimitam o que foi possível confirmar. ### Planos - As consultas apresentadas utilizam `show_on_website` e `deleted`. - `mostrar_internet` é alterado no cadastro administrativo, mas não aparece como filtro nos métodos de consulta examinados. - A recuperação direta de um plano pelo ID não confirma, por si só, sua visibilidade pública. ### Pedidos e pagamentos - O pedido é representado pela fatura criada no ERP. - A fatura começa com status `not_paid`. - A cobrança é criada separadamente no Asaas. - O código de `save_client()` não chama diretamente um método chamado `website_payment_save_post()`. - O registro e a atualização dos identificadores da cobrança ocorrem nos métodos de integração apresentados. - O código compartilhado não comprova que todos os métodos de pagamento e todas as situações de falha tenham sido testados em produção. ### Webhook e ativação - O webhook utiliza regras específicas para identificar pagamentos originados no site. - O provisionamento depende das condições de processamento do evento e da existência prévia de plano ativo. - Não foi confirmado que todos os tipos de plano possuam um fluxo completo de provisionamento. - A criação do registro de plano ativo ocorre antes de todas as operações de provisionamento estarem necessariamente concluídas. ### Integrações e ambiente - O processo de criação do banco depende das ferramentas de linha de comando do MySQL e do acesso ao servidor. - Os trechos analisados não confirmam integralmente todos os tratamentos de erro das integrações com WHM e dos caminhos de provisionamento. - O fluxo de demonstração possui tratamento próprio e prazo definido de sete dias. --- ## 20. Conclusão O sistema Nebix/WAS utiliza uma integração entre o website, a API do ERP, o Asaas e os métodos de provisionamento para processar a contratação de planos. A API do ERP fornece os dados dos planos, cadastra clientes e cria faturas. A camada do website organiza a contratação e solicita ao Asaas a criação de cobranças ou assinaturas. Os identificadores retornados são associados à fatura, e o webhook processa os eventos de pagamento para verificar a necessidade de ativação. Após essa etapa, o método de ativação identifica o plano contratado e executa o fluxo de provisionamento correspondente. Para o ERP, esse fluxo inclui cópia de arquivos, configuração e criação de banco de dados e criação do usuário inicial. Para hospedagem, há integração com WHM. A documentação cobre o fluxo principal identificado no código, os campos relevantes, as responsabilidades dos métodos e as diferenças entre as categorias de plano. Os comportamentos não confirmados em todos os cenários foram indicados como limitações, sem presumir que existam APIs ou etapas não demonstradas no código analisado.