Alexandre Aleixo

Estamos falando aqui de carteira sem registro, em todos os momentos. É muito importante deixar isso claro. Nessa carteira, o boleto é gerado por um sistema próprio, que não possui comunicação com o banco. E então, o banco só fica sabendo do boleto quando o cliente vai pagar. Daí, o banco cria um arquivo ret com a relação de boletos que foram pagos. A outra forma de carteira é a COM REGISTRO, onde o banco fica sabendo do boleto ANTES dele ser pago. Isso ocorre pra permitir que sejam aplicados juros, protestos e outros serviços adicionais que os bancos oferecem pra boletos, inclusive compensação antecipada de boletos... Nesse caso, o arquivo ret CONTINUA sendo disponibilizado pelo banco, com a relação de títulos vencidos e não pagos, pagos, protestados e etc... Nisso não muda nada. ENTRETANTO, existem DUAS formas de emissão desse boleto COM registro: uma através do sistema do banco e outra através de sistema próprio. No segundo caso, sei que é emitido um arquivo DE REMESSA pelo sistema próprio da empresa, semelhante ao RET, mas que ao invés de conter informações de boletos pagos, vencidos e etc, consta as informações de boletos EMITIDOS, a serem registrados. O que eu entendi das suas mensagens foi isso que seu cliente precisa: gerar os boletos através de sistema próprio e repassar em lote pro desenvolvedor do sistema pra que ele possa "lançar" no sistema. (Só não entendi a parte onde o condômino entre pra baixar o próprio boleto pelo CPF. Não faz muito sentido, mas enfim...) Mas não sei se a extensão é a mesma do arquivo de retorno (ret), nem mesmo se a estrutura do arquivo é a mesma, pois nunca usei esse método. Concluindo: 1- Arquivo de RETORNO é uma coisa. Arquivo de REMESSA é outra coisa. 2- Se a estrutura desses arquivos for a mesma, você consegue SIM criar arquivo RET usando como base alguns dos scripts presentes aqui, mas vai envolver MUITA programação pra adaptar os scripts pra fazer o que você quer. Afinal, o que temos aqui é um "leitor" de ret, ou seja, ele lê o ret pronto e mostra as informações de um modo que possa ser manipulável através do PHP. E o que você precisa é o contrário: um script que leia as informações que você quer e gere o arquivo de ret, ou seja: um "escritor" de ret. Se quiser, posso fazer um orçamento pra esse desenvolvimento. Basta me mandar mensagem privada com seu email. Abraços!

Sim... Terá que fazer algumas alterações, porque cada banco oferece uma ordem de dados um pouco diferente. Se quiser, faço a adapção pra você. Me mande um email e vemos o orçamento.

Essas informações o seu banco disponibiliza pra você... Não tem mistério... Fale com seu gerente. Sim, funciona... Mas provavelmente terá que fazer algumas alterações, porque cada banco oferece uma ordem de dados um pouco diferente. Se quiser, faço a adapção pra você. Me mande um email e vemos o orçamento. Shopline se eu não me engano é outra coisa... mas é o que eu falei acima... O módulo deve funcionar pra qualquer banco, mas cada banco tem algumas pequenas diferenças, que devem ser adaptadas no módulo pra funcionar. Se quiser, faço um orçamento pra adaptação do módulo pra você. Dá uma olhada nas mensagens anteriores... O link inicial pra download continua funcionando. Sobre a integração com o Santander, funciona porque já testei, mas foi preciso realizar algumas modificações no módulo pra se adaptar a ordem dos dados do Santander. Como desenvolvedor PHP creio que não terá dificuldades, mas precisando de ajuda, me avise... Abraços!

Olá... Posso fazer a adaptação pra você. Me mande um email e vemos o orçamento certinho... Abraços.

Qual é a versão do seu PHP? Sugiro atualizar pra versão estável mais recente.

Vai funcionar sim, mas vai ser necessário adaptar porque cada banco possui um padrão de informações diferentes em seu retorno. O que eu fiz foi a base pra outras pessoas usarem pra incrementar com novas funcionalidades e pra outros bancos.

Olá Marcus, 1) Depende do banco. Cada banco dá variáveis diferentes. No que eu fiz, sim, ele pega o valor processado e lança na fatura. Assim, se o cliente pagar menos do que o valor da fatura, ele não dá a baixa, mas apenas lança o crédito na fatura, reduzindo o valor da mesma, mas mantendo o saldo restante em aberto, com a fatura UNPAID. Mas como eu disse, depende do banco... Quem fizer a adaptação pra outro banco tem que se certificar se está pegando o valor pago ou o valor integral do boleto... E tem que se certificar se é esse valor que está sendo lançado, e não somente dar a baixa integral seguindo apenas o "nosso número/ invoice id". 2) Pelo 24 que você falou no "nosso número", imagino que esteja falando da Caixa, certo? Eu já trabalhei com ela, e realmente no extrato de pagamentos que eles me disponibilizavam não aparecia o hífen. No caso da geração do boleto em si, eu sei que aparece no boleto, mas eu acredito que no código de barras esse hífen não seja "apresentado". Agora, nunca trabalhei com o retorno da Caixa, então não sei te dizer exatamente, mas eu sei que nem no Santander e nem no Bradesco o hífen aparece no retorno. E sinceramente, acho que não é pra aparecer mesmo não. Acho que isso é mais uma questão do sistema que lê mesmo, colocar o hífen automaticamente pra separar o dígito verificador. No mais, já li seu email e já lhe adicionei no skype, ok? Abraços!

Menigma, agora eu entendi... Isso não é complicado de fazer não, mas sinceramente não acho muito positivo, pq como você mesmo falou, afetaria as informações nos relatórios financeiros... Só que não ficaria tão mais "real", mas sim ocultaria um valor que realmente foi entrada. No meu ponto de vista, se há um custo, ele entra na saída de um livro caixa, deduzindo de TODA a entrada, junto com custos de servidores, licenças de sistemas, funcionários, INSS, FGTS, aluguel, luz, telefone e etc... O que eu faço mensalmente é pegar o extrato da conta bancária, colar no excel em modo texto comum e somar todas as taxas pelo Excel, selecionando as células que tem taxas bancárias. Então, eu lanço no livro caixa um dado "Taxas com banco X". E na entrada, claro, eu lanço o valor total que entrou no WHMCS (que é comparado com o valor que entrou na conta pra saber se não houve diferenças de erros em um ou outro). Pra saber lucro/prejuízo, deduzo um do outro. Dá um trabalhinho, mas me dá um panorama correto de tudo que entrou e tudo que saiu no mês, e o mais importante, onde que saiu. Tem tempos que quero escrever um script onde eu lance os dados e ele já faça todos os cálculos... Mas tá um pouco difícil conseguir tempo pra escrever assim do zero. No mais, se realmente quiser essa funcionalidade implementada, podemos combinar um orçamento... Ou faço até de graça se for útil pra outras pessoas também.

Adriano, me manda mp que a gente conversa sobre o Itaú. Menigma, sua sugestão é pra cobrar a mais do cliente no momento da geração do boleto ou é pra lançar a informação na transaction ao dar a baixa sem cobrar a mais do cliente? O Mauro Lino me mandou um email pedindo informações sobre configuração da API. Pra quem tiver a mesma dúvida, vejam esse tutorial de criação do usuário "API" no whmcs: https://www.gohigheris.com/documentation/integrator-3/ch12s03 No mais, abraços!

Daniel, tudo começou com a sua contribuição do script de leitura criado pelo Manuel... Confesso que eu não conseguiria fazer essa leitura do zero como ele fez. Essa funcionalidade eu acabei esquecendo de implementar, apesar de você ter me mandado o arquivo com suas modificações... Me manda por email as linhas que você fez pra eu implementar essa funcionalidade também? Resolvido! :-) Com certeza! Fiquei muito feliz com o resultado... Grande abraço e parabéns pra todos que contribuíram!

Pessoal, terminei agora a pouco a versão 0.2 desse script. Com a ajuda do DiegoFernando, consegui adaptar o script para se adequar à Caixa também. Testado com sucesso então no Bradesco e na Caixa! Acredito que o mesmo vá funcionar em outros bancos também... O arquivo original foi atualizado e a versão nova já está disponível no link da minha postagem anterior. Quem já tinha baixado, baixe denovo, ok? Aproveitei e fiz algumas outras alterações, como aumento da exatidão dos avisos, alteração do método de envio dos dados da visualização para a execução (antes tinha que enviar o arquivo duas vezes. Agora não precisa mais) e etc... Peço que testem bastante antes de colocar em produção... Aqui funcionou tudo belezinha, mas cada caso é um caso.... Qualquer falha, me avisem e eu corrijo.. Abraços!

Ele até funciona na Caixa, mas tem que fazer uns ajustes... Ele está funcionando perfeito mesmo é no Bradesco. Outros bancos eu não sei...

Isso é fácil de resolver. No arquivo "processar.php", vá nas linhas 274, 275 e 276 e descomente as 3. Vão aparecer todas as variáveis disponíveis no arquivo. Aí é só você modificar todas as variáveis que tenham "$vlinha" nesse arquivo. Se quiser me mandar um exemplo de RET da Caixa eu vejo pra você.

Atualizando aqui pra registrar que esse script foi disponibilizado em outro post aqui mesmo no PDH: http://portaldohost.com.br/forum/index.php?showtopic=9470&page=2#entry106980

A propósito, diego123, as linhas 253 e 254 do "processar.php" são as que tratam da "localização" do arquivo de retorno. 253. //$fileName = "retorno_cnab240.ret"; 254. $fileName = $_FILES['arquivo']['tmp_name']; Se você comentar a 254 e descomentar a 253, ele passa a processar o RET em um local específico, e ignora o que for mandado pelo formulário. Agora o seu problema é fazer ele saber qual arquivo deve processar. No Bradesco por exemplo, os arquivos se chamam CB270300.RET, CB260300.RET e etc... Onde eu acho que os 4 primeiros números seriam a dia e o ano de sua geração, mas não tenho certeza. Na caixa não sei como são esses nomes. Além disso, nesse caso deveria ser feito um relatório após o processamento e enviado por email ou deixado em algum lugar com as informações, para referência futura... E claro, o mais complicado, que seria a cron pra pegar o arquivo automaticamente do banco. Feito isso tudo, é moleza remover a entrada do formulário e a página de "validação" dos dados, deixando somente a de inserção. Mas eu particularmente prefiro rever os dados antes de inserí-los no whmcs. Então o processo acima não me agrada muito não, pq se der pal, eu só fico sabendo depois.

Oi Diego, tudo bem? Obrigado pela mensagem. Eu só testei ele no apache 2.2.24 e no PHP 5.3.23, usando dois arquivos de retorno do Bradesco. Aqui foi tudo belezinha, sem erros. Você quer me mandar um arquivo de retorno da CAIXA pra eu testar aqui? Ah, o PHP 5.2.17 já está marcado como "deprecated" hein... Eu sugeriria a atualização dele. No mais, o código está longe de ser uma obra de arte, e pode ter bugs sim... Mas pelo menos por aqui ele cumpriu com o que deveria. Abraços.

Há uns anos, encontrei aqui mesmo no PDH um rapaz que disse que tinha conseguido aplicar o arquivo de retorno no WHMCS, fazendo as baixas das faturas somente com o envio do retorno por um formulário. Feliz, porque já estava buscando isso há bastante tempo, baixei o arquivo que o rapaz teve muita boa vontade de fornecer gratuitamente, m,as infelizmente, o arquivo não funcionou porque havia uma falha na codificação que ele fez pra proteger seus créditos de direitos autorais. Não o culpo. Afinal, o que mais tem é gente que quer só sugar, sem acrescentar em nada nessa vida. Dessa época em diante, vi diversas pessoas tentando fazer esse script de retorno com o WHMCS, alguns conseguindo e cobrando por seus sistemas, outros desistindo ao longo do caminho por desmotivação, mas o pior: alguns CONSEGUINDO fazer os sistemas funcionarem, mas não divulgando-os. E assim fomos ficando sem o script, por causa do egoísmo daqueles que conseguiram criá-lo e não quiseram divulgá-lo, e da falta de respeito de outros em não manter nem mesmo o crédito de quem dedicou algumas (ou muitas) horas de seu tempo em criar aquilo de graça, fazendo com que até quem tinha boa vontade de publicar de graça, ficasse desmotivado em fazê-lo... Isso tudo foi o que mais me incentivou em entrar nesse projeto. Pensei por alguns segundos em cobrar por ele, afinal, dediquei pelo menos umas 20 horas nisso, mas aí lembrei da quantidade de scripts gratuitos que eu já usei nessa vida, além da boa vontade de diversas pessoas em fazer artigos e publicar dicas que eu sempre encontro pelo Google quando preciso de uma informação que não tenho. Então, divulgar isso de graça é o MÍNIMO que eu posso fazer pra retribuir. Esse deveria ser o pensamento de TODOS. Afinal, devemos SIM remunerar nosso trabalho, mas NÃO devemos esquecer da quantidade de coisa gratuita que a gente já usou, especialmente daquelas nas quais GANHAMOS dinheiro um dia. E assim é com muito prazer que eu publico aqui o script de retorno de boleto bancário do whmcs EM PRIMEIRA MÃO, DE GRAÇA, SEM CODIFICAÇÃO, totalmente OPEN, e torcendo pra que outras pessoas LEGAIS incrementem-o com funcionalidades e modificações necessárias: Faça o download aqui A instalação dele é bem fácil (tem tudo no arquivo "instalação.txt") e não acredito que seu uso vá ter algum mistério. Basicamente ele faz o seguinte: 1- Te dá um formulário pra você mandar o RET 2- Exibe os dados do RET pra você confirmar se os dados estão OK, e te notifica nessa tela se o valor do saldo da fatura for inferior ao pago no boleto, ou se a fatura já está marcada como "paid" no whmcs 3- Após seu OK, ele insere os dados no WHMCS, mas APENAS para as faturas que estão em aberto (Unpaid). Se a fatura estiver "Paid" ou "Cancelled", ele não insere aqueles dados e te notifica com uma mensagem em vermelho. 4- Caso a fatura esteja como "unpaid", mas seu "balance" seja inferior ao valor pago no boleto, ele aplica o valor integral pago, MAS ATENÇÃO, nesse caso o whmcs aplica um crédito pra esse cliente automaticamente. E claro, se quiser agradecer, faça um orçamento de algum serviço comigo. Vai ser um prazer lhe atender!

Oi diego123, tudo bem? Eu estou fazendo pra minha necessidade: 1- Usuário envia o RET manualmente através de um formulário 2- Os dados do RET são exibidos e o usuário confirma se devem ser aplicados no whmcs 3- Clicando em "aplicar", os dados são aplicados na API. Vou disponibilizar o resultado e quem quiser modificar, vai poder fazer a seu gosto. Mas é fácil fazê-lo ler o arquivo no servidor. Eu ajudo indicando o caminho disso sem problemas... O difícil vai ser puxar ele do banco e colocar na pasta, além de fazer o script identificar qual RET deve executar... No bradesco, por exemplo, cada RET tem um nome diferente, que me parece ser a data, mas sem o ano... Ah, e ainda no bradesco, o acesso pra pegar o RET é difícil e envolve diversas senhas pelo NET Empresa. Não sei exatamente se eles disponibilizam uma forma mais fácil pra fazer isso... mas a minha idéia inicial é tornar pelo menos SEMI AUTOMATICO. E é isso que eu vou disponibilizar primeiro, ok? Estou tendo sucesso por aqui. Aguardem. Abraços.

Primeiramente, diego123 e redirect, obrigado pelas contribuições. diego123, você conseguiu fazer exatamente a parte que eu estava enrolando pra fazer... O que eu consegui até hoje foi pegar os arquivos que o danielvisnet forneceu no início do tópico e exibir os dados do arquivo de retorno em variáveis PHP. Agora que a inserção dos dados está pronta via API (fiz apenas algumas modificações no código do diego123, como incluir a variável de valor pago, data e etc), fazer a integração das variáveis que eu já tinha feito, com a api vai ser moleza :-) Acho que hoje ainda consigo disponibilizar algo... Retorno assim que tiver algo. Abraços e mais uma vez obrigado a todos que contribuiram.

Galera, tudo parece muito simples... O pessoal que fez esse script arrebentou! Nos deram tudo pronto, praticamente. O pior já passou, que era a organização dos dados do arquivo RET em formas humanamente compreensíveis... Rssss. Como o Daniel mesmo falou, agora só precisamos integrar isso ao WHMCS. E eu topo a tarefa! =) Alguém quer dividir comigo esse tempo? O que eu consegui até agora: O arquivo "processar.php" é o que nos dá o resultado todo. É nele que precisamos começar o trabalho. E o melhor de tudo é que ele está todo comentado... Então, consegui definir pra ele me exibir apenas os dados que eu quero (algo simples, que já existe no arquivo, na verdade, bastando "descomentar" uma linha e comentar outra). Depois, comecei a buscar uma forma de inserir esses dados diretamente no banco, marcando as cobranças como "paid". Parecia o mais simples, mas não seria, porque as ações decorrentes de um pagamento, como tirar suspensão, mudar data de vencimento da próxima fatura e etc, teriam que ser todas refeitas diretamente no banco. Então, recorri ao API: http://docs.whmcs.co...Invoice_Payment E agora estou trabalhando em tentar colocar as variáveis no API... Se alguém quiser me ajudar, me mande MP!

Bom, se está dando certo na nova estrutura, que continue dando certo... E que você não tenha mais dor-de-cabeça. ;-) Sucesso.

Oi Paulo, Também gostei de sua resposta. Levanta pontos interessantes, mas que pra mim são fáceis de se responder. Desde já, deixo claro que esse é o meu entendimento pessoal, que em nada tem a ver com fatos oficiais da Netrevenda (até porque não os tenho). São apenas suposições do que eu imagino que ocorreu, coisas que pra mim são um tanto quanto simples de se concluir após mais de 7 anos trabalhando com hospedagem e já tendo passado por quase tudo um pouco. De fato, mas pelo que eu entendi em seu relato, o ataque final foi muito superior aos ataques iniciais. Provavelmente a intensidade dos ataques iniciais poderia ser mitigada na solução que lhe apresentaram. Possivelmente até foi mitigada em um primeiro momento após a contratação para a nova solução, mas o atacante deve ter intensificado mais o ataque até o ponto que a proteção deles não suportou mitigar mais. E aí seria necessário mais investimento, algo comercialmente inviável pelo valor que você pagava à eles (algo em torno de R$ 500,00 mensais, suponho). Enfim, você já entendeu o quadro. Isso é simples: se o ataque era direcionado à sua empresa, é o domínio que é o alvo, não o IP. Mudou o IP do domínio, o ataque muda junto e o IP anterior é esquecido pelo atacante. Se era ataque à porta 80, é esse o motivo do IP funcionar e do apache não poder ser retomado. É até engraçado você citar isso porque só comprova mais ainda o que eles alegaram. Se fosse problema de rede, os Ips ficariam fora mesmo com o apache offline. E até se o problema não fosse um ataque direcionado ao seu domínio (ou à um de seus clientes), ele não voltaria tão rapidamente após você mudar o domínio pra outro IP. O atacante pode ter dado um tempo ou pode não ter o mesmo poder de ação nos EUA, já que aqui a rede em geral possui menor capacidade do que lá fora. Agora, tenha cuidado. O datacenter onde você está não possui boa reputação e pode lhe deixar na mão caso você sofra, de fato, um ataque. É mesmo estranho não terem lhe fornecido gráficos do roteador. Eu tenho experiência pessoal com dois clouds não-gerenciados na estrutura deles há cerca de 1 ano. Em questão de disponibilidade e estabilidade de hardware e rede, fora os problemas de dezembro, não tenho do que reclamar. Confesso que não lembro nenhuma vez que houve indisponibilidade nesses serviços. Quanto ao gerenciamento, não tenho base pra falar porque nunca usei. Software eu e minha equipe gerenciamos por conta própria. Mas é aquele negócio: todo produto / serviço atende à uns e não atende à outros. É assim em todo lugar, desde coca-cola / pepsi até automóveis. No geral, ocorre o que eu falei com relação à reclamações e eu vejo a Netrevenda usando isso muito bem. Acho, inclusive, muito estranho qualquer empresa querer mandar um cliente embora (seja ele reclamão ou não) sem um motivo grave, Mais estranho ainda é essa empresa deixar um cliente adimplente (suponho que você mantinha suas mensalidades em dia) offline por tanto tempo quando não havia nenhum ataque real, se partirmos da premissa que as alegações de ataque eram mentira, como você imagina. O que eles ganhariam com isso? Por fim, a grande pergunta que ninguém fez: você, por acaso, possui algum desafeto que poderia ter interesse em lhe realizar um ataque? Se não possui, você tem algum cliente que talvez possua? Um fórum de cheats, jogos, site bolão virtual e etc? Para nós dois!. =)

Não sei não, mas tenho certeza que tem muita meia verdade sendo contada por aqui. Todo mundo aqui já brincou de telefone sem fio quando era criança, não é mesmo? Pois bem... Primeiramente, supondo que tudo o que o Paulo falou seja a mais pura verdade sem nenhuma distorção, inclusive sendo verdade tudo o que a Netrevenda passou pra ele, se imaginem na cadeira do proprietário da Netrevenda no meio dessa confusão. O quadro é: Sua empresa está com trocentos clientes offline por conta de um ataque gigantesco direcionado à um único cliente. Esse cliente, apesar de estar sendo feito tudo que é possível para mantê-lo online dentro das condições comerciais existentes (leia aqui "valor que esse cliente paga pelo serviço"), passa a reclamar publicamente (com razão), não por uma falha sua ou da sua equipe, mas sim por causa de algum inimigo que ele próprio criou na Internet. O que você faria? Continuaria esmurrando ponta de faca? Serei bem claro em minha visão, até mesmo saindo um pouco da posição de neutralidade que há algum tempo eu me impus em fóruns como esse: Se o meu cliente prejudica outros clientes meus de qualquer forma, não penso duas vezes em pedir educadamente que procure outro serviço. Não porque não consigo mantê-lo ou por que ele reclama aqui e ali, mas sim em respeito aos meus outros clientes. Tentar manter um cliente que gera problemas de queda (sendo ele o culpado pelo problema ou não) só gera mais problema. Quem mantém o cliente a qualquer custo é ganancioso e somente o faz porque não quer perder o lucro que esse cliente lhe trás. E o pensamento desse pessoal com relação aos demais clientes? "Ah, bem, eles que segurem um pouco as pontas até eu conseguir normalizar..." Simples assim. Na prática, numa boa, DUVIDO que qualquer um aqui agiria de forma diferente. Dito isso, tenho CERTEZA que o maior motivo pro cancelamento do contrato foi o fato da empresa do Paulo ser o alvo do ataque e não as reclamações públicas. Vi DIVERSOS outros clientes reclamando em seus Twitters de formas até grosseiras e ignorantes (com razão) e recebendo respostas cordiais do Twitter oficial da Netrevenda e do Twitter pessoal de seu proprietário. Duvido muito que eles tenham cancelado o contrato desse pessoal todo. Até porque, reclamação pública é uma ÓTIMA forma de publicidade... E bem mais barata que as formas convencionais. Pensem comigo: qual a sensação que vocês têm quando uma reclamação é resolvida? E o que toda empresa faz quando recebe uma reclamação pública? Responde e resolve, não é mesmo? O único mal da reclamação pública é quando ela não é respondida. Mas é exatamente pra isso que as empresas estão no Twitter. As pessoas reclamam e as empresas respondem. Publicidade de graça. ;-) Pra finalizar, sobre a localização do proprietário da Netrevenda, o que me espantou foi ver em seu Twitter em pleno domingo, enquanto o próprio site da empresa ainda estava offline, que ele estava comendo lagosta na praia. Mas, passado o espanto, vamos raciocinar: As férias já estavam planejadas e ele já estava em outro estado há muitos quilômetros de distância da empresa quando o problema ocorreu. Era véspera de reveillon. Imagine a dificuldade de conseguir um vôo às pressas pra voltar pra São Paulo. O que fazer, então, tendo um smartphone na mão pra acompanhar tudo e sabendo que tem gente na empresa resolvendo o problema? Eu, no lugar dele, acharia essencial parar as férias e ir pra SP, já que pelo que me pareceu, a empresa toda estava offline. Por outro lado, seria bom (pra mim, pros funcionários e principalmente pros clientes) saber que a empresa funciona sem mim. Bom, esses são os pontos que eu identifiquei ao longo desses dias que "pescocei" a situação. Pra mim, isso tudo faz muito sentido, diferente de alguns outros comentários que eu li no restante do tópico. Mas esse é o objetivo do fórum mesmo: trocar idéias e opiniões. No mais, desejo sucesso ao Paulo e sucesso à Netrevenda nesse ano de 2012.

A lógica é a mesma do cPanel então. Quem já usa cPanel não terá problema com isso. O Plesk, por exemplo, têm a opção de limitar o espaço de banco de dados. O cPanel, não. Mas tudo bem... Por mim, quanto mais semelhante a lógica for, melhor. Mais fácil de treinar o suporte, mais fácil de atender o cliente.

E irritante, diga-se de passagem. Por que? Isso já era de se esperar por ser lançamento. Mas como o Plesk também não tem a tradução, não tem o que comparar. Na verdade o Plesk até perde nisso na minha avaliação, pois há 6 anos uso ele e só tive o suporte ao português em uma das primeiras versões, menos de 6 meses. Até hoje espero a tradução das demais versões... Você migrou os clientes do Plesk para ele ou usou o Enkompass apenas para novos clientes?