Список ожидаемых дополнений

[admin]

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

О каком именно уведомлении идет речь?

Какой в этом смысл, если при блокировке указывается, что автоматическая разблокировка при оплате не возможна. Зачем вообще в этом случае давать клиенту платить?

Зачем клиент производит оплату, если причина блокировки - не просрочка платежа?

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

При необходимости измените фразы в языковом файле, добавив туда информацию, что требуется ввести ключевое слово.

[Lazek]

3.0 Beta 3

Добавьте пожалуйста возможность, сотрудникам (и администраторам), добавлять записи в события аккаунта.

[Lazek]

3.0 Beta 3 или 4.0 Alpha 1

Добавьте пожалуйста интеграцию с 1С, пример:

http://ru.ispdoc.com/index.php/%D0%98%D0%B...5%D0%B9_1%D0%A1

[Vladimir812]

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

 

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

[Lazek]

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

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

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

Полностью согласен, так же хотел предложить, но спасибо Владимиру за подробное описание.

[Vladimir812]

Я конкретно предлагаю сделать доп. защиту на биллинг вцелом, можно с выбором страницы, можно как то иначе. Если это можно реализовать с помощью доп. полей, то на данный момент они не настолько функциональны.

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

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

Предлагаю вариант платной доработки, как мы уже делали ранее. Готов оплатить Вашу работу + к тому и другие пользователи биллинга останутся в плюсе. Защита лишней не бывает...

[admin]

3.0 Beta 3

Добавьте пожалуйста возможность, сотрудникам (и администраторам), добавлять записи в события аккаунта.

Зачем? Приведите пример, для чего такое может пригодиться.

3.0 Beta 3 или 4.0 Alpha 1

Добавьте пожалуйста интеграцию с 1С, пример:

http://ru.ispdoc.com/index.php/%D0%98%D0%B...5%D0%B9_1%D0%A1

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

Но в ближайшее время самим может понадобиться (планируем оптимизировать бухгалтерские расходы, сейчас в данные в 1С добавляет бухгалтер самостоятельно, а будет директор ).

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

Пропустит, значит манибека не получит, т.к. идентификация про пройдена

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

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

Видимо хочет увеличить срок хостинга до решения проблемы/получения ответа от сапорта по причине блокировки.

Хочет оплатить - его право.

Я конкретно предлагаю сделать доп. защиту на биллинг вцелом, можно с выбором страницы, можно как то иначе. Если это можно реализовать с помощью доп. полей, то на данный момент они не настолько функциональны.

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

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

Предлагаю вариант платной доработки, как мы уже делали ранее. Готов оплатить Вашу работу + к тому и другие пользователи биллинга останутся в плюсе. Защита лишней не бывает...

Даже платно дорабатывать что-либо в этой области не буду, это лишнее. Есть доп. защита по IP на весь биллинговый аккаунт.

[Vladimir812]

Ну хорошо как мне на странице возврата сделать обязательное заполнение доп. поля ?

[Lazek]

Зачем? Приведите пример, для чего такое может пригодиться.

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

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

Но в ближайшее время самим может понадобиться (планируем оптимизировать бухгалтерские расходы, сейчас в данные в 1С добавляет бухгалтер самостоятельно, а будет директор

Ясненько, ну в последних билдах, статистика вообще отлично работает, точность на 95-99%, но в 1C естественно удобнее . Хотя может быть лучше дорабатывать статистику в самом биллинге... Чем куда либо импортировать данные...

[admin]

Ну хорошо как мне на странице возврата сделать обязательное заполнение доп. поля ?

Подобное невозможно, однако Вы при помощи изменений в lang-файле Вы можете указать, что ввод каких-либо данных в реквизиты для moneyback - обязателен.

Зачем? Приведите пример, для чего такое может пригодиться.

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

При работах с сервером Вы предлагаете вносить собитие в соотв. логи для всех клиентов?

Лучше добавляйте эти данные в статус сети.

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

Но в ближайшее время самим может понадобиться (планируем оптимизировать бухгалтерские расходы, сейчас в данные в 1С добавляет бухгалтер самостоятельно, а будет директор

Ясненько, ну в последних билдах, статистика вообще отлично работает, точность на 95-99%, но в 1C естественно удобнее . Хотя может быть лучше дорабатывать статистику в самом биллинге... Чем куда либо импортировать данные...

Какая именно статистика и как считает неверно?

[Lazek]

При работах с сервером Вы предлагаете вносить собитие в соотв. логи для всех клиентов?

Лучше добавляйте эти данные в статус сети.

Алексей, нет что Вы, снова же извиняюсь как обычно не довел мысль до конца, это я приводил пример для DEDICATED аккаунта клиента, то же самое может быть и для VPS и т.п.

Какая именно статистика и как считает неверно?

Извинился ранее Имел введу статистику в виде графиков, т.к. вот прямо сейчас перед глазами - на 99% верная статистика на странице - /order/admin/?mod=statistics&go=hosting , а вот на страницах графиков, не совсем точно...

[Vladimir812]

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

[admin]

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

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

При работах с сервером Вы предлагаете вносить собитие в соотв. логи для всех клиентов?

Лучше добавляйте эти данные в статус сети.

Алексей, нет что Вы, снова же извиняюсь как обычно не довел мысль до конца, это я приводил пример для DEDICATED аккаунта клиента, то же самое может быть и для VPS и т.п.

Добавляйте это в комментарии, если по клиенту есть что-то особенное.

Выставляются счета - добавляйте туда.

Запросы в тикетах - учитывается в событияъ автоматически.

Какая именно статистика и как считает неверно?

Извинился ранее Имел введу статистику в виде графиков, т.к. вот прямо сейчас перед глазами - на 99% верная статистика на странице - /order/admin/?mod=statistics&go=hosting , а вот на страницах графиков, не совсем точно...

Что именно не точно?

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

Если бы я считал, что это нужно, то обязательно бы добавил в биллинг.

Но добавлять функцию лишь из-за того, что у Вас случился косяк (не сверили данные по отправителю и получателю платежа), - не буду.

[Vladimir812]

Не понял про купоны, что значит только один? А если потом клиенту надо будет еще купон на домен истратить, например, как с этим ?

[rrr]

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

сейчас это заменяется на примерное такое &256;

[admin]

Не понял про купоны, что значит только один? А если потом клиенту надо будет еще купон на домен истратить, например, как с этим ?

Сможет при произведении второго платежа.

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

сейчас это заменяется на примерное такое &256;

Нет. Даже если и сделаю поддержку этих символов, то они не будут проходить при регистрации доменов на стороне регистратора и пр.

[Lazek]

Какая именно статистика и как считает неверно?

Алексей, имел введу статистику графическую - /order/admin/?mod=paymentstat

Если аккаунт даже удален, в таблице платежей DELETED_ID то в графиках, он всеравно учитывается, именно это исправьте пожалуйста..

[admin]

Да, это так, платежи от удаленных аккаунтов также учитываются в статистике.

[Lazek]

Да, это так, платежи от удаленных аккаунтов также учитываются в статистике.

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

[admin]

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

 

Обновил архив в соотв. с ответами на форуме, мелкие исправления.

[Lazek]

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

Алексей, да Вы правы, ошибка именно с RUR из-за этого и написал сюда, ну это более подробно в теме рядом расписано .

[Vladimir812]

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

[admin]

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

Нет, т.к. не вижу смысла в этом разделении скидок.

[Lazek]

Письма об активации аккаунта.

Раздел: 5. Партнерская Программа

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

[admin]

Ок.