Как работает биллинг: принципы и особенности биллинговых систем

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

Есть 2 основных типа расчета:

• Постоплата — выставление счёта за период по его итогам (postpaid)
• И авансовая система (prepaid), когда деньги заносятся заранее.

Постоплатная система

Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN — circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система

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

Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

По этому протоколу OCS общается с сетью коммутации каналов. Вот пример тарификации исходящего голосового вызова:

Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

1. Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point — то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
2. После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
3. Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
4. MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
5. Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
6. MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
7. Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
8. В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
9. MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
10. OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

--- INVOKE ---
 A1     TAG    : A1h [1]
 1B     LEN    : 27
      --- INVOKE ID ---
 02       TAG    : 02h INTEGER
 01       LEN    : 1
 02       INVOKE ID  : 2
       === CAP ===
         --- INVOKE ---
         --- OPERATION ---
 02      TAG    : 02h INTEGER
 01      LEN    : 1
 23      OPERATION  : 35 = applyCharging
       --- APPL CHARG ---
 30        TAG    : 30h SEQUENCE
 13        LEN    : 19
         --- ACH BCC ---
 80      TAG    : 80h [0]
 0C      LEN    : 12
       --- TDC ---
 A0        TAG    : A0h [0]
 0A        LEN    : 10
         --- MAX C P D ---
 80          TAG    : 80h [0]
 03          LEN    : 3
 01 19 40        MAX C P D  : 4370

Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD — Maximum Call Period Duration) равно 437,0 сек.

Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

1. При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
2. В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
3. Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
4. Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
5. Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
6. Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
7. Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
8. При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.

Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

Ссылки

как действуют и что это такое?

Биллинг представляет собой систему дистанционных взаиморасчетов, передачи денежных средств. Действует данная система во многих сферах человеческой жизни. От энергетики до рекламы и науки. В современном мире это эффективный инструмент для произведения расчетов, сбора информации о клиентах.

Значение термина

Биллинг (от англ. bill – счет) – система контроля оплаты услуг. Сюда входит расчет тарификации, выставление счетов на оплату. Система работает по принципу модульного действия. То есть однотипно для разных сфер жизни. Особенность биллинговых расчетов – клиент может не иметь банковского счета. Проводимые операции действуют без индивидуальных счетов.

Система действует прозрачно для налоговых органов и участников платежей. В то же время операции с деньгами закрыты от несанкционированного доступа посторонних лиц.

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

Биллинг в бюджетной сфере

Для расчетов бюджетной сферы (в том числе ЖКХ) биллинг стал основой расчетов. Система незаменима при оплате пошлин, налогов, электроэнергии, газоснабжения.

Как работает биллинг в бюджетной сфере:

• формируется платежка;
• отправка платежки клиенту-плательщику;
• внесение плательщиком оплаты по платежке через банк, терминал либо банкомат;
• получение квитанции об оплате.

Для плательщика удобно, что все необходимые реквизиты уже находятся в системе. Биллинг работает в автоматическом режиме. Клиенту следует лишь найти в списке услуг ту, что необходимо оплатить. А также выбрать фирму-получателя денег. ИНН и другие данные получателя самопроизвольно высветятся в окне платежа. Клиент проверит данные и нажмет кнопку «Оплатить».

Денежные средства перечисляются моментально. Причем клиент способен отследить движение денег.

В программное обеспечение входят данные о каждом плательщике. В том числе его льготы. К примеру, льготы инвалидов либо пожилых людей, пенсионеров. Человеку для получения льготы следует представить соответствующий документ. То есть для получения налоговой льготы в налоговую службу. Единоразово. Далее работник внесет данные в программу. Платежи автоматически перейдут на другую тарификацию.

Что делать, если вы забыли распечатать квитанцию об оплате? Это распространенная ошибка плательщиков. Но, ошибка не страшна. Автоматическая система имеет архив платежей. Через онлайн-режим можно зайти в систему, найти проведенный платеж, распечатать квитанцию. Подобная система действует при оплате через онлайн-кабинеты на личной страничке банков.

Телекоммуникации и биллинг

Самые распространенные расчеты по биллинговой системе – оплата счетов телефона, телевидения. Многие люди не задумываются об этом. Подходя к терминалу, внося средства не номер телефона, они производят оплату через систему биллинга.

Эффект системы клиент чувствует сразу. Платежи начисляются в течение пары минут при минимальных комиссиях. Зачастую комиссии и вовсе отсутствуют.

Работает способ аналогично бюджетной сфере. Клиент подходит к банкомату, терминалу. Выбирает в списке оператора, вводит номер телефона либо договора на телевидение. Вносит сумму. Нажимает кнопку «Оплатить». Тут же через онлайн-кабинет оператора возможно проследить движение денег.

Банковский биллинг

Банковские операции перевода денежных средств тесно связаны с расчетами биллинговой системы. С помощью подобной автоматизации клиент самостоятельно способен оплатить через банкомат любые платежи. Но не только это. Плательщик может войти в систему, как зарегистрированный пользователь. А также изменить данные для платежей. К примеру, сменить тарифный план, или отключить услугу.

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

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

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

Что такое биллинг | Forward Telecom

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

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

Совокупность всех цикличных операций, продуцируемых программой, называется биллингом. Подобный «софт» используется не только операторами сотовой связи. С его помощью интернет-провайдеры выставляют счета и ведут учет объемов трафика. Благодаря биллинговой системе можно провести анализ показателей в стационарной телефонии, например, направление и продолжительность звонков. Представители операторов IP-телефонии также являются пользователями биллингового ПО.

Биллинговые системы создаются на основе многофункциональных систем управления базами данных. Наиболее часто используемыми СУБД являются Oracle, Informix и Sybase. Последние две рассчитаны на работу с большими объемами информации и могут быть взяты за основу для БС для транснациональных операторов мобильной связи. Среди телекоммуникационных операторов наиболее популярны БС CBOSS, BIS, Bill-2000-prepaid, Flagship и Arbor.

Сущность и качества БС, востребованных среди операторов сотовой связи

Биллинговые системы часто носят другие названия, полностью отражающие их суть:

• ИБС – информационная биллинговая система;
• АСР – автоматизированная система расчетов.

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

Настраиваемость

Возможность внедрения дополнительных настроек дает возможность расширить возможности системы и обеспечить решение большего количества задач.

Гибкость

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

Открытость

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

Модульность построения системы

Использование модулей, специализированных независимых друг от друга подсистем, позволяет упростить тестирование программы и строго разделить задачи, решением которых будет заниматься БС. Функционирование каждого блока программы будет максимально автономным. Так, например, частью биллинговой системы могут быть подсистема оповещения абонентов или предварительной обработки данных, модуль оперативного управления биллингом.

Масштабируемость

Рост абонентской базы, увеличение спектра предоставляемых услуг не должны повлечь за собой потребность в доработке программной части биллинговой системы. Расширение ее возможностей должно осуществляться за счет модернизации аппаратной части БС. При этом сама СУБД должна интегрироваться с различными платформами для многопроцессорного и бесперебойного режима работы.

Надежность

Одно из ведущих качеств БС, как и любых других «софт»-продуктов. Его уровень определяется надежностью технологий и СУБД, а также соблюдением стандартов, которые использовались при разработке системы.

Мультиязычность и мультивалютность

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

Оптимизация биллинга

Самостоятельное улучшение БС оператором – важное качество, позволяющее расширить потенциал системы и увеличить число решаемых задач. Оптимизация неотрывно связана с открытостью и невозможна без прозрачности действий разработчика. К дополнительным полезным качествам биллинговой системы относятся отложенный и горячий биллинг. В первом случае расчеты производятся после завершения состоявшихся звонков, во втором – непосредственно в процессе разговора, а новый соответствующий реальной действительности баланс счета становится доступным сразу после окончания звонка. Постинг биллинга как дополнительная особенность бухгалтерской системы для оператора сотовой связи позволяет фиксировать результаты расчета и делать их доступными для абонентов, например, благодаря рассылке.

Возможности современных БС для операторов связи

Одной из ведущих задач биллинговой системы является автоматизация корректных расчетов с клиентами от момента заключения договора до выписки со счетов. Но на этом функционал АСР не завершает свое многообразие. Современные БС не ограничивают абонентов в самообслуживании благодаря подсистемам автоматического сбора данных и автоматизации услуг. Благодаря им может быть произведено подключение или оплата услуги через Интернет.

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

Биллинговые системы: функции и структура АСР

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

• клиентские данные;
• условия контрактов с абонентами;
• стоимость передачи информации через дилеров;
• наличие сторонних поставщиков услуг.

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

Спектр функциональных возможностей БС позволяет разделить их на три категории:

• БС для транснациональных операторов связи обеспечивают работу сетей на международном уровне и обязаны обладать качествами мультивалютности и мультиязычности.
• Заказные БС национального уровня разрабатываются для работы с конкретным оператором, фактически являются штучными биллинговыми системами и могут нуждаться в интеграции с уже функционирующей системой расчетов. Это обуславливает сложность их создания, из-за чего они остаются достаточно дорогостоящими.
• Региональные системы среднего класса обладают всеми необходимыми базовыми качествами БС, но используются в пределах определенных областей.

Разработчики БС ориентируются на потребности определенного оператора, при ее создании учитывается бизнес-процесс конкретного предприятия с его оборудованием, технологическим циклом предоставления услуг связи. При этом любая биллинговая система сохраняет и унифицированный функционал, присущий любой АСР для телекоммуникационных операторов всех категорий.

Предварительный анализ и обработка базовой информации

К подобным операциям можно отнести любые запросы к коммутатору: получение данных о соединениях и предоставленных услугах.

Управление сетевым оборудованием

Указанные операции включают активацию или блокировку абонентов, изменение условий тарификации и подписки пользователей, находящихся в СУБД оператора.

Базовые функции СУБД:

• формирование и правка таблиц в базе данных расчетной системы;
• запись коммутатора о вызовах и оказанных услугах, их тарификация, основанная на закрепленных в базе условиях;
• выставление текущих счетов, их печать для абонентов;
• формирование отчетов;
• управление кредитной линией абонентских счетов;
• архивация и хранение информации.

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

Модуль предварительной обработки данных

В этом приложении происходит сбор и анализ информации о соединениях абонента, определяется тип услуги и параметры используемого трафика: источник и направление звонков, условия роуминга, взаиморасчеты с дилерами услуг связи. Ключом модуля является декодер исходной информации о соединениях. Наиболее сложной среди всех выполняемых операций в этом модуле является роуминг. Это связано с необходимостью конвертации записей всех форматов от разных коммутаторов из БС в формат, используемый в конкретной биллинговой системе. При этом должны быть учтены все стандарты передачи данных.

Для этого создаются служебные таблицы, материалом для которых служат тарифицированные записи о соединениях между задействованными операторами. После остальные модули используют собранную и систематизированную в таблицах информацию для произведения расчетов с абонентами, формирования отчетов и проведения взаиморасчетов с другими телекоммуникационными операторами. Применение своеобразных «интеллектуальных систем» внутри БС дает возможность обрабатывать разные виды услуг, выставляя счет в удобном и для абонента, и для оператора формате.

Модуль оперативного управления биллингом

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

Модуль оповещения абонентов

Голосовые, текстовые и другие сообщения от оператора его абонентам – важная составляющая биллинга. Основой для формирования оповещения также является информация из СУБД. Подобное деление БС на функциональные модули является классическим примером АСР, но не считается единственным возможным для всех биллинговых систем.

Биллинг и история формирования его мировых стандартов

Необходимость осуществления взаимодействия между разными операторами мобильной связи послужила началом для выработки определенных стандартов биллинга. Формирование общих норм нужно, например, при поддержке роуминга.

Стандарты биллинга делятся на три международные группы. Так, в 1998 году американским институтом стандартов ANSI был разработан и утвержден стандарт ANSI 124. Его дальнейшее развитие и усовершенствование для новых потребностей операторов и их абонентов полностью зависит от ассоциации TIA. Компания CIBERNET также занялась уточнением и делением бизнес-процессов, происходящих при передаче сообщений внутри этого стандарта. Рабочей группой компании была сформулирована новая категория стандартов NSDP-B&S. Спецификации этого класса подразумевают полное соответствие всех процессов, осуществляемых операторами, и информации, которая передается во время операций по обмену данными между коммутаторами по стандарту ANSI 124.

С 1998 года и по настоящее время CIBERNET совместно со своим комитетом CAC-IS поддерживает биллинговый стандарт CIBER, который является первым североамериканским стандартом биллинга. Под эгидой CAC-IS объединены разработчики БС и телекоммуникационные операторы, благодаря чему обеспечено продуктивное взаимодействие создателей и непосредственных пользователей биллинговых систем. CIBER применяется в сотовых сетях стандарта AMPS. В Европе же был сформирован стандарт ТАР, который используется с 1992 года. Курирование норматива осуществляется рабочей группой TADIG. Действующие телекоммуникационные европейские операторы используют вторую спецификацию стандарта ТАР2, хотя уже сформулирована и утверждена и третья версия. Спецификация TD.27, известная и как NAGTAP2, является модификацией ТАР2 и применяется на территории США с 1995 года.

Мобильный билинг. Биллинговые системы: основные понятия.

Статья о пониятии биллинг по номеру телефона/

Навигация

Биллинг ! Какое звучное, загадочное слово!
Как звучит сухая расшифровка этого слова в Википедии, Биллинг означает комплексные меры, действия, решения, на предприятиях связи, где проходит сбор информации о разных видах услуг связи, расценках операторов, счетов клиентам, обработки платежных счетов.

Биллинг — навигация на мобильном телефоне.

По сути, Биллинг – система, это дополнительная программа для поддержки бизнес – услуг в сфере коммуникации.

Что значит биллинг по номеру телефона?

Биллинг по номеру телефона, а точнее биллинг среди операторов сотовой связи, это серия услуг, предлагаемых абоненту. Выделяются следующие услуги по данному направлению:

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

Как все это происходит?

Допустим, нам надо найти человека, установить координаты его нахождения, то есть провести биллинг – операцию.
Обычный звонок, это конкретная группа действий. Как указывалось выше, любой сотовый телефон имеет свой код (имейл). При звонках, то есть авторизации в сети мобильной связи, код работает, как номер серии телефонного аппарата. Код используется также, для отслеживания за телефонными устройствами (к примеру, крадеными), блокирования.
Код — идентификатор (имейл) остается постоянным, как бы не изменялась СИМ карта. Вычислить, кто пользовался СИМ – картой, не составляет труда.

С каждого телефона идут входные и выходные вызова, сообщения. По данным действиям оператор, также, может узнать, где находится человек.

Как работает абонентская сотовая связь?

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

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

Самому абоненту заниматься биллингом, без разрешения соответствующих органов, запрещено.
Биллинг , очень действенное, сильное, но дорогостоящее средство поиска.

Биллинг. Какие ассоциации вызывает этот термин? Может быть, есть какая-то связь с Биллом Гейтсом? Нет, к счастью он еще не «сунул свой нос» в область телекоммуникаций. Ну это так — шутка. А если быть серьезным, то давайте рассмотрим происхождение слова биллинг. Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».

Что такое биллинговая система?

Системы, вычисляющие стоимость услуг связи для каждого клиента и хранящие информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются телекоммуникационными операторами для выставления счетов абонентам и взаиморасчетов с другими поставщиками услуг, носят название биллинговых; цикл выполняемых ими операций именуется биллингом. Биллинговая система (БС) — это бухгалтерская система, программное обеспечение, иными словами — «софт», разработанный специально для операторов. Каких операторов? Телекоммуникационных. Т. е. речь не идет лишь об операторах сотовой связи. БС используются также операторами обычной (стационарной, проводной) связи. В малых офисах, например, можно вести биллинг телефонии (анализировать: кто звонил, когда, сколько длился разговор). IP-телефония — другая область применения БС. А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД). Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выд

Обзор биллинговой системы BGBilling / Хабр

Предыстория

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

Заказывать разработку новой системы под свои задачи — слишком дорого и слишком долго. Поэтому встала задача — найти подходящее решение. Выбор в итоге пал на BGBilling. В итоге вот уже год как мы работаем с этой системы и в целом всем довольны. Почему мы выбрали именно систему и чем она хороша (минусы тоже постараюсь осветить) постараюсь подробно изложить ниже.

Введение

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

Пожалуй, начнем.

О системе

Система — российская. Сайт — bgbilling.ru
Как я понял, система писалась для сети УфаНет, и потом выросла в отдельный продукт. Разработка идет где-то с 2003 года. Текущая версия 5.0 (у нас стоит 4.6, отличий от текущей — практически никаких, новая версия была вызвана окончанием действия сертификата), в разработке находится версия 5.1, в которой разработчики обещают много нового, но про нее пока я ничего сказать не могу.

Архитектура системы — серверная часть написана на Java. Первое время беспокоила производительность и стабильность такой системы. По прошествии года могу сказать — с производительностью и стабильностью нет никаких проблем. Но есть одно НО. Сервер требует последнюю Java, а с ней есть определенные проблемы на FreeBSD. Поэтому этой системы нет в списке поддерживаемых. Но зато есть — Windows, Linux. Конкретно у нас стоит на Fedora 10. Mac как поддерживаемая платформа не заявляется, но в целом мне ничто не помешало запустить сервер и клиент у себя на ноутбуке. СУБД — MySQL.

Документированность БД — изумительная. Идем на сайт dbinfo.bitel.ru и шаримся, смотрим что и как с чем связано, какие параметры могут быть. Честно признаюсь, для меня документированность БД была одним из решающих факторов. Было ясно, что функционал специфичный только для нас придется допиливать самому, поэтому такое подспорье как адекватная документация, меня как радовали, так все больше и радуют.

Клиент для оператора биллинга — отдельное GUI приложение.

Что следует отметить — в клиенте есть встроенные sql редактор, который из самого клиента позволяет выполнять зарпосы к бд и получать результаты в удобоваримом виде.

Стоимость, лицензии и прочее

Система — модульная. Каждый модуль имеет количество лицензий с которыми он может работать (или бесконечное количество). Чем больше лицензий — тем дороже модуль. Максимальная цена — за бесконечное количество лицензий.

Какие модули стоит выделить — модуль списания абонентский плат, модуль diap up, модуль ipn, voiceip. Рассчитать стоимость лицензии можно на сайте — bgbilling.ru/price_count.shtml

Какие модули кому нужны будут? Без модуля абонентских плат — никуда. Берем его, максмальная цена за бесконечное количество лицензий (бесконечное начинается с 10000 лицензий) — ~100тр.
А теперь смотрим чем мы занимаемся? Оператору КТВ по сути больше ничего не нужно. Провайдеру еще бы и модуль работы с сетью. Это или IPN или DialUP — и тот и другой максимально стоят тоже порядка 100тр.
Модуль телефонии — один из самых дорогих. Порядка 240тр.
Остальные модули — voiceip, модуль цифрового телевидения — по-моему не так популярны, их рассматривать не будем. Если интересно — можно посчитать на сайте.

Техподдержка, комьюнити

Спорный вопрос по техподдержке. Она платная. При покупке лицензии предлагается заключить контракт на техподдержку и приобрести пакет обращений. За 25тр можно получить 50 обращений на год. За 9тр — 15 обращений, тоже на год. Много это или мало? Мы использовали за год — 5 обращений. Сообщения об ошибках за обращения не засчитываются, но для их сообщения все равно нужен пакет хоть с одним обращением.

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

Что и приводит нас к вопросу о комьюнити и вики-базе. Сообщество мне очень понравилось. На форуме можно найти помощи практически по любому вопросу. В последнее время и ко мне в аську начали с вопросами обращаться, с радостью подсказываю, если знаю что и как.

Производительность и факапы

Официальные данные представлены на соответствующей странице сайта — bgbilling.ru/program/speed.shtml. В целом им можно верить. АП списываются довольно шустро. Радиус(мы используем модуль DiapUP для доступа к сети) держит нагрузку при одновременной авторизации 1000-1500пользователей (пропадаение света в районе, а потом включение) вполне нормально. Радиус же занимается обсчетом нетфлоу статистики. Справляется с потоком от 6 цисок с гигабитом трафика на каждой.

Если не считать факапов вызванных своими кривыми руками, то был один довольно неприятный факап 1 января 2010 года. На каждый месяц автоматически создаются новые таблицы с балансом. Из-за какой то недоработки в логике в 2010 году новые таблицы не создались. Поэтому в момент списания АП у всех был 0 на счету. Благо БД очень хорошо документирована и есть функции групповых операций — это удалось очень быстро устранить (до того как большая часть абонентов отошла от похмелья и полезла в интернет).

Запуск, перенос существующих баз

Настройка и запуск системы осуществляются довольно просто, особо выделить даже нечего. Распаковать архив, добавить исполняемые .sh в автозапуск, загрузить структуру таблицы из файла дампа и пожалуй все — уже будет работать =).

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

Кстати про распределение нагрузки. Все задачи сваливаются в очередь, которую обрабатывает шедулер. Причем он практически никак не связан с сервером. Т.е. задача на выгрузку статистики, переобсчет трафика — нагрузит шедулер, но никак не скажется на производительности самого сервера биллинга — он будет работать в нормальном режиме, складывая задачи в очередь, будет давать доступ до бд радиусу и других модулям.

Заключение, сравнение с другими системами

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

Сравнить с другими системами особо возможностей и не было. По отзывам тех кто переезжает с UTM — небо и земля — документированность и открытость бд, возможность дописать свои скрипты, реализовать собственную бизнес логику.

PS если появились какие-то вопросы — задавайте, постараюсь ответить.

Типовая схема биллинга / Хабр

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

В итоге сейчас уже имея довольно большой опыт работы с АСР я решил сделать свою схему. Но так-как я все же один человек, то ее стоит показать другим и подвергнуть критике. Так что я надеюсь их эта тема заинтересует и они мне расскажут что еще стоит сделать и как. Схема которую я публикую здесь, уже подвергнута улучшениям и корректировкам, а так же уже есть возможность скачать ее с github. Как в виде файла для Power Architect так и в виде готового DDL файла для PostgreSQL. Единственное я не успел еще заполнить справочники, но всему свое время. А сейчас переходим к схеме.

Первым делом стоит посмотреть на ER-диаграмму, как наиболее удобное средство представление схемы.

Как видите хотя таблиц довольно много, на самом деле функционал достаточно небольшой.
И состоит из следующих возможностей:

• Хранение договора клиента и ведение его баланса
• Хранение услуг и ведение их стоимости
• Проведение начислений за предоставленные услуги
• Предоставление скидок
• Проведение платежей
• Перевод денежных средств с договора на договор
• Ввод остатков по клиентам при переносе их из другой системы
• Хранение выставленных счетов клиенту
• Погашение выставленных счетов

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

• Все внешние ключи имеют формат <первичный ключ>_<имя таблицы>. В случае если внешних ключей несколько или они указывают на саму таблицу допускается или дополнение к названию вида id_<имя таблицы>_<поясняющее дополнение> или же id_<поясняющее дополнение>. В качестве примера id_trx_from, id_trx_to для первого случая и id_revoke,id_revokedby для второго случая в таблице bill.transfer.
  
• Поля с деньгами определены как numeric(18,4).
• Поля с датой имеют префикс dt в обязательном порядке.
• Поля с датой и временем имеют префикс ts в обязательном порядке.
• В случае если имеется временной интервал (dtfrom, dtto или tsfrom, tsto), то первая дата всегда задана и по умолчанию равна now(), вторая дата может быть пустой и в этом случае интервал считается действующим на данный момент.
• В части случаев у справочников вместо числового первичного ключа используется текстовый мнемонический ключ. Такие ключи обозначены как sid. Используется исключительно для удобства при работе с данными напрямую через консоль РСУБД.

А теперь слайды описание.

Опорными таблицами являются:

• Договоры (bill.contract) — минимально необходимое для использование описание договора
• Проводки (bill.trx) — Журнал проведенных операций. Фактически сумма денег пришедшая или ушедшая со счета.
• Используемая сторона учета (bill.ledgertype) — указывает на то куда идет проводка (дебит, кредит)
• Отчетные периоды (bill.period) — отчетыне периоды в бухгалтерском смысле слова. Хотя и содержит дату начала и дату завершения, фактически всегда равен месяцу
• Счета выставленные клиенту (bill.invoice) — те самые счета что выставляются клиенту за отчетный период.

Хотя этих таблиц вполне достаточно для работы биллинга, но для удобства работы добавляются таблицы первичных документов. Под первичными документами подразумеваются те документы на основании которых делаются проводки на по договору клиента.

Сейчас в схеме присутствуют следующие первичные документы:

• Остатки (bill.remain) — входящие остатки из другой системы. Эти документы должны быть всегда, иначе если вы мигрируете из другой системы, вы никогда не узнаете какой был баланс у клиента на момент миграции. Этим кстати страдают многие АСР, так-как разработчики считают, что достаточно ввести баланс. Но это не так, так-как в нормальной системе баланс клиента расчетная величина.
• Платежи (bill.payment) — поступающие от клиентов денежные средства.
• Переводы (bill.transfer) — перевод денежных средств со счета на счет. Сразу замечу, стоит явно запрещать перевод денежных средств при их отсутствии. Т.е. если баланс клиента отрицательный, то перевод должен быть запрещен.
• Начисления (bill.charge) — начисления за потребленные или предоставляемые (при авансе) услугию
• Скидки (bill.discount) — Скидки на услуги. Хотя в целом нет единого мнения как выражать скидку. Я считаю что скидку стоит выражать в денежном эквиваленте к определенному начислению. Это упрощает работу с ней.
• НДС (bill.vat) — НДС с начисления, выставляется отдельным документом. Все проводки с начислений идут без НДС, при этом само начисление может включать НДС. Это к примеру требуется для физических лиц. В этом случае в bill.charge есть явный флаг, что начисление включает НДС. При этом проводка по начислению не включает НДС и полная сумма начисления составляется из двух проводок, проводка по первичному документу начисление + проводка под НДС.

У первичных документов есть как общие поля так и общие правила работы с ними. Начнем с общих полей:

• id_contract (id_contract_from,id_contract_to) — указывает на договор или договора документа
• id_trx (id_trx_from, id_trx_to) — указывает на проводку или проводки документа
• id_period — в какой отчетный период проводится документ.
• ts — дата документа
• tscreate — дата создания документа.
• amount — сумма документа
• id_revoke — корректируемый документ. Указывает на тот документ который корректируется этим.
• id_revokedby — корректирующий документ. Указывает на тот документ который откорректировал текущий.

Насчет отчетного периода и корректируемого и корректирующего документа остановлюсь по подробнее.

Отчетный период.
В конце месяца у вас может быть два открытых отчетных периода из-за того, что к примеру последние дни выпадают на выходные, и платежи по банку еще не разнесены. Плюс это требуется в случаях к примеру когда фактическая дата документа январь 2014 года, а используемый период июнь 2015, проводимый в начале июля 2015. Т.е. в периоде июнь 2015, в дате создания 2 июля 2015, а в дате документа январь 2014. Из-за этого фактически у документа три даты.

Корректируемые и корректирующие документы.
Фактически если у вас в системе возник документ, который является ошибочным, то удалять его нельзя. Его можно только аннулировать. Т.е. создать корректирующий документ который строго противоположен некорректному документу. Именно для этого используются эти два поля. id_revoke — заполняется корректирующего документа, а id_revokedby у корректируемого. Корректировать иным образом, к примеру часть документа, не рекомендуется, как и удалять документы. Вместо этого скрывайте такие документы, в случае если они идут в одном периоде. Если документы находятся в разных периодах, то скрывать их как раз таки не требуется. Так же обратите внимание что у проводок таких полей нет, они не бывают корректируемыми.

Кроме общих полей, у первичных документов есть свои специфичные поля:

• Документы начислений (bill.charge) — count и vatincluded. Первое указывает на количество предоставленных услуг, второе на включается ли НДС в сумму документа.
• Документы НДС (bill.vat) — id_charge и id_vatrate указывающие на документ начислений к которым относится НДС и какой процент НДС был на момент проведения документа начислений.
• Документы скидок (bill.discount) — id_charge указывающее на какое начисление была применена скидка.
• Документы остатков (bill.remain) — sid_ledgertype позволяющее указывать используемую сторону учета при проведении документа.

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

В схеме присутствуют следующие справочные таблицы:

• Типы платежей (bill.paymenttype) — для деления платежей по типам. Нал, безнал, платежные агенты и т.п.
• Единицы измерения (bill.unit) — собственно единицы измерения используемых услуг. К примеру можно взять из справочника ОКЕИ. Ссылка на самого себя используется для единиц которые включают другие.
• Услуги (bill.service) — наименование услуг предоставляемых по договору.
• Цены (bill.price) — Стоимость услуг. Для учета изменения стоимости добавлены временные интервалы.
• Тип проводки (bill.trxtype) — Указывает на используемый тип проводки для первичных документов, а так же сторону учета используемую по умолчанию. В случае если сторона по умолчанию не указана, выбор происходит при проведении документа. К примеру это документы остатков.

А так же две вспомогательные таблицы:

• История баланса (bill.balance) — история изменения баланса договора с привязкой к проводкам.
• Обороты (Сальдо) за отчетный период (bill.saldo) — таблица с агрегированными данными по оборотам привязанная к периоду. Весьма часто используется в различной аналитике.

И на этом все. Если вас не затруднит ответьте на опрос. Результаты будут учтены при написании следующего в серии поста 🙂 Ну и задавайте свои вопросы в комментариях.

Как работает безбумажный биллинг | Откройте для себя

Выбор получения безбумажных счетов или электронных счетов является растущей тенденцией среди клиентов кредитных карт как удобный и простой способ отслеживать отчеты и расходы и оплачивать счета вовремя.

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

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

Зачем идти без бумаги

Существует несколько причин, по которым получение выписок по кредитным картам через Интернет работает на благо клиентов.

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

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

Ты поможешь Земле . Согласно веб-сайту Greenbill.com, при конвертации только одного бумажного счета и выписки каждый месяц в течение трех лет экономится один фунт бумаги, 10 галлонов воды, один галлон бензина и 44 фунта парниковых газов.

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

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

Сделайте безбумажный биллинг на шаг вперед

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

Существует несколько инструментов, которые помогут вам никогда не пропустить платеж.

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

Например, Discover позволяет получать уведомления по электронной почте или по тексту, когда:

• Ваше заявление доступно
• Ваш минимальный платеж —
• Платеж отправлен на ваш счет
• Ваша карта была отклонена
• Возврат от продавца или перевод баланса опубликовал

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

Откройте для себя ^® Chrome Student Card

Рекламные

Получите возврат денег на бензин и рестораны с Discover it ^® Chrome.

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

Отказ от ответственности: Этот сайт предназначен для образовательных целей и не является заменой профессионального совета. Материалы на этом сайте не предназначены для предоставления юридических, инвестиционных или финансовых советов и не указывают на наличие какого-либо продукта или услуги Discover. Это не гарантирует, что Discover предлагает или одобряет продукт или услугу.За конкретными советами о ваших уникальных обстоятельствах вы можете обратиться к квалифицированному специалисту.

,

Как работает биллинг — Американский реестр интернет-номеров

Годовой биллинг

Ежегодная плата за услуги реестра от ARIN взимается за все ресурсы нумерации Интернета (включая ресурсы нумерации IPv4, IPv6 и ASN), охватываемые Соглашением о предоставлении услуг регистрации ARIN (RSA) или Соглашением о предоставлении услуг прежней регистрации (LRSA), Услугами членства и услуги для посредников, включенных в указанную службу листинга переводов (STLS). Ежегодная плата обычно взимается каждый год в последний день юбилейного месяца.Например, если 17 января 2000 года организациям были предоставлены ресурсы с номерами в Интернете, годовой срок оплаты составит 31 января. Счета отправляются по электронной почте контактному лицу для выставления счетов, предоставленному организацией, за 60 дней до даты оплаты.

Напоминание о счете и коллекция

Сообщения с напоминанием счета-фактуры отправляются по электронной почте за 30 дней до и снова в срок. Эти сообщения отправляются в Admin, Tech и Billing Contacts для организаций с открытыми счетами.

Письма с напоминаниями и сообщениями о сборе направляются клиентам в зависимости от типа организации и отправляются с одного из следующих писем:

Когда срок счета-фактуры истекает через 30 дней, электронное письмо с уведомлением о сборе будет отправляться каждые 30 дней всем контактам организации до тех пор, пока учетная запись не станет текущей или ARIN не прекратит предоставление услуг организации.Дополнительные попытки связаться с владельцем ресурса номера в Интернете предпринимаются по электронной почте и / или по стандартной и заверенной почте — квитанция о возврате. Коллекционные телефонные звонки также совершаются в попытке связаться с владельцами интернет-ресурсов до отзыва.

Уведомление об отмене регистрации, отправленное в ожидании, отправляется по электронной почте всем контактам Организации, когда срок оплаты счета истекает через 100 дней Это сообщение указывает дату, когда произойдет отзыв. Посетите ресурс отзыва, возврата и восстановления для получения дополнительной информации.

Биллинг-контакт организации указывает лицо или группу, с которыми ARIN будет работать по всем вопросам, связанным с выставлением счетов и выставлением счетов. Если ваша учетная запись ARIN Online связана с учетной записью администратора или технической точки контакта (POC), мы рекомендуем вам связать свою учетную запись с идентификатором организации в качестве контактного лица для выставления счетов для доступа к платежной информации вашей организации. Если ваша учетная запись НЕ связана с администратором или Tech POC, вы должны запросить авторизацию выставления счетов в организации ARIN Online, прежде чем сможете управлять платежной информацией.Обратите внимание, что злоупотребление, NOC и маршрутизация POC могут просматривать, но не управлять информацией для выставления счетов.

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

Запрос авторизации счета

1. Войдите в свою учетную запись ARIN Online.
2. Выберите Payments & Billing в меню навигации.
3. Выберите Запросить авторизацию биллинга .
4. Введите идентификатор организации, для которого вы хотите авторизовать биллинг. Уведомление по электронной почте с авторизационным URL будет отправлено на адрес электронной почты контактного лица, указанного в ARIN.
5. При входе в ARIN Online выберите ссылку, указанную в уведомлении по электронной почте. После подтверждения вы получите уведомление о том, что у вас есть права на управление платежной информацией для этой организации.

Обновление платежной информации

1. Войдите в свою учетную запись ARIN Online.
2. Выберите Payments & Billing в меню навигации.
3. Выберите идентификатор организации, которую вы хотите просмотреть, из списка.

Если информация на странице платежной информации неверна:

1. Выберите Изменить платежный контакт .
2. Введите новую контактную информацию и выберите Отправить .

Примечание . Платежная контактная информация не может включать общие учетные записи электронной почты от таких поставщиков, как Gmail, Outlook.com, Hotmail или Yahoo Mail.

,

Учетная запись и биллинг

Как зарегистрироваться или обновить

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

Планы SurveyMonkey

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

Возможность ежемесячной оплаты

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

команды

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

Скидки и Коронавирусные Ресурсы

Мы предлагаем скидки некоторым некоммерческим организациям, студентам и преподавателям, которые имеют на это право.Доступные скидки различаются в зависимости от страны, в которой вы находитесь.

Переход на бесплатный план

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

Мобильные приложения SurveyMonkey

Узнайте больше о трех мобильных приложениях, которые SurveyMonkey предлагает для загрузки.

,

Как работают циклы выставления счетов

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

Еженедельные платежные циклы

Периодические платежи собираются в один и тот же день недели.

Например, если подписка стоит 10 долларов США в неделю, и подписчик подписывается во вторник, 23 декабря, счет подписывается следующим образом:

• Вторник, 23 декабря = 10 долларов.00 USD
• Вторник, 30 декабря = 10,00 долларов США
• вторник, 6 января = 10,00 долларов США
• и так далее

Ежемесячные платежные циклы

Периодические платежи собираются в тот же день месяца. Если первоначальный регулярный платеж выпадает на 31-е, PayPal в конечном итоге корректирует платежный цикл до 1-го числа месяца. Если первоначальный регулярный платеж выпадает на 29-е или 30-е, PayPal корректирует платежный цикл до 1-го числа месяца следующего февраля.

Пример: ежемесячные регулярные платежи, подлежащие оплате 31 марта

Если условия подписки составляют 25,99 долларов США в месяц, и подписчик подписывается в четверг, 31 июля. Абоненту выставляется счет следующим образом:

• четверг, 31 июля = 25,99 долларов США
• Суббота, 31 августа = 25,99 долларов США
• среда, 1 октября = 25,99 долларов США
• суббота, 1 ноября = 25,99 долларов США
• и так далее

Обратите внимание, что в сентябре не было собрано ни одного ежемесячного платежа, но периодические платежи были получены примерно каждые 30 дней.

Пример: ежемесячные регулярные платежи, подлежащие оплате 30 марта

г.

Если условия подписки составляют 25,99 долларов США в месяц, и подписчик подписывается во вторник, 30 декабря, абоненту выставляется счет следующим образом:

• Вторник, 30 декабря = 25,99 долларов США
• пятница, 30 января = 25,99 долларов США
• Воскресенье, 1 марта = 25,99 долларов США
• среда, 1 апреля = $ 25,99USD
• и так далее

Обратите внимание, что в феврале не было собрано ни одного ежемесячного платежа, но периодические платежи были получены примерно каждые 30 дней.

Годовой цикл выставления счетов

Периодические платежи собираются в один и тот же месяц и день каждого года. Если первоначальный регулярный платеж приходится на 29 февраля високосного года, PayPal корректирует платежный цикл до 28 февраля или 1 марта следующего года.

Пример: Ежегодные регулярные платежи, подлежащие выплате 29 февраля

г.

Если условия подписки составляют 125,99 долларов США в год, и подписчик подписывается в пятницу, 29 февраля, абоненту выставляется следующий счет:

• пятница, 29 февраля 2012 года = 125 долларов США.99 долларов США
• воскресенье, 1 марта 2013 г. = 125,99 долл. США
долл. США
• воскресенье, 1 марта 2014 г. = 125,99 долл. США
долл. США
• и так далее

См. Также

,