[ruri]

>7. Модуль интеграции с 1С .... привязка к клиентам в 1С 7.7 сделана через ведомые руками номера клиентов из 1с. дубли и прочие неадекваты не отслеживаются.

 

Мы его назначаем в биллинге как лицевой счёт. Потм уже передаём в 1С. Повторений нет...

 

[sol]

непонятно, зачем он вообще нужен... При наличии ИНН.

 

[ruri]

>непонятно, зачем он вообще нужен... При наличии ИНН.

У нас при приёме денег через терминал или банкомат клиент указывает свой л/с. И они автоматом попадают в биллинг

Изменено 27 июля, 2010 пользователем ruri

[Skylaer]

А если клиент имеет 2 договора, то тоже по ИНН обрабатывать? :))

[sol]

А если доку от модуля 1С почитать? Там прописан алгоритм поиска клиентов. http://www.lanbilling.ru/filedownload/comm.../1.9/doc_1s.pdf

 

 

[jp1111]

6. Был в офисе. Вся контора - это одна комната и ~10 человек, включая бухгалтерию. ТП - один человек. Девелопер - один человек и тот, похоже, на удаленке

 

Корреспондент по двум пунктам из 3х как минимум гонит: разработчиков 6, не считая удаленщиков, комнат 3 (просто не всем все показывают), бухгалтер, правда, один. Корреспондент в этой части полностью прав.

[sol]

разработчиков 6, не считая удаленщиков

Был ровно год назад. МБ с тех пор воз сдвинулся. Но отчего-то вся ТП в один голос ссылается на одного разработчика. Который, по словам ТП, иногда бывает в отпуске.

[jp1111]

разработчиков 6, не считая удаленщиков

Был ровно год назад. МБ с тех пор воз сдвинулся. Но отчего-то вся ТП в один голос ссылается на одного разработчика. Который, по словам ТП, иногда бывает в отпуске.

Опять не правда Ваша Сергей Сергеевич. Вот сижу смотрю штатное расписание за тот год. Пятеро, без удаленщиков. Хотите в личку вышлю? Да не в этом, собственно, даже вопрос.

Ваша компания купила продукт в конце девятого года, пользуетесь Вы им без малого год и, купили Вы его как раз в тот момент, когда статус первой сборки стал "релиз кандидатом". В общем-то дальше все становится на свои места. Врядли кто из читателей/писателей этой конференции не понимает, что именно _новый_ продукт проживает за первый год своей жизни. Вы прожили этот год вместе с нами. Спасибо Вам. Он был не простой, больше скажу, частично Ваши комментарии имеют под собой основания. Отмечу, в бОльшей степени частично, и яркий пример тому, то утверждение к которому я "прицепился". Хотя врядли Вы кинете в мой огород камень, другие компании - производители бюджетных биллингов (я бы назвал их малой тройкой :), что компания, количество клиентов которой переваливает без малого через 2 тыс операторов, может себе позволить оказывать сервис одинаковый и контрактным и не контрактным пользователям. Ваша компания пользователь не контрактный насколько я могу судить по crm, с соответствующими гарантиями поддержки, которые написаны на сайте, повторять их нет смысла. Мы уже без малого 10 лет на рынке. Мы знаем как делать свой продукт и что для этого нужно. Более того, в условиях когда у нас работы все больше и больше количество квалифицированных и _адекватных_ квалификации качественных кадров для того уровня системы, которую мы делаем находить все труднее. А именно это залог удовлетворенности пользователей. Скажу больше, мы расширили в этом году отдел разработчиков, сообразно новым запросам рынка со стороны федеральных операторов, которые пользуются нашей системой и с учетом того, что 6 и 7 сборки имеют возраст кода в 1 год ситуация уже изменилась в лучшую сторону. Я неспроста говорю о _новой_ системе. Был соблазн при истечении сертификата "переклеить" лейбл 1.8 на 1.9 на старом коде и продолжать его, как говорят на урале, банчить. Так нет, мы изменили в биллинге почти все, со всеми вытекающими, как положительными, моментами, так и отрицательными (смотрите вверх страницы - это не просто рекламный слоган, это суть нашей более чем годовалой работы). Но позвольте, к чему _столько_ критики? Давайте будем терпимее друг к другу. Позитив вернется сторицей. Не ошибается, не падает и не встает тот, кто ничего не делает и никуда не идет. Вы, я думаю, уже поняли о чем я коллега. Мы работаем, что бы у _нас_ было больше работы. Да Вы не ошиблись, не только денег, но и работы, ибо прежде чем становится много денег становится много работы. Нам, и не только нам, это удается. Не у всех же получилось делать бизнес в девяностые и сесть "на трубу" когда такая возможность была. Приходится работать.

 

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

 

p.s.: на совещании разработчиков сегодня привел Вашу цитату про одного разработчика удаленщика, все ухмыльнулись, а руководитель разработки пошутил, "нам этого удаленщика найти бы, и не пришлось бы столько всем программистам вкалывать :)". Может поможете найти? Денег бы в бюджете нам сэкономили, мы бы поделились...

 

[xeb]

Позабавило:

Финализирована

сборка №5 АСР LANBilling 1.9. Эта версия содержит результат существенной

работы, проведенной над интерфейсом АСР, как в части его

производительности, так и usability. .... бла бла .... Наша компания считает эту сборку наиболее стабильной во всей

линейке 1.9 и рекомендует ее к установке на действующие узлы связи.

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

[xeb]

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

[No_name]

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

Включать мозг пробывали? ;)

... Не заметно.

[dutch_cheese]

Позабавило:

Финализирована

сборка №5 АСР LANBilling 1.9. Эта версия содержит результат существенной

работы, проведенной над интерфейсом АСР, как в части его

производительности, так и usability. .... бла бла .... Наша компания считает эту сборку наиболее стабильной во всей

линейке 1.9 и рекомендует ее к установке на действующие узлы связи.

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

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

[sol]

О! представитель компании появился.

Ну тогда поехали.

1. Продукт я купил в августе 2009 года.

2. Претензий по функционированию ДО финализации у меня нет.

3. Финализировали продукт в конце августа 2009 года. Вопрос: почему после финализации остались глюки? Почему на вопрос о том, отчего-же агент CDR телефонии не пишет статистику в safe режиме ТП ответила, помявшись, что он это как-бы не умеет и уметь будет, но потом? Как вы получили сертификат на эту систему, если в ней не работают заявленные функции?

4. О одинаковом сервисе для клиентов на контракте и без. Выходит, контрактникам вы высылаете рабочие патчи а просто клиентам нерабочие? В качестве самостоятельного примера сравните последний присланный патч из запроса #12912 с аналогичным файлом из дистрибутива и расскажите нам тут, что-же такое он правит. Так-же было-бы неплохо огласить дату открытия этого тикета. И ответить таки на заданные в нем вопросы.

5. Расскажите нам, как при возрасте кода в 1 год одни и те-же баги кочуют из версии в версию? Пример - зависание перерасчета. Правится уже на протяжении 3-х релизов. И в каждом написано: Исправлено зависание при перерасчете статистики.

 

 

Ну и так, в порядке общего потока мыслей. Написание биллинга - дело не хитрое. Нет там ничего этакого и заумного. В конце концов, это просто умножения и сложения кучи строк статистики. И даже в такой простой задаче вы умудряетесь делать такие ляпы. Это даже не баги. Это просто ляпы. Типа деления на 0. 90% того, что выпускается в мир не проходит тестирования на работоспособность элементарных функций. Типа копирования тарифа. Это пример неработоспособности "из коробки". А все это от отсутствия культуры производства. Поверьте старому производителю софта. Нет тестирования. Нету его.

 

О штатном расписании: Девелопер в отпуске - это из ответов ТП по телефону. Так-же из ответов ТП прямо в офисе: Отстаньте, у меня еще на сегодня 63 открытых тикета. КАК, расскажите мне 1 человек может решить в сутки 63 тикета. КАК? (сегодня, кстати их 82). А на самом деле очень просто, как: У вас даже фраза есть такая, "мяч на вашей стороне". Пример: все тот-же злополучный тикет #12912. Занадобилось кому-то пример кривой выгрузки. Там в начале тикета есть логин и пароль для доступа к биллингу. Казалось-бы, пять кликов мыши - и вот она, выгрузка. Но нет, "мяч на моей стороне" и непременно, непременно надо, что-бы я самолично выгрузил и прикрепил к тикету. А потом ТП все это рассмотрит, когда "мяч прилетит на ее сторону". Опа, вот и отложилось решение вопроса. И я хорошо понимаю, почему так поступает ТП. Она ФИЗИЧЕСКИ не способна решать такое кол-во вопросов совешенно дурацкого вида. Тариф не копируется, деление на 0 происходит на ровном месте. Это простой порочный круг. Девелоперов мало/девелопер криворук/дефелопер загнан (ненужное зачеркнуть) и "гонит вал" без намека на тестирование. А потом в мыле правит то, что собрала для него ТП. А через месяц - очередной релиз надвигается. и надо скорее-скорее. Вот от того и появляются патчи, повторяющие дистрибутивные файлы. От того и глюки кочуют из релиза в релиз.

 

Позвольте совет: ОСТАНОВИТЕСЬ. Отдышитесь и добейтесь того, что-бы тикетов стало не 82, а 1-2 В НЕДЕЛЮ. Кодовую базу, наработанную по итогам паузы заморозьте и новые версии выпускайте на ее базе. И очередной релиз не ранее чем до срока 1-2 новых тикета В НЕДЕЛЮ. Вот тогда к вам потянутся люди.

 

 

 

Ах да, и приведите наконец документацию в соответствие.

 

[jp1111]

Сергей я слабо представляю куда Вы мне предлагаете ехать. Мне "ехать" не хочется, поэтому в ветке более участвовать не буду, предварительно высказав свое мнение на Вашу "аргументацию", т.к. несколько знаком с ситуацией. Тем не менее, заранее вынужден также и заметить, что причина отказа от публичной дискуссии еще и в том, что Вы не мытьем, так катаньем обращаете внимание к своим "проблемам", которые после анализа сказанного Вами таковыми признать не могу, скорее они следствие невнимательности или не желания использовать предоставленные Вам средства для их решения. Кстати, обратить внимание инженеров на свои сложности эксплуатации можно проще, но незначительно дороже. Этот способ обозначен в действующем прайс-листе за индексом LBSP0024. Написание столь подробных сообщений отнимает массу времени, которого у тех, кто работает нет, как на их обдумывание так и, банально, на печать. Вообще напоминает терроризм: "Вот моя 'проблема' посмотрите какие плохие ребята, помогли мне не за 20 минут, как мне бы хотелось, теперь посмотрим что скажут". То, что скажем - ниже.

 

1) Без комментариев, полностью согласен именно так и записано в crm

2) Спасибо

3) "Глюки" (слово очень не люблю, кстати, очень уж оно какое-то, дилетантское что-ли, по моему, _сугубо_субъективному_ мнению, ибо обозначает, то, что мало кто может объяснить или формализовать). Они есть _в_любом_ продукте, _любого_, даже гиперуважаемого разработчика софта. У Майкрософта после финализации не было "глюков"? Увольте меня если это так! Однако признать Ваш аргумент в пользу того, что "глюком" является неспособность работы агента платформы "Телефония" в режиме safe не могу. ИБО в документации на странице 54 черным по белому написано следующее: "Прим: Режимы работы Main и Safe существуют только для агентов, осуществляющих учет, лимитирование и тарификацию услуг «объемного» типа." Врядли Вы видели и физиономию инженера технической поддержки в момент ответа, а потому нельзя и говорить, что техподдержка "помялась". Таким образом вынужден констатировать, что Вы просто невнимательно почитали документацию в этой части. Так же, обратите пожалуйста внимание, что сертификат - есть подтверждение соответствия функционала системы требованиям 73 приказа Мининформсвязи, а не "заявленного функционала" разработчиком. Таким образом, гипотетически научив биллинг готовить Вам кофе по утрам, в том случае, если однажды утром биллинг этого не сделает, Вы не вправе сомневаться в его факте сертификации т.к. в 73 приказе нет ни слова про кофе, и кстати про safe режим тоже не слова нет. Его (режима) реализация - наша собственная инициатива в помощь Вам оператору, причем использовать которую целесообразно _только_ для ШПД услуг. Если Вы пытаетесь применить этот режим для услуги телефонии Вы банально не понимаете его смысл и оригинальное предназначение. Таким образом Ваш аргумент №3 _не_аргумент_, а проявление а) невнимательности б) непонимания сути государственной системы сертификации в области связи. Претензия №3 публично не принята.

 

4) В качестве констатации: контрактникам и НЕ контрактникам мы высылаем _одинаковые_ патчи, НО в первую очередь контрактникам и по их запросам, затем уже всем остальным. Ввиду того, что информационный терроризм я не поощряю, конкретно отвечать по локальной проблеме, которую Вы описали в запросе к техподдержке №12912 не буду. Однако дам общую характеристику хода решения вопросов по этому тикету. Вынужден признать, что Вы все же своего добились и вызвали у меня желание более пристально ознакомиться с этим эпизодом из жизни нашего отдела технической поддержки. Поздравляю с успехом, но прошу, все же, на будущее не пользоваться этим "запрещенным" приемом. В боксе за это очки снимают. Не хочется проводить аналогии по отношению к Вашей компании :) с моим хоккейным прошлым.

В тикете 12912, который Вы порядочно приводите, без содержания (были, и видимо есть, в этой конференции корреспонденты, которые вынесли на публику даже и содержимое одного из тикетов), читать которое интересно было бы только единицам из здесь присутствующих, Вами поднимаются последовательно (за это хоть спасибо), аж 3 проблемы. На будущее, как и написано в правилах хелпдеска, просим Вас создавать по одному тикету на каждую проблему/задачу. Как Вы выражаясь "поехав" по тикету Вы найдете, что, уяснив суть Вашего вопроса, подчеркиваю, _не_являясь_ контрактным клиентом у Вас сразу попросили удаленный доступ к Вашей системе, что бы на Ваших данных провести диагностику, чего, как правило, для неконтрактников вообще никогда не происходит. Не происходит потому, что "влезая" к Вам в систему мы начинаем нести ответственность за то, что с системой происходит. Поэтому, в условиях, когда в контракте не прописаны зоны ответственности и регламент взаимодействия между компаниями, это делать категорически запрещено инженерам. Из правила есть исключения. Мы просим доступ когда подозреваем, что в коде может иметь место ошибка, из за которой могут пострадать пользователи. И тогда инженера идут на риски, связанные с удаленным доступом только для того, что бы из - за формализма не страдали все пользователи АСР. Сказанное, теоретическое лирическое отступление для того, что бы дать Вам понимание почему в данном конкретном случае Вам пошли на встречу и приложили большее количество усилий к диагностике, чем могли бы. В первую очередь получив доступ к системе был сделан вывод, что горе произошло от ума. Вы совершенно бессмысленно использовали агентскую схему телефонии с _единственным_ оператором в системе. Для тех, кто не знаком с системой, сообщаю, что это нонсенс (non sence - то, чего не может быть). Говоря это не хочу сказать, что ошибки в одном из документов _при_включенной_агентской_схеме_ не было. Ошибка была. Но Вы с ней столкнулись, тогда когда Вам этого не требовалось. Тем не менее благодаря Вам мы исправили ошибку _шаблона_, которая проявлялась в режиме, который врядли кто еще задействует таким способом, как умудрились это сделать Вы (агентская схема и _ОДИН_ dafault оператор !!!). Для меня сказанное Выше является в общем-то самым показательным из всего анализа тикета, который я провел.

 

Далее Вы опять же таки подняли проблему, связанную с шаблоном документа. Проблему справедливо подняли, проблема была. Ее решили за 2 дня. ХОТЯ тут можно сказать следующее: шаблоны поставляются в открытом виде, более того, инструкция по работе с шаблонами, в которой _подробнейшим образом расписано _как_именно_ написать свой шаблон с нуля приведена по ссылке: http://www.lanbilling.ru/neworders.html. Прочитав Ваш пост снизу вверх в первую очередь Вы нам даете советы как и в какой последовательности выполнять свою работу являясь, цитирую Вас же "старым производителем софта" (расскажите какого кстати, очень интересно будет покритиковать Вас). Ответьте на мой вопрос: как старый производитель софта, пока он _без_контракта_ поддержки ждал ответа от инженера не смог разобраться не то что бы в элементарном, а тривиальном шаблоне документа, который у нас осваивают на второй день работы студенты из вузов, которые приходят на стажировку из партнерских учебный учреждений? Причем не разобрался в ситуации когда Вас, с Ваших же слов, "сьест бухгалтер". В общем, проблемы могло бы не быть. Раз уж она возникла она могла быть решена а) Вами (ибо код открыт и подробнейшим образом описан) б) нами не за двое суток, а сутки, при условиях LBSP0024

 

На сегодня, указанный Вами тикет находится в состоянии ожидания реакции от Вас с начала июня (выражусь так не любимым Вами образом: мячик-то на Вашей стороне :) гол Вам Сергей Сергеевич. Если мы не получили реакции, то считаем, что проблема решена. Если это не так продолжайте работу по тикету, зачем же его в публику-то? Люди читая такие сентенции пишут обычно "Афтарр жжот, много букаф, не осилил"), когда Вам была выслана корректная, с нашей точки зрения sql процедура.

 

Т.е. разобрав по Вашей настоятельной просьбе тикет №12912 отмечаю высокий профессионализм отдела технической поддержки, налаженность взаимодействия этого отдела с разработчиками, четкое следование внутренним инструкциям компании и предельную корректность к Заказчику. Таким образом, считаю ответ на Ваш вопрос был проработан и подробнейшим образом изложен. Следующий пункт тоже по сути претензией не является, а является просьбой объяснить факт. Объясняю.

 

5. Перерасчет - технологически сложный алгоритм и сказанное в Changelog - демонстрация нами честности по отношению к Вам клиентам, когда на протяжении _трех_ сборок мы находим ошибки в этом алгоритме. Может сложиться обманчивое впечатление, что исправляется одна и та же ошибка. Это не так. Алгоритм содержал разные ошибки, которые проявлялись при разных условиях, и в разных его участках. Утверждал и буду утверждать: класс компании определяется не тем, что команда разработчиков не делает ошибок, а тем насколько эффективно эта команда справляется с их исправлениями. Мудрость этой команды позволяет делать минимальное количество ошибок в коде. Идеальные команды ошибок не делают, но таких не бывает, как известно. Мы стремимся к идеалу, но придем с большой долей вероятности, только к мудрости.

 

Теперь переходим к Вашему "общему потоку мыслей". Сергей Сергеевич, при всем моем уважении, мой поток мыслей, мало того, что не разделяет Ваш, но еще и находит в нем изрядное количество изъянов:

Во-первых: в этой конференции не присутствует разве что очень ленивый разработчик биллинга. Мы, сами знаете, на рынке давно, так вот, за последние 6-7 лет команды разработчиков биллинга наделали уже порядка 30-40 вариантов бюджетных решений разного уровня. Обращаюсь к Вам коллеги: "Гей (не понять привратно!!!) славяне, ну поддержите меня хотя бы в том, что биллинг - ДЕЛО ХИТРОЕ !!!!". Заумное там есть и очень много. Возьмите, хотя бы, алгоритмы сходимости при расчете эффективных таймаутов разрыва сессии. Да что там объяснять. Я выражаю категорическое не согласие с Вашим потоком мысли, а потому отказываюсь комментировать Ваши наблюдения относительно "деления на ноль". Обсуждать подобные ошибки в отрыве от контекста бессмысленно. По поводу тестирования опять же ошибаетесь, его предписывает проводить система менеджмента качества, внедренная в соответствии с условиями сертификата. Которая кстати, реализуется как заводскими испытаниями (привет штатным бета тестерам) так и линейными (привет лояльным клиентам). Так что "НЕ ВЕРЮ" Вам Сергей Сергеевич (с) Станиславский.

 

О штатном расписании 2: инженеров не 1. иначе действительно с потоком запросов от нашей абонентской базы не справиться. Как можно ответить на 63, 82 и т.д. запросов. Да вот, представьте себе, справляемся. Не так эффективно как хотелось бы, но приходится устанавливать приоритеты. И самый действенный способ его повысить Вы знаете, не буду повторяться. Поскольку Вы к нему не обратились, поэтому и вынужден подтвердить, что не все запросы мы решаем в приемлемый для _всех_ срок. Хотя в сказанном Вами немного (очень немного) ценной информации к размышлению, действительно есть. Плодом этих размышлений является то, что наша компания на своем тернистом пути выходит медленно, но верно на некий новый качественный уровень работы, и, теперь Вы мне поверьте, соответствующие кадровые действия предпринимаются. Результат Вы почувствуете, он себя не заставит ждать.

 

Не буду ерничать Сергей Сергеевич, Вы рациональное зерно в Вашем совете нам передали. Мы действительно в текущих сборках именно такие задачи себе поставили и выполним их, но что касается насчет тяги к нам людей позвольте мне слабость, не буду комментировать. Равно как и отставание документации от кода. Это есть, было и будет. У всех. Но к сведению уже принято, причем уже пару месяцев назад. Работаем.

 

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

 

p.s.2: ответ кому-то выше: редакция по нашей просьбе ничего не удаляет, хотя, возможно, этого стоило бы добиться, поэтому смотрим внимательно

 

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

 

С уважением.

Изменено 31 июля, 2010 пользователем jp1111

[vIv]

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

Мндее.. Стукните там кого-нибудь... больно. Это даже не ляп тестирования, это небрежность проектирования. Уж граничные-то точки можно было заранее продумать, - ещё до написания кода, кстати. 0 агентов, 1 агент, 2 агента... Как вы вообще смогли напрограммать 2+ агентов, но при этом глюкнуть на одном? 8-)

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

 

А вообще ЛБ хороший, годный биллинг! А мелочи на то и светятся, чтобы быть почищенными, да? ;-)

[jp1111]

А вообще ЛБ хороший, годный биллинг! А мелочи на то и светятся, чтобы быть почищенными, да? ;-)

да! :)

Андрей, не агентов, а операторов (существенно разные объекты модели), что при агентской схеме на мой взгляд бессмысленно, а потому тестировано не должным образом.

Изменено 2 августа, 2010 пользователем jp1111

[sol]

Вот и я говорю: Заморозьте новые фичи и начните править баги в текущем коде. И тестировать, тестировать, тестировать... И вот тогда будет хороший и годный биллинг. Ибо принципиальных косяков в дизайне не видно пока. А вот в его реализации - мама моя.

 

[IvanI]

Тут в скором будущем (через полгода) понадобится от радиус агента выдавать реальники динамически с привязкой диаппазона к НАСу и одновременно на техже НАСах статически с привязкой ip к юзверю, это есть в 1.9 и работает?

[Paparaцo]

Похоже jp1111 "горбатого лепит".

[vIv]

Андрей, не агентов, а операторов (существенно разные объекты модели)

Для перечисления единиц на множестве целых неотрицательных чисел, - монопенисуально.

 

Тут в скором будущем (через полгода) понадобится от радиус агента выдавать реальники динамически с привязкой диаппазона к НАСу и одновременно на техже НАСах статически с привязкой ip к юзверю, это есть в 1.9 и работает?

Учитывая соседние ветки про фрирадиус и DHCP, - настоятельно рекомендую подумать в эту сторону тоже. У юзера может быть несколько адресов (например, подсеть или диапазон) и ему надо ПРАВИЛЬНО выдавать адреса по DHCP. Понятно, что для этого нужно иметь стык с базой пользователей.

[jp1111]

Учитывая соседние ветки про фрирадиус и DHCP, - настоятельно рекомендую подумать в эту сторону тоже. У юзера может быть несколько адресов (например, подсеть или диапазон) и ему надо ПРАВИЛЬНО выдавать адреса по DHCP. Понятно, что для этого нужно иметь стык с базой пользователей.

Предыдущую фразу заценил, однако уточню про dhcp. Совет касается ISG или нет? Спрашиваю потому, что в ASRах все уже сделано, причем сделано по уму когда dhcp сессия корректно завершается, чего не происходит в массе других реализаций. А без isg я лично не вижу программно-аппаратного комплекса, который качественно отследит релиз адреса и завершит сессию.

Есть соседняя ветка, в которой динамика выдачи адреса через DHCP уже обсуждена вдоль и поперек: http://forum.nag.ru/forum/index.php?showtopic=49890

Причем один из прошлогодних тикетов был закрыт со следующим комментарием:

 

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

 

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

 

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

Вот этот совет я лично воспринял правильно, без всякой иронии, практически с благодарностью. Потеем над этим практически ... как вся москва потеем :)

[Andrei]

не агентов, а операторов

Позволите вопрос про агентов и их состав в различных продаваемых вами платформах?

Куплена платформа "Интернет", на которой я полагал реализовать функционал доступа в интернет пользователей с авторизацией через радиус. И это работает. Но обнаружил, что с помощью этой платформы не реализовано, например, единовременное списание денег за подключение абонента. Оказывается для этого надо купить еще и вторую платформу - "Телематика". Это такой маркетинговый ход? :)

[jp1111]

"Телематика". Это такой маркетинговый ход? :)

Нет, это последовательное следование выбранной и четко структурированной архитектуре системы :).

Изменено 8 августа, 2010 пользователем jp1111

[IvanI]

не реализовано, например, единовременное списание денег за подключение абонента

Что нет платежа со знаком "-" и коментарием?

 

И повторю свой вопрос - в скором будущем (через полгода) понадобится от радиус агента выдавать реальники динамически с привязкой диаппазона к НАСу и одновременно на техже НАСах статически с привязкой ip к юзверю, это есть в 1.9 и работает?

Изменено 9 августа, 2010 пользователем IvanI

[Andrei]

это последовательное следование выбранной и четко структурированной архитектуре системы :).

Получается, что купив платформу "Интернет", полноценно биллинговать услуги доступа в интернет я не могу?

 

Что нет платежа со знаком "-" и коментарием?

Спасибо! Надо будет попробовать.