mrlexus

Коллеги, кто-то делал отслеживание и обработку события отвязки оборудования от УЗ?

created, timefrom, activated время выставляю в 00:00:00 Воспроизвел у себя такую же ситуацию. После изменения времени напрямую в БД в указанных полях на 00:00:00 перерасчет прошел практически мгновенно. Вероятно, время перерасчета зависит от параметров блокировки и типа списания в тарифном плане. У меня блокировка - Активная, списание - Комбинированно.

Какие поля в таблице меняете?

Еще лучше вынести это в параметр конфига. Приводим функцию к такому виду: public function validateVgid() { if (!yii::app()->params['vgroup_schedule_blocked']) { if ($this->vgroup()->vgroup->blocked) { throw new Exception('Account is blocked'); } } foreach ($this->tarrasp() as $item) { if ($this->byUser($item)) { throw new Exception('Please remove allready scheduled tariff change'); } } } И в конфиг ЛК добавить такие строчки: //Разрешить смену тарифного плана при блокировке УЗ 'vgroup_schedule_blocked' => false, ЗЫ Просто ради интереса, сколько денег попросили бы разработчики за такую доработку?

Посмотрел код ЛК. Оказалось все очень просто. Ищем файл client2/client/components/tariff/changing/Tariff_Changing_Helper.php и приводим в нём функцию к такому виду: public function validateVgid() { /* if ($this->vgroup()->vgroup->blocked) { throw new Exception('Account is blocked'); } */ foreach ($this->tarrasp() as $item) { if ($this->byUser($item)) { throw new Exception('Please remove allready scheduled tariff change'); } } }

Не совсем так. В интерфейсе админки в двух местах (Объекты - УЗ и Объекты - Пользователи - нажать +) есть менюшки управления блокировками, которые как раз используют только текущее время при изменении состояния и изменять это поведение разработчики не намерены. Поэтому выход: либо выпиливать эти менюшки из интерфейса либо бить по рукам операторов, которые ими пользуются. Пытался допилить в ЛК мастер управления пакетами ТВ, с первого захода не осилил. Но там можно взять за образец мастер смены тарифного плана и в коде вычислять нужную дату и время ставить 00:00. Ну и крайний вариант - запрашивать доработку у разработчиков.

Любое обновление ЛБ - это боль, страдание и бессонные ночи. Лучше уточните, какие платформы используете (Интернет, Телефония/IP телефония, ЦТВ/КТВ и т.д.), могу рассказать более детально. ЗЫ Учитывая, что сейчас обновление только с пакетом тех. поддержки, то должно быть проще. Но, не уверен.

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

Согласен удобно. Только этом механизм не годен для полноценной замены учетных записей USBOX. Для привязки оборудования к УЗ все равно надо создавать учетку USBOX. Мы так надеялись, что теперь не придется плодить пустые учетки, но, увы...

2anichka991 Я понял Вашу позицию. Странно, что представитель СР акцентировал внимание публики, что суд с разработчиком - это одно из конкурентных преимуществ отечественного ПО. Вы начали его поддерживать, переведя тему в политоту, а теперь уходите в сторону таки соблюдения договоренностей между сторонами. Уточните еще один важный момент: договоренности или же договора (бумажные) конкретно у Вашей компании с разработчиком? Это две большие разницы. Мне действительно это интересно в свете последних изменений в сервисной политике разработчика. Гарантированное время решения это хорошо. Только решение решению рознь. Могу рассказать конкретный пример с техническими подробностями, если Вам интересно и Вы готовы дать свои профессиональные комментарии.

В данном конкретном случае все регламенты и прочие бумажки в одночасье становятся фИговыми листочками, которыми можно лишь прикрыться при разборах полетов. Если под большой красной кнопкой написать "НЕ НАЖИМАТЬ", на неё обязательно нажмут, и, наоборот, если написать "НАЖАТЬ ОБЯЗАТЕЛЬНО" - никто не нажмет. Это человеческий фактор и он не решается только административным воздействием. Поэтому необходимо делать техническую реализацию системы положительной или отрицательной связи для контроля возникновения ошибки а работе штатного (!) функционала системы. На реализацию данной системы требуются ресурсы, как временные, так и человеческие. Итог - система работает, но появился очередной костылик под падающий забор. Вы мне уже ответили в первом абзаце. Опуская промежуточные ходы и ответвления итог один - "Идите в суд" (с) Мне ясна Ваша позиция. Если взять конкретный продукт, то без Linux/UNIX, MySQL, Apache, php + extentions, python и умения все это приготовить, LB просто набор байтов. И только в совокупности все это становится БИЛЛИНГОМ. Поэтому Ваше высказывание немного сомнительно. Кроме всего, для того, чтобы все это стало по настоящему АСР, требуется дополнительная обвязка для управления оборудованием, и тут без opensource совсем не обойтись. Даже CoA не послать. К чему я все это. Я вижу, что продукт развивается, местами становится лучше, но в эту бочку меда разработчики своими же руками кидают совсем уж неприличные объемы дегтя. Причем, иногда складывается ощущение, что они сознательно выпускают релиз с некоторой долей ошибок, иногда совсем "детских" и от релиза к релизу повторяющихся. Мне очень хочется, чтобы это было неправдой и с каждым релизом старые ошибки не повторялись, а новые - не появлялись. А описанные мною выше "нежданчики", и, особенно, реакция на них разработчиков - небольшое недоразумение, которое будет решено до окончания срока подписки на обновления. Пока я вижу некоторое улучшение, связанное с приходом нового технического директора в команду СР. Но мне хочется в этом быть уверенным, а не надеяться на нисхождение просветления на ответственные за разработку продукта головы.

Разработчик отмалчивается и не принимает разумные доводы. Ок. Принято. Решение через изменение бизнес-логики - убедить 50 менеджеров (их действия уже доведены практически до автоматизма) делать не так, как они привыкли за 5(!) лет использования системы, а прям вот сейчас делать так, как надо разработчику по его прихоти. Ваши действия?

Ок. Принято. Разработчик в ТТ отвечает, что это не баг, а фича, и доку мы поправим. На неоднократные вопросы о сроках решения проблемы ответа нет несколько месяцев. Доход вашей компании все также теряется... Оба контрагента - резиденты РФ. Ваши действия? P.S Не читайте советских газет до обеда (с) Ф.Ф. Преображенский

anichka991 Интересно Вас читать. Все смешалось в доме Облонских... Машины, деньги, полствола... :) Невольно вспомнилось детство и мультик про полтора землекопа :) Однако, хочется узнать Ваше мнение по более конкретному вопросу. Представьте, что с очередным обновлением ПО (оплаченном), Вы обнаруживаете нештатное поведение системы, которое не описано ни в документации, ни в списке изменений к релизу. Причем это поведение прямо влияет на уменьшение дохода Вашей компании. Ваши действия, как лица, ответственного за функционал этого ПО в Вашей компании?

Создание тикетов в HD доступно? При покупке лицензии на обновление? Доступно. Но решение проблемы не гарантировано. В большинстве случаев проблемы решают, но решение может растянуться на несколько месяцев. Будьте готовы к отпискам со стороны HD.