Моё решение. Поставил в месяц минимальный трафик 30 Мб . То есть, если клиент ушёл в минус и не пользуется инетом целый месяц, ему этот месяц не засчитывается. А дальше вот такой финт: если клиент в минусе, то при пополнении счёта начало услуги переносится на дату оплаты. То есть, если у клиента закончились деньги и он пару недель не пополнялся (оно ему было не надо), эти две недели не учитываются, и отсчёт нового месяца пойдёт с даты оплаты.

Не настолько сильно отличаются конфиги, чтобы не было понятно, как его настроить. Параметры для настройки нужно прописать те-же самые, что и в 1-й версии. Ищете, меняете на нужные вам значения. Если что непонятно - читаете man.

в группах появилась галочка "второстепенная группа". Теперь группы делятся на 2 категории "клиенты" и "иные". Иные - я не даю конкретного названия, потому что в "иные" можно перенести, например, Администраторов. А можно перенести оборудование как я сделал в своей бывшей сети.

Как добавлять во второстепенные группы? Или это ещё не выложено на svn?

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

Точно! При установке нового биллинга я обратил внимание, что в доке не прописана обработка дисконнекта. Однако, в старом биллинге этот параметр у меня был включен и всё работало как надо, поэтому я оставил настройки без изменения, предположив, что в доке нового биллинга просто потерялась последняя строчка при копипасте настроек.
Вобщем, сам виноват. Спасибо за подсказку!

Наблюдаю странное. У тех, кто не в онлайне, отсутствуют данные о сеансах подключений. А у подключенных - в сеансах подключений только одна запись (текущее подключение). Хотя по графикам трафика видно, что люди в интернет заходили не только вот прямо сейчас, но и раньше были сеансы - сегодня, вчера, позавчера.

Складывается такое впечатление, что после окончания сеанса запись о нём не сохраняется. Из-за чего такое может быть? Что проверить, где подправить?

Сделаешь чтоб и сам админ мог видеть свои личные платежи тоже?

А ещё лучше, чтобы админ мог выбрать, чьи платежи ему посмотреть - все, свои, админа такого-то...

Согласен можно и так, только как-то название "Бонусный платеж" с минусом не красиво выглядит или это только мне так кажется?

Не только тебе. Я везде попереименовывал "Бонусный платёж" в "Безналичный платёж" и "Безнал" - теперь выглядит более осмысленно.

Правда, задалбывает после каждого обновления править файлы биллинга. А делать это приходится, т.к. текст не вынесен в языковые файлы.

"Новая новость": мы тут посмотрели на текущий N+ и поняли, что хорошо повыносили функционал в модули. Т.е. на "голом" N+ работать можно, но профессионалам нужны модули.  Поэтому возвращаемся к старой схеме: N+ скоро станет бесплатным и мы будем зарабатывать только на модулях. Ура, ура. Благодаря, вам, кстати - пришло время похвалить, сейчас вы действительно покупаете модули. Предварительная дата объявления N+ бесплатным - 1 октября 2013.

Модули подорожают?

Так и не понял, как поступать с 1-м числом в Nodeny+ если припадает на праздники?

Мы вот тоже с 1-го числа полностью перешли на Н+. И тоже есть недовольные клиенты. Стараемся относиться к этому философски - недовольные будут всегда, даже если у вас всё идеально. Ведём разъяснительную работу. Лучше месяц-другой потратить на объяснения, чтобы дальше спокойно работать. Были пару человек, которые сказали - сделайте как раньше, иначе уйдём к другим провайдерам. Не ушли. Оба заплатили. Один правда, буркнул что-то типа:"Вы гады, но интернет у вас лучше, чем у других"

У нас периоды начинаются не с 1 числа месяца, а с того числа, когда клиент заплатил. Мы считаем, что так лучше - и деньги равномерно поступают, и оператор на приёме платежей не перенапрягается в конце месяца, работая с одинаковой загрузкой во все дни.

Чтобы клиент не забывал заплатить - за 5 дней до конца его периода заглушка выдаёт предупреждение о том, что ему через 5 дней отрубит интернет и нужно заплатить не менее такой-то суммы денег, чтобы этого не произошло. Большинству вменяемых клиентов этого срока хватает, чтобы заплатить.

Однако, бывает, что человек в этот момент был в отпуске/командировке/на учёбе и заплатить всё-таки не успел. В этом случае он прямо по ссылке с той-же заглушки идёт в модуль кредита и оформляет себе бесплатный кредит на 5 дней.

Если с такими подсказками и кредитами клиент сумеет остаться без интернета, то он сам в этом виноват.

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

Вобщем, включайте заглушку, включайте кредиты - и вам не страшны никакие праздники 1-го числа.

Такую "штуку" я могу реализовать если ты расскажешь как она будет работать). Применять обычный патч - это делать не буду т.к. код может меняться и будут патчи только к определенной ревизии.

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

Ведь от замены
[ 'бонусы'              => 'p.category=2'   ],
на
[ 'безналичный платёж'          => 'p.category=2'   ],
код не перестанет работать.

А таких исправлений лично у меня довольно много. Как-то так сложилось, что у нас с вами одно и то-же обзывается немного разными словами. И ввиду отсутствия языковых файлов, приходится вносить исправления прямо в коде

Думаю, для поддержания принятой системы исправлений, правки должны вноситься только в фантомные файлы, а если для нужного файла фантома ещё нет - он должен создаваться.

уже есть такая фича

Ясно, спасибо.

Другой вопрос. У меня есть куча исправлений вот такого рода:
[ 'бонусы'              => 'p.category=2'   ],
меняю на
[ 'безналичный платёж'          => 'p.category=2'   ],

или
my $for_adm = _('[] [] [] [] []', Adm->get($from_adm)->admin, $cash, $cfg::gr, $msg, Adm->get($to_adm)->admin);
на
my $for_adm = _('[] [] [] [] []', Adm->get($from_adm)->admin, $msg, $cash, $cfg::gr, Adm->get($to_adm)->admin);

Можно, конечно, использовать для таких замен diff/patch, но лучше, если такая штука будет сразу встроена в install.pl.

И сразу ещё вопрос - планируете-ли вынести весь текст в отдельные языковые файлы?

А где такой сервак можно купить? Желательно б/у)

Например, здесь:

httр://local.com.ua/forum/forum/143-торговля-серверное-оборудование

или здесь:

httр://aukro.ua/setevoe-oborudovanie-servery-144646

возможно обьединение с другими районами, вот и думаю на будущее, например при обьединении будет около 3к абонентов

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

Поддержу ваше ИМХО своим. Лучше поставить рядом ещё один сервер и разделить нагрузку пополам.

Серверное железо, конечно, надёжное, но тоже выходит из строя. И когда это случается - запчасти к нему в любом компьютерном магазине не купишь. Приходится заказывать издалека. И пока оно доедет - все эти 3к абонентов будут звонить и ругаться. Кто-то уйдёт к конкурентам.

Так что, лучше иметь два сервера.

Я тут активно правлю Н+ под свои требования, и столкнулся с тем, что одни и те-же файлы правятся не только у меня, но и в модулях других разработчиков.
А поскольку код я перепахиваю довольно сильно, простыми вставками в район хуков не обойтись - приходится делать new.

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

Допустим, ввести ещё один необязательный параметр order:
#<ACTION> file=>'web/users.pl',hook=>'new',order=>'2'
Чем меньше число, тем раньше загружать модуль. При отсутствии параметра считать его равным, допустим, 100.

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

Проблема не в гироскопе. Он довольно точный, + акселерометр подкорректирует его значения. Фишка именно в том, что ПИД управлятор двигателями не может реализовать то, что мы хотим получить: жесткую реакцию без перелета как при пассажире, так и без него

А ваш ПИД инерцию учитывает? Чтобы не было перелёта, при подходе к расчётной точке равновесия надо не просто уменьшать управляющее воздействие, а заранее включать его в обратном направлении, пока система под действием инерции не сместится в точку равновесия.