forum.bitel.ru
http://forum.bitel.ru/

предоплата абонплаты за следующий месяц
http://forum.bitel.ru/viewtopic.php?f=14&t=2343		 Страница 1 из 1
Автор:  ЛИС [ 24 май 2009, 18:36 ]
Заголовок сообщения:  предоплата абонплаты за следующий месяц
V4.5
Делаю все как в (цитата): "Пример 14.2. Пример второй

А корпоративным клиентам необходимо выставлять отдельными строчками абонплату, наработку по интернет и телефонии. За каждый месяц необходимо выставлять счета с наработкой за данный месяц и предоплатой абонплаты за следующий."

А в счете НОЛЬ где должна быть предоплата абонплаты за следующий месяц!
Что делаю не так?
Автор:  Администратор [ 27 май 2009, 16:32 ]
Заголовок сообщения: 
Конфиги и скрины выложите.
Автор:  WhiteWind [ 04 июн 2009, 11:36 ]
Заголовок сообщения: 
У меня возникла подобная проблема. В конфигурации написано:
Код:
bill.pos.1.title=Интернет
bill.pos.1.name=Абонплата за услуги интернет за $nextmonth
bill.pos.1.summ=SERVICE_ACCOUNT($nextmonth,52)
bill.pos.2.title=За порт
bill.pos.2.name=Абонплата за выделенный порт за $nextmonth
bill.pos.2.summ=SERVICE_ACCOUNT($nextmonth,26)
bill.pos.3.title=Статичный IP
bill.pos.3.name=Абонплата за статичный IP адрес за $nextmonth
bill.pos.3.summ=SERVICE_ACCOUNT($nextmonth,6)

Все три абонплаты начисляются как "подневной режим снятия до текущего дня".
При генерировании счетов сумма по этим трём позициям равна нулю. Что неудивительно, т.к. в документации сказано:
Цитата:
SERVICE_ACCOUNT(<month>, <коды услуг через запятую>) - наработка по определенным услугам
, а за будущий месяц наработка не начисляется.

Как выставлять счета на предоплату? Единственный вариант, который я вижу сейчас - переделать абонплаты на "подневной режим снятия авансом за месяц" и выставлять счета в текущем месяце, но этот вариант нам не подходит
Автор:  Администратор [ 04 июн 2009, 14:29 ]
Заголовок сообщения: 
А какую сумму-то ставить в позицию? Размер абонплаты в следующем месяце?
Автор:  WhiteWind [ 04 июн 2009, 14:40 ]
Заголовок сообщения: 
Да. Исходя из установленных периодов приостановления/отключения/закрытия договоров, смены тарифных планов (менять статус договора и тарифные планы можно и в будущем) рассчитывать размер абонплаты на следующий месяц
Автор:  Jimson [ 04 июн 2009, 20:36 ]
Заголовок сообщения: 
я не очень понимаю, если вы выставляете счета на абон плату АВАНСОМ, то зачем делать подневное снятие ?
поставьте помесячное и все заработает, другой вопрос что вы будете делать когда на конец месяца окажется что по договору были простои, и надо каким то способом вычислить разницу выставленной и реальной абон платы
я для решения данной проблемы добавляю в счета корректировку, которую вычисляю как сумма выставленных счетов указанного типа минус наработки по услугам, немного громоздко в конфиге, но работает...

P.S. у нас почему то жесткое требование авансовые счета выставлять первым числом месяца, поэтому у меня доплатный счета и авансовые это разные документа, хорошо разберитесь в том что хочет ваша бухгалтерия видить
Автор:  Jimson [ 04 июн 2009, 20:39 ]
Заголовок сообщения: 
а вот что... корректировку абон платы нельзя вставлять в тот же документ в котором выставляется аванс на абон плату, иначе выйдет фигня, корректировка будет считать с учетом корректировки и фактически единожды возникнувшая корректировка будет списываться и дописываться вечно, то в плюс то в минус, из месяца в месяц

вообщем если интересно будет я подробнее опишу свои мытарства с авансами на кредитных договорах
Автор:  WhiteWind [ 04 июн 2009, 20:40 ]
Заголовок сообщения: 
Я не совсем понимаю, что такое доплатный счёт, это счёт в конце месяца, допустим, за трафик, который невозможно выставить авансом?

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

Вот-вот. Мне хочется узнать, что же я буду делать) И очень бы не хотелось узнать, что мне придётся делать систему костылей и подпорок. Поэтому я и прошу у разработчиков какого-нибудь совета, а лучше функционала
Автор:  aardvark [ 08 июн 2009, 16:43 ]
Заголовок сообщения: 
Попробуйте вместо конструкции SERVICE_ACCOUNT, конструкцию SERVICE_AMOUNT.
Ибо первая у меня никак не заработала, а вторая нормально работает. Я начинаю подозревать что опечатка в доке по поводу данного механизма.
Автор:  WhiteWind [ 08 июн 2009, 17:53 ]
Заголовок сообщения: 
Ровным счётом ничего не изменилось - SERVICE_ACCOUNT и SERVICE_AMOUNT дают одинаковый результат.

Разработчики, вы где?
Автор:  Администратор [ 09 июн 2009, 12:12 ]
Заголовок сообщения: 
Цитата:
Да. Исходя из установленных периодов приостановления/отключения/закрытия договоров, смены тарифных планов (менять статус договора и тарифные планы можно и в будущем) рассчитывать размер абонплаты на следующий месяц

Это невозможно. Макрос SERVICE_ACCOUNT просто берет наработку из таблицы contract_account, т.е. абонплата уже должна быть начислена.
Автор:  WhiteWind [ 09 июн 2009, 12:27 ]
Заголовок сообщения: 
Я так и думал.

И как вы посоветуете выходить из сложившейся ситуации?
И будете ли вы как нибудь с ней бороться?
Автор:  Jimson [ 09 июн 2009, 12:42 ]
Заголовок сообщения: 
С чем бороться ?
Расскажи подробно что ты хочешь сделать, только не фантазии на тему что бы мог сделать биллинг, а именно результат, что и когда ты хочешь получить: такой то счет на такие то услуги такого то числа за такой то месяц и тд и тп.
Автор:  WhiteWind [ 09 июн 2009, 12:59 ]
Заголовок сообщения: 
Я хочу в июне, до 5-го числа, выставить счёт на предоплату услуг за июнь. Т.е. если в договоре есть абонплата с подневным режимом снятия до текущего дня со стоимостью 1000р в месяц, то я ожидаю, что в счёте будет позиция, соответствующая этой абонплате с суммой 1000р.

Я полагаю, что этого можно добиться сменив тип абонплаты на "подневной режим снятия до конца месяца", но я хочу, чтобы абонплата снималась по дням.
Автор:  max [ 09 июн 2009, 19:34 ]
Заголовок сообщения: 
Jimson писал(а):
я для решения данной проблемы добавляю в счета корректировку, которую вычисляю как сумма выставленных счетов указанного типа минус наработки по услугам, немного громоздко в конфиге, но работает...
поделитесь рецептом?
Автор:  Jimson [ 09 июн 2009, 21:37 ]
Заголовок сообщения: 
у меня есть два типа абон план за услуги передачи данных: обычная фиксированная абон плата (id=4) и доводящая абон плата (id=5), которая "съедается" наработкой по модулю IPN.

Абон плату в счетах я выставляю одной позицией:

bill.pos.100.title=[A] Абонплата за передачу данных
bill.pos.100.name=Абонентская плата за услуги передачи данных
bill.pos.100.summ=NPAY_MIN_ACCOUNT(2, $month, 5) + SERVICE_AMOUNT($month, 4)
bill.pos.100.unit=--

эта позиция присутсвует в шаблонах "авансовый счет" и "единый счет". Ну и есть еще куча всяких позиций типа "тех обслуживание", "абон плату за резервинования CIR", абон платы за воип услуги и тд и тп, вообщем некий перечень позиций, которые в свою очередь формируются наработками по перечню услуг, за которые я хочу выставить счет авансом. В моем случае это все услуги модуля NPAY.

Тип документа "авансовый счет" выставляется от первого числа каждого месяца, а "единый" понятное дело от последнего числа месяца. Грубо говоря, в понедельник 1-го июня, я прийдя на работу сгенерил счета за МАЙ от 31.05.2009 по типам "единый" и "доплаты", затем сгенерил акты/сф за МАЙ от 31.05.2009, затем сгенерил счета за ИЮНЬ от 1.06.2009 по типам "авансовый".

Для корректировки выставленных авансом абон плат есть позиция:
bill.pos.900.title=[А] Корректировка абонплаты
bill.pos.900.name=Корректировка абонентской платы
bill.pos.900.summ=SERVICE_ACCOUNT($month, 3, 4, 8, 9, 12,14,15, 16, 17, 18, 21) + NPAY_MIN_ACCOUNT(2, $month, 5) - BILL_BILL_SUM(3, $month, 1)
bill.pos.900.unit=--

эта позиция включена только в тип документа счетов "доплаты", в едином она понятное дело не нужна.

Итак, берется наработка по _всем_ услугам которые участвуют в формировании позиций типа документа "Авансовый счет" (id = 1), по доводящей абон плате (id = 5) берется не наработка а максимальный предел макросом NPAY_MIN_ACCOUNT (я хз почему его min обозвали, но не суть важно), из этой суммы вычитается сумма счета с типом документа ID=1 за этот же месяц по модулю с ID=3 (модуль bill).

Т.е. когда я выставлял авансы, то наработка по адон платам была допустим X рублей, по итогам же прошедшего месяца она стала Y рублей (приостановки договоров, изменения тарифных планов и тп), соответсвенно корректировка будет равна X-Y рублей.

Дальше варианты:
1) корректировка положительна, все OK, клиент доплачивает, если у него какие то вопросы возникнут он просто сравнивает авансовый и доплатный счет с актом и видит откуда взялась корректировка, так как в акте будет уже реальная наработки по всем услугам которые выставлялись авансом, в том числе если авансового счета небыло вообще (клиент включился в середине месяца и ему не стали выставлять авансовый счет руками) он увидит все наработки по своим абон платам в актах/сф, а доплатном счете будет просто положительная корректировка.

2) корректировка нулевая, ну тут все понятно, эта позиция просто исчезнет из документа когда он будет создаваться.

3) корректировка отрицательная но меньше чем наработка по сумме доплатных позиций, иначе говоря сумма счета остается положительной или нулевой, тут все тоже нормально, клиент все поймет посмотрев в акты

4) корректировка отрицательная и больше наработок по услугам выставляемых как "доплаты", вот тут немного фигня выходит, это отрицательный счет, ваша бухгалтерия с этим счетом дело иметь не захочет, да и клиенту он нафик не уперся. В большинстве случаев по таким договорам и оплаты по авансовому счету небыло еще, они заплатят уже по факту получения актов и проблем ни у кого не будет. Иногда же договор блокируется уже после получения аванса, тогда на договоре висит положительное сальдо, если договор будет снова активирован через сколько то месяцев то это положительное сальдо надо будет как то вычитать из суммы счета, но это ни в коем случае нельзя делать ручным модифицированием документа с типом "авансовый счет", иначе в итоговом счете вылезет неправильная корректировка (X-Y, где Y лажа, нарисованная руками). Вообщем у нас за этим есть кому следить.
Если же договор расторгается, то биллинг тут опять же не при делах, все разборки с положительным сальдо ложатся на плечи бухгалтерии, там своя механика возврата денег и в нее вам лучше не вникать.


вроде все, если что не понятно спрашивайте
Автор:  Jimson [ 09 июн 2009, 21:43 ]
Заголовок сообщения: 
WhiteWind писал(а):
Я полагаю, что этого можно добиться сменив тип абонплаты на "подневной режим снятия до конца месяца", но я хочу, чтобы абонплата снималась по дням.


ну не получится так, пока нет наработки вы не сможете выставить счет стандартным способом, с извратами если, тогда надо в шаблоне генерирующем авансовый счет городить таррификацию услуг для вычисления месячной наработки, я бы не советовал с этим связываться, это костыли из пластелина выйдут
Автор:  WhiteWind [ 10 июн 2009, 07:53 ]
Заголовок сообщения: 
Если я правильно понял, то сумма аванса за текущий месяц полагается равной наработке за прошлый месяц, или как?

Цитата:
ну не получится так, пока нет наработки вы не сможете выставить счет стандартным способом


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

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

Это можно легко решить, если добавить новый макрос для позиции счёта, который будет считать размер указанной абонплаты как если бы она была "подневной режим снятия авансом за месяц".

Разработчики, насколько это сложно, и можно ли рассчитывать на то, что вы сделаете это безвозмездно?
Автор:  Администратор [ 10 июн 2009, 11:07 ]
Заголовок сообщения: 
Цитата:
Разработчики, насколько это сложно, и можно ли рассчитывать на то, что вы сделаете это безвозмездно?

Это сложно. Т.к. вместо получения одной суммы из базы, нужно запустить фактически процесс тарификации с выводом результата не в базу а в счет. Рассчитывать не стоит, тем более, что подобных запросов больше пока не было.
Автор:  skn [ 10 июн 2009, 12:09 ]
Заголовок сообщения: 
а нафига такой алгоритм?

например, что будет если клиент 10 числа приостановит договор на 5 дней...
вроде счет выставлен на полную абонплату, а реально снято за 25 дней...
Автор:  Jimson [ 10 июн 2009, 12:57 ]
Заголовок сообщения: 
проверь чем заполнится npay_add_cost_detail_x_y если тариф по доводящей абон плате сделать с подневным снятием, очень может быть что там окажется месячная наработка, которую ты и выставишь в счетах через NPAY_MIN_ACOOUNT()
но вообще, это ппц какой бред, сам по суди "АВАНСОВАЯ за месяц ! абонплата с подневным снятием", претендент на bash.org или где там щас постят такое )

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


skn, делать в этом случае именно то что описал я выше, но к подневному снятию это уже отношения не имеет
Автор:  WhiteWind [ 10 июн 2009, 16:09 ]
Заголовок сообщения: 
skn писал(а):
а нафига такой алгоритм?

например, что будет если клиент 10 числа приостановит договор на 5 дней...
вроде счет выставлен на полную абонплату, а реально снято за 25 дней...


Если он напишет заявление о приостановлении до выставления счёта, то ему и выставится за 25 счёт, а если после - то будет точно так же, как бухгалтерия делает и без биллинга.

Jimson писал(а):
но вообще, это ппц какой бред, сам по суди "АВАНСОВАЯ за месяц ! абонплата с подневным снятием", претендент на bash.org или где там щас постят такое )

Не бред. Мне нужно выставить авансовый счёт клиенту, но я не хочу, чтобы он отключился в начале месяца, если у него хватает денег на 20 дней работы.
Автор:  skn [ 10 июн 2009, 16:58 ]
Заголовок сообщения: 
у вас в договоре что написано?
абонплата за месяц или за день?
предоплата или по факту?
Автор:  ЛИС [ 17 июн 2009, 04:21 ]
Заголовок сообщения: 
WhiteWind писал(а):
Если я правильно понял, то сумма аванса за текущий месяц полагается равной наработке за прошлый месяц, или как?

Нельзя так делать! так как в новом месяце может быть другой тариф!!!

Администратор писал(а):
Это сложно. Т.к. вместо получения одной суммы из базы, нужно запустить фактически процесс тарификации с выводом результата не в базу а в счет.


Это может быть и сложно, но нужно. Именно так, посчитать за будущий месяц, с учетом действующих тарифов в тот момент. Авансовый платеж для этого и предназначен, что юзверь платит авансом... выберет он эту сумму, или переберет будет учтено в акте, который будет в БУДУЩЕМ, когда этот период, за который СЕЙЧАС выставлен аванс, превратится в ПРОШЛОЕ))))

Администратор писал(а):
Рассчитывать не стоит, тем более, что подобных запросов больше пока не было.


А вот тут Вы лукавите!!!
Этот запрос Вы получали от меня... Непомню точно дату (посмотрите, когда я модуль покупал!), но очень давно...
Мне Шамиль обещал поставить в to do..... Был разговор, что или быстро за деньги или медленно но бесплатно.... Сроки все вышли))))
Тем более, что в документации все это описано, как действующий функционал!!! Край делать, что бы работало как в документации!!!
ЗЫ
но как мы работаем давно, могу немного и заплатить.... Хотя, судя по ветке функционал будет востребован!!!! Оставляю этот вопрос на Вашу совесть)))))
Автор:  Администратор [ 17 июн 2009, 12:45 ]
Заголовок сообщения: 
Цитата:
Мне Шамиль обещал поставить в to do..... Был разговор, что или быстро за деньги или медленно но бесплатно.... Сроки все вышли))))
Тем более, что в документации все это описано, как действующий функционал!!! Край делать, что бы работало как в документации!!!

Макрос в документации просто выбирает наработку за будущий месяц, если она уже начислена.. Вроде это и было обещано и сделано. Сделать макрос, который запускает тарификатор - это гораздо сложнее. Да и генерация счетов тормозить будет.

Если покажете любой фрагмент текста, где я вам это обещал - это будет сделано.

Возможно, проще сначала запускать тарификацию с занесением наработки в какие-то фиктивные таблицы. И сделать макрос выборки из этих фиктивных таблиц..
Автор:  ЛИС [ 17 июн 2009, 15:37 ]
Заголовок сообщения: 
Администратор писал(а):
Макрос в документации просто выбирает наработку за будущий месяц, если она уже начислена.. Вроде это и было обещано и сделано.
....Если покажете любой фрагмент текста, где я вам это обещал - это будет сделано.

Сразу после приобретения модуля мы с Вами общались по телефону (извините, я Вам доверяю и разговоры не записываю!).
Именно это, только другими словами Вы и сказали, что тяжело сделать вычисление будущих расходов для авансовых счетов, что надо отдельную таблицу и т.д. После Вы сказали, что так как это сложно, то будет дорого сделать в текущей (на тот момент 4.3) версии, но Вы поставите в To Do лист на будущие версии...
Конечно, моя вина, надо было звонить, напоминать!))))
Но теперь, когда не только у меня есть интерес, может сделаете???
Я готов оплатить, но не очень дорого.....

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

Пусть тормозит, это раз в месяц!!!
Как делать, Вам виднее!!!
Автор:  Администратор [ 17 июн 2009, 16:29 ]
Заголовок сообщения: 
Цитата:
Именно это, только другими словами Вы и сказали, что тяжело сделать вычисление будущих расходов для авансовых счетов, что надо отдельную таблицу и т.д. После Вы сказали, что так как это сложно, то будет дорого сделать в текущей (на тот момент 4.3) версии, но Вы поставите в To Do лист на будущие версии...

Хм. Ну может быть, спорить не буду..
В TODO ничего в данный момент такого нет. Теперь уже не знаю: я ли не занес, удалил ли, т.к. никто не спрашивал или что еще..
Если есть интерес - пишите на почту, обговорим конкретно алгоритм реализации, сроки и цену.
Пока, получается, запрос был на подобный функционал от двух клиентов. Т.е. все равно низковостребован.
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/