BiTel

В соответсвии с базовым шаблоном счета и счета фактуры, столбцы Цена и Сумма будет всегда равны, и выставляются в шаблоне в format-number(@summ - $nds, '0.00')

При этом существует возможность указать значенние столбца Кол-во (quantity) для каждой позиции счета. Таким образом, если пользователь создаст позицию счета в которой quantity будет устанавливаться в значение отличное от единицы, документ станет не правильным, ибо в нем будем написанно:

Абон плата в кол-ве 5 штук по цене 20000 рублей на сумму 20000 рублей.

Поэтому предлагаю, в шаблоне выставлять цену в summ деленное на quantity, без относительно к тому что по сути эта цена есть фуфло и ни какого отношения в реальным тарифам не имеет. Зато документ будет правилен математически.

А вот пользоваться ли механизмом задания quantity в позиции или не пользоваться будет каждый пользовательно решать сам.


P.S. если можно напишите как и где в шаблоне можно определить переменную $quantity которая будет равна @quantity либо будет равна единице если @quantity не определена.

Предложенный вами вариант не походит, т.к. сумма не всегда пропопрциональна объему услуги.


Да вроде так и сделано..

а вариант позиции:



так устраивает ? ведь имеено так и будет в документе если я в конфиге выставлю quantity
по сутип шаблон расчитан ТОЛЬКО на quantity=1

там может пусть лучше поле цены в документе будет лажовым с точки зрения тарификации но при этом счет не будет отображать бреда в стиле 3000 * 50 = 3000 ?

У вас есть пример шаблона, вы можете делать в нем все, что захотите. На то и шаблон.

т.е. в столбце где цена
вместо

А как-то можно выудить цену из тарифного плана?

А как-то можно выудить цену из тарифного плана?
Ну можно, только очень муторно ) Путем ипользования расширения XSLT sql и последовательного выбора нужных данных из базы.

очень сомнительно что что то сложное можно реализовать через XSLT, застрянем где то точно на ограничениях xsl:variable
проще реализовать алгоритм в виде хранимой функции, даже притом что процедурный язык mysql даже отдально не напоминает plsql ) но тем не менее, а из xslt уже позвать функцию с кучей параметров и получить односложный ответ

вот только, snik, как вы определите какая "цена" по позиции "междугородная и международная телефонная связь" или скажем "цена" пропорциональной абон платы тариф по которой изменялся посредли месяца и договор был активен не полный месяц ?

Полностью согласен

А как тогда считаются деньги? Я так понимаю по событию (звонок в телефонии или объём за сессию в ПД) из тарифа берётся соответсвующая цена и умножается на объем. Верно? Если да, то никто не мешает хранить эту цену в базе, а при необходимости изымать и вставлять в документы отчётности. Усложнения как я понимаю заключается в добавлении одного поля в базу и написании функции в модуле биллинга, что бы пользователь мог изымать цену.

PS: Вопорс есть по поводу подсчета трафика в ПД: Преобладабщий трафик это MAX(входящий,исходящий) за сессию или за переод отчетности NASа?

Неверно. "Цены за единицу" нет как таковой для сколько-нибудь сложного тарифа. Как вы её, собственно, представляете себе?

А как собственно говоря при отсутсвии цены происходит подсчет денег потраченных пользователем? Или "от фонаря"? При любом самом сложном тарифе 1 единица услуги стоит определенную сумму денег. Вот эту сумму и надо указать в цене.

В случае телефонии и VoiceIP цена звонка есть в базе - log_session, там параметр cost - для телефонии и session_cost - для VoiceIP ..Звонок является неделимым, т.е если увас 300 минут по одной цене и когда было 295, у вас произошёл звонок на 10 минут, то все 305 минут будут по этой цене, а следующий звонок уже по другой ..В случае dialup нет понятия цены сессии .. половина сессии может быть по одной цене, а вторая по другой, потому как эта сессия перешла из одного узла тарифа в другой .

Тогда по шагам попробуйте объяснить: КАК СНИМАЮТСЯ ДЕНЬГИ В DialUp?
Если сесия попала на 2 тарифа то цена 1 байта у каждой части все равно есть. Не важно по времени переход или по объёму. Цена все равно есть! Иначе со счета деньги не снимутся.

Цена при определённом уровне детализации есть на всё. И что же, Вы хотите в печатной форме своей выводить что-то такое?

Да. Примерно это и нужно. Но мне нужна цена из тарифного плана. Расхождение цены в договоре и в счете не все понимают.

В 4.6 вопрос решился?

если вам для IPN то оно уже реализуемо, через TRAFF_DETAIL, в соответсвующих таблицах есть как сумма так и объем, цены вычислите делением при условии что в пределах категории трафика цена не меняется внутри одного тарифа в зависимости от периода или еще чего то

P.S. рядом тема про то же самое...

Нет. Меня интерисуе DialUP. При этом тариф не обязательно линейный (простое деление не поможет).
Например:
1. Объём до 1 гб стоит:
С 00:00 до 08:00 40 коп. за 1 мб
С 08:01 до 18:00 80 коп. за 1 мб
С 18:01 до 23:59 60 коп. за 1 мб
2. Объём от 1 гб до 5 Гб стоит:
С 00:00 до 08:00 35 коп. за 1 мб
С 08:01 до 18:00 70 коп. за 1 мб
С 18:01 до 23:59 60 коп. за 1 мб
3. Объём свыше 5 гб стоит:
С 00:00 до 08:00 30 коп. за 1 мб
С 08:01 до 18:00 60 коп. за 1 мб
С 18:01 до 23:59 50 коп. за 1 мб

И как такой тариф в Счет-фактуре расписать? Клиент требует что бы ему показали сколько он скачал и по какой цене.

В DialUp все аналогично. При любом делении можно прямо в узле "Стоимость" можно указывать определенный в конфигурации tariff.detail . Потом сделать полный переобсчет по клиентам за месяц и можно макросами в бухгалтерии вытаскивать TARIFF_DETAIL

А каким образом это сделать? Детализацию по объёму понятно. Детализация по сумме то же не проблема. А вот когда происходит деление вылезают копейки. Которые бухгалтерия не принимает.

ЗЫ: Вопрос не совсем в тему хотя касается бухгалтерского модуля. При формировани счетов и с-ф был макрос mm, а вот макроса yy не было. Обещали в 4.6 добавить. Сделали?

Да, с копейками там засада выйдет, может не сойтись наработка в договоре и сумма по позициям.

В имени позиций? Нет, не делали, по-моему. Вы бы кинули ссылку на тему, где это обсуждалось.

Она самая и есть. Вот и жду когда добавите функцию


Мы с Amir ом по телефону общались. Он обещал добавить.

Какую функцию-то? Если там реально наработка по копейкам не делится на типы эти..

Вы точно опишите, что добавить-то надо? То, что я предположил?

что бы копейки сошлись надо одну из позиций считать как разность наработки и суммы всех остальных "тариф-детайлов"

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