Биллинг

Тоже использовал все 4 их списка панелей (правда ава-панель совсем давно и чуть-чуть), но когда нужно было делать новый проект, решили использовать BILLmanager:

1) Нормальная работа с российскими юрлицами: счета, акты, договоры умеют генерироваться автоматически.

2) Относительно поддержки ава-панели, рутпанели и поддержки у тогдашнего единственного русского дилера http://whm-cs.ru/ BILLmanager очень сильно выигрывает.

3) Рутпанель не расширялась очевидным способом без покупки полной лицензии с открытым исходником. А покупать для доработки исходник панели, в которой через месяц находят критические дыры -- странное занятие.

4) Whmcs очень неудобно выглядит, если у клиента > 10-20 услуг.

Но у BILLmanager

1) Абсолютно убогая тикетница, невозможность адекватной интеграции со сторонней тикетницей (так как часть биллинга завязана на использовании именно встроенной тикетницы), невозможнсть нормально забирать почту с ящика для тикетницы (вырезая HTML, принимая автоматически письма не от зарегистрированных клиентов и т.д.).

2) Ранее озвученные апдейты.

3) Для кого-то может быть минусом требование отдельного VPS/Сервера под биллинг.

Кстати, если потратить пару месяцев на желание разобраться, по писать под BILLmanager становится просто, потому что почти всё выдержано в одном стиле и имеет некоторую свою логику.

---------- Добавлено 29.01.2012 в 04:57 ----------

У самописного биллинга на начальном этапе будет намного больше проблем чем у любого из предложенных.

В данный момент мы разрабатываем собственный биллинг на Java/Groovy. Модулей к нему сейчас почти нет (на данный момент только ispamanager и virtuozzo), но мы напишем любые модули на заказ.

Из минусов:

- На данный момент довольно сложная установка.

- Потребляет много памяти (около 256 мб)

Из плюсов:

- Высокая производительность. Хоть 10 тысяч клиентов в онлайне - проблем не будет, в том числе с нагрузкой на базу (при наличии более-менее адекватного железа, конечно же)

- Надёжность и безопасность. Таких глупых уязвимостей, как в WHMCS, нет.

- Низкая стоимость. Мы готовы предоставлять биллинг бесплатно при условии сохранения наших копирайтов или за деньги с предоставлением полного исходного кода.

- Будут доступны простые и понятные API, с помощью которых вы сможете написать модули любой сложности к любой из систем биллинга (серверы, платёжные системы, система уведомлений, система поддержки)

- "Умная" локализация. Если ваш клиент говорит по английски - биллинг будет для него на английском.

- Программируемые шаблоны уведомлений

- Кроссплатформенность. Всё будет работать одинаково хорошо как линуксе, так и на винде. Никакого cron'а и других специфичных вещей не требуется.

- Поддержка множества различных баз данных. Полный список здесь https://community.jboss.org/wiki/SupportedDatabases2

- Мультитредовость. В большинстве биллингов на php не используются ни отложенные задачи, ни какие-либо инструменты для выполнения задач в фоне. В итоге при заказе услуг клиенту или платёжной системе во время уведомления о платеже приходится ждать выполнения скрипта, занимающегося созданием аккаунта или отправкой почты через удалённый сервер. Это чревато проблемами, но в нашем биллинге они исключены.

ArtemZ Вы последний пункт уберите. А то звучит по-детски.

Мультитредовость биллингу особо не нужна, если его бекенд база данных.

Сервер Apache обеспечит "мультитредовость" или скорее мультизадачность, а синхронизацией данных должна заниматься БД. Если структура БД верная, то и тормозить при "уведомлении об оплате" ничего не будет, т.к. все они будут в разных запросах апача или чего там на фронтенде стоит.

Ждать и тем и другим придется, потому что действия что Вы описали должны быть последовательными.

БД тут вообще не при чём. Блокировки, возникающие вней, на процессы в апаче не влияют, да. Я говорю про случаи, когда при уведомлении об оплате происходит обращение к удалённому серверу (ispmanager, directadmin, регистратор доменов и т.п), это обращение вызывает блокировку, которую ждёт весь скрипт, а вместе с ним и клиент.

Нормальная у них поддержка и адекватно отвечает.

Певый уровень поддежки конечно же не всегда может помочь, а вот при передаче запроса дальше, он уже решается и вполне адекватно.

На данный момент у них есть модуль только для импорта данных из Joonta, который ещё дорабатывает.

А в чём проблема написать свой собственный?

Нет ни какой дикой нагрузке, о которой Вы говорите, даже при большом кол-ве онлайн клиентов.

Или может быть вы его запускали на VDS, с парой сотней мегагерц и 100 метрами ОЗУ?

Вот кстате еще одна (проблема|минус|ошибочное мнение) как isp так и ее сторонников. Что клиент, купив готовый продукт обязан чето там дописывать, исправлять, ковырять и т.д. И заметьте, панель не на php написана и не много найдется людей, которые способны исправить проблему.

Я говорил про написание модуля для импорта данных из других биллингов, под которые ISPsystem ещё не разрабатывала модуль импорта, т.е. в данном случае на сколько я понял речь идёт о whmcs.

В этом случае да, но согласитесь, есть такое у isp, что предлагают самому переписать, дописать, исправить, причем даже если это бага панели, а сами не спешат ничего править, вплоть до критических уязвимостей.

как раз на stable , скуль умеем жарить :)

---------- Добавлено 29.01.2012 в 14:04 ----------

+ недавно словили 2 критических бага, известили разработчиков , пока тишина

---------- Добавлено 29.01.2012 в 14:05 ----------

как раз они написали модуль, whmcs rootpanel и joonte

написали криво

---------- Добавлено 29.01.2012 в 14:09 ----------

дада перекидывают между отделами....

запускали скуль на таком сервере:

HP DL165G7

2x Opteron 6164 HE, 24 Cores (2x12)

12 GB DDR3-RAM ECC

2x 1,000 GB SATA II

RAID 1

это вы считаете ведро с 100 метрами? :)

Я конечно извиняюсь, но никде не увидел замечаний по поводу отсутствия у Bill манагера модулей к распространенным панелям управления виртуальными машмнами- есть только ВДС менеджер и виртузо. Мы как раз собираемся переходить на новый биллинг- и, по сути, только из-за этого от Bill Manager и отказались. Решили ставить WHMCS - там и HyperVM и SolusVM