В модуле Inet переоформлять договоры стало проблематично:


2. Сессии (и наработка по ним) не переносятся на новый договор при переоформлении задним числом, как это было в Dialup.

В чём вообще проблема фиктивно разорвать сессию, как это делается на границе суток?
Если это нельзя сделать фиктивно на разных сервисах (я не разбирался), то можно ведь закрыть или сбросить.
В Inet ведь даже radius-сессии могут подниматься из update - пакетов, в крайнем случае можно просто сбрасывать активную сессию и спокойно переоформляться.

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

Переоформление договоров крупных клиентов, где много точек (Банки)

План переоформления договоров крупных клиентов (где точек много).
Подготовить скрипт (А), который автоматически запретит в логине (IPoE, PPPoE, Dial-up) доступ.
Подготовить скрипт (Б), который автоматически разрешит в логине (IPoE, PPPoE, Dial-up) доступ.
Подготовить SQL запрос (В) для отображения текущих сессий (IPoE, PPPoE, Dial-up) клиента по CID супердоговора
SELECT u.login, u.id, c.comment, c.title, s.*
FROM
log_session_23_201201 s, user_login_23 u, contract c
WHERE s.lid = u.id AND c.scid = 125202 AND c.id = u.cid
AND s.STATUS = 0
Согласовать с клиентом дату и время переоформления, предупредить клиента о том, что возможны прерывания сервиса. Согласовать приоритет точек, которые в первую очередь должны быть подняты и проверены.
Предупредить саппорт о проводимых работах
В назначенную дату:
Запускаем SQL запрос (В), смотрим какие сессии сейчас активны.
Необходимо с помощью SQL скрипта посмотреть у каких логинов договора не проставлена дата открытия. - проставить началом даты договора/субдоговора.
Запускаем скрипт А
ждем 30 секунд пока все сессий будут сброшены
Запускаем SQL запрос (В), смотрим какие сессии сейчас активны. Если остались активные сессии, смотрим состояние логина и скидываем ручками.
Через биллинг запускаем переоформление договора. Ждем пока все договоры (субдоговоры) клиента будут переоформлены.
Запускаем скрипт Б

История переоформления <BANKNAME>
Перерыв сервиса у клиента был примерно 15 минут. Из них минут 13 биллинг переоформлял договоры (61 договор)
Остальное время требовалось чтобы поднялись сессии.

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

2.1.2. Отвечать на сообщения Заказчика в течении 10 рабочих часов с момента их отправки. Ответ на сообщение может содержать:
- ответ на заданный вопрос в рамках консультационно-справочного обслуживания;
- уведомление о выполненной работе;
- уточняющий вопрос;
- предложение по срокам и стоимости выполнения работ;
- отказ в обслуживании в случае если вопрос либо работа лежат вне сферы компетенции Исполнителя.

Хотя бы в планах есть?
И когда?
В HD тема лежит уже 17 дней без ответа.

У Битела нет культуры работы с клиентами: если не могут/не хотят что-то делать, то просто притворяются мертвыми.
Даже в HD.
И непонятно - сколько ждать и ждать ли вообще.

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

Можно просто написать, что задача в очереди на рассмотрение.
Я же ведь не знаю - может вы вообще забили сразу.

Ситуация: куча субов, переоформление занимает несколько минут, в процессе приходит update или flow по сервису и поднимается сессия. Переоформление останавливается с такой ошибкой, половина субов переведена, половина - нет.

2. Мб можно как-то лочить фичу поднятия сессии по аккаунтингу в момент переофрмления?

1. Можете более информативно сделать - чтобы в ошибке договор и сервис выдавало?

1. Можете более информативно сделать - чтобы в ошибке договор и сервис выдавало?
2. Мб можно как-то лочить фичу поднятия сессии по аккаунтингу в момент переофрмления?
3. Делать закрытие сессий по wrap.contract.finish.current.sessions=1 не при первичной проверке перед переоформлением (или не только), а при собственно переносе сервиса (в методе inetServWrap())