BiTel

V4.5
Делаю все как в (цитата): "Пример 14.2. Пример второй

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

А в счете НОЛЬ где должна быть предоплата абонплаты за следующий месяц!
Что делаю не так?

Конфиги и скрины выложите.

У меня возникла подобная проблема. В конфигурации написано:

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

Как выставлять счета на предоплату? Единственный вариант, который я вижу сейчас - переделать абонплаты на "подневной режим снятия авансом за месяц" и выставлять счета в текущем месяце, но этот вариант нам не подходит

А какую сумму-то ставить в позицию? Размер абонплаты в следующем месяце?

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

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

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

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

вообщем если интересно будет я подробнее опишу свои мытарства с авансами на кредитных договорах

Я не совсем понимаю, что такое доплатный счёт, это счёт в конце месяца, допустим, за трафик, который невозможно выставить авансом?


Вот-вот. Мне хочется узнать, что же я буду делать) И очень бы не хотелось узнать, что мне придётся делать систему костылей и подпорок. Поэтому я и прошу у разработчиков какого-нибудь совета, а лучше функционала

Попробуйте вместо конструкции SERVICE_ACCOUNT, конструкцию SERVICE_AMOUNT.
Ибо первая у меня никак не заработала, а вторая нормально работает. Я начинаю подозревать что опечатка в доке по поводу данного механизма.

Ровным счётом ничего не изменилось - SERVICE_ACCOUNT и SERVICE_AMOUNT дают одинаковый результат.

Разработчики, вы где?

Это невозможно. Макрос SERVICE_ACCOUNT просто берет наработку из таблицы contract_account, т.е. абонплата уже должна быть начислена.

Я так и думал.

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

С чем бороться ?
Расскажи подробно что ты хочешь сделать, только не фантазии на тему что бы мог сделать биллинг, а именно результат, что и когда ты хочешь получить: такой то счет на такие то услуги такого то числа за такой то месяц и тд и тп.

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

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

поделитесь рецептом?

у меня есть два типа абон план за услуги передачи данных: обычная фиксированная абон плата (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 лажа, нарисованная руками). Вообщем у нас за этим есть кому следить.
Если же договор расторгается, то биллинг тут опять же не при делах, все разборки с положительным сальдо ложатся на плечи бухгалтерии, там своя механика возврата денег и в нее вам лучше не вникать.


вроде все, если что не понятно спрашивайте

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

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



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

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

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

Разработчики, насколько это сложно, и можно ли рассчитывать на то, что вы сделаете это безвозмездно?

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

а нафига такой алгоритм?

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

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

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


skn, делать в этом случае именно то что описал я выше, но к подневному снятию это уже отношения не имеет

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


Не бред. Мне нужно выставить авансовый счёт клиенту, но я не хочу, чтобы он отключился в начале месяца, если у него хватает денег на 20 дней работы.

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

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



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



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

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

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

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

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


Пусть тормозит, это раз в месяц!!!
Как делать, Вам виднее!!!

Хм. Ну может быть, спорить не буду..
В TODO ничего в данный момент такого нет. Теперь уже не знаю: я ли не занес, удалил ли, т.к. никто не спрашивал или что еще..
Если есть интерес - пишите на почту, обговорим конкретно алгоритм реализации, сроки и цену.
Пока, получается, запрос был на подобный функционал от двух клиентов. Т.е. все равно низковостребован.