| forum.bitel.ru http://forum.bitel.ru/ |
|
| Предлагаю добавить в биллинг http://forum.bitel.ru/viewtopic.php?f=1&t=2701 |
Страница 1 из 1 |
| Автор: | lda [ 07 авг 2009, 11:41 ] |
| Заголовок сообщения: | Предлагаю добавить в биллинг |
1. Предлагаю для типов задач CRM ввести признак "Запрещено менять тип". Т.е. для задач, у которых стоит тип с этим признаком, запрещено менять тип задачи. 2. Предлагаю добавит возможность определять набор параметров договора не только группой параметров, но и программно, т.е. через BGBS. |
|
| Автор: | skn [ 07 авг 2009, 13:05 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
lda писал(а): 2. Предлагаю добавит возможность определять набор параметров договора не только группой параметров, но и программно, т.е. через BGBS.
не понял, программно менять группу параметров? |
|
| Автор: | lda [ 07 авг 2009, 13:09 ] |
| Заголовок сообщения: | |
Да. Сделать событие типа "Получить список параметров договора". |
|
| Автор: | skn [ 07 авг 2009, 13:15 ] |
| Заголовок сообщения: | |
а зачем? |
|
| Автор: | lda [ 07 авг 2009, 13:46 ] |
| Заголовок сообщения: | |
skn писал(а): а зачем?
Для увеличения гибкости биллинга. У нас возникают задачи, при которых необходимо выполнить определенное действие для договора. Одни действия можно выполнить через доп. действия, а другие нельзя, так как необходимо осуществить ввод данных. Вот например у нас есть задача отслеживание оплаты юридических лиц, работающих по факту (режим "Кредит"). Менеджер находит договор, который давно не платит, и указывает, что если он не оплатит 1000р. с сегодняшнего числа, то отключить его через 3 дня. Эти данные сейчас вводятся в параметрах договора. Или еще задача. Для физ. лиц договор будет проходить через определенные стадии. Например: 1. Заявка на подключение. 2. Подключение (для монтажников). 3. Подключение (для настройщиков). 4. Ремонт. и т.д. Для каждой стадии необходим свой набор параметров, что бы упростить работу нашим сотрудникам и автоматизировать работу по максимуму. Конечно можно создать штук 20-30 различных наборов параметров и переключать их программно, но это не плохой вариант. Если бы было событие "Получить список параметров договора", то я бы смог при определенных условиях выдавать дополнительный набор параметров, которые расширяют функционал. |
|
| Автор: | skn [ 07 авг 2009, 14:33 ] |
| Заголовок сообщения: | |
мне не понятно когда должно генерироваться это событие... каждый раз при выборе ветки #параметры договора# в карточке договора? |
|
| Автор: | lda [ 07 авг 2009, 14:35 ] |
| Заголовок сообщения: | |
Да. |
|
| Автор: | skn [ 07 авг 2009, 14:38 ] |
| Заголовок сообщения: | |
и группы при этом не работают? а если мне нужен какой то параметр который скрипт не возвращает - то пипец? |
|
| Автор: | lda [ 07 авг 2009, 14:47 ] |
| Заголовок сообщения: | |
skn писал(а): и группы при этом не работают? а если мне нужен какой то параметр который скрипт не возвращает - то пипец?
У вас же есть подобные события "Получить список доп. действий" и "Получить список карт регистрации"? Если они чего то не возвращают то правится скрипт который генерит список. Я считаю что вполне логично и оправдано сделать тоже самое для параметров договора. Как это сделать в биллинге, отказаться вообще от групп параметров или сделать специальную группу, для которой список параметров будет определяться скприптом или же вообще ничего не добавлять это ваш вопрос... Я предлагаю "малой кровью" получить серьезное расширение функционала биллинга. |
|
| Автор: | skn [ 07 авг 2009, 14:57 ] |
| Заголовок сообщения: | |
сомнительное достоинство на мой взгляд.... 1) необходимость динамического изменение параметров при каждом просмотре этой панели - сомнительна 2) а изменение группы параметров возможно по другим событиям (изменение статуса, приход платежа и т.д.) |
|
| Автор: | lda [ 07 авг 2009, 15:10 ] |
| Заголовок сообщения: | |
skn писал(а): сомнительное достоинство на мой взгляд.... 1) необходимость динамического изменение параметров при каждом просмотре этой панели - сомнительна 2) а изменение группы параметров возможно по другим событиям (изменение статуса, приход платежа и т.д.) Дело ваше. Я свое мнение высказал. Цитата: 1. Предлагаю для типов задач CRM ввести признак "Запрещено менять тип". Т.е. для задач, у которых стоит тип с этим признаком, запрещено менять тип задачи.
По этому вопросу вы ничего не сказали. |
|
| Автор: | skn [ 07 авг 2009, 15:27 ] |
| Заголовок сообщения: | |
lda писал(а): Цитата: 1. Предлагаю для типов задач CRM ввести признак "Запрещено менять тип". Т.е. для задач, у которых стоит тип с этим признаком, запрещено менять тип задачи. По этому вопросу вы ничего не сказали. а должен ли он вообще меняться? |
|
| Автор: | lda [ 07 авг 2009, 15:46 ] |
| Заголовок сообщения: | |
Код: а должен ли он вообще меняться?
Нет не должен. У нас сотрудникам сказано, что менять тип задачи в crm нельзя. Но все равно есть те кто меняет. Хотелось бы закрыть эту возможность. Возможно вводить признак "Запрещено менять тип" и не обязательно. Можно просто добавить событие "Перед изменением задачи CRM" и в скрипте выводить ошибку, есть нельзя менять тип задачи. |
|
| Автор: | lda [ 10 авг 2009, 12:51 ] |
| Заголовок сообщения: | |
up |
|
| Автор: | skn [ 10 авг 2009, 14:42 ] |
| Заголовок сообщения: | |
добавили запрет редактированя типа, будет в следующем апдейте плагина |
|
| Автор: | lda [ 10 авг 2009, 14:56 ] |
| Заголовок сообщения: | |
skn писал(а): добавили запрет редактированя типа, будет в следующем апдейте плагина
Ок. Спасибо! |
|
| Автор: | borisk [ 26 сен 2009, 21:24 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
Предлагаю добавить в биллинг зависимость абонплаты от количества почтовых ящиков/доменов. Так же было бы неплохо добавить событие удаления/изменения почтового аккаунта. |
|
| Автор: | max [ 27 сен 2009, 12:02 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
borisk писал(а): Предлагаю добавить в биллинг зависимость абонплаты от количества почтовых ящиков/доменов. а как вы себе это представляете? |
|
| Автор: | borisk [ 27 сен 2009, 14:28 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
А собственно чем, по сути, это отличается от вот этой вот возможности? module.quantity.1.mid=73 module.quantity.1.class=bitel.billing.server.npay.bean.PhoneModuleQuantity module.quantity.1.sids=103 Соответственно будет EmailModuleAddressQuantity и EmailModuleDomainQuantity |
|
| Автор: | Администратор [ 28 сен 2009, 15:48 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
Так и будет. В TODO есть, по возможности сделаем. |
|
| Автор: | borisk [ 01 окт 2009, 12:51 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
Еще хотелось бы некий флаг для услуги вроде "не влияет на баланс". Нужно чтобы услуга считалась в денежном эквиваленте, но на баланс не влияла. |
|
| Автор: | stark [ 02 окт 2009, 18:41 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
borisk писал(а): Еще хотелось бы некий флаг для услуги вроде "не влияет на баланс". Нужно чтобы услуга считалась в денежном эквиваленте, но на баланс не влияла. зачем ? |
|
| Автор: | borisk [ 03 окт 2009, 09:50 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
Есть политика предоставления сотрудникам компании ресурсов на "условно бесплатной" основе. Руководство смотрит сколько оно наработало в денежном эквиваленте, а потом решает "простить или наказать". Если при этом стоимость заносится на баланс, то не очень красиво выглядит для бухгалтерии и та ворчит. |
|
| Автор: | stark [ 05 окт 2009, 16:53 ] |
| Заголовок сообщения: | Re: Предлагаю добавить в биллинг |
borisk писал(а): Есть политика предоставления сотрудникам компании ресурсов на "условно бесплатной" основе. Руководство смотрит сколько оно наработало в денежном эквиваленте, а потом решает "простить или наказать". Если при этом стоимость заносится на баланс, то не очень красиво выглядит для бухгалтерии и та ворчит. Повесьте отдельным договором(или субдоговором снезависымым баланосом), который не проходит через бухгалтерию |
|
| Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|