self billing что это
What is Self-billing Invoice and How it Works
4 min Reading time | 11. Jun 2019
Self-billing is a quick and easy way for your customers to pay you. It also ensures your cash flow is better and the relationship you have with your customers is a better one, too.
What is self-billing?
A self-billing arrangement is an agreement between a supplier and their customer. One of its benefits is that you don’t need to worry about writing an invoice and sending it to your customer. The invoice includes the company name, the registered office address and any VAT number. Self-billing invoices have to be marked with ‘Self-billing’ as their reference by law.
If an agency handles the self-billing on your behalf it is up to you to ensure the invoices are correctly issued. The whole set-up is an arrangement that has a lot of legal weight to it and will need to be agreed upon by your company or an agency.
Who can issue a self-billing invoice?
It is the customer who prepares the self-billing invoice before forwarding a copy of it to you or their supplier along with the payment. You should get your customer or your supplier to agree to produce such an invoice.
How VAT for self-billing works
When it comes to VAT self-billing, you must give the customer a VAT invoice, this is regardless of whether you are supplying reduced or standard rate services or goods to someone else who is VAT registered.
A VAT invoice shows specific information about the goods or services you’re supplying. All of your customers need their VAT invoices as evidence of the VAT you have charged them. If you supply goods or services that are zero-rated for VAT, you do not have to issue a VAT invoice. Additionally, you will not be required to issue a VAT invoice for supplying to customers who are not VAT-registered.
It is common for businesses to issue a VAT invoice only to those who ask for one. This is because you cannot tell if the customer is VAT registered.
Pros & Cons of Self-Billing and Points to Watch
Points to watch
If you’re a supplier or customer, you will also need to:
Self-billing Agreements
They should include the following details:
What are the Main Rules for Self-billers?
Self-billing arrangements can be set up with suppliers as long as the following conditions are met:
Suppliers can be based in the UK, in the European Union or countries outside the EU. Invoices must not be issued to any supplier who has made a change to their VAT number unless a new agreement has been prepared.
If a supplier is no longer registered for VAT you can self-bill them but you cannot issue VAT invoices as the self-billing arrangement is no longer covered by VAT regulations.
What Is a Self-Billing Invoice?
Self-billing invoices are raised when the customer prepares the supplier’s invoices and send it to them for payment. To enter into this arrangement, both the customer and the supplier must be VAT registered.
The advantage of this is that the customer no longer needs to wait to receive an invoice from the supplier and reconcile it with the timesheet before payment. On the supplier’s side, the process is easier as there is no need to produce an invoice. Once they approve the timesheets, the customer can generate the invoice.
What this article covers:
What Is Self-Billing?
VAT invoices are usually issued by the supplier. However, in some circumstances, the customer can prepare the invoice and send the supplier the copy. This agreement between the customer and the supplier is called self-billing.
While any business can use this process, there are certain conditions that have to be fulfilled. This includes:
If a supplier is no longer registered for Vat, the customer can continue to self-bill them. However, they can’t issue the self-billing invoices and claim any input tax as the self-billing arrangement is no longer valid by VAT regulations.
It’s important to note that:
What Is a Self-Billing Invoice?
Once the self-billing agreement is in place, self-billing invoices are issued by customers for all the transactions with the suppliers during the period of the agreement.
Along with the details of a full VAT invoice, a self-billing invoice to a supplier will also include:
Both parties of the agreement should ensure that the self-billing invoice accurately reflects the relevant transactions and the correct VAT rate is applied.
Some customers use third-party service providers to issue self-billed invoices on their behalf. In this case, the customer still remains responsible for guaranteeing that the invoices are issued.
The customers should still make sure they set up and review self-billing agreements with suppliers, keep copies of those agreements with the names, addresses and registration details of your suppliers and produce the suppliers’ details for inspection by the HMRC.
Suppliers should not treat self-billed invoices as purchase invoices and reclaim the VAT shown as input tax.
Why Use Self Billing?
Some of the key advantages of self-billing are:
Because the rules of self-billing are not clearly defined, you should consult a qualified tax specialist if you’re planning to enter into an arrangement with the suppliers.
What is Self-Billing?
What is Self-Billing?
Self-billing is a financial agreement between a customer and a supplier. In most cases, it involves the customer preparing the invoice and sending it, along with the payment, to the supplier. This kind of financial arrangement brings much-needed ease to transactions and virtually rids the supplier of the responsibility to write and send an invoice to their customer. Self-billing ensures that cash flow is always consistent and smooth.
Who Can Issue Self-Billing Invoices?
By its nature, self-billing places more responsibilities on the customer—they are the only ones who can create and issue a self-billing invoice. But whether your role is customer or supplier, both parties need to agree to the conditions attached to the agreement.
The Benefits of Self-Billing
It’s no secret that self-billing offers compelling benefits to both the supplier and the customer. Here are the top four:
Since the supplier has less administrative responsibilities, there are substantial time savings. For growth-focused companies, streamlining manual processes is a business imperative.
Typically, since payments are attached to most invoices, suppliers can expect to get paid faster.
Self-billing encourages operations to be uniform, which makes it easier to manage. Since the customer is supplying the invoice, they will already incorporate all the necessary details in the invoice for the supplier’s reference and convenience.
One of the many benefits of self-billing includes customers having the freedom to manage their self-billing invoices. In scenarios where the supplier lacks the initiative to bill the customer, the customer now has the option to alert the supplier to the invoice and speed up the transactional process.
Although there are numerous pros to self-billing, there are a few cons to consider. In some cases, self-billing might open your business up to extensive errors. Documents could go missing, or the wrong VAT rate could be attached to the invoice.
The Standard VAT Process in Self-Billing
It is a requirement for the supplier to issue a VAT invoice to the VAT-registered customer, regardless of the current rate of your goods or services.
This type of invoice should always detail the supplied goods or services. An exception to this rule is if your product or service is verified to be zero-rated for VAT.
However, if your customer is not VAT-registered, you do not have to send them a VAT invoice.
In some cases, businesses will only issue VAT invoices to customers who request it. Since it can be hard to ascertain whether a customer is VAT-registered immediately, this often becomes the norm. Keep in mind; there might be a requirement for the supplier and the customer to be VAT-registered before entering into a self-billing agreement.
The Steps Suppliers Need to Take to Ensure Compliance with VAT Regulations
While the dictated self-billing terms are agreed on by the customer and the supplier, both need to be aware of their compliance with specific VAT conditions. To do this, suppliers will need to take the following steps:
Basic Rules for Self-Billing
Customers should adhere to the following conditions if they wish to establish a self-billing agreement with suppliers:
Upon confirmation of the agreement, customers now have the long-term responsibility of issuing invoices for every transaction, until the agreement expires. The self-billing invoice should include the supplier’s name, address, and VAT registration number. Additionally, the statement “The VAT shown is your output tax due to HMRC” should be included in every invoice.
How Customers and Suppliers Can Mitigate Errors in Self-Billing Invoices
There is no shortage of benefits for self-billing agreements. Unfortunately, the same is valid for possible hurdles. As long as the customer and the supplier take the steps needed to ensure accuracy and compliance, there is a considerable benefit to this type of financial agreement.
About the Author
Darius Ghassemian is the Revenue Operations Manager at Tipalti. He started his career in public accounting at KPMG, focusing on auditing venture capital backed startups in the Bay Area. A Bay Area native, he graduated from San Jose State with a Bachelor’s degree in Accounting.
Биллинг в большом проекте
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.
Что такое «биллинг»
Для нас биллинг ― это всё, что связано с получением денег от пользователей: конфигурация цен, страница приема платежей, непосредственно прием и обработка платежей, оказание оплаченных услуг, различные промоакции и, конечно же, мониторинг всего вышеописанного.
Изначально, как и во всех стартапах, у нас не было платных услуг. Первые серьезные шаги в сторону монетизации начались в далеком 2008 году, при том что официально сайт был запущен в 2006-м. Для экспериментов была выбрана Франция, а оплата принималась только через SMS. Сам прием платежей был организован на файлах. Каждый запрос записывался в отдельный файл, который затем перекладывался bash-скриптами из одной папки в другую, что означало смену статусов обработки. База данных использовалась только для учета успешно обработанных транзакций. Такая схема успешно проработала чуть больше года, после чего ее стало сложно поддерживать, и мы решили отказаться от файлов и переписать всё с использованием БД.
Разработка новой версии прошла достаточно быстро, так как стран, где были доступны платные услуги, было не много. Но она была рассчитана только на прием платежей через SMS, из-за этого у нас даже до сих пор сохранилось несколько забавных артефактов, например, поля MSISDN (номер телефона) и short code (короткий номер, на который отсылают платную SMS) в таблице обработанных платежей.
Сейчас мы принимаем платежи почти во всём мире. Каждую секунду пользователи пытаются что-то оплатить на сайте или в приложениях для всех популярных мобильных платформ. А если наложить это на карту, то получится картина «Вид на Землю из космоса ночью»:
У нас доступно около 50-ти способов оплаты, предоставляемых разными партнерами. Самые популярные ― это банковские карты, SMS & Direct billing и покупки в мобильных приложениях.
Среди них есть и экзотические, например, прямое списание со счета интернет-провайдера или оплата через городской телефон. А однажды нам поступил платеж через обычную почту!
Банковские платежи
Все платежные системы позволяют принимать платежи от своих пользователей. Такие прямые интеграции удобно делать, пока их не очень много и вы подключаете известные системы с отлаженными процессами. Но когда нужно выйти на локальные рынки, то начинают появляться проблемы. Поддерживать «зоопарк» разных API становится всё сложнее, отличаются требования регуляторов, популярная локальная платежная система может вообще отказаться работать с иностранными клиентами при низких оборотах, или подписание контракта и улаживание юридических проблем может затянуться на долгое время. Несмотря на такие сложности, локальные платежные системы могут вас приятно удивить своей конверсией. Например, Голландия, которую мы считали не очень перспективной, после подключения популярного в этой стране способа оплаты iDeal стала приносить на 30-40% больше денег.
Если есть спрос, будет и предложение. На рынке много компаний-агрегаторов, или, по-другому, платежных шлюзов (англ. payment gateway), целью которых является объединение всех популярных платежных систем, в том числе локальных, под единым API. Сделав одну такую интеграцию, мы получаем возможность принимать платежи через десятки платежных систем по всему миру. Можно даже не делать страницу оплаты на своем сайте, а воспользоваться уже готовой, предоставленной агрегатором, и подогнать под себя только дизайн. Особо продвинутые компании дают возможность загружать свои CSS- и JS-файлы, менять картинки, тексты переводов и даже зарегистрировать получившуюся страницу на вашем поддомене, например, payments.example.com. Это дает очень богатые возможности по «кастомизации», и у пользователя складывается ощущение, что он не покидает ваш сайт. У себя мы этой возможностью не пользуемся, так как одновременно работаем с несколькими агрегаторами, но для кого-то это может быть очень удобным решением.
Какой способ использовать ― прямую интеграцию или через агрегатора ― зависит в первую очередь от размера комиссии. Чем больше ваших клиентов пользуется платежной системой, тем выгоднее может оказаться сэкономить на комиссии и подключиться к ней напрямую. Второй важный фактор ― это качество API, удобство работы и стабильность. Здесь агрегаторы позволяют сгладить шероховатости, а иногда и предоставить более стабильный сервис, чем прямое подключение.
SMS-платежи
Особняком стоят платежи через SMS и прямые списания с баланса мобильного телефона. Они находятся под очень жестким контролем во многих странах, особенно в Европе. Локальные регуляторы или само государство могут предъявлять особые требования к тому, как должна выглядеть страница оплаты или каким должен быть текст отсылаемых SMS-сообщений. За изменениями подобных требований нужно следить и вовремя вносить изменения у себя на сайте. Так, например, в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне, а рядом с ним должна быть указана его стоимость.
Технические детали
Badoo работает на связке PHP + MySQL, поэтому для обработки платежей мы используем те же технологии. Код выполняется на отдельной группе серверов, выделенной из общего пула. Внутри мы ее разделили еще на несколько логических подгрупп: cерверы для обработки входящих запросов, серверы для фоновых операций и сбора статистики, серверы баз данных, серверы для обработки платежей по банковским картам. Последние выделены в отдельную группу, потому что они должны соответствовать стандарту безопасности PCI DSS, разработанному при участии Visa, MasterCard, American Express, JCB и Discover для организаций, работающих или хранящих данные держателей банковских карт.
Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного (на время его обслуживания, для запросов от системы мониторинга или сбора статистики).
После реализации API наступает этап тестирования. На Хабре уже были статьи о том, как выглядит наш процесс разработки и автоматизации. Но для биллинга есть некоторые особенности, связанные в основном с тем, что приходится тестировать не просто наш код, но и взаимодействие с агрегаторами. Очень удобно, если у них есть для этого тестовое окружение, которое полностью эмулирует реальный прием платежей. Если же его нет, мы делаем «заглушки», эмулирующие поведение агрегатора. Это упрощает нам ручное тестирование и позволяет писать автотесты, проверяющие весь процесс оплаты. Вот пример того, как выглядит одна из заглушек.
После тестового окружения нужно проверить, как всё будет работать в жизни, провести реальную оплату. Но для SMS-платежей часто приходится получать одобрение от регуляторов или операторов, а это может длиться несколько месяцев. Чтобы не выкладывать полуготовый код на продакшн-серверы, мы придумали такую вещь, как External Shot. Это наш обычный Shot, который представляет из себя директорию с веткой задачи и предназначен для ее тестирования на продакшн-серверах, но кроме локального домена он имеет дополнительный внешний адрес, по которому любой желающий может зайти и посмотреть сделанные изменения. Для безопасности такие «шоты» создаются не для каждой задачи, а только в тех случаях, когда действительно необходимо. Ссылки на них мы даем нашим партнерам, и они в любое время дня и ночи могут проверить сделанные изменения. Особенно это актуально для стран, расположенных в другом полушарии, с которым разница во времени может достигать 12 часов.
Поддержка и эксплуатация
После того как новая интеграция выкладывается на продакшн-серверы, наступает этап ее эксплуатации и поддержки. Техническая поддержка занимает примерно 60-70% нашего времени.
Сюда входит, во-первых, разбор жалоб от пользователей. Все простые ситуации решаются командой первой линии поддержки, она же переводит для нас жалобы с разных языков на английский. Поэтому к нам попадают только самые сложные случаи, действительно требующие внимания разработчиков.
Вторая составляющая технической поддержки ― это исправление ошибок или внесение изменений в существующие интеграции. Ошибки возникают по разным причинам. Например, из-за невнимательного чтения документации или пробелов в ней. Однажды вместо нее нам даже пришлось использовать логи чата с разработчиком агрегатора, потому что документация для их новой системы была еще не готова. Были случаи, когда агрегатор без уведомления менял протокол взаимодействия или его параметры. В другой раз банк-эквайер отключил наш шлюз, и пришлось в срочном порядке перенаправлять трафик в другое место. Как потом выяснилось, это был древний сервер из 80-х, который, по данным банка, вообще ничего не должен был обрабатывать. В общем, скучать не приходится, особенно если учитывать, что каждая минута простоя ― это недополученная прибыль.
Для решения подобных проблем мы пишем подробные логи работы приложения. Туда попадают не только ошибки, но и всё взаимодействие с системами агрегаторов или просто важные события, происходящие во время выполнения запросов. Каждый запрос имеет свой уникальный идентификатор, по которому можно найти все связанные с ним записи и восстановить ход его обработки. Это бывает особенно полезно, когда приходится разбираться с ошибками, с момента которых уже прошло несколько недель или месяцев.
Вот так организован биллинг в Badoo. Конечно, осталось еще много интересных тем, о которых мы планируем рассказать будущем, например мониторинг, сертификация PCI DSS и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.
Биллинговые системы: основные понятия
Биллинг. Какие ассоциации вызывает этот термин? Может быть, есть какая-то связь с Биллом Гейтсом? Нет, к счастью он еще не «сунул свой нос» в область телекоммуникаций. Ну это так — шутка. А если быть серьезным, то давайте рассмотрим происхождение слова биллинг. Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».
Что такое биллинговая система?
Системы, вычисляющие стоимость услуг связи для каждого клиента и хранящие информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются телекоммуникационными операторами для выставления счетов абонентам и взаиморасчетов с другими поставщиками услуг, носят название биллинговых; цикл выполняемых ими операций именуется биллингом. Биллинговая система (БС) — это бухгалтерская система, программное обеспечение, иными словами — «софт», разработанный специально для операторов. Каких операторов? Телекоммуникационных. Т. е. речь не идет лишь об операторах сотовой связи. БС используются также операторами обычной (стационарной, проводной) связи. В малых офисах, например, можно вести биллинг телефонии (анализировать: кто звонил, когда, сколько длился разговор). IP-телефония — другая область применения БС. А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД). Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выделить Sybase и Informix как рассчитанные на большие объемы информации. А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС может подразумеваться и аппаратное обеспечение, участвующие в организации биллинга.
Терминология
Я постараюсь рассмотреть все основные понятия и определения, относящиеся к БС. Основной упор буду делать на БС, используемые операторами сотовой связи. Но большинство определений также подходит и к БС, используемым в других сферах. Постараюсь объяснять как можно проще, чтобы большинству читателей материал был понятен. Если у Вас будет что добавить к введенным мною терминам, пишите на e-mail.
Существуют несколько названий биллинговой системы: АСР — автоматизированная система расчетов; ИБС — информационная биллинговая система.
Одним из важных качеств БС является ее гибкость, то есть способность приспосабливаться к изменившимся обстоятельствам. Гибкая система адаптирована не только к сиюминутным потребностям оператора; за счет таких качеств, как настраиваемость, модульность и открытость она позволяет решать перспективные задачи. Чем больше у системы возможностей для настроек, тем лучше. А что такое модульность? Модульный принцип построения системы — это такой принцип, при котором вся система собирается из отдельных частей (модулей), как дом собирается по кирпичикам. БС тоже состоит из таких модулей — подсистем. БС включает в себя, например, подсистему предварительной обработки данных, подсистему оперативного управления биллингом, подсистему оповещения клиентов (читайте ниже о структуре и функциях БС). Под открытостью системы подразумевается открытость исходного кода программного продукта, что позволяет оператору не зависеть от разработчика в будущем и самостоятельно обслуживать и модернизировать систему. Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета — масштабируемость.
Масштабируемость по нагрузке. При росте абонентской базы, появлении дополнительных услуг не должна появляться необходимость изменять или дорабатывать программную часть БС. Увеличение возможностей БС должно достигаться за счет модернизации аппаратной части системы. Что важно учитывать при проектировании масштабируемых систем? Необходимо использовать СУБД, рассчитанные на большие объемы данных. СУБД должна быть совместима с различными компьютерными платформами, чтобы обеспечивать поддержку многопроцессорного режима работы.
Надежность — одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы. Далеко не последнее место занимает надежность поставщика (разработчика) прикладного программного обеспечения: время его работы на рынке и, как косвенный показатель, процент присутствия разработанных им систем на телекоммуникационном рынке. Почему показатель косвенный? А разве Microsoft Windows самая лучшая и надежная операционная система?… И при этом она занимает значительную долю рынка. Однако надежность БС обеспечивается также соблюдением определенных стандартов при их разработке (об этом читайте ниже).
Мультиязычность — возможность устанавливать различные языки для представления информации.
Мультивалютность — возможность работать с любыми валютами
Отложенный биллинг — биллинг, при котором расчеты производятся после состоявшихся звонков.
Горячий биллинг — изменение баланса счета происходит в процессе разговора, и информацию об остатке на Вашем счету можно получить сразу после звонка.
Оптимизация биллинга — улучшение, совершенствование оператором своей БС.
Большие БС — системы, применяемые крупными операторами.
Постинг биллинга — фиксация результатов расчета биллинга; после расчетов результаты становятся доступными пользователям (рассылаются, печатаются).
Что может, что должна или за что отвечает БС?
Вы пользуетесь услугой prepaid? Вы задумывались, как так получается, что сразу после звонка можно узнать об изменении баланса на Вашем счету? Вас обслуживают по кредитной системе? Кто подсчитывает сумму, которую Вы должны заплатить за предоставленные услуги? Все это «обязанности» биллинговой системы. Вы подключены по авансовой системе? Когда-нибудь замечали «исчезновение» незначительных сумм с Вашего счета? У Вас было такое: хотите узнать остаток Вашего счета, а автоинформатор предоставляет Вам сведения вчерашней свежести? Все это «глюки» биллинговой системы.
Так как БС предназначена для автоматизации расчетов с клиентом, то она и должна обеспечивать эту автоматизацию начиная с заключения договора до выписки счетов за услуги сотовой связи, причем корректно. При помощи подсистем автоматических услуг и автоматического сбора данных АСР должна предоставлять абонентам возможность самообслуживания. Некоторые БС позволяют абонентам оформлять заказы на подключение и производить оплату услуг через Интернет.
Структура и функции БС
Схема организации биллинга не сложна: информация о соединениях и их продолжительности записывается коммутатором и после предварительной обработки передается в расчетную систему. Расчетной системе «известны» тарифы. Она идентифицирует вызов и выполняет необходимые расчеты, формируя тем самым счет абонента. Очевидно, что в памяти системы должны храниться не только нормативы, тарифы и информация об услугах, но и данные о клиентах, заключенных контрактах с абонентами и сторонними поставщиками услуг связи (если таковые имеются), а также о стоимости передачи информации по разным каналам и направлениям (системой должно быть также предусмотрено наличие дилеров: у них могут быть другие расценки, например, на подключение). Кроме этого, любая БС должна иметь базу, хранящую историю платежей: только эти сведения позволяют контролировать процесс оплаты и автоматизировать так называемую активацию/деактивацию абонентов. Эту функцию БС можно еще назвать защитной, так как она не позволяет пользоваться услугами сотовой связи тем, кто за них не платит.
По функциональным возможностям БС можно разделить на три класса: предназначенные для транснациональных операторов связи, заказные национального масштаба и системы среднего класса для региональных сетей.
БС, относящиеся к первому классу, должны обеспечивать взаимодействие сетей на межнациональном уровне, в различных временных зонах, т. е. они должны быть мультивалютными и мультиязычными.
Заказные системы национального масштаба создаются под определенного оператора. Оператору может понадобиться новая БС, совместимая с уже существующей расчетной системой. Разумеется, стоимость таких единичных систем значительно выше.
В масштабе региона можно вполне обойтись стандартными БС. Однако и такие системы должны обладать качествами, перечисленными выше: гибкостью, масштабируемостью, надежностью.
Любая БС создается и настраивается на бизнес-процесс определенного оператора связи, имеет собственный набор функций, соответствующий технологическому циклу предоставления услуг, и может работать с конкретным сетевым оборудованием, поставляющим ей информацию о вызовах и соединениях, — то есть БС не является «коробочным» продуктом. Но существует и стандартный набор функций, поддерживаемых практически всеми БС. В него входят:
операции, выполняемые на этапе предварительной обработки и анализа исходной информации, например, функция получения данных о соединениях и услугах (запросы к коммутатору);
Как уже было сказано, БС должна обладать гибкостью или модульностью. Каждый элемент АСР обеспечивает реализацию конкретного участка технологической цепочки обслуживания клиента. Основные подсистемы, характерные для биллинга, это: подсистема предварительной обработки данных о соединениях, оперативное управление биллингом и подсистема оповещения клиентов.
Подсистема предварительной обработки данных.
Это приложение анализирует исходную информацию о соединении, определяет класс предоставляемой услуги и параметры трафика (направление вызова, источник, зоны взаиморасчетов, условия роуминга). В состав данной подсистемы входит декодер исходной информации о соединениях. Одна из сложнейших процедур этой подсистемы — поддержка роуминга. Дело в том, что требуется конвертировать роуминговые записи всевозможных форматов от разных коммутаторов (с учетом различных стандартов передачи информации в канале связи) и разных биллинговых систем в тот формат записи, которым пользуется данная БС. Программное обеспечение (ПО) тарифицирует все записи о соединениях между операторами (согласно проходящему трафику) и создает служебные таблицы, которые используются остальными подсистемами для выполнения расчетов с абонентами, взаиморасчетов операторов связи и формирования отчетов. Современные БС позволяют обрабатывать различные телекоммуникационные услуги, обеспечивая удобное выставление счетов (один клиент — один баланс — один счет). Это достигается за счет применения «интеллектуальных систем» предварительной обработки исходной информации о соединениях, трафике и услугах, выполняющих тарификацию независимо от вида связи.
Подсистема оперативного управления биллингом.
Данная подсистема дает возможность автоматически или через оператора биллинговой системы изменять условия подписки абонентов на коммутаторе, т. е. блокировать связь конкретного абонента или снимать эту блокировку, включать или отменять услугу. Вы звоните оператору и говорите: «Включите мне, пожалуйста, голосовой ящик». Вам отвечают: «Пожалуйста, назовите свой номер». После еще нескольких «обменов любезностями» Ваш голосовой ящик оказывается включенным.
Подсистема оповещения клиентов.
Неотъемлемая часть современного биллинга — подсистема оповещения клиентов с помощью голосовых или электронных сообщений. Информацию для рассылки уведомлений и объявлений данная подсистема берет из таблиц базы.
Перечисленное деление на функциональные подсистемы не является «строгим» для всех БС. Это лишь пример «классической» АСР.
Стандарты биллинга
Чтобы обеспечить взаимопонимание между различными БС разных операторов (это, например, требуется при роуминге, были разработаны группы стандартов биллинга. Основных международных групп стандартов три.
В 1998 г. американский институт стандартов ANSI утвердил стандарт ANSI 124. Дальнейшим усовершенствованием и поддержкой ANSI 124 занимается ассоциация TIA. После этого компания CIBERNET создала рабочую группу для определения спецификаций бизнес-процессов при передаче сообщений в стандарте ANSI 124, которые получили название NSDP-B&S. Данные спецификации устанавливают однозначное соответствие между бизнес-процессами телекоммуникационных операторов и информацией, передаваемой при обмене данными между коммутаторами по стандарту ANSI 124.
В 1998 г. было опубликовано описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS. Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER — сотовые сети стандарта AMPS.
Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG. Большинство операторов Европы используют ТАР2, хотя существует и третья версия. С 1995 г. модификация ТАР2, известная как спецификация TD.27, или NAGTAP2, начала применяться и в США.
Вместо заключения
Вы достаете из кармана свой сотовый, набираете номер, жмете «вызов» и… разговор состоялся. Теперь Вам не терпится узнать остаток на Вашем счете. Если биллинг системы «горячий», Вам тут же сообщают эту сумму. «Все точно подсчитала, хорошая биллинговая система», — думаете Вы. А в это время другой абонент узнает, что он только что исчерпал лимит времени и его отключили. «Зачем мне этот «горячий» биллинг! Глупая биллинговая система!», — сетует он… Да, одновременно всем не угодить!
Особая благодарность за информационную поддержку Большовой Галине, обозревателю журнала «Сети».