stark писал(а):
snark писал(а):
stark писал(а):
Как вариант можно ему тариф зарисовать прямо в карточке в том виде , какой он есть ..Но это не понятно для человека .
Что, в общем виде, мы имеем в дереве тарифа? Мы имеем всего 2 вещи: "услуга" и ее "цена" и достаточно, при выставлении contractcard.showTarif=1, просто "выплюнуть" этот список в XML, где skyb его нарисует так, как ему захочется
Такой вариант мы можем - это называется отобразить тариф как есть .Т.е выгрузить его xml . Но skyb-придется опять же делать ЧАСТНОЕ решение , он распарсить тариф частного вида и покажет его пользователю. Если тариф кардинально поменяется ( наример ночью по четным числам в високосные годы станет другая скорость и цена ), то он опять же будет менять свой скрипт .
snark писал(а):
Периодов, как таковых, в тарифе и соответственно в карточке нет, т.к. в каждый конкретный промежуток времени действует только одна цена на опред. услугу.
Цена может меняться, в зависимости от тарифных опций, но ведь все опции доступные договору, для которого генерится карта, мы обязаны указать в распечатанном даже из doc/xsl тарифе и поэтому к списку "услуга Х = цена Y" в XML прибавляется список "опция Х = цена Y".
Если говорить про npay, то там помимо услуги и ее цены надо выводить еще метод снятия, чтобы мы могли написать "абонентская плата снимается <режим начисления>".
Это о тех деталях, о которых сразу вспомнил, а т.к. я определенно про что-то забыл, то надеюсь что вы напомните.
Это все частные случаи, пример одного случая вы сами же выше и привели . В общем случае есть не только абонплаты и тарификатор это конструктор, который позволяет сделать что угодно . Отобразить это в виде еирархии точно в таком виде как это выглядит в тарифе -нет проблем. И вы сделаете очередное частное решение, которое парсит эту xml и выложите его в wiki . А потом через год кто-то составит новый тариф и опять новое частное решение и т.д. Более того вы сейчас даже уже можете считать все узлы тарифа slq-запросом в карточке и сделать с ними что угодно .
Предположим, что есть:
"услуга 1" и "услуга 2" - какие-то модули
"услуга 3" - модуль npay
Все что нужно - это просто выдать в XML "простыню" тарифного дерева вида:
Код:
тариф A
услуга 1 цена X
услуга 2 цена Y
услуга 3 цена Z безусловно
тариф B
услуга 1 цена X
услуга 2 цена Y
услуга 3 цена Z пропорционально периоду
тариф C
услуга 1 цена X
услуга 2 цена Y
услуга 3 цена Z по дням
тарифные опции
опция 1 цена X <условия активации>
опция 1 цена Y <условия активации>
опция 1 цена Z <условия активации>
И тогда каждый волен с ней делать все что ему заблагорассудится.
Вы же сейчас выводите название тарифа и наверное это потому, что когда-то, кому-то, для его частного случая, это понадобилось и теперь этим все пользуются. Так вот если расширить название тарифа до его полного описания, то это станет из частного случая skyb общей практикой для всех остальных
Пожалуйста поймите, мы все это, ну или что-то другое, не используем не потому что не хотим, а потому что у нас попросту этого нет, т.е. будет в карточке некое отображение дерева тарифа - мы сможем, выдирая нужные куски имеющейся инфы, человеческим языком расписать тариф, ну или тупо нарисовать табличку.
skyb писал(а):
Phricker писал(а):
Добавить в тарифы поле "Комментарий" где будут полные описания тарифа которые подставляются в карточки )
Самое простое решение )
кстати ДА
Кстати НЕТ. Поле - это элемент интерфейса + поле в БД + обработчики, а то чего прошу я (прошу и фантазирую за тебя, если ты не заметил) в БГ уже есть (дерево тарифа то рисуется) и надо это просто выдать в XML карточки договора, а еще лучше - в отдельную карточку которая будет заниматься pdf-изацией тарифов, чтобы мы могли, например, выдернуть тариф для опред. группы и распечатать его на принтере, вместо того чтобы хранить doc/xsl/etc что ну или дать ссылку на странице статистики, чтобы дать юзеру возможность скачать.
Вход
Регистрация
FAQ
Поиск
