nightfly

Сам в шоке Ну оно же для людей сделано.... Хотелось бы надеяться... Удачки

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

Нафиг. По поводу средств полученых за водку и подключения вполне себе описано в FAQ. Вполне логично оформлять их как "фиктивный платеж" - их будете видеть и вы, и абонент в кабинете и на счет они не попадут. По поводу "месяц бесплатно" - это уже вам решать настоколько это будет "месяц" и как вы его будете вносить (натуральный платеж/корректировка/фиктивный) и будете ли вносить вообще (халява до конца месяца).

и тем более использовать в 2013-м году для авторизации что-то кроме нормального IPoE.... Ласково намекаешь, на вышедший недавно HTC One? P.S. обязуюсь оптимизировать работу убиллинга под safari если мне предоставят mac pro

Враховуючи адвайсність ави, чогось такого:

Она другого цвета и вероисповедания? Ну и что? Нисколько. Коммерческая поддержка осуществляется только для софтбоксов/NAS на базе FreeBSD. Еще разочек для приличия потыкаю в документацию, где максимально подробно рассмотрены вопросы взаимодействия с Mikrotik.

ENG Please stop ignoring fucking documentation - it was not written just for beauty or something like this shit. All of questions that you are asked - clearly described in the wiki.

Пасибоньки - поймал 100% Давно желал сделать человекообразную импортилку абонбаз из сторонних продуктов - теперь, вот - мотиватор есть

Так по дефолту и есть. Я не знаю почему человек сам накрутил себе так снятие абонплаты, после чего удивляется "ой мама чтойта за цифры". По ГСТУ учет производиться до 9-го знака. Не отображать реальное состояние счета - мягко говоря мудацтво, а также чревато последующими разборками на тему "а почему у абонента на счету 0 денег а он всеравно не работает?". С другой стороны в FAQ вполне себе четко, обозначена наша позиция по поводу таких штук как FullFee = no и SpreadFee=yes. Подразумевается, что те, кто пытается это использовать - представляют себе последствия такого подхода (тобишь ухода от дефолтной модели начисления АП) и готовы к ним. В противном случае - ССЗБ.

Че ж вы windows 95 не используете? Там тоже все работает. Зачем обновляться? 2 madf Не, не поможет. Их в принципе не будут читать. Также как и другую документацию. Закончится также как и всегда - адекватным кастомерам будет продаваться адекватный саппорт, а неадекватные и нищие дальше будут ныть по форумам, с наивными ожиданиями/претензиями, что девелопер просто обязан бесплатно вытирать им сопли и конечно же самолично им строить свой солюшн. При этом будучи безмерно благодарным конечно же.

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

Походу нет - там все модуля нарисованы как $this->registerModule($module, 'main', ...

kill -1 `cat /var/run/stargazer.pid` попробуйте

#use DN online detection? DN_ONLINE_LINKING="YES" В обновляторе

В данном контексте - выглядит единственным хоть немного адекватным.

Скриптом. Только это будет "плохой ноль" - что опять же попахивает шизофренией.

Если речь идет о DN_ONLINE_DETECT=1, то возникает резонный вопрос - а что у вас лежит в billing/content/dn?

Искренне надеялся, что вы самостоятельно догадаетесь по дням покликать. Но нет, видать не судьба. Куда уж "детальнее"?

То ничего, что в профиле пользователя, есть еще модуль отображающий детальную стату?

В норме да - но вы ж то их за ноль морозить собрались? Значит они - прокляты. Я тоже неответственный и ленивый - почему-то мне за это бабла никто не дарит Поэтому я "место" и в кавычках написал в изначальном посте. Есть еще и люди которые должны следить за живостью сети в доме абонента, и електричество которое хавается серверами доступа, купленными к слову для того чтобы нормально обслуживать этого абонента, есть еще зарплата уборщицы которая убирает в офисе , есть еще кондиционеры и кофе для работников, в конце концов затраты на внешние аплинки и зарплата саппортам/менеджерам/бухам - и это тоже только несколько из многих затратных статей из которых и должна формироваться себестоимость услуги. Если абонент "поехал в отпуск" - вы же не сокращаете эти затратные механизмы? Значит ваши расходы остаются приблизительно одинаковыми - и платить за них, чисто по логике вещей должен либо абонент, либо абонент. Что? Сокращаете? А как? Перестаете пользоваться кондиционером и урезаете зарплату уборщице? Вот видите, вы уже все знаете, что я собирался вещать Потому, что его в принципе нет. Как и для прочих административных проблем - нету адекватных технических решений. Тоесть решение, то могу придумать - например ввести такое понятие как "два разных ноля на счету". Типа один "хороший ноль" при котором услуга предоставляется, а второй, типа "плохой ноль" при котором абоненту АП не начисляется и услуга не предоставляется. Но согласитесь - это мягко говоря шизофренией попахивает.

далеко не факт насколько я понимаю механику старгейзера - оно будет просто переставать начислять АП и пользователь останется с чем-то типа -1,612903225806452 на счету. А у абонента не может быть просто ноля на счету? Это, что проклятая цифра и абонент должен нести за нее наказание? Да - и это будет мудацтвом в независимости от реализации. Да - принять для себя тот факт, что вы предоставляете услугу за которую абонент обязан вам платить. Если абонент временно не пользуется услугой - это его забота оповестить провайдера о этом факте, простым нажиманием одной(!) кнопочки в ЛК либо телефонным звонком. В любом случае я не знаю, что вы понимаете под "себестоимостью" услуги, но подозреваю что вы не учитываете того факта, что пока абонент пусть даже и не работает - вы все равно несете затраты из своего кармана на резервирование под него "места". Думаю корень всех ваших "проблем" кроется только в этом. ЗЫ ну вы уже сами знаете, что я должен был бы сказать в конце?

Думаю при помощи FeeChargeType вы таки не выкрутитесь. При FeeChargeType=1 вы получите на счету всеравно "минус" в размере как минимум суточной АП, а при FeeChargeType=2 - просто подарите абонентам вечные безлимиты. Так что если абонент не потрудился "отморозиться" вовремя - он сам себе злобная буратина. Вы не можете себе позволить обзванивать каждое тело, чтобы узнать "а часом не умер ли ты дружок?".

Морозить абонентов, не? А морозилку так же как и попрошайку можно сделать еще и платной....

"Авторизатор" це трохи не те. Загалом забудьте про це - нормально визначити наскільки користувач "онлайн" в 2013 році практично не можливо. DN_ONLINE_DETECT взагалі призначено для того, щоб мати уявлення - виконався для користувача OnConnect чи ні.