Перейти к содержимому
Local
AoW

Вопрос по тарифам

Рекомендованные сообщения

Возможно ли следующее?

Итак:

Снятие денег за весь месяц на перед.

Если на счету абонента денег меньше чем его тарифный план по состоянию на 1 число - абонент отключается автоматически.

После пополнения на необходимую сумму - абонент остается активным 30 дней.

Никакого минуса, только кредит доверия в 3 дня.

Если абонент пополнил счет 10 числа - работает до 10 числа следующего месяца.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно ли следующее?

Итак:

Снятие денег за весь месяц на перед.

Если на счету абонента денег меньше чем его тарифный план по состоянию на 1 число - абонент отключается автоматически.

После пополнения на необходимую сумму - абонент остается активным 30 дней.

Никакого минуса, только кредит доверия в 3 дня.

Если абонент пополнил счет 10 числа - работает до 10 числа следующего месяца.

"Снятие денег на месяц вперед" - стандартная логика Stargazer'а.

"Если на счету абонента денег меньше чем его тарифный план по состоянию на 1 число - абонент отключается автоматически" - как-бы так оно и есть, но, видимо, предполагается "без снятия абонплаты". Для этого смотреть в сторону FeeChargeType, но для безлимитных тарифов работать не будет (не будет отключать абонента).

"Никакого минуса, только кредит доверия в 3 дня" - что за "кредит доверия"?

По поводу остального: Stargazer предусматривает только фиксированный период тарификации, сделать плавающий в нем возможно только с помощью ежедневного снятия абонплаты, но тут есть свои проблемы, о которых подробно может рассказать nighfly :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Значение 2

следует использовать с осторожностью, т. к. при этом на безлимитных

тарифах абоненты получат услугу бесплатно

 

Вот это вот не понял.

Можно ответ от разработчика?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Никакого минуса, только кредит доверия в 3 дня" - что за "кредит доверия"?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для этого смотреть в сторону FeeChargeType, но для безлимитных тарифов работать не будет (не будет отключать абонента).

Абонплата снялась, на следующий месяц абонплаты не достаточно, абонент заблокировался

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Значение 2

следует использовать с осторожностью, т. к. при этом на безлимитных

тарифах абоненты получат услугу бесплатно

 

Вот это вот не понял.

Можно ответ от разработчика?

Абонплата не будет снята, абонент не уйдет в "минус" и не будет отключен. И будет продолжать пользоваться услугой вечно :)

 

Для этого смотреть в сторону FeeChargeType, но для безлимитных тарифов работать не будет (не будет отключать абонента).

Абонплата снялась, на следующий месяц абонплаты не достаточно, абонент заблокировался

Абонент блокируется только если у него отрицательный баланс.

 

"Никакого минуса, только кредит доверия в 3 дня" - что за "кредит доверия"?

 

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

Stargazer не оперирует временем, он оперирует деньгами. Хотя такое можно реализовать с помощью внешних скриптов и crond/atd.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если абонент пополнил счет 10 числа - работает до 10 числа следующего месяца.

 

вот это тоже интересует, возможность реализации.

Выход, который нашёл на данный момент-ежедневное снятие абонплаты.

Обсуждалось с nightfly : http://local.com.ua/...post__p__345917

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если абонент пополнил счет 10 числа - работает до 10 числа следующего месяца.

 

вот это тоже интересует, возможность реализации.

Выход, который нашёл на данный момент-ежедневное снятие абонплаты.

Обсуждалось с nightfly : http://local.com.ua/...post__p__345917

Я уже выше писал - Stargazer умеет только фиксированный период тарификации.

В прочем, можно абонплату и руками снимать. Тобишь, скриптами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Абонплата не будет снята, абонент не уйдет в "минус" и не будет отключен. И будет продолжать пользоваться услугой вечно :)

 

 

Присоединяюсь. Можнов последующих версиях (а лучше патч к этой :) ) добавить опцию, в случае включения которой, абоненту бы проставлялись признаки отключен/заморожен, если для снятия абонплаты недостаточно средств. При этом сама абонплата не снималась бы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Абонплата не будет снята, абонент не уйдет в "минус" и не будет отключен. И будет продолжать пользоваться услугой вечно :)

 

 

Присоединяюсь. Можнов последующих версиях (а лучше патч к этой :) ) добавить опцию, в случае включения которой, абоненту бы проставлялись признаки отключен/заморожен, если для снятия абонплаты недостаточно средств. При этом сама абонплата не снималась бы.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Особенно актуально на начало сезона отпусков.

Тоесть уже не актуально :)

 

...кстати в своё время мне приходилось реализовать...

За скриптовыми подпорками будущее! ;)

 

nicepony.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

дабы не плодить новых тем. 

stargazer 2.408

абонплата снимается каждый день, т.е.

SpreadFee = yes

 

имеет ли значение в таком случае параметр FeeChargeType ???

 

Задача следующая:

хочу ввести карточки пополнения. Но возникает проблема: у абонентов счёт уходит в минус и постепенно этот минус накапливается если абонент не пополняет счёт. Мне необходимо сделать чтобы абонплата, после того как у абонента 0 на счету не снималась и есесно инет не работал. Чтобы в последствии при пополнении карточкой счёт нормально пополнился...

А так получается у абонента например на счету -25 грн. пополнил он карточкой 60 грн... и на счету теперь 35 грн... а не 60...

Можно ли как то это решить?

Изменено пользователем felixio_01

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Морозилка у меня и так платная, хотелось бы не через неё, так как сниматься будет опредлённая сумма. типа за мороз )))

Изменено пользователем felixio_01

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю при помощи FeeChargeType вы таки не выкрутитесь.

При FeeChargeType=1 вы получите на счету всеравно "минус" в размере как минимум суточной АП, а при FeeChargeType=2 - просто подарите абонентам вечные безлимиты.

Так что если абонент не потрудился "отморозиться" вовремя - он сам себе злобная буратина. Вы не можете себе позволить обзванивать каждое тело, чтобы узнать "а часом не умер ли ты дружок?".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

аха....

FeeChargeType=1   меньшее из зол, мне нужно было узнать именно про этот вариант (это первый вариант), т.е. как оно будет влиять.

вариант FeeChargeType=2 я не рассматривал. 

если же сумму за заморозку выставить 0 грн. можно ли сделать чтоб когда на счету ноль, он автоматом морозился??? (это второй вариант) Я так понимаю скриптами?

 

Должен быть третий ))))))))) самый идиальный ....

Изменено пользователем felixio_01

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FeeChargeType=1   меньшее из зол,

далеко не факт

 

т.е. как оно будет влиять.

насколько я понимаю механику старгейзера - оно будет просто переставать начислять АП и пользователь останется с чем-то типа -1,612903225806452 на счету.

 

можно ли сделать чтоб когда на счету ноль, он автоматом морозился??? (

А у абонента не может быть просто ноля на счету? Это, что проклятая цифра и абонент должен нести за нее наказание? :)

 

Я так понимаю скриптами?

Да - и это будет мудацтвом в независимости от реализации.

 

Должен быть третий ))))))))) самый идиальный ....

Да - принять для себя тот факт, что вы предоставляете услугу за которую абонент обязан вам платить. Если абонент временно не пользуется услугой - это его забота оповестить провайдера о этом факте, простым нажиманием одной(!) кнопочки в ЛК либо телефонным звонком.

 

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

 

ЗЫ ну вы уже сами знаете, что я должен был бы сказать в конце? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 А у абонента не может быть просто ноля на счету? Это, что проклятая цифра и абонент должен нести за нее наказание?
 
вот нравится мне ваше чувство юмора, блин...
 
может конечно быть ноль. но при этом то услуга не прекращается, инет то будет всё равно литься...или я что то не понимаю...
 

 

Да - и это будет мудацтвом в независимости от реализации.

 

вот вот, и я об этом, поэтому должен быть третий вариант!!! ))))))
 

 

Да - принять для себя тот факт, что вы предоставляете услугу за которую абонент обязан вам платить. Если абонент временно не пользуется услугой - это его забота оповестить провайдера о этом факте, простым нажиманием одной(!) кнопочки в ЛК либо телефонным звонком.

 

нынче абоненты ой какие пошли неответсвенные и ленивые... из практики: 

у нас ситуация такая, если абонент не платит более 3 мес. мы его физически отрубаем, если после этого он хочет опять подключиться, то должен оплатить три мес. на перёд согласно тарифному плану. Это если он не прозвонил заранее и не предупредил что типа он уезжает куда-то там, или временно приостанавливает услугу... и всё равно находятся такие, которые приходят по истечению 3-4-6 мес (во время которых есесно не платили) и типа не в курсе, что надо было предупредить, или забы(И)ли и т.д. хотя всех предупраждаем что такое нужно делать. 

Далее, вот как необъясняй, всё равно, лень челу зайти в личный кабинет и поставить на заморозку.

 

 

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

 

ЗЫ ну вы уже сами знаете, что я должен был бы сказать в конце?
вот знал ведь, знал что припомните: я ведь тебе говорил как плоха эта штука - размазанная абонплата ))))
 
но всё же, считаю, что эта проблема актуальна, и нужно попытаться найти решение. Прежде чем поднимать тему, поискал по форуму, и видел, что подобный вопрос в частности отрицательного баланса, поднимался не раз... но решения нормального не нашёл.

 

Изменено пользователем felixio_01

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

В норме да - но вы ж то их за ноль морозить собрались?  Значит они - прокляты. :)

 

нынче абоненты ой какие пошли неответсвенные и ленивые... из практики:

Я тоже неответственный и ленивый - почему-то мне за это бабла никто не дарит :(

 

чтоб держать под него место (на свитчах свободные порты есть (((( )

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

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

Что? Сокращаете? А как? Перестаете пользоваться кондиционером и урезаете зарплату уборщице? :)

 

 

вот знал ведь, знал что припомните: я ведь тебе говорил как плоха эта штука - размазанная абонплата ))))

Вот видите, вы уже все знаете, что я собирался вещать :)

 

поднимался не раз... но решения нормального не нашёл.

Потому, что его в принципе нет. Как и для прочих административных проблем - нету адекватных технических решений.

 

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

Изменено пользователем nightfly

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А чем, собственно, плох вариант с FeeChargeType=1? По-моему, вполне логично: снялась абонентка за день; её не хватило, чтобы полностью заплатить за этот день, поэтому счет ушел немного в минус. При следующем пополнении счета, клиент платит свой небольшой образовавшийся долг (тот самый минус) за недооплаченную часть дня, а остальное переходит в плюс на оплату новых дней.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

дабы не плодить новых тем. 

stargazer 2.408

абонплата снимается каждый день, т.е.

SpreadFee = yes

 

имеет ли значение в таком случае параметр FeeChargeType ???

Имеет.

Задача следующая:

хочу ввести карточки пополнения. Но возникает проблема: у абонентов счёт уходит в минус и постепенно этот минус накапливается если абонент не пополняет счёт. Мне необходимо сделать чтобы абонплата, после того как у абонента 0 на счету не снималась и есесно инет не работал. Чтобы в последствии при пополнении карточкой счёт нормально пополнился...

А так получается у абонента например на счету -25 грн. пополнил он карточкой 60 грн... и на счету теперь 35 грн... а не 60...

Можно ли как то это решить?

FeeChargeType = 1

Будет небольшой уход в "минус".

Про "заморозку" уже писали.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 А чем, собственно, плох вариант с FeeChargeType=1? По-моему, вполне логично: снялась абонентка за день; её не хватило, чтобы полностью заплатить за этот день, поэтому счет ушел немного в минус. При следующем пополнении счета, клиент платит свой небольшой образовавшийся долг (тот самый минус) за недооплаченную часть дня, а остальное переходит в плюс на оплату новых дней

 

я склоняюсь к этому варианту...

 

 

 

FeeChargeType = 1

Будет небольшой уход в "минус".

Про "заморозку" уже писали.

 

вот только как автоматом морозить абонента когда у него 0 на счету???

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вот только как автоматом морозить абонента когда у него 0 на счету???

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

вот только как автоматом морозить абонента когда у него 0 на счету???

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

 

 

эх... вообщем первый вариант с FeeChargeType = 1 самый приемлемый.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×