통신 청구-빠른 가이드

전자 매체를 사용하여 한 지점에서 다른 지점으로 음성, 데이터, 사진, 팩스 등을 보내는 것을 통신이라고하며 줄여서 'telecom'. 예를 들면 전화, 라디오, 텔레비전 및 인터넷이 있습니다. 전송 매체에는 Wire (구리), Fiber Optics, Ether (무선), Radio Towers, Microwave, Satellite 등이 있습니다.

이제 고객에게 만족스러운 통신 서비스를 제공하는 몇 가지 국제 통신 사업자를 나열 해 보겠습니다.

Verizon
Vodafone
Airtel
TATA
Etisalat
Qtel

또한 잘 알려진 다양한 통신 사업자가 제공하는 몇 가지 기본 통신 서비스를 나열 해 보겠습니다.

음성 통화
팩스 서비스
SMS 및 MMS
인터넷 연결
데이터 다운로드 및 업로드
화상 회의
IP 기반 서비스, 즉 VoIP 또는 VPN

통신 사업자는 다양한 방법으로 고객에게 요금을 부과하고 있지만 고객에게 요금을 부과하는 데 주로 사용되는 두 가지 매개 변수가 있습니다.

Rental Charges− 제공된 서비스에 대해 매월 고객이 부과하는 요금입니다. 예를 들어, 사용 여부에 관계없이 월간 전화 요금은 $ 5.00입니다.
Usage Charges− 서비스 이용률에 따라 고객에게 부과되는 요금입니다. 예를 들어 전화를 건 모든 통화 또는 휴대 전화를 사용하여 다운로드 한 데이터에 대해 요금이 부과됩니다.

월 임대료 및 사용료와 별도로 사업자는 서비스 시작, 설치, 서비스 중단 또는 종료에 대해 귀하에게 비용을 청구 할 수 있습니다.

Telecom Billing은 사용량을 수집하고, 집계하고, 필요한 사용량과 임대료를 적용하고, 최종적으로 고객에 대한 송장을 생성하는 프로세스입니다. 통신 청구 프로세스에는 고객으로부터 지불을 받고 기록하는 것도 포함됩니다.

결제 시스템

수동으로 처리하기 어려운 매우 복잡한 충전 시나리오가있을 수 있습니다. 청구 작업을 매우 효율적으로 처리하고 서비스 제공 업체에 다양한 가격 구조로 서비스를 제공 할 수 있도록 많은 유연성을 제공 할 수있는 소프트웨어 시장에서 사용할 수있는 최첨단 청구 시스템이 있습니다.

청구 시스템은 고객으로부터 돈을 수금 (영수)하는 데 도움이되므로 청구 시스템은 종종 미수금으로 간주됩니다. 고객은 종종 무선 로밍, 장거리 및 다른 네트워크를 통한 통화 완료와 같은 다른 회사의 서비스를 사용하기 때문에 청구 시스템은 미지급금 (이동 통신사 간 결제)의 일부입니다.

결제 시스템은 다양한 기능을 제공하는 안정적이고 값 비싼 하이 엔드 소프트웨어입니다. 다음은 가장 중요한 기능 목록이지만 다음으로 제한되지 않습니다.

Rating & billing − 제품 또는 서비스 사용량을 평가하고 월별 청구서를 작성하는 작업이 포함됩니다.
Payment processing − 고객의 결제 금액을 자신의 계정에 게시하는 것이 포함됩니다.
Credit control and collections − 미결제 금액을 추적하고 적절한 조치를 취하여 금액을 징수합니다.
Disputes and adjustments − 여기에는 청구서에 대한 고객의 분쟁을 기록하고 분쟁을 해결하기 위해 분쟁 금액을 환불하도록 조정하는 작업이 포함됩니다.
Pre-pay and post-pay services − 선불 및 후불 고객 기반을 모두 지원합니다.
Multilingual & multiple currencies − 비즈니스가 전 세계에 분산되어 있고 다국적 고객이 있거나 정부 규정에서 요구하는 경우 다국어 및 다중 통화 지원이 필요합니다.
Inter-carrier settlements − 서로의 고객에게 서비스를 제공하는 이동 통신사 간의 수익 공유를 포함합니다.
Products & services − 여기에는 다양한 제품 및 서비스를 유지하고 개별적으로 또는 패키지로 판매 할 수있는 유연한 방법을 제공하는 것이 포함됩니다.
Discount applications − 여기에는 고객 이탈을 줄이고 고객 기반을 유치 및 늘리기 위해 다양한 할인 계획을 정의하는 것이 포함됩니다.

청구 유형

청구 주제를 드릴 다운하면 더 복잡해집니다. 이 튜토리얼의 뒷부분에서 대부분의 개념을 다루려고하지만 먼저 널리 사용되는 청구 유형에 대해 폭넓게 살펴 보겠습니다.

Pre-pay Billing− 고객이 선불로 결제 한 후 서비스 사용을 시작하는 결제 메커니즘. 일반적으로 선불 고객은 인보이스를받지 않으며 '라고하는 고 가용성 결제 시스템을 통해 실시간으로 청구됩니다.IN'(지능형 네트워크).
Post-pay Billing− 이것은 수년 동안 계속되는 기존 청구입니다. 여기에서 고객은 제품과 서비스를 구매하여 한 달 내내 사용하고, 월말에는 서비스 제공 업체에서 송장을 생성하고 해당 송장을 고객에게 전송하여 정산합니다.
Interconnect Billing:네트워크 운영자는 일반적으로 고객이 서비스 비용을 지불하는지 여부에 관계없이 다른 네트워크에서 고객에게 제공하는 서비스에 대해 재정적으로 책임이 있습니다. 상호 연결 청구는 이동 통신사 간 또는 때때로 호출됩니다.partner settlements.
Roaming Charges− 고객이 한 네트워크 운영자의 서비스 지역에서 다른 운영자의 서비스 지역으로 이동할 때 첫 번째 운영자는 두 번째 운영자에게 한계 요금을 지불하여 고객에게 서비스를 제공합니다. 이러한 유형의 요금은 로밍 청구를 통해 정산됩니다. 이 정산은 TAP3 프로토콜에 따라 수행되며 다음 장에서 논의 할 것입니다.
Convergent Billing− 수렴 청구는 모든 서비스 요금을 단일 고객 청구서에 통합하는 것입니다. Convergent Billing은 고객 및 해당 고객에게 제공되는 모든 서비스 (모바일, 고정, IP 등)에 대한 통합보기를 만드는 것을 의미합니다.

결제 시스템 공급 업체

빌링 시스템은 모든 통신 사업자의 중추입니다. 사업자가 강력한 결제 시스템을 갖추고 있지 않으면 매력적인 프로모션 및 거래로 제품과 서비스를 제공 할 수 없으며 궁극적으로 오늘날의 경쟁적이고 역동적 인 시장에서 설 수 없습니다.

많은 기능을 요구하는 청구 제품을 판매하는 수천 개의 공급 업체를 찾을 수 있지만 시장에는 정말 훌륭하고 가장 일반적으로 사용되는 몇 가지가 있습니다. 좋은 결제 시스템 중 일부는 다음과 같습니다.

체계	웹 사이트
Convergys IRB	www.convergys.com
Amdocs Ensemble	www.amdocs.com
AMS 태피스트리	www.amsinc.com/telecom
케난 아버	www.kenan.com
단일보기	www.intecbilling.com
포털 인프라넷	www.intecbilling.com
Ericsson IN	www.ericsson.com

다음 다이어그램은 결제 시스템의 일반적인 아키텍처를 보여줍니다-

여기에 두 가지 가능성이 있습니다.

CRM (Customer Relationship Management) / OMOF (Order Management and Order Fulfilment) 시스템은 빌링 시스템과 연결하고, 빌링 시스템은 프로비저닝 시스템과 연결하여 서비스 및 네트워크 인벤토리 시스템을 프로비저닝하고 전화 번호 또는 IP 주소 등을 할당합니다.
두 번째 가능성은 CRM / OMOF 시스템 자체가 프로비저닝 시스템과 연결하여 서비스 및 네트워크 인벤토리 시스템을 프로비저닝하고 전화 번호 또는 IP 주소 등을 할당하는 것일 수 있습니다.

일반적인 결제 프로세스

위의 시스템 아키텍처를 고려할 때 : → 통화가 이루어 지거나 최종 고객에 의해 사용량이 생성되었다고 말할 수있는 경우 중개 시스템은 네트워크 스위치에서 사용량 데이터를 수집하고 call-detail record(CDR). 이 CDR에는 'A'당사자 번호와 'B'당사자 번호, 시작 및 종료 날짜 및 시간이 포함되어야합니다.

그런 다음 CDR은 등급이 지정 될 때까지 저장됩니다. 통화를 평가하기 위해 CDR을 검사하여 해당 통화가 예를 들어 800 번호인지, 지역 통화 계획이 적용되는 시내 전화, 국제 전화 또는 유료 전화인지 확인합니다. 통화 시간, 도시 코드 또는 국가 코드와 같은 정보를 사용하여 통화 요금을 계산합니다.

각 통화가 평가되면 일반적으로 한 달에 한 번 송장이 실행될 때까지이 정보가 저장됩니다. 인보이스가 실행되면 할인 또는 월별 요금과 같은 기타 비 사용 요금이 청구서 또는 송장이라고도하는 경우에 적용될 수 있습니다.

평가 시간 할인 또는 청구 시간 할인, 고객이 수행 한 다른 지불, 제공된 다른 조정, 이러한 모든 정보가 최종 송장 생성에 기여할 수 있습니다.

이 정보는 읽을 수있는 형식으로 인쇄 할 수있는 형식으로 변환됩니다. 마지막으로 봉투가 인쇄되고 인클로저로 채워져 최종 고객에게 발송됩니다.

결제 시스템 요구 사항

청구 시스템은 함께 실행될 때 청구 시스템이라고하는 일련의 독립적 인 애플리케이션으로 구성되어야합니다. 좋은 결제 시스템은 다음과 같은 주요 기능을 유연성과 함께 제공해야합니다.

Customer-interface Management − 청구 시스템은 고객이 시작한 연락을 처리하고, 아웃 바운드 고객 연락을 감독하고, 연락 수명주기를 관리 할 수 있어야합니다.
Order Management− 일반적인 결제 시스템에서 사용할 수있는 기본 기능입니다. 청구 시스템은 제품 및 서비스 주문을 캡처하고 주문 입력 수명주기를 관리하고 주문 완료 수명주기를 감독 할 수 있어야합니다.
Sales and Marketing − 만족스러운 청구 시스템은 고객의 질문에 답하고, 수수료를 처리하고, 판매 지원을 제공하고, 잠재 고객을 추적하고, 캠페인을 관리하고, 제품 성능을 분석하고, 여러 주택을 확보해야합니다.
Rate Plans and Rating − 청구 시스템은 다양한 제품 및 서비스, 해당 제품 및 서비스와 관련된 다양한 요금제를 관리해야하며 해당 제품 및 서비스에서 생성 된 사용량을 평가하는 유연한 방법을 제공해야합니다.
Discounting − 결제 시스템은 다양한 사용 및 대여에 대해 다양한 유형의 할인을 제공 할 수 있어야합니다.
Invoicing − 시스템이 과금 조회, 청구서 생성, 예금 처리, 계정 관리 수행, 세금 및 수수료 정보 유지, 재무 정보 처리가 중요합니다.
Credit Control & Collection− 결제 시스템은 고객마다 다른 신용 등급을 할당하여 사용량과 수익을 제어해야합니다. 시스템은 지불 수금을 지원하고이를 다른 송장에 적용해야합니다.
Multilingual Support − 다국어 지원에는 여러 언어로 된 송장 및 고객 관리 서비스 제공이 포함됩니다.
Multiple Currencies − 여러 국가에서 사용되는 여러 통화는 청구 및 고객 관리 시스템이 여러 통화 단위로 기록 및 처리 할 수 있어야하기 때문에 청구 시스템을 복잡하게 만들 수 있습니다.
Partner revenue management − 파트너 수익 관리는 서로의 고객에게 서비스를 제공하는 이동 통신사 간의 수익 공유입니다.
Problem Handling − 청구 시스템은 또한 문제 티켓 입력을 관리하고, 문제 티켓 마감을 조정하고, 문제 티켓의 해결 진행 상황을 추적 할 수 있어야합니다.
Performance Reporting − 만족스러운 시스템은 성능보고를 제공하고, 서비스 품질 (QoS)보고를 보장하고, 관리 보고서를 작성하고, 규제 보고서를 생성합니다.
Installation and Maintenance − 시스템은 또한 인력 일정을 제공하고 고객 구내에서 수행되는 활동을 관리해야합니다.
Auditing & Security− 청구 시스템은 데이터 감사 및 무결성 검사를 수행해야합니다. 운영자에게는 보안 시스템이 항상 바람직합니다.

위의 기능 외에도 좋은 결제 시스템은 다음과 같아야합니다.

새로운 서비스 출시를위한 시장 출시 시간 단축.
고객 및 제품에 대한 수렴 된보기를 가능하게합니다.
비용 효율적인 아키텍처 확장 성을 지원합니다.
파트너 관계 관리 및 합의를 가능하게합니다.
총 소유 비용 절감.

다음은 무엇입니까?

다음 장부터는 제품 및 서비스 정의, 계획 및 관세를 해당 제품과 연결, 고객 확보 (최종 고객에게 제품 판매), 해당 고객이 생성 한 사용량 캡처, 마지막으로 등급 지정부터 전체 프로세스를 다루려고합니다. 해당 고객에게 최종 청구서를 보내기 위해 사용량을 청구합니다.

Airtel과 같은 통신 사업자가 자체 결제 시스템을 설정하려고한다고 가정 해 보겠습니다. 그런 다음 Airtel은 결제 시스템을 설정하기 전에 먼저 판매 및 마케팅 부서에서 제품과 서비스를 정의해야합니다.

제품이란?

제품은 운영자가 최종 고객에게 판매 할 수있는 논리적 또는 물리적 엔티티입니다. 휴대폰, 인터넷 연결, 음성 통화 연결, VPN, 주문형 비디오, 디지털 TV 연결 등이 될 수 있습니다.

제품은 월간 렌탈이 가능하며이를 주기적 요금이라고도합니다. 제품은usage generating product 또는 non-usage generating product. 사용량 생성 제품은 이벤트 생성 제품이라고하며, 비 사용 생성 제품은 비 이벤트 생성 제품이라고합니다.

예를 들어, 전화 번호와 함께 제공되는 음성 통화 연결은 최종 고객이이 제품을 사용하여 음성 통화를 할 때마다 사용량을 생성하기 때문에 사용량 생성 제품입니다. 연결이없는 간단한 전화기는 사용량이 발생하지 않는 제품이며 월세로만 고객에게 줄 수있다. 따라서 고객이 사용하지 않더라도 월 임대료를 지불해야합니다.

서비스 란?

대부분의 경우 서로 다른 청구 및 마케팅 전문가가 서로 바꿔서 사용하기 때문에 마케팅 관점에서 이야기 할 때 제품과 서비스간에 차이가 없습니다.

간단히 말해, 운영자는 자사 제품을 사용하여 고객에게 음성 서비스를 제공합니다. 국제 전화는 음성 통화 연결을 사용하여 제공되는 서비스라고 할 수 있습니다. 또 다른 예는 800 번호 통화가 특정 운영자를 통해 이용 가능하거나 이용 가능하지 않을 수 있으며, 통화 대기, 착신 전환은 전화 세트 모델 또는 운영자가 제공하는 서비스라고 할 수 있습니다.

이 튜토리얼에서는 Product and Service용어는 서로 바꿔서 사용할 수 있습니다. 단순하게 말하면 제품은 고객이 직접 구매하거나 임대 할 수있는 항목입니다. 제품은-

실제 물체 (예 : 휴대폰)
서비스 (예 : 전화 시스템의 통화 대기 서비스)
더 추상적 인 개념 (예 : 서비스 수준 계약)

제품군

관련 제품을 제품군으로 함께 그룹화 할 수 있습니다. 여러 수준의 제품이 가능하므로 제품은 동시에 부모와 자식이 될 수 있습니다.

또한 각 제품군은 필요한 경우 둘 이상의 상위 제품을 가질 수 있습니다. 제품군의 예는 다음과 같습니다.

전화 서비스
케이블 TV
Internet
전용선

제품 그룹 (패키지)

운영자는 여러 번 하나 이상의 제품을 단일 그룹으로 묶어 완전한 패키지로 판매합니다. 다양한 유형의 제품을 패키지로 함께 묶을 수있는 과금 시스템이 있습니다. 할인 된 가격으로 제공 될 수 있습니다.

패키지를 사용하면 제품이 패키지의 일부로 사용되는 경우 할인 된 가격으로 고객에게 제품을 제공 할 수 있습니다. 각 패키지는 여러 제품으로 구성 될 수 있으며 이러한 제품은 둘 이상의 제품군에서 가져올 수 있습니다.

제품에 대한이 패키지 가격 계획은 일반적으로 회사가 전체 패키지 구매에 대해 고객에게 할인을 제공하는 방식이기 때문에 비교 (즉, 패키지가 아닌) 가격 계획과 다릅니다. 그러나 제품은 패키지 내에서 일반 가격 계획 중 하나를 지정할 수 있으므로 필수는 아닙니다.

제품 속성

제품에는 관련된 여러 속성이있을 수 있습니다. 제품 속성을 사용하면 제품 유형간에 관련 정보가 다른 경우 개별 제품 인스턴스에 대한 정보를 보유 할 수 있습니다. 예를 들어 유료 TV 제품에는 셋톱 박스 번호를 기록하는 속성이있을 수 있습니다.

또한 휴대폰 제품은 IMSI (International Mobile Subscriber Identity) 및 MSISDN (Mobile Station International ISDN Number)을 기록하기위한 속성이 필요할 수 있습니다.

제품 이벤트 유형

제품에는 관련된 여러 이벤트 유형이있을 수 있습니다. 이러한 이벤트 유형은 제품에서 생성 할 수있는 이벤트를 제어합니다.

예를 들어 휴대폰 제품에는 음성 통화 및 메시징 서비스와 같은 이벤트 유형이있을 수 있습니다. 단일 전화 장치와 관련된 더 많은 이벤트 유형이있을 수 있으며 운영자는 고객이 생성 한 각 이벤트에 대해 최종 고객에게 비용을 청구 할 수 있습니다.

결제 시스템 관점

마케팅 부서에서 모든 제품, 서비스, 패키지 및 관련 가격을 확정하면 결제 시스템에서 구성됩니다.

서로 다른 청구 시스템은 상위, 하위 및 손자 제품과 관련하여 제품 및 계층 구조를 정의하는 다양한 수준의 유연성을 제공합니다.

일부 시스템은 패키지 및 번들을 지원할 수있을만큼 유연하며 일부 시스템은 패키지 및 할인 된 가격과 관련된 제한된 기능을 제공합니다.

일부 시스템은 더 나은 모듈 식 접근 방식을 제공하기 위해 제품 카탈로그를 가격 카탈로그와 별도로 유지하고 일부 청구 시스템은 제품 설명, 기능 및 관련 가격을 모두 결합합니다.

모든 제품, 서비스, 패키지 및 이벤트가 결제 시스템에 구성되면 다음 단계는 다음 장에서 다룰 임대 및 사용 가격을 정의하는 것입니다.

다음은 무엇입니까?

제품 또는 서비스 및 패키지가 무엇인지 이해했다면 다음 장으로 진행하여 모든 운영자가 이용할 수있는 마케팅 부서에서 가격을 정의하는 방법을 이해할 수 있습니다.

통신 사업자 회사의 마케팅 부서는 다양한 제품 및 서비스에 대한 임대 및 사용 요금을 정의하기 위해 열심히 노력합니다. 이러한 요금은 다른 경쟁사 및 규정을 염두에두고 정의됩니다. 대체로 말하면, 다른 청구 시스템에서 사용되는 용어에 따라 요금제 또는 요금제라고도하는 두 가지 유형의 관세가 있습니다.

제품 및 관련 서비스에 대해 다양한 유형의 요금이 적용될 수 있습니다. 특정 제품에 대해 운영자는 다음 요금 중 하나 이상을 정의 할 수 있지만 이러한 요금에만 국한되지 않고 국가, 위치 및 비즈니스 상황에 따라 다른 유형의 요금이있을 수 있습니다.

Product Initiation Charges − 이는 일회성 요금이며 설치, 활성화, 서비스 또는 연결 시작의 일부로 고객이 지불 할 수 있습니다.
Product Periodic Charges − 제공되는 제품 및 서비스의 렌탈로 월별, 격월 또는 연 단위로 적용 할 수있는 요금입니다.
Product Termination Charges − 이는 제품 및 서비스 종료시 적용될 수있는 요금입니다.
Product Suspension Charges− 이는 어떤 이유로 인해 제품이 일시 중단 된 경우 적용될 수있는 요금입니다. 예 : 미납.
Product Suspension Periodic Charges − 고객이 어떤 이유로 인해 일시 중지 된 경우에도 고객에게 주기적으로 요금을 청구해야 할 수 있습니다.
Product Re-activation Charges − 어떤 이유로 인해 제품이 일시 중지되어 이제 활성화가 필요하다고 가정하면 운영자는이 서비스에 대한 재 활성화 요금을 적용 할 수 있습니다.
Product Usage Charges− 이는 서비스 이용에 따라 적용되는 가장 중요한 요금 유형입니다. 예를 들어 분당 또는 초당 호출, MB 당 데이터 다운로드 등이 있습니다.

위의 모든 요금은 규제에 따라 적용 가능한 세금을 포함하거나 제외하는 다른 요금 카탈로그에 정의 (구성)됩니다. 이러한 카탈로그는 청구 시스템마다 다릅니다. 일부 청구 시스템은 모든 가격을 단일 카탈로그에 보관하고 일부 청구 시스템은 사용 요금을 다른 요금과 별도로 유지합니다.

이러한 카탈로그는 청구 시스템에서 유지 관리되지만 프런트 엔드 시스템에서도 사용할 수 있으므로 고객 계정을 만드는 동안 고객에게 다른 관세를 적용 할 수 있습니다.

모든 가격은 제품과 패키지에 따라 정의됩니다. 다른 패키지에 다른 가격을 제공하는 제품의 다른 조합이있을 수 있습니다.

다음 섹션은 관세 정의와 밀접하게 관련된 다른 개념에 대한 아이디어를 제공합니다.

선불 및 연체 요금

운영자가 일부 서비스에 대해서는 사전에 고객에게 요금을 부과하고 다른 서비스에 대해서는 매월 말에 요금을 청구하려는 상황이있을 수 있습니다.

서비스를 제공하기 전에 미리 부과 된 요금이 호출됩니다. in-advance charging 서비스 제공 후 부과 된 요금을 in-arrear charges.

체납 청구의 경우 제품 요금은 현재 명목 청구일 (또는 비정기 청구일의 청구 요청 일) 전날까지 적용됩니다.

따라서 다른 요금을 구성하는 동안 청구 시스템은 요금을 미리 구성 할 수있는 조항을 제공해야하며 운영자가 특정 가격을 선불 또는 선불로 구성하려는 경우 항상 선택 사항입니다.

NOTE− 다음 달에 고객이 얼마나 많은 사용량을 생성할지 모르기 때문에 일시불이 될 때까지 사용 요금을 미리받을 수 없습니다. 일시불 인 경우에는 그 금액을 미리 받아 고객의 요구에 따라 무제한 서비스를 이용할 수 있습니다.

비례 배분 및 비례 배분 불가능한 청구

고객이 월 중순에 전화 연결을하고 매월 1 일에 송장을 생성해야하는 상황을 고려하십시오. 가격을 비례 배분할 수없는 경우 청구 시스템은 고객에게 공정하지 않은 월 전체에 대해 고객에게 청구합니다. 해지시에도 동일하게 적용되며, 고객이 월 중순에 서비스를 해지하면 운영자는 해당 월의 나머지에 대해 고객에게 비용을 청구하지 않을 수 있습니다.

비례 배분 가능한 가격은 고객이 서비스를 사용할 일 수에만 적용된다는 것을 의미합니다. 예를 들어 월간 제품 임대료가 $ 30이고 고객이이 제품을 10 일 동안 만 사용한 경우 청구 시스템은 해당 10 일 동안 고객에게 $ 10 만 청구해야합니다.

따라서 청구 시스템은 비례 할 수있는 것과 비례 할 수없는 특정 가격을 구성하는 옵션을 제공하고 운영자가 가장 적합한 제품군을 선택할 수 있도록해야합니다.

환불 및 환불 불가 요금

이제 운영자가 한 달 동안 고객에게 미리 요금을 청구하지만 고객이 10 일 동안 서비스를 사용한 후 월 중순에 떠나는 상황을 생각해 보겠습니다.

가격이 환불 불가로 구성된 경우 고객에게 환불되지 않지만 환불 가능으로 구성된 경우 고객에게 환불됩니다. 두 번째 규칙은 가격이 비례 배분 가능하도록 구성된 경우 비례 배분에 따라 환불되고 그렇지 않으면 전체적으로 환불됩니다.

비용 대체 옵션

좋은 청구 시스템은 고객에게 제공되는 기본 가격을 대체 할 수있는 옵션을 제공합니다.

예를 들어, 카탈로그의 특정 제품 기본 가격은 월 $ 30로 정의되어 있지만 고객은 지불 할 준비가되지 않았습니다. $30 per month, and based on some bargaining, he is ready to pay $한 달에 25 개. 이러한 상황에서 고객 서비스 담당자 (CSR)는 정의 된 기본 가격을 재정의 할 수 있어야합니다.$30 and add them as $시스템에서 고객 생성시 25.

청구 시스템은 특정 가격이 재정의 될 수 있는지 여부를 운영자에게 선택적으로 제공해야하며, 운영자가 판매시 일부 요금을 재정의할지 또는 모든 상황에서 고정 할지를 결정하도록해야합니다.

수익 코드에 따른 수익 분리

모든 운영자는 특정 제품, 임대, 일시 중지 또는 사용 등을 사용하여 얼마나 벌 었는지 알고 싶어합니다.

카탈로그에서 서로 다른 가격을 정의하는 동안 청구 시스템은 특정 유형의 수익 코드 또는 키워드를 서로 다른 유형의 요금과 연관시키는 조항을 제공해야합니다. 이는 수익과 관련된 코드를 기반으로 다양한 보고서를 생성하는 데 도움이됩니다.

관세 분류

운영자는 다른 신용 등급을 가진 다른 사람들에게 제공 될 수있는 다른 관세를 정의 할 수 있습니다. 예를 들어 비용이 5mbps 인 데이터 라인$100 per month can be offered to a customer having monthly income more than $최소 월 수입이 $ 500 / 월인 고객에게 1000 / 월 및 1mbps 데이터 라인을 제공 할 수 있습니다.

모든 청구 시스템은 다양한 신용 등급을 정의 할 수있는 옵션을 제공하며, 이는 고객의 신용 기록 및 수입을 기반으로 고객에게 할당 될 수 있으며 운영자가 정의한 일부 다른 매개 변수를 기반으로 할 수 있습니다.

모든 제품과 서비스는 일반 클래스에서 VIP 클래스에 이르기까지 다양한 계층의 사람들에게 제공 될 수있는 다른 요금제를 가질 수 있습니다.

사용 요금에 대한 매개 변수

사용 요금을 정의하는 동안 사용할 수있는 여러 매개 변수가 있습니다. 예를 들면-

일반적으로 피크 타임이라고하는 주간 통화는 더 높은 요금으로, 야간에는 요금이 부과됩니다. 즉, 피크 타임 외 요금은 상대적으로 낮습니다.
통화가 동일한 네트워크 내에서 종료되는 경우 (일반적으로 온넷 통화라고 함) 비교적 저렴한 요금이 부과됩니다.
주말, 즉 토요일과 일요일의 통화는 저렴한 가격으로 청구됩니다.
특정 목적지로의 전화는 높은 가격으로 청구됩니다.
일부 축제 기간 중에는 특별 요금이 부과됩니다.
특정 사이트에서 데이터 다운로드는 무료입니다.
특정 코드로 SMS를 보내면 높은 요금이 부과됩니다.
일반적으로 CUG (Closed User Group)라고하는 특정 번호 그룹 내의 통화는 제로 가격으로 청구됩니다.
국제 또는 국내 MMS 전송은 동일한 가격으로 청구됩니다.

청구 시스템은 고객이 생성 한 음성, 데이터, SMS 또는 MMS 사용량을 청구하는 다양한 규칙을 정의 할 수있는 많은 유연성을 제공합니다.

다음은 무엇입니까?

이제 청구 시스템에서 모든 제품, 서비스 및 관련 관세를 사용할 수 있습니다. 다음 장에서는 이러한 제품을 최종 사용자에게 판매하고 시스템에서 레코드를 만드는 방법을 살펴 보겠습니다.

고객은 서비스 제공 업체가 제공하는 제품 및 서비스를 받고 청구서를 지불하는 책임이있는 "법적 실체"(개인 또는 회사 일 수 있음)입니다. 주거용 청구 시나리오에서 고객은 단일 가구 주일 수 있습니다. 비즈니스 청구 시나리오에서 고객은 회사 일 수 있습니다.

Individual customer− 개별 고객은 하나 이상의 제품을 구입하고 요금을 지불하는 한 사람 (또는 가구)입니다. 고객 또는 계정을 유지하는 데 필요한 계층은 없습니다.
Company customers− 회사 고객은 단일 회사 또는 회사의 지점입니다. 회사의 여러 지점 또는 부서를 나타내는 일반적인 상위 및 하위 유형의 고객 계층이있을 수 있습니다.

고객 확보 프로세스

고객 확보는 잠재적으로 수익성이있는 고객을 식별, 유치 및 유지하는 프로세스입니다. 이것은라는 시스템을 사용하여 처리됩니다.Customer Relationship Management (CRM)은 중요한 비즈니스 지원 시스템 (BSS) 중 하나입니다.

CRM 시스템은 항상 과금 시스템을 포함한 다양한 시스템과 연결되며 고객 개인 데이터와 제품 및 서비스 정보를 과금 시스템에 공급합니다.

제품 및 서비스를 구매하는 고객은 시스템에서 활성화되어야하며이를 위해 고객에 대한 다양한 세부 정보가 필요합니다.

고객은 개인 정보를 제공하는 신청서를 작성해야 할 수 있습니다.
사기를 방지하기 위해 고객의 신원을 확인합니다.
서비스 제공자는 고객에 대한 신용 확인을 수행하고 신용 내역 및 월 소득 등을 기반으로 적절한 신용 등급을 지정해야합니다.
서비스를 제공하기 위해 네트워크에서 프로비저닝되는 적절한 제품을 제공하십시오.

고객이 확보되면 고객을 관리하고 유지해야합니다.

판매 및 수집 활동을 위해 고객과 상호 작용하고 의사 소통합니다.
이러한 상호 작용은 메모, 음성 녹음 등과 같은 다양한 형식으로 기록 될 수 있습니다.이 데이터는 고객의 행동을 분석하는 데 사용될 수 있으며 서비스 제공 업체가 고객을 유지하기 위해 더 나은 서비스를 제공하는 데 도움이됩니다.
네트워크 또는 송장 등에서 직면 한 문제에 대해 고객이 제기 한 문제 티켓을 처리합니다.이 데이터는 고객의 행동을 분석하는데도 사용될 수 있으며 서비스 제공 업체가 고객을 유지하기 위해 서비스를 개선하는 데 도움이됩니다. .
고객과 서비스 제공 업체간에 제기 된 모든 청구 분쟁 및 조정 처리.

고객 라이프 사이클

일반적인 고객 라이프 사이클은 다음 다이어그램에 나와 있습니다.

고객 라이프 사이클을 구성하는 모든 단계가 여기에 요약되어 있습니다.

Customer Engagement − 고객이 CSR (고객 서비스 담당자)에게 연락하면 CSR이 고객에게 판매하여 제공되는 다양한 제품 및 서비스로 고객을 참여시킵니다.
Order Creation and Fulfilment − 고객이 제품과 서비스를 가져 가고 CSR이 주문을 생성하고 시스템에 완료 한 다음 고객에게 필요한 제품과 서비스를 제공하여 이행합니다.
Service Provisioning − 제품과 서비스는 다음과 같은 시스템을 사용하여 네트워크에서 제공됩니다. Provisioning System. 프로비저닝 시스템은 고객의 정보와 사용 권한이있는 서비스에 대해 네트워크에 알립니다. 실제로 이것은 네트워크에서 고객을 활성화합니다.
Products Utilization − 고객이 네트워크에서 활성화되면 고객은 전화 걸기, 데이터 다운로드 등을 포함한 제품 및 서비스 사용을 시작합니다.
Products and services usage is Rated & Billed − 고객 사용량은 네트워크에서 수집 된 후 정의 된 요금제에 따라 등급이 매겨지며 제품 대여 및 필수 할인, 조정 등을 적용하도록 청구됩니다.
Bill Delivery − 청구서가 생성되면 제공된 서비스에 대한 수익을 요구하는 최종 고객에게 전달됩니다.
Bill Payments − 고객은 수령 한 송장에 대해 지불합니다.
Dunning & Collection− 정시에 청구서를 지불하지 않는 고객이 많을 수 있습니다. 이러한 유형의 고객에게는 지불에 대해 상기시키기 위해 다른 독촉장이 발송됩니다. 고객이 제 시간에 지불하지 않으면 고객 서비스를 중지하는 것부터 하나씩 다른 수금이 수행됩니다.
Customer Termination− 시스템에서 고객 해지가 필요한 경우 여러 가지 이유가있을 수 있습니다. 예를 들어 고객이 다른 위치로 마이그레이션하거나 제공된 서비스에 만족하지 않을 수 있습니다.

주어진 날짜에 시스템의 총 활성 고객 수를 customer base. 시스템에 고객을 추가하고 시스템에서 고객을 종료하는 것을customer churn.

고객 유형

일반적으로 오늘날의 통신 시장에는 다음과 같은 유형의 고객이 있습니다.

Mobile Pre-Paid Customers− 사전에 요금을 지불하여 모바일 서비스를 이용하는 고객입니다. 예 : GSM, GPRS 전화 사용자. 이러한 고객은 요구 사항에 따라 휴대 전화를 충전합니다.
Mobile Post-Paid Customers− 청구서를받을 때마다 요금을 지불하여 모바일 서비스를 이용하는 고객입니다. 예 : GSM, GPRS 전화 사용자. 이러한 고객은 월별 또는 격월로 청구서를 지불합니다.
Fixed Pre-Paid Customers− 유선 전화 등 유선 서비스를 이용하여 요금을 선불로 지불하는 고객입니다. 예 : PSTN, WiMax 전화 사용자. 이러한 고객은 요구 사항에 따라 휴대폰을 충전합니다.
Fixed Post-Paid Customers− 이들은 수신 된 모든 청구서 이후에 요금을 지불하여 유선 서비스와 같은 유선 서비스를 사용하는 고객입니다. 예 : PSTN, WiMax 전화 사용자. 이러한 고객은 월별 또는 격월로 청구서를 지불합니다.

다음은 무엇입니까?

이제 우리는 제품 및 서비스와 함께 청구 시스템에 고객이 있습니다. 고객은 구매 한 모든 제품 및 서비스를 활용하기 시작하고 국내 및 국제, 데이터 및 음성 통화를 생성하기 시작합니다.이 통화는 청구 시스템에 의해 평가되고 청구되며 이후 장에서 이러한 프로세스에 대해 논의 할 것입니다.

고객은 운영자가 판매하는 제품 및 서비스를 사용하기 시작하는 즉시 네트워크에서 사용량을 생성하기 시작합니다. 네트워크 요소는 소프트웨어와 하드웨어의 조합이며 모든 유형의 서비스에 대한 전반적인 서비스 제어 및 측정 이벤트를 담당합니다.

이벤트 란?

이벤트는 일반적으로 네트워크에 의해 전자적으로 캡처되는 제품 사용의 단일 청구 가능 발생입니다. 예를 들어 휴대폰 사용자가 전화를 걸면 통화 시간, 통화 시간, 전화 번호 등 해당 전화 통화에 대한 정보가 포함 된 이벤트가 생성됩니다.

CDR이란 무엇입니까?

모든 속성과 함께 이벤트가 호출됩니다. Call Detail Record(CDR). 네트워크 스위치의 데이터 수집기는 CDR (Call Detail Record) / UDR (Usage Detail Record) 형식으로 사용량을 캡처합니다. 이러한 원시 CDR / UDR은 중재 시스템에 의해 결제 시스템이 이해할 수있는 형식으로 차례로 변환됩니다.

서비스를 제어하고 다양한 유형의 CDR을 생성하는 다양한 네트워크 요소가있을 수 있습니다. 예를 들어 GSM 전화의 경우-

음성 통화는 MSC (Mobile Switching Centre)에서 캡처됩니다.
SMS 트래픽은 SMSC에 의해 캡처됩니다.
데이터 트래픽은 GGSN에 의해 캡처됩니다.
MMS 트래픽은 MMSC에 의해 캡처됩니다.
로밍 CDR은 로밍 파트너의 스위칭 요소에 의해 캡처됩니다.

GSM, MSC, SMS, SMSC, GGSN, MMS, MMSC에 대한 자세한 내용은 GSM 자습서 를 참조하십시오 .

다음 다이어그램은 사용량 데이터를 캡처하고 원시 UDR을 조정 시스템으로 전송하고 마지막으로 평가 및 청구를 위해 청구 시스템으로 보내는 네트워크 요소를 보여줍니다.

CDR 속성

위에서 언급했듯이 CDR은 다양한 기타 유용한 정보와 함께 사용 세부 정보를 유지합니다. 다음은 CDR의 가장 중요한 속성입니다.

발신자 (번호).
수신자 (B 번호).
통화 시작 (날짜 및 시간).
통화 시간 (기간).
통화 유형 (음성, SMS, 데이터 등).
레코드를 식별하는 고유 한 시퀀스 번호입니다.

또한 CDR은 다음과 같은 다른 정보를 기록 할 수도 있습니다.

전화 교환기의 식별자입니다.
통화 결과 (응답 여부 등).
통화를 연결하는 데 사용되는 트렁크 또는 경로입니다.
오류 상태가 발생했습니다.
착신 전환, 3 자간 통화 등과 같은 기능의 사용을 나타내는 표시기
통화 대기 또는 통화 전환과 같이 통화 중에 사용되는 모든 기능.
요구 사항에 따라 다양한 기타 속성.

UDR에 필요한 모든 정보의 정확한 기록은 스위치 공급 업체의 논리와 스위치 별 테이블 항목에 따라 다릅니다. 이들 중 어느 하나라도 데이터를 정확하게 기록 할 수없는 경우 중개 시스템은 완료된 통화를 인식하지 못하고이를 청구 시스템으로 전달할 수 없습니다.

CDR 처리

중재 시스템은 서로 다른 형식의 서로 다른 네트워크 요소에서 CDR을 수집합니다. 다양한 네트워크 요소는 ASN.1 형식으로 CDR을 생성하며 일부 네트워크 요소에는 고유 한 CDR 형식이 있습니다.

중재 시스템은 모든 CDR을 처리하고 일반적으로 청구 시스템 인 다운 스트림 시스템과 호환되는 형식으로 변환합니다. 중재 시스템은 CDR에 다양한 규칙을 적용하여 처리합니다. 예를 들어, 중개 시스템은 전화를 건 번호 (B- 번호)를 기준으로 국제 전화를 표시하고, 중개 시스템은 A- 번호 및 B- 번호를 기준으로 온-넷 통화를 표시하는 것과 동일합니다.

통화 시간이 5 초 미만인 모든 통화를 필터링해야하는 요구 사항이있을 수 있습니다. 이러한 유형의 통화를 필터링하는 가장 좋은 위치는 중재 시스템 수준입니다. 같은 방식으로, 청구에 중요한 CDR에 추가 정보가 필요한 경우 중재 시스템은 CDR 내에서 사용 가능한 다른 속성을 기반으로 이러한 정보를 제공하는 데 도움이됩니다.

수집 된 CDR이 처리되면 일반적으로 중재 및 청구 시스템이 서로 다른 시스템에서 실행되기 때문에 중재 시스템은 FTP를 사용하여 모든 CDR을 청구 시스템에 푸시합니다.

다음은 무엇입니까?

이제 고객이 생성 한 사용량을 캡처했습니다. 다음 장에서는 최종 사용자로부터 적절한 수익을 수집 할 수 있도록 캡처 된 사용량을 평가하는 방법에 대해 설명합니다.

요금은 이벤트 발생에 대한 요금 / 가격입니다. 요금의 예에는 전화 통화 시간에 대한 요금이 포함됩니다. 예 : "1 분당 0.40 INR"또는 특정 수량. 예 : 1MB 다운로드의 경우 10.00 INR 또는 서비스 품질에 대해 요금이 부과 될 수 있습니다.

이벤트는 제품 / 서비스 사용의 단일 발생이라고 이미 설명했습니다. 이벤트는 CDRS / UDR의 형태로 네트워크 요소에 의해 캡처되고 등급 및 청구를 위해 청구 시스템으로 전달됩니다.

등급은 개별 이벤트의 요금 / 가격을 결정하는 프로세스입니다. 예를 들어, 2 분 통화 요금은 0.80 INR이며 비율은 분당 0.40 INR입니다.

Billing 시스템의 일부인 Rating Engine은이 등급 기능을 수행합니다.

평가 프로세스

평가 엔진은 제품 / 서비스의 사용을 설명하는 CDR (통화 정보 기록) 또는 UDR (사용 정보 기록)이라는 데이터 기록 형식으로 이벤트를 수신합니다. CDR은 이벤트를 평가하는 데 사용되는 통화 날짜 및 시간, 통화 길이, 발신자, 수신자 등과 같은 통화 정보를 포함하는 데이터 문자열입니다.

Rating / Rating Engine의 기본 기능 목록이 있습니다.

로밍 사용의 경우 중재 시스템 또는 기타 서비스 제공 업체 또는 로밍 파트너로부터 CDR을 수락합니다.
CDR의 유효성을 검사하고 중복 레코드를 제거합니다. 이러한 중복 이벤트는 나중에 확인하기 위해 데이터베이스 테이블에 저장됩니다.
이벤트에 대해 청구되어야하는 고객 계정을 결정합니다. 여기서 Rate 프로세스는 이벤트 소스 (휴대폰 번호 또는 IP 주소 등)를 선택하고 데이터베이스를 확인하여이 이벤트 소스가 계정과 연결되어 있는지 확인합니다. 이 단계를 이벤트 안내라고합니다.
이벤트를 안내 할 수없는 경우이 이벤트는 거부되며 서스펜스 카테고리에 포함될 수 있습니다. 이러한 거부 된 이벤트는 나중에 확인할 수 있도록 데이터베이스 테이블에 저장됩니다.
등급 관세 (요금 계획이라고도 함)에 따라 이벤트의 비용 / 가격을 계산합니다.
적용 가능한 등급 시간 할인을 적용합니다. 처음 5 분 동안은 무료 일 수 있으며 그 이후에는 정상 요금이 부과됩니다. 이러한 유형의 할인을 등급 시간 할인이라고합니다.
청구 목적으로 데이터베이스에 등급 이벤트를 저장하거나 청구를 위해 외부 시스템으로 전송합니다.

다음 이미지는 평가 엔진 및 관련 기능의 개요를 보여줍니다-

고객 정보에 따라 요금 / 가격 계산에 사용할 요금제 (정격 요금)가 결정됩니다. 등급 엔진은 등급 테이블과 CDR의 이벤트 정보 (예 : 거리, 시간, 통화 위치, 이벤트 기간 또는 볼륨 등)를 사용하여 각 통화에 대한 실제 요금을 계산합니다.

중복 이벤트

중복 이벤트는 다음과 같은 방식으로 다른 청구되지 않은 이벤트와 관련된 청구되지 않은 이벤트로 정의됩니다.

계좌 번호는 동일합니다.
이벤트 소스는 동일합니다.
이벤트 유형 ID는 동일합니다.
이벤트 날짜와 시간은 동일합니다.

중복 이벤트를 식별하기 위해 청구 시스템에서 다른 기준을 정의 할 수 있습니다. 중복 이벤트가 청구 시스템에 제출 될 수있는 여러 상황이 있습니다.

중개 시스템의 필터링 메커니즘 실패.
중개 시스템 소프트웨어의 코딩 오류.
평가 엔진으로 전달되는 이벤트 파일의 전체 또는 일부를 반복합니다.

거부 된 이벤트

Billing System에서 특정 이벤트에 문제가 발생하면 잘못된 이벤트가 거부됩니다. 거부는 다음과 같은 문제로 인해 발생할 수 있습니다.

이벤트 자체.
요금제입니다.
고객 및 계정 데이터.
구성 데이터.

이벤트를 거부하는 세 가지 주요 이유가 있습니다.

구문 분석 오류로 인해 청구 시스템이 이벤트 세부 사항 레코드의 정보를 읽을 수 없습니다. 이벤트 레코드의 데이터가 손상되었거나 형식이 잘못되어 구문 분석 오류가 발생할 수 있습니다.
유도 할 수없는 오류는 Geneva가 이벤트와 관련된 이벤트 소스 또는 계정을 식별하지 못하게합니다. 이벤트 소스가 Billing System 데이터베이스에 아직 존재하지 않기 때문에 안내 할 수없는 오류가 발생할 수 있습니다.
평가할 수없는 오류로 인해 Billing System이 이벤트 비용을 계산하지 못합니다. 요금제 문제로 인해 평가할 수없는 오류가 발생할 수 있습니다.

거부 된 모든 이벤트는 특별 계정에 게시됩니다. internal account 또는 suspense account 이러한 거부 된 이벤트는 suspense events. 재무 부서는 거부 된 모든 이벤트를 추적하고이를 수익 손실의 일부로 계산합니다. IT 부서는 거부 된 이벤트를 해결하고 수익을 절약하기 위해 적절한 등급을 매기기 위해 항상 많은주의를 기울입니다.

거부 된 이벤트를 수정할 수없고 운영자가 내부 계정에 게시하기를 원하지 않는 경우 이벤트를 삭제할 수 있습니다. 이벤트가 삭제되면 평가 엔진에 제출되지 않으며 평가를 더 이상 시도하지 않습니다.

실시간 평가

실시간 평가는 이벤트가 발생하면 즉시 평가하고 이벤트 생성과 비용 산정 사이에 가능한 한 지연을 최소화하는 프로세스입니다. 실시간 등급은 파일 기반 등급과 대조 될 수 있습니다. 여기서 이벤트 세부 정보는 전체 파일이 최종 등급을 매기기 전에 몇 시간, 며칠 또는 몇 주 동안 파일 버퍼에 저장됩니다.

실시간 시스템 프로세스에는 전자 상거래 및 데이터 다운로드가 포함됩니다. 이벤트를 평가하고 고객의 계정에 신속하게 적용해야하는 모든 애플리케이션은 실시간 평가에 적합한 후보입니다.

이벤트 재평가

이벤트를 재평가해야하는 몇 가지 상황이 있습니다. 예를 들어,-

사용 된 요금제의 오류로 인해 가격이 잘못 책정 된 이벤트가 발생했습니다.
이벤트가 잘못된 계정에 대해로드되었습니다 (잘못된 이벤트 소스 등록으로 인해).
마지막 청구일과 다음 청구일 사이에 기존 요금제가 대체되었습니다.
제품의 요율 계획, 가격 계획 또는 이벤트 소스가 소급하여 변경되었습니다.

이벤트를 재평가하는 과정은 매우 간단하며 다음과 같습니다.

제공된 유틸리티를 사용하여 데이터베이스에서 모든 이벤트를 언로드 / 언 레이트합니다. 대부분의 청구 시스템은 평가 된 모든 이벤트를 언로드하거나 언 레이트하는 유틸리티를 제공합니다.
어디에 있든 문제를 해결하십시오.
평가 엔진에서 평가할 이벤트를 다시 제출하십시오.

부분 이벤트

부분 이벤트를 통해 이벤트가 진행되는 동안 고객의 잔액을 유지할 수 있습니다.

예를 들어 긴 데이터 다운로드의 경우 중개 시스템은 부분 이벤트를 결제 시스템에 계속 전송하여 결제 시스템이 이벤트 완료를 기다리지 않고 계속 평가하도록하고 고객의 신용 한도 위반시 계정이 금지되고 네트워크 요소는 통화를 종료하라는 알림을받습니다.

임계 값 및 조치

평가 엔진은 평가 시간 할인 임계 값을 포함하여 평가 시간 임계 값에 도달했는지 자동으로 확인할 수 있습니다.

평가 시간 임계 값은 많은 수익 손실로부터 운영자를 보호하는 데 도움이됩니다. 예를 들어, 고객이 자신의 신용 한도 이상을 지불 할 의사가 없을 수 있습니다.이 경우 신용 한도 임계 값에 도달하는 즉시 고객의 통화를 종료해야합니다.

평가 시간 조치를 취해야하는 경우 가능한 한 실시간 평가를받는 것이 중요합니다.

다음은 무엇입니까?

지금까지 고객이 사용량을 생성하는 방법과 중재 시스템이 해당 사용량 (CDR)을 청구 시스템으로 푸시하는 방법 및 청구 시스템이 해당 CDR을 평가하는 방법을 살펴 보았습니다.

다음 장에서는 한 달 동안 평가 된 모든 CDR을 수집하고 제공된 서비스에 대한 수익을 수집하기 위해 최종 고객에게 전송되는 최종 송장 / 청구서를 생성하는 방법에 대해 설명합니다.

청구는 모든 비 반복적이고 주기적이며 청구 가능한 이벤트를 계정별로 집계 한 것입니다. 또한 모든 미결제 요금과 사용 가능한 할인 및 보너스를 계산합니다.

청구 프로세스의 출력은 종이, 디스크 또는 기타 미디어에 청구서를 작성하는 데 사용할 수있는 태그가 지정된 청구서 데이터 스트림입니다. Billing System의 일부인 Billing Engine은 송장을 생성합니다.

빌 프로세스

다음 다이어그램은 Billing Engine 및 관련 기능의 기본 다이어그램을 보여줍니다.

Billing Engine은 청구서를 생성하기 위해 계정을 선택하고 송장 데이터를 생성하기 위해 다음과 같은 관련 정보를 수집합니다.

송장 월 내 고객에 대한 모든 정격 CDR.
고객의 제품 및 서비스에 적용되는 모든 유형의 요금 (시작, 설치, 정기, 일시 중지, 종료 등).
환불 또는 기타 요금이 적용되는 경우.
이전 청구서의 총 미결제 금액입니다.
해당 월에 고객이 지불 한 총 금액입니다.
고객을 위해 또는 고객에 대해 전달 된 총 조정입니다.
고객에게 제공되는 총 할인입니다.
고객의 사용 및 임대료에 적용되는 총 세금.
청구 엔진을 실행하는 데 필요한 청구 구성 매개 변수입니다. 예 : 지불 기한 등

위에서 언급 한 정보는 단지 예시 일 뿐이며 청구 시스템마다, 운영자마다 다를 수 있습니다.

Billing Engine은 최종 청구서를 생성하는 데 필요한 모든 정보를 포함하는 원시 데이터를 생성하며이 원시 데이터를 사용하여 최종 고객에게 보낼 최종 청구서를 생성 할 수 있습니다.

빌 사이클

고객이 청구 시스템에 추가되면 시스템은 고객에게 사전 정의 된 청구주기를 할당합니다. 청구주기는 Billing Engine이 실행되고 고객 집합에 대한 청구서를 생성하는 날짜입니다.

고객이 많은 경우에는 서로 다른 결제 주기로 나뉩니다. 예를 들어 고객 그룹은 매월 1 일로 청구 데이터를 가질 수 있습니다. 다른 하나는 매월 15 일에 청구 날짜를 가질 수 있습니다.

고객이 매월 1 일에 청구서를 실행하도록 지정된 경우이를 고객의 nominal bill date. 그러나 여러 가지 이유로 인해 여러 번 빌 실행이 지연되고 나중에 실제 청구서가 생성됩니다.actual bill date.

빌 유형

사용자가 사용할 수있는 다양한 유형의 청구서가있을 수 있습니다. 일부 결제 시스템에서 지원하지 않을 수 있습니다.

Sr. 아니.	청구서 유형 및 설명
1	Initiation bill 일반적으로 계정의 첫 번째 청구서로만 요청됩니다. 제품 요금 및 조정은 포함되지만 이벤트는 없습니다.
2	Periodic bill 일정한 간격으로 생산됩니다. 모든 정기 청구, 이벤트 및 조정을 포함합니다.
삼	Interim bill 마지막 청구 이후 계정에 대해 처리 된 이벤트로 인한 요금이 포함 된 추가 청구서입니다. 모든 이벤트 및 조정을 포함하지만 정기 요금은 없습니다.
4	Suspension bill 계정이 정지되었을 때 전송됩니다. 모든 정기 청구, 이벤트 및 조정을 포함합니다.
5	Final bill 미결제 금액을 모두 청구하기 위해 계정이 해지되었을 때 전송됩니다. 환불과 함께 모든 정기 청구, 이벤트 및 조정을 포함합니다. 예를 들어, 보증금 반환.
6	Post-final bill 해지 된 계정에 최종 청구서 생성 후 미결제 AR이있을 때 전송됩니다. 종료 후 이벤트 및 조정을 포함하지만 정기적 인 요금은 없습니다.
7	Credit note 마지막 청구 이후 생성 된 고객의 편의에 따라 모든 조정이 포함 된 추가 청구서입니다.
8	Summary Statements 고객 주도 청구 계층 구조에 대한 요약 명세서를 생성 할 수 있습니다. 각 고객과 관련된 모든 계정에서 생성 된 모든 청구서를 요약 할 수 있습니다. 선택적으로 모든 청구서를 하나의 명세서로 연결할 수도 있습니다.

청구서는 자동으로 또는 고객의 요청에 따라 생성됩니다.

결제 모드

결제 시스템은 두 가지 모드로 청구서를 생성 할 수 있습니다.

Test (what if?) billing mode−이 모드는 데이터베이스를 변경하지 않고 형식화 된 테스트 청구서를 생성하는 데 사용됩니다. 이러한 청구서는 시스템이 제대로 작동하는지 확인하고 청구서 템플릿 또는 관세를 변경 한 후 테스트하는 데 유용합니다.
Billing Engine을 테스트 모드로 실행할 때 데이터베이스에 커밋되지 않습니다. 따라서 테스트 청구를 여러 번 실행 한 후에도 고객의 프로필에 영향을 미치지 않습니다.
테스트 청구서는 일반적으로 샘플 고객 세트에 대해 실행됩니다. 테스트 청구서에 만족하면 생산 청구서를 진행할 수 있습니다.
Production (live) billing mode−이 모드는 일반 생산 청구서를 생성하는 데 사용됩니다. 대부분의 경우 이는 Billing Engine의 기본 모드입니다.
생산 청구서가 생성되면 Billing Engine은 고객이 지불 할 총 미결제 잔액과 다음 청구 날짜 등으로 데이터베이스의 고객 프로필을 업데이트합니다.

청구 엔진은 모든 생산 청구서에 서로 다른 청구서 번호를 지정하여 청구서에 대해 이루어진 서로 다른 지불을 추적하는 데 도움을줍니다.

빌 억제

청구서를 생성 할 가치가없고 청구서를 억제하는 것이 더 좋은 상황이있을 수 있습니다. 다음은 이러한 유형의 상황입니다.

0 (활동 청구서가 없음) 또는 가치가 매우 적은 (소액 청구서) 계정에 대한 청구서를 억제합니다.
동시에 여러 청구서 유형이 요청 / 예약되어 불필요한 청구서가 고객에게 발송되는 것을 방지하는 경우 특정 유형의 청구서를 제외 할 수도 있습니다.

소액 청구서는 최소 양수 청구 금액과 최대 음수 청구 금액으로 정의 된 범위, 예외적 인 청구 조건 사이에있는 청구서입니다. 소액 청구서는 생성 된 다음 청구 프로세스에서 제거되어 고객에게 발송되지 않습니다.

뛰어난 청구서

가능한 예외적 인 청구서의 예로는 계정의 신용 한도를 설정된 배율로 초과하는 비정상적으로 높은 청구서 또는 청구서가 있습니다. Billing Engine은 생성하는 청구서 데이터에 대해 몇 가지 기본 검사를 수행합니다. 여기에는 다음 조건이 충족되는지 확인하기 위해 청구되는 총액 테스트가 포함됩니다.

청구서 총액이 최소 음수 청구 금액보다 큽니다.
청구서 합계가 최대 양수 청구 금액보다 적습니다.
청구서 총액이 계정의 신용 한도에 신용 한도 승수를 곱한 값보다 적습니다.

위의 모든 조건은 과금 시스템과 과금 시스템 및 운영자마다 다르며 예외적 청구 조건이라고합니다.

빌 항목 화

기본적으로 모든 송장은 사용 요금과 함께 제품 및 서비스 요금에 대한 자세한 요약을 제공합니다. 그러나 고객의 모든 통화에 대한 세부 정보를 제공하지는 않습니다.

항목 별 청구서는 고객의 모든 통화에 대한 완전한 세부 정보를 제공하는 것을 의미합니다. 인쇄하려면 더 많은 용지가 필요합니다. 최근 추세는 전자 메일을 통해 항목 별 청구서를 발송하는 것이며, 청구서의 실제 사본을 사용하여 요약 명세서를 발송합니다.

빌 포맷팅

최종 형식의 청구서를 생성하는 데 사용할 수있는 청구 형식화 유틸리티를 제공하는 청구 시스템이 있습니다.

Bill 포맷터는 Billing Engine에서 생성 된 출력 데이터를 가져와 일반적으로 Bill Printing Company에서 사용할 수있는 Post Script 파일 또는 PDF 파일을 생성합니다.

Billing System이 형식화 된 청구서를 생성하기에 충분하지 않은 경우 시스템은 청구 정보와 함께 태그가 지정된 파일 세트를 생성하고 외부 Bill Formatter는 해당 태그 정보를 사용하여 올바른 형식의 청구서를 생성 할 수 있습니다.

어쨌든 Billing System이 형식화 된 송장을 생성하거나 외부 도구를 사용하여 청구 엔진에서 생성 된 원시 데이터를 사용하여 이러한 형식화 된 송장을 생성하는 경우 마지막으로 이러한 송장은 송장 생성의 최종 사본을 생성하는 청구서 인쇄 회사로 전송됩니다. . 이에 대해서는 다음 장 "인보이스 생성"에서 자세히 설명합니다.

다음은 무엇입니까?

다음 장에서는 실제로 평가 및 청구 프로세스의 일부인 할인 프로세스에 대해 설명 할 것이지만 항목이 다양하기 때문에 더 많은 설명이 필요하므로 별도의 섹션으로 유지했습니다.

다양한 유형의 할인 계층에 대해 설명하고 평가 및 청구시 제공 할 수 있습니다.

모든 할인은 이벤트 및 / 또는 제품 세트에 대해 지불 할 가격을 변경합니다 (가장 일반적으로 감소). 할인은 고객에게 돈을주는 방법입니다. 할인은 특정 기준을 충족하는 제품 또는 사용량에 적용 할 일정 금액 (백분율 또는 화폐)을 정의합니다. 예를 들어 2010 년 1 월 1 일이라는 특정 날짜에 이루어진 모든 시내 전화에는 $ 0.20가 청구됩니다.

할인은 평가 프로세스 또는 청구 프로세스 중에 계산할 수 있습니다.

Rating Time Discount− 평가 과정에서 제공되는 모든 할인. 이러한 할인은 사용시에만 적용됩니다. 평가 시간 할인의 예는 "모든 국제 전화의 첫 시간에 5 % 할인"입니다.
Billing Time Discount− 결제 과정에서 제공되는 모든 할인. 이러한 할인은 정격 사용량과 제품 및 서비스 요금에 대해 제공 될 수 있습니다. 청구 시간 할인의 예는 "한 달에 $ 15 이상 지출시 5 % 할인"입니다.

사전 항목 화 할인은 재평가 된 가격을 결정하기 위해 적용되는 각 이벤트의 가격을 수정하는 할인입니다. 이 할인은 청구 시간 할인 범주에도 적용되지만 통화 등급과 관련이 있습니다. 다른 청구 시간 할인은 이벤트 가격을 수정하지 않고 그대로 둡니다. 사전 품목 화 할인에는 제품 요금이 포함되지 않고 이벤트 요금 만 포함됩니다.

할인 단계 및 임계 값

할인 규모는 일련의 할인 단계 및 임계 값을 사용하여 결정됩니다. 할인 단계를 통해 특정 임계 값에 도달했을 때 할인 크기를 변경할 수 있습니다.

예를 들어 전화 이벤트 할인은 통화 시간 (분)에 따라 달라지며 100 분 후 10 % 할인, 200 분 후 20 % 할인이 적용됩니다.

각 할인에는 최소한 한 단계가 있어야합니다. 할인이 더 많은 수량으로 다소 유리 해지기 위해 필요한 경우 추가 단계를 추가 할 수 있습니다. 각 할인 단계에는 금액 또는 백분율 (둘다는 아님)으로 표시되는 할인이있을 수 있습니다.

간단한 할인 유형

최종 고객에게 제공되는 할인 유형은 무한 할 수 있지만 결제가 지원하는 항목에 따라 다릅니다. 다음은 제공 할 수있는 간단하지만 매우 좋은 유형의 할인입니다.

교차 제품 할인

제품 및 이벤트 세트가 다른 제품 및 이벤트 세트에 대한 할인을 결정하는 할인입니다.

예 : "휴대 전화에 $ 30 이상 지출하면 SMS 10 개 무료". 여기에서 모바일 통화가 할인을 결정하고 SMS 제품이 할인을받으며 이러한 유형의 할인을cross product discounts.

계층 할인

이는 지정된 할인 임계 값 사이에 해당하는 이벤트 또는 지출 된 금액의 일부에만 적용됩니다. 예를 들어, 다음 다이어그램에서 지출에 대해 0 % 할인$0-$100 임계 값 또는 0-100 이벤트 임계 값, 지출시 5 % 할인 $100-$200 개 임계 값 또는 100-200 개 이벤트 임계 값 등

볼륨 할인

특정 제품이 생성하는 이벤트 수 또는 제품 요금에 따른 할인입니다. 예를 들어, 다음 다이어그램에서 $ 100 또는 100 이벤트 등의 지출에 대해 5 % 할인됩니다. 표시된 것처럼 지출이 클수록 할인이 더 많이 발생합니다.

세금 할인

세금 할인은 일부 면세를 처리하는 대체 방법을 제공합니다. 계정이 청구될 때 계산되고 적용됩니다.

할인 기간 및 비례 배분

대부분의 할인에는 할인 기간이 있으며, 일, 주 또는 월이 될 수 있습니다. 이 기간은 세 가지 방법으로 사용할 수 있습니다.

임계 값에 도달해야하는 시간을 지정합니다.
절대 할인이 적용될 빈도를 지정합니다.
가장 높은 사용량 필터가 연결된 할인에 대해 가장 높은 사용량이 결정되는 빈도를 지정합니다.

할인은 요구 사항에 따라 비례 배분되거나 비례 배분되지 않을 수 있습니다. 할인이 비례 배분 된 경우 서비스가 사용 된 일수를 기준으로 할인이 계산되고, 비 할인 할인의 경우 할인이 구성된 전체 기간에 대해 계산됩니다.

보너스 제도

보너스 제도는 고객에게 무료 이벤트를 제공하는 방법으로, 무료 이벤트의 수는 일정 기간 (예 : 전년도) 동안 하나 이상의 제품에 대한 이전 사용 또는 요금에 의해 결정됩니다.

예를 들어, "초특가 전화 패키지를 사용하고 지난 분기에 3 시간 동안 국제 전화를 걸 때마다 10 달러의 무료 통화를받을 수 있습니다."

예를 들어, 패키지를 통해보다 유리한 가격 계획을 제공하고, 수량이 증가함에 따라 제품의 단가를 낮추는 등 고객에게 돈을주는 다른 방법이 있습니다.

CUG (서클 그룹 호출)

발신 서클 그룹은 회원과 (기본적으로) 비회원으로 모델링 된 사용자 간의 관계를 정의합니다.

이 모델 내에서 서클 회원이 서클의 다른 회원에게 전화를 걸면 동일한 통화를하는 비회원 (또는 준회원)에게 적용되는 요금과 다른 요금이 적용됩니다.

발신자 간의 관계는 발신자 신원의 조합에 의해 결정됩니다. 네트워크가 동일한 교환 원에 속하고 단일 통화 서클에 모바일 및 유선 사용자를 모두 포함 할 수있는 경우 발신 서클이 네트워크에 걸쳐있을 수 있습니다.

다음은 무엇입니까?

이전 장에서 이미 청구 프로세스를 다루었습니다. 다음 장에서는 원시 송장 데이터에서 구조화 된 청구서 형성에 이르기까지 송장 생성의 마지막 부분에 대해 설명합니다.

대부분의 청구 시스템은 청구서의 정보 내용을 포함하는 구조화 된 ASCII 텍스트를 생성합니다. 각 청구서의 청구서 데이터는 처음에 데이터베이스 또는 플랫 텍스트 파일에 기록됩니다. 이 단계의 데이터 형식은 데이터 처리 방법에 관계없이 동일합니다.

이 청구서 데이터는 원하는 형식으로 출력을 생성하기 위해 여러 형식화 엔진 중 하나에 의해 처리 될 수 있습니다. 예 : 종이, CD-ROM 등

내부 Bill Formatting 도구를 제공하는 Billing System이 있습니다. 청구 시스템이 형식화 된 청구서를 생성 할 수있는 도구를 제공하지 않는 경우 가장 일반적으로 사용되는 도구 중 하나 인 DOC1과 같은 타사 도구를 사용할 수 있습니다.

다음은 청구서 서식의 흐름을 보여주는 일반적인 다이어그램입니다.

다음은 Convergy의 Infinys Billing System에서 가져온 청구서 데이터의 스냅 샷입니다.

DOCSTART_85
DOCTYPE BILL
GENEVAVERSION 5.0
BILLSTYLE 1
BILLTYPE 1
BILLTEMPLATE 85
BILLSEQ 1
BILLVERSION 1
ACCCURRENCYCODE BEF
BILLLANGID 2
BILLLANGNAME English (US)
BILLLANGLOCALE us
PAYMETHODID 1
FORMATREQ A30001001/0001
COPYBILLNUM 0
BILLPURPOSE 1
ADDRESSNAME Dr D Jackson
POSITION Project Manager
DEPARTMENT Recruitment
ADDRESS1 12 South Street
ADDRESS2 Detroit
ADDRESS3 Michigan
ZIPCODE 12345
COUNTRY United States
BSTARTACCFADDR
ACCFADDR_1 United States
ACCFADDR_2 Michigan
ACCFADDR_3 12345
ACCFADDR_4 12 South Street
ACCFADDR_5 Detroit
ACCFADDR_6 Dr D Jackson
BENDACCFADDR
CUSTOMERREF C30001
CUSTOMERTYPE Standard
ACCTAXSTATUS Exclusive
INVOICINGCONAME Invoicing company for English (US)
INVOICINGCOADDRESS1 Company House
INVOICINGCOADDRESS2 Atlanta
INVOICINGCOVATREG taxref000576
ACCOUNTNO A30001001
BENDBFPAYSUMMARY
BALOUT 0.00
CHARGES 142.00
NEWBAL 142.00
BSTARTBFPAYDETAILS
ACCDEPPREVTOT 0.00
ACCDEPCHANGE 0.00
ACCDEPCURRTOT 0.00
BENDBFPAYDETAILS
BENDBFSTATEMENT
BILLREF A30001001@0001
BILLDATE 02/20/99
NEXTBILLDATE 03/20/99
BSTARTPAYMENTDUEINFO
PAYMENTDUEDATE 03/04/99
DEBTSTARTDATE 02/25/99
PAYMENTTERMDESC Payment due 7 days after the bill date
PAYMENTDUEDAYS 7
BENDPAYMENTDUEINFO
GIROREF 34
GIROACCOUNT 404 7800
OCRREF 1300010019
OCRSORTCODE V6344047800
GIROAMOUNT 142.00
OCRAMOUNT 000142000
INVOICEACTUALDATE 02/25/99
INVOICETAXDATE 02/25/99
INVOICESTART 01/03/99
INVOICEEND 02/19/99
TAXTYPE 1,2.00,
TENDTAXTYPE
INVTOTALTAX 2.00
BENDTAXDETAILS
INVTOTAL 142.00
INVTOTALROUNDED 142.00
TOTALSAVE -11.00
PERIODEND 02/25/99
POINTSBALANCE 0
POINTSEARNED 0
POINTSREDEEMED 0
POINTSADJUST 0
NEWPOINTSBALANCE 0
DOCEND

Bill 데이터는 일련의 ASCII 텍스트 행으로 구성됩니다. 각 라인은 다음과 같은 형식을 취합니다.

TAGNAME tagvalue

TAGNAME 및 태그 값은 공백의 태그 구분 기호 (tagsep)로 구분됩니다. tagvalue는 단일 값이거나 구분 기호로 구분 된 값 목록 (9 월) 일 수 있습니다. 사용 된 구분 기호는 지정하지 않는 한 쉼표입니다.

빌 포스트 프로세서

청구 엔진은 청구서에 필요한 모든 정보를 생성하지 못하거나 청구서에 제공된 데이터에 대해 특별한 계산을 수행해야 할 수 있습니다. 이를 Bill Post Processing이라고하며 일반적으로 Bill Post Processor (BPP).

BPP는 선호하는 프로그래밍 언어로 작성 될 수 있습니다.이 언어는 원시 송장 파일을 읽고 최종 형식화를 위해 전달하기 전에이 파일에 필요한 수정을 수행합니다.

요구 사항이 운영자마다 다르며이 프로세스를 표준화 할 수 없기 때문에 기본 BPP 기능을 제공하는 청구 시스템이 없습니다. 기껏해야 청구 시스템은 Billing Engine과 함께 사용자 정의 BPP를 연결하는 플러그인 지점을 제공 할 수 있습니다.

DOC1 빌 포맷터

DOC1은 PitneyBowes Company에서 제공하는 매우 유명한 Bill Formatter 도구로, 청구서를 PDF 또는 Post Script 파일로 형식화하는 데 도움이됩니다.

위에서 언급했듯이 Billing Engine의 출력은 청구서의 정보 콘텐츠를 포함하는 구조화 된 ASCII 텍스트입니다. 청구 시스템에서 생성 된 소스 송장 파일 태그와 DOC1에 필요한 태그간에 매핑이 설정됩니다. DOC1에는 아래와 같이 고정 길이 태그가 필요합니다.

다음은 제공된 송장 파일의 가상 샘플입니다.

ACCOUNTNO ACC0010000
ACCUMBONUSPOINTS_1 BON0050100
ACCUMBONUSPOINTS_2 BON0050100
ACCUMBONUSPOINTS_3 BON0050100
ACCUMBONUSPOINTS_4 BON0050100
ACCUMBONUSPOINTS_5 BON0050100
ADDRESS1 ACC0030000
ADDRESS2 ACC0040000
ADDRESS3 ACC0050000
ADDRESS4 ACC0060000
ADDRESS5 ACC0070000
ADDRESSNAME ACC0020000
BUSINESSNAME ACC0120000
TSTARTADJ ADJ0000000
..........

이제 위의 번역을 사용하여 DOC1에 대한 최종 파일이 생성되고 DOC1은 제공된 정보를 사용하여 최종 송장 생성을 처리합니다.

일부 수정은 DOC1 수준에서도 수행 할 수 있지만 송장을 수정하는 데 많은 유연성을 제공하지 않습니다. 훨씬 더 많은 기대치를 얻을 수있는 최신 버전을 사용해 볼 수 있습니다.

최종 송장 생성

모든 계정이 청구되고 청구서가 내부 또는 외부 청구서 포맷터를 사용하여 포맷되면 이러한 청구서는 최종 인쇄를 위해 Bill Print Company로 전송됩니다.

운영자가 전자 메일 기능을 사용하여 고객에게 청구서를 보내는 경우 동일한 청구서 사본을 전자 메일 시스템으로 보내 최종 고객에게 보낼 수 있습니다.

Tier 1 운영자 (2 천 ~ 3 천만 명 이상의 고객 기반)는 일반적으로 청구서 분배를 포함하여이 작업을 아웃소싱합니다.

다음은 무엇입니까?

송장을 생성 한 후 최종 고객에게 보냅니다. 이제 고객으로부터 수익을 수집 할 때입니다. 수익 수집 과정은 한 장 후에 논의 할 것입니다.

계속 진행하기 전에 매우 중요하며 수익 수집 전에 다루어야하는 신용 관리 부분을 다룹니다.

모든 운영자는 서비스를 제공하고 비즈니스에서 생존하기 위해 최종 고객으로부터 수익을 수집합니다. 최종 고객에게 청구하는 방법은 두 가지가 있습니다.

In-Advance− 운영자는 서비스를 제공하기 전에 고객에게 미리 요금을 청구합니다. 이로 인해 고객 만족도가 떨어지지 만 운영자는 수익 관점에서 더 안전합니다.
In-Arrears− 운영자는 필요한 서비스를 제공 한 후 매월 말에 위험을 감수하고 고객에게 비용을 청구합니다. 이것은 더 많은 고객 만족으로 이어지지 만 운영자는 더 적은 수익을 모을 위험에 처해 있습니다.

운영자가 특정 고객과 관련된 수익 손실을 감당할 수있는 한계는 항상 있습니다. 동시에 운영자가 특정 고객에 대해 감수 할 수있는 위험의 임계 값이 있습니다.

예를 들어, 고객의 소득이 $10,000/month, then operator can provide him their services very easily up to $1000- $2000 but for the same operator it would be difficult to provide him a service, which would cost almost $이러한 상황에서는 고객이 매월 결제하기 어려울 것이기 때문에 월 10,000 회입니다.

동일한 개념을 유지하면서 운영자는 서로 다른 신용 등급을 정의하여 고객을 분류하고 서로 다른 신용 및 징수 조치를 연결하는 데 사용합니다.

학점 등급

신용 등급은 고객의 범주를 정의하고 해당 고객과 관련된 수익 위험을 감수 할 수 있습니다. 신용 등급은 또한 소유자가 만기 된 (분쟁되지 않은) 지불을하지 않을 경우 고객에게 적용될 수금 일정을 정의합니다.

모든 결제 시스템은 다양한 신용 등급을 정의 할 수있는 기능을 제공하며, 시스템에 추가 할 때 다른 고객에게 할당 할 수 있습니다. 신용 등급의 몇 가지 예는 다음과 같습니다.

VIP Credit Class − 이것은 VIP 고객에게 할당 될 수 있으며 신용 한도의 가치가 매우 높습니다.
General Public Class − 이것은 가장 일반적인 학점 등급이며 거의 $100 or $200 크레딧 한도.
Segment Specific Class − 이러한 등급은 경찰, 군대 또는 은행원 등과 같은 다양한 부문을 기준으로 정의 될 수 있습니다. 운영자는 편의에 따라 신용 한도를 정의 할 수 있습니다.

고객의 요구 사항과 범주에 따라 정의 된 신용 등급은 무한 할 수 있습니다.

신용 관리

특정 유형의 고객 범주에 대해 신용을 제어 할 수있는 주로 두 단계가 있습니다.

미 청구 사용량 기반

이것은 평가 프로세스에 의해 수행되는 평가 시간 제어입니다. 여기에서 고객의 사용량 및 총 청구액은 할당 된 여신 한도에 대해 확인되며, 고객이 할당 된 여신 한도에 접근하기 시작하면 동일한 사실을 고객에게 알리고 여신 한도를 위반 한 후 적절한 조치를 취할 수 있습니다.

고객이 신용 한도를 위반하는 경우 서비스를 금지 (즉, 일시적으로 중지)하고 지불이 완료되면 서비스를 금지하려는 운영자가 있습니다. 예를 들어, 크레딧 한도가 $ 200 인 고객은 SMS를 통해 사용량의 80 %에 대해 알림을 받고, 임계 값이 90 %에 도달하면 알림 통화 등을 통해 알림을받을 수 있으며, 크레딧이 100 % 인 경우 한계에 도달하면 발신이 금지 될 수 있습니다.

크레딧을 제어하기 위해 운영자는 음성 및 SMS 사용의 경우 발신 전화 만 금지하는 것을 선호하지만 데이터 다운로드의 경우 고객은 데이터 다운로드를 수행 할 수 없습니다.

청구 사용량 기반

이것은 일반적으로 송장을 보낸 후 수행되며 다음 장에서 논의 할 수익 수집 프로세스와 관련이 있습니다.

평가 시점에 신용을 관리하려면 가능한 한 실시간으로 평가하는 것이 중요합니다. 사용량이 실시간으로 캡처되지 않고 오랜 간격 후에 등급이 지정되는 경우 고객이 신용 한도를 초과하고 법적으로 고객이 할당 된 신용 한도를 초과하여 금액을 지불 할 수 없을 가능성이 있습니다. 이는 국가 및 통신사마다 다릅니다.

매장

계좌에 대한 예금을 지원하는 청구 시스템이 있습니다. 예금은 계좌 잔고와 함께 보관되며 현금은 둘 사이에 이체 될 수 있습니다.

계정에 대해 유지 관리 할 수있는 다양한 종류의 서비스를 제공하기 위해 다양한 수준의 예금이있을 수 있습니다.

예금은 운영자가 고객이 지불 할 수없는 경우 수익을 충당하는 데 도움이됩니다.

다음은 무엇입니까?

다양한 등급의 고객에게 제공되는 크레딧을 제어하는 방법에 대한 아이디어가 있기를 바랍니다. 그럼에도 불구하고 자신의 능력 내에서 크레딧을주고도 제때 지불하지 않는 다양한 고객이있을 것입니다. 서비스 이용 후 전혀 지불하지 않는 다양한 고객이 있습니다.

다음 장에서는 제공된 서비스에 대한 수익을 수집하기 위해 다양한 수익 수집 프로세스 및 일정을 정의하는 방법을 설명합니다.

송장이 생성되어 고객에게 발송되면 이상적으로는 모든 고객이 청구서를 받고 즉시 지불하게됩니다. 그러나 청구서를 지불하지 않는 일부 고객이있을 수 있으며 청구서 지불이 용납 할 수없는 지연이있을 수 있으므로 서비스 제공 업체는 상황을 해결하고 미결제 금액을 징수하는 데 필요한 조치를 취해야합니다 (미수금, A / R로 축약 됨).

수금은 고객 계정에서 연체 AR을 추적하는 프로세스입니다. 여기에는 일반적으로 고객에게 알림을 보내고 만기일 이후 지불해야 할 금액이 없을 경우 적절한 조치를 취하는 것이 포함됩니다.

Billing Systems는 송장을 기준으로 송장에서 AR을 추적하는 송장 레벨과 여러 송장에 걸쳐 계정에 대한 모든 연체 금액을 단일 독촉 조치로 처리 할 수있는 계정 레벨에서 독촉 (미수금 추적)을 지원합니다.

계정에 사용할 독촉 모델은 신용 등급을 기준으로 지정됩니다. 핵심 수집 프로세스에는 다음 두 항목이 포함됩니다.

Collections Aging Tracking− 지정된 결제 기한 내에 결제되지 않은 고객 송장을 추적하는 과정입니다. 그것은 "미수금의 나이"를 다룹니다; 예를 들어, 연체 0-30 일, 연체 30-60 일 등의 송장.
Collections Actions− 징수 조치는 미수금이 특정 연령에 도달했을 때 수행되는 조치입니다. 예를 들어, 고객에게 발송 될 알림 메시지 또는 녹음 된 오디오 메시지를 재생해야합니다.

수집 조치 일정

일반적으로 컬렉션 작업은 다음 단계에서 수행됩니다.

알림 메일 및 / 또는 전화 보내기 : 고객 서비스 부서에서 결제를 상기시키는 고객에게 연락합니다. 그래도 지불이 수신되지 않으면 다음 작업을 진행하십시오.
빨간색 편지 보내기-예를 들어 "7 일 이내에 지불"편지가 발행됩니다. 그래도 지불이 수신되지 않으면 다음 작업을 진행하십시오.
서비스 연결 해제-네트워크 관리 부서에서 서비스를 일시 중단합니다.

수금 일정은 고객이 지불하지 않을 때 수행해야하는 수금 조치와 수행해야하는 시간을 정의합니다.

수금 일정은 수금 프로세스를 구성하는 일련의 단계를 지정합니다. 각 단계에 대해 다룹니다.

조치가 발생하기 위해 AR이 있어야하는 유효 연령입니다. 받을 채권의 유효 연령은 실제받을 연령을 취하여 계산됩니다.
취해야 할 조치입니다. 이는 예를 들어 특정 날짜에 독촉 통지를 보내는 것과 같이 Billing System이 수행 할 작업 일 수 있습니다.
조치가 필수인지 여부입니다. 작업이 필수 인 경우이 작업이 수행 될 때까지 후속 작업을 수행 할 수 없습니다.
조치가 수행되지 않는 최소 AR 금액입니다.

소프트 수금 조치-독촉 통지

수금 프로세스의 초기 단계에서 소프트 수금 조치는 일반적으로 간단한 알림 편지와 지급 요청 인 여러 독촉 통지를 보내는 것입니다.

여러 단계에서 여러 독촉 통지를 보낸 후 일반적으로 다른 조치가 스케줄링됩니다. 예를 들어, 고객 서비스 담당자 (CSR)가 고객에게 전화를 걸어 지불하지 않은 이유를 물어 보도록 지정할 수 있습니다.

하드 컬렉션 작업-블랙리스트

초기 시도가 실패하면 서비스 차단 또는 서비스 연결 해제와 같은보다 적극적인 조치를 취할 수 있습니다. hot-lining (핫라인은 연체 고객의 모든 전화를 수금 담당자에게 리디렉션하는 프로세스입니다).

회비를 징수하려는 모든 시도가 실패하면 서비스 제공 업체는 계정을 상각하고 납입 금액을 불량 부채로 표시하거나 수금 기관에 계정을 양도 (매각) 할 수 있습니다. 징수 대행사는 징수 된 수익의 일정 비율로 작업합니다. 단, 미수금 인보이스가 수금 대행 업체에 매각되면 서비스 제공 업체는 결제와 관련하여 고객과 협력 할 수 없습니다.

여기서 상각이란 서비스 제공 업체 (운영자)가 고객을 대신하여 회비를 정산하고 계정을 영구적으로 폐쇄하는 것을 의미합니다. 이것은 회계 목적으로 수행되며 그렇지 않으면 운영자에게 손실입니다.

서비스 제공 업체는 블랙리스트 고객이라고도하는 상쇄 계정의 기록을 유지하여 다시 활성화되지 않도록하고 해당 계정에 대해 신용 확인 /보고 기관에 알립니다.

다음은 무엇입니까?

대부분의 고객은 기한 이전에 결제합니다. 결제에 사용되는 다양한 채널이있을 수 있습니다.

다음 장에서는 다양한 유형의 지불과 송장 정산을위한 종단 간 처리에 대해 설명합니다.

송장이 고객에게 전송되면 고객은 청구서 지불을 시작합니다. 청구 시스템으로의 청구서 지불 처리를 지불 처리라고합니다.

고객이 지불 한 금액은 고객의 계정에 게시됩니다. 미결제 송장이있는 경우 지급되는 송장은 계정의 회계 방법에 따라 다릅니다. 회계 방법에는 두 가지 유형이 있습니다.

Balance forward accounting −이 방법을 사용하면 미결제 인보이스가 여러 개인 경우 수령 한 결제 금액이받을 수있는 연령에 따라 인보이스에 할당되며 가장 오래된 인보이스가 먼저 생성됩니다.
Open item accounting−이 방법을 사용하면 특정 송장에 지불을 할당 할 수 있습니다. 미결 항목 회계는 특히 비즈니스 고객의 지불을 처리 할 때 유용합니다.

결제 방법

고객은 서비스 제공자가 지원하는 다양한 결제 방법을 사용하여 결제 할 수 있습니다. 예를 들어, 고객은 수표, 신용 카드, 직불 카드 또는 전신 송금 또는 직접 현금 입금과 같은 지불 방법을 사용하여 지불 할 수 있습니다.

운영자는 은행 계좌를 통해 직접 지불을받을 은행 계좌를 여러 개 가질 수 있습니다. 이러한 은행 계좌를 보유 계좌라고하며 결제 세부 정보를 텍스트 파일로 청구 시스템에 보냅니다.

결제 시스템 외부에서 수동 또는 전자 방식으로 결제를 받으면 해당 결제는 자동 프로세스를 사용하여 시스템에 업로드되어 송장을 정산합니다.

자동 결제

Billing Systems는 신용 카드 또는 직불 카드 정보를 수집하는 기능과 매월 자동 결제 방법을 제공합니다.

신용 카드 또는 직불 카드를 사용하여 결제 방법을 자동으로 설정하면 모든 인보이스 또는 지정된 날짜에 결제 요청이 자동으로 생성되고 이러한 요청은 결제 승인을 위해 결제 게이트웨이 (또는 은행)로 전송됩니다.

모든 지불이 승인되면 청구 시스템에 업로드되어 만기 송장을 정산합니다.

수동 결제

현금이나 수표를 사용하여 지불하는 경우 고객이 시스템에 미리 입력하거나 일부 기관에서 수집 한 경우 이러한 모든 지불이 수집되어 청구에서 제공하는 자동화 된 방법을 사용하여 청구 시스템에 게시됩니다. 체계.

받은 모든 지불에 대해 지불 파일은 사전 정의 된 형식으로 준비된 다음 Billing System이 사전 정의 된 위치로 자동으로 푸시되어 Billing System이이를 선택하여 청구 데이터베이스에 업로드합니다.

신용 카드 나 수표로 결제가되지 않는 상황이있을 수 있습니다. 이 결제가 이미 시스템에 게시 된 경우 금액을 조정하려면 취소해야합니다. Billing System은 실패하거나 취소 된 지불을 처리하는 유틸리티를 제공합니다.

결제 인터페이스

인터페이스는 결제 시스템과 결제를 받기위한 다른 외부 시스템 간의 경계입니다. 인터페이스를 사용하면 두 시스템이 미리 정의 된 규칙에 따라 다른 시스템과 통신 할 수 있습니다.

예를 들어 간단한 텍스트 파일은 은행과 청구 시스템 간의 지불 인터페이스가 될 수 있습니다. 인터페이스가 파일 기반 인 경우 은행은 사전 정의 된 형식의 결제 파일을 사용하여 결제 세부 정보를 계속 보냅니다.

은행과 결제 시스템간에 온라인 API 기반 인터페이스가있을 수 있습니다. 온라인 인터페이스가있는 경우 은행은 제공된 API를 호출하여 결제 시스템에 직접 결제를 게시합니다.

비슷한 방식으로, 지불 수금과 관련된 제 3 자에게 제공되는 파일 기반 또는 온라인 인터페이스가있을 수 있습니다.

다음은 무엇입니까?

지금까지 통신 고객의 전체 수명주기를 거의 완료했습니다. 다음 장은 운영자와 고객간에 발생하는 분쟁 상황을 이해하는 데 중요합니다.

분쟁이란 무엇입니까?

분쟁은 계좌의 금액에 대한 질의 기록입니다. 일반적으로 고객이 청구서의 일부 측면을 문의 할 때 분쟁이 기록됩니다. 분쟁을 제기 할 수 있습니다.

계정의 송장에 대해.
계정의 특정 등급 이벤트에 대해. 예를 들어 고객이 정전으로 인해 특정 유료 TV 이벤트에 이의를 제기하는 경우입니다.

분쟁 처리

분쟁이 기록 된 후에는 다음 중 하나를 수행하기 위해 조사되고 확인됩니다.

Accept − 제기 된 분쟁이 고객 측에서 유효한 경우 분쟁이 수락되고 고객에게 환불됩니다.
Reject − 분쟁이 허용되지 않는 것으로 판명되면 분쟁이 거부됩니다.
Cancel − 분쟁이 잘못 입력 된 경우 분쟁이 취소됩니다.

분쟁에 대해 다음 사항에 유의해야하며 청구 시스템이 이러한 사항을 지원해야합니다.

금액의 분쟁 상태가 보류 중일 때는 수금 조치가 에스컬레이션되지 않지만이 기간 동안 수금이 만료됩니다.
분쟁이있는 이벤트는 청구될 때까지 수금 계산에 포함되지 않습니다. 그 후 컬렉션은 정상적으로 에이징됩니다.

조정이란 무엇입니까?

조정은 임의의 금액으로 계좌에 입금 또는 출금하는 방법입니다. 조정은 계정 전체 또는 해당 계정의 특정 등급 이벤트에 대해 제출할 수 있습니다.

결제 시스템을 사용하면 다양한 유형의 조정을 생성 할 수 있으며, 이는 서로 다른 상황에서 사용할 수 있으며 각 조정은 서로 다른 승인 단계를 거치게됩니다.

분쟁이 수락되면 분쟁 금액이 계정에 입금되도록 조정이 생성됩니다. 조정은 승인 될 때까지 계정 잔액에 영향을주지 않습니다. 승인 보류 상태의 조정은 청구 또는 수금에 영향을주지 않습니다.

세금 포함 계정에 대한 분쟁 및 조정에는 세금이 포함 된 것으로 간주됩니다. 총액이 입력되고 청구서에 출력 할 수 있습니다.

다음은 무엇입니까?

다음 장에서는 관리에 필요한 다양한 유형의 보고서에 대해 설명합니다. 바로 사용할 수있는 보고서 목록이있을 수 있으며 사용자 지정 개발이 필요한 일부 보고서가있을 수 있습니다.

재무, 영업 및 시스템 성능에 대한 경영진에게 귀중한 정보를 제공하기 위해 다양한 보고서가 생성됩니다. 재무 보고서, 관리 보고서, 조정 보고서, 네트워크 활동 보고서 등과 같은 다양한 종류의 보고서를 생성 할 수 있습니다.

보고서에는 비즈니스 성공을 유도하고 비즈니스 상태를 모니터링하고 문제 영역을 식별하여 적절한 수정 조치를 취할 수 있도록 돕는 정보가 포함됩니다.

보고는 청구 시스템 중 어떤 것도 100 % 요구 사항을 즉시 충족 할 수없는 영역 중 하나입니다. 확실히 마케팅 또는 재무 부서는 이러한보고 요구 사항을 제시 할 것이며 많은 사용자 지정 개발이 필요합니다.

청구 시스템이 데이터웨어 하우스 (DWH)에 데이터를 푸시하는 경우보고 활동을 DWH 시스템으로 전송할 수 있지만 여전히 많은 부서에서 청구 시스템 인 소스 시스템의 중요한 보고서를 갖고 싶어합니다.

보고서를 두 가지 범주로 분류 할 수 있습니다.

Core/Canned Reports− 이러한 보고서는 결제 시스템에서 시스템의 핵심 기능으로 제공됩니다. 때로는 미리 준비된 보고서 또는 표준 보고서라고도합니다.
Custom Reports − 이러한 보고서는 시스템에서 직접 사용할 수 없으며 PL / SQL, PERL 또는 Shell 스크립트 등을 사용하여 약간의 개발이 필요합니다.

다른 청구 시스템은 다른 영역에서 다른 유형의 보고서를 제공합니다. 상호 연결 청구 시스템은 도매 청구를 처리하기 때문에보고와 관련된 더 많은 기능을 제공해야합니다.

보고 요건

다음은 다른 부서에서 요구하는 보고서 목록입니다-

재무 보고서

결제 보고서는 일정 기간 동안 고객의 계정 결제에 대한 정보를 제공합니다. 미수금 월령 보고서는 미수금, 미결제 회비 등에 대한 정보를 제공합니다.

분쟁 및 조정 보고서는 분쟁 및 조정의 이유 패턴을 식별하고 그러한 분쟁 및 조정의 이유를 이해하고 적절한 시정 조치를 취하는 데 도움이됩니다.

관리 보고서

관리 보고서는 고객, 제품 및 서비스 사용, 통화 패턴, 고객 피드백 등에 대한 정보를 제공합니다. 이러한 보고서는 새로운 서비스를 도입하기 위해 고객 이탈을 줄이기위한 적절한 조치를 취하는 데 도움이됩니다.

이탈은 고객이 한 서비스 제공 업체에서 연결을 끊고 다른 서비스 제공 업체로 이동하는 과정이며, 이는 부적절한 고객 서비스 또는 경쟁 제품 부족 또는 경쟁력있는 요금 부족과 같은 여러 가지 이유 때문일 수 있으며, 지리적 인 자연적인 이유 때문일 수 있습니다. 고객의 재배치.

조정 보고서

이 보고서는 수익 및 비용의 모든 출처가 관찰되고 있으며 어떤 종류의 수익도 유출되지 않도록하는 수익 보증 (RA) 정보를 제공합니다. 예를 들어, 네트워크 시스템의 유출, 중재 또는 과금 실수, 새로운 서비스의 신속한 도입 요구 등과 같은 여러 가지 이유로 인해 수익이 손실 될 수 있습니다.

수익 보증 보고서는 적절한 조치를 취할 수 있도록 누출 위치를 식별하는 데 도움이됩니다.

네트워크 활동 보고서

이러한 보고서는 네트워크 정체 영역을 식별하는 정보를 제공하여 이러한 문제를 극복하기위한 수정 조치 (라우팅 변경 또는 추가 리소스 추가)를 수행 할 수 있습니다.

기타 보고서

다음은 청구 시스템에서 필요할 수있는 몇 가지 다른 보고서의 가상 목록입니다.

Sr. 아니.	보고서 설명
1	신용 등급, 고객 세부 사항, 가격 계획, 청구 유형 등을 기준으로 특정 날짜 범위의 수익 정보를 요약하는 수익 분류 보고서입니다.
2	주로 수금 추적을 지원하기 위해 제공되는 고객 상세 내역, 월령 AR 및 미결 항목 보고서.
삼	일일 활동을 요약하고 총계정 원장 정보를 제공하는 Daybook 보고서.
4	데이터베이스의 제품 및 특정 청구 / 등급 카탈로그에서 사용할 수있는 패키지에 대한 세부 정보를 제공하는 제품 및 패키지 보고서.
5	아웃 바운드 상호 연결 CDR의 조정을 용이하게하는 IAA (Interconnect Agreement Accounting) 보고서입니다.
6	매일 활성화, 종료, 포트 인 또는 포트 아웃의 총 수입니다.
7	매일 신용 한도를 위반하는 총 계정 수와 신용 위반으로 발생하는 수익입니다.
8	특정 기간 동안 성공적으로 평가되고 내부적으로 게시되고 비용없이 게시 된 이벤트 수에 대한 보고서입니다.
9	특정 서비스 또는 모든 서비스 (예 : 음성, SMS, MMS 등)에 대한 중복 이벤트 보고서
10	특정 서비스 또는 모든 서비스 (예 : 음성, SMS, MMS 등)에 대한 거부 된 이벤트 보고서

자동 vs 수동

매월, 매주 또는 매일 필요한 보고서 목록이있을 수 있습니다. 따라서 이러한 유형의 보고서는 시스템 내에서 사용할 수없고 일정이 잡혀 있지 않은 경우 개발되어 수동 개입없이 최종 사용자의 전자 메일 상자로 보낼 수 있습니다.

일부 요구 사항에 따라 수시로 다른 보고서에 대한 요구가있을 것입니다. 이러한 유형의 보고서는 미리 상상하고 개발할 수 없습니다. 따라서 이러한 보고서는 다른 사용자의 요구에 따라 개발되고 전송됩니다.

다음은 무엇입니까?

다음 장부터 다양한 유형의 청구에 대해 다룰 것입니다. 예 : 소매, 도매, MVNO, 로밍 등

대부분의 운영자는 고객에게 두 가지 옵션을 제공합니다. postpaid 또는 prepaid연결. 후불 및 선불 연결에는 고유 한 장점과 단점이 있습니다.

일반적으로 운영자는 선불 고객으로 구성된 70 % -80 %의 고객 기반을 가지며 나머지 고객 기반은 후불 측에서 나옵니다. 운영자에게는 후불 고객을 더 많이 확보하는 것이 항상 좋습니다.

두 유형의 고객, 서비스 및 시스템 간의 차이점에 대해 알고 싶을 수 있습니다. 둘 사이의 몇 가지 주요 차이점을 나열 해 보겠습니다.

Service Payments− 이것은 두 고객 기반을 구분하는 가장 중요한 요소입니다. 선불 고객은 서비스를 이용하기 전에 선불 결제하는 반면 후불 고객은 한 달 내내 제공되는 서비스를 사용하며, 월말에 고객은 주어진 기간 내에 결제 대금을받습니다.
Charging & Billing − 선불 고객의 경우 모든 사용량에 대해 실시간으로 고객에게 청구해야하며, 후불 고객은 월말에 과금 할 수 있습니다.
Service Offerings− 후불 결제 시스템은 실시간 충전 시스템에 비해 더 많은 유연성을 제공합니다. 예를 들어, 실시간 과금 시스템은 복잡한 비즈니스 고객의 계층 구조를 유지하는 데 유연하지 않으며, 후불 과금 시스템은 최대 N 수준의 고객 계층 구조를 처리 할 수 있습니다.
Support & Maintenance− 운영자는 두 비즈니스 모두에 동일한주의를 기울여야합니다. 선불 비즈니스의 경우 운영자가 운영을 제어 할 수있는 숙련 된 인력이 필요한 경우, 운영자는 요금, 청구서 및 운영 문제 해결과 관련된 후불 고객의 문의를 처리 할 훌륭한 직원이 동시에 필요합니다.
Supported Network− 오래 전, 선불과 후불 연결의 네트워크가 달랐습니다. 이것은 선불 연결이 후불 연결보다 더 나은 연결을 제공하거나 그 반대의 경우도 가능하다는 불만을 불러 일으켰습니다. 컨버전스 빌링의 시대이며 사업자는 통신 품질 저하없이 동일한 네트워크로 비즈니스를 운영하고 있습니다.

후불 시나리오

네트워크 요소 (예 : 스위치, SMSC)는 청구 시스템에 필요한 정보를 포함하는 UDR (Usage Detail Records) 또는 CDR (Call Detail Records)이라는 원시 사용량을 생성합니다.

발신 번호 (A 번호)
착신 번호 (수신 번호) (B 번호)
통화 시작 시간 (날짜 및 시간)
통화 시간
통화 유형 (MOC, MTC 등, MOC는 Mobile Originated Call, MTC는 Mobile Terminated Call을 나타냄)

네트워크 요소 및 다른 서비스 제공 업체의 위의 원시 UDR은 청구 시스템에 의해 수신되고 청구 시스템은이를 시스템에서 이해할 수있는 형식으로 변환합니다. 위의 형식화 / 변환 된 UDR은 통화가 청구되어야하는 고객 / 계정을 찾은 다음 그에 따라 이벤트를 평가하도록 안내됩니다.

그런 다음 위의 등급 UDR이 청구 데이터 저장소에 저장되고 청구주기 날짜에 청구 프로세스는 이러한 등급 UDR을 선택하여 처리하고 결제, 세금, 할인 등을 고려하여 청구 / 청구서를 렌더링합니다.

그런 다음 고객이 청구서를 지불하고 청구 시스템이 지불 세부 정보로 업데이트됩니다. 다음은 위의 표준 결제 프로세스를 보여주는 다이어그램입니다.

선불 시나리오

선불 결제와 관련된 단계는 다음과 같습니다.

고객이 전화를 걸면 선불 스위칭 게이트웨이가 전화 번호를 캡처하고 계정 정보를 실시간 과금 시스템으로 보냅니다.
위의 정보를 활용 한 실시간 과금 시스템은 사용자의 신원을 인증하고, 요금표와 통화의 최대 허용 시간을 이용하여 고객 계정의 잔고를 계산하고이 정보를 선불 게이트웨이로 전송합니다.
게이트웨이가 호출을 설정합니다.
통화 중에 게이트웨이는 사용자가 허용되는 최대 통화 시간을 초과하지 않도록 통화를 모니터링합니다.
통화가 끝나면 게이트웨이는 실제 통화 시간을 선불 결제 시스템으로 전송 한 다음 실제 통화 비용을 계산하고 계정 잔액을 업데이트하여 남은 잔액을 줄입니다.

다음 그림은 일반적인 선불 결제 시나리오를 보여줍니다-

선불 결제 프로세스에는 계정 정보 수집 및 통화 완료 후 계정 업데이트와 함께 다음과 같은 중요한 단계가 포함됩니다.

Authenticating− 인증은 사용자가 자신이 주장하는 신분을 확인하는 프로세스입니다. 사용자는 사용자 ID 및 비밀번호와 같은 인증 신임 정보를 제공합니다. 시스템은이를 입력으로 받아들이고 사용자가 유효하고 시스템에 액세스 할 수 있는지 확인합니다.
Authorizing− 인증은 인증 된 사용자가 수행 할 수있는 작업을 확인하는 프로세스입니다. 일반적으로 RADIUS (Remote Access Dial In User Server) 프로토콜은 시스템에 대한 액세스를 등록 및 승인 된 고객으로 제한하는 데 사용됩니다.
Providing advice of charge (AOC)− 이벤트 전후의 실제 통화 비용에 대한 정보를 제공합니다. AOC는 이벤트 발생 전이나 후에 이벤트의 실제 비용을 조언하는 통신 시스템의 기능을 제공합니다.

통신 청구에 대해 이야기 할 때 기본적으로 소매 청구에 관한 것입니다. 앞서 논의한 바와 같이 통신 소매 청구는 다음과 같이 정의됩니다.

"Telecom Billing은 사용량을 수집하고 집계하고 필요한 사용량과 임대료를 적용하고 최종적으로 고객에 대한 송장을 생성하는 프로세스입니다. Telecom Billing 프로세스에는 고객의 지불을 받고 기록하는 것도 포함됩니다."

소매 청구는 최종 고객과 직접 거래되며 최종 고객의 기대치 및 규제 의무를 충족하는 데 많은 어려움이 따릅니다. 청구는 다음 기준을 충족하는 한 성공적으로 간주됩니다.

Timely Billing− 최종 고객의 송장이 정시에 생성됩니다 (예 : 명목 날짜). 일부 물류 문제로 인해 최종 고객이 제 시간에 송장을받지 못하는 상황이있을 수 있지만, 마감일에 모든 만기 청구서를 생성하는 것은 IT의 책임입니다.
Billing Accuracy− 이는 고객 만족과 규제 의무 관점에서 가장 중요한 요소입니다. 청구 시스템이 정확한 청구서를 생성하지 않으면 합법성 관점에서 심각한 비즈니스 문제가 발생할 수있을뿐만 아니라 고객을 불만족 상태로 남겨 둘 수 있습니다.

소매 대 도매 청구

소매 청구는 최종 고객과 개별 고객에 대한 청구를 처리하는 반면 도매 청구는 비즈니스의 상황과 성격에 따라 다음 엔티티에 대한 청구를 처리합니다.

통신 사업자와 관련된 청구 리셀러.
다른 통신사의 고객에게 전화를 걸기위한 상호 연결을 제공하는 청구 상호 연결 파트너입니다.
고객이 운영자의 서비스 지역에서 로밍 할 때 고객에게 서비스를 제공하기 위해 로밍 파트너를 청구합니다.

도매 청구는 소매 청구에 비해 쉬우 며 큰 수준의 허용 한도를 허용하는 반면 소매 청구는 항상 100 % 정확해야합니다. 도매 청구는 두 사업자의 시스템에 구성된 가격의 차이 또는 어떤 네트워크 요소에서든 일부 통화를 놓칠 수 있기 때문에 평가 된 통화 수의 차이와 같은 다양한 이유로 인해 100 % 정확할 수 없습니다.

Convergys와 같은 소매 청구를 처리하는 데 사용되는 특수 청구 시스템이 있으며 Amdocs 청구 시스템은 소매 청구로 유명하지만 ASCADE 및 INTEC 청구 시스템은 도매 청구로 유명합니다.

도매 과금은 너무 많은 할인 및 판촉 유형을 다루지 않기 때문에 간단한 보고서를 사용하여 소매 과금 시스템을 사용하여 정산 할 수있는 반면, 소매 과금은 이러한 모든 복잡성이 필요하고 도매 과금 시스템을 사용하여 처리 할 수 없습니다.

이 자습서에서 지금까지 논의 된 모든 개념은 소매 결제와 관련이 있으며 후속 장에서는 상호 연결 결제, 로밍 결제 및 기타 결제 유형에 대해 설명합니다.

상호 연결은 다른 서비스 제공 업체의 호출을 처리하는 프로세스입니다. 이를 통해 한 서비스 공급자의 고객이 다른 서비스 공급자의 고객과 통신 할 수 있습니다.

두 운영자 A와 B가 상호 연결 파트너가 아니면 운영자 A의 고객이 운영자 B의 고객과 통신 할 수 없습니다.

일반적으로 운영자는 고객이 서로 통신 할 수 있도록 서로 계약을 유지합니다. 이것은 상호 연결에 관여하는 모든 운영자에게 좋은 비즈니스 기회를 제공합니다. 당사자가 각각의 네트워크 연결에 동의하는 모든 상호 연결 지점을 "Interconnection Point".

상호 연결의 예는 다음과 같습니다.

인접한 비경쟁 전화 네트워크 두 개가 상호 연결되어 한 네트워크의 가입자가 다른 네트워크의 가입자에게 전화를 걸 수 있습니다.
장거리 운송 업체는 지역 서비스 제공 업체의 시설에 대한 액세스 권한을 얻고 공통 고객 기반에 장거리 서비스를 제공하는 데있어 해당 제공 업체와 경쟁합니다.
기존 유선 전화와 새로운 무선 이동 통신 사업자는 상호 연결되어 기존 전화 서비스의 가입자가 무선 가입자에게 전화를 걸 수 있으며 그 반대의 경우도 마찬가지입니다.
새로운 경쟁력있는 지역 전화 사업자는 기존 사업자와 상호 연결하여 공통 서비스 영역에서 가입자를 유치하고 해당 가입자가 기존 사업자의 네트워크에서 가입자에게 전화를 걸 수 있도록합니다.
기존 전화 통신사의 고객은 전화 접속 인터넷 서비스 공급자에게 전화를 겁니다. 이는 다시 경쟁 지역 통신사의 고객입니다.

상호 연결 인보이스

이는 수신 상호 연결 통화 세부 정보 레코드 (CDR)와 관련하여 상호 연결 파트너에게 보낼 인보이스를 생성하는 프로세스입니다.

Interconnect Billing은 성공적인 통화 발신 및 종료를 위해 당사 인프라가 연결하는 각 네트워크 사업자에게 지불하고받을 금액을 계산하는 것과 관련이 있습니다. 통화를 상호 연결하기위한 CDR은 통화 라우팅 정보를 유효한 값 그룹으로 유지하여 통신사 및 국가 세부 정보를 식별합니다.

Interconnect CDR 세트에는 다음 세부 정보가 포함되어 있습니다.

CDR은 소매 및 도매 고객에게 청구 할 수있는 항목입니다. 통신 제공 업체의 수익입니다. 로컬 청구라고도합니다.
상호 연결 제공 업체에 대해서만 청구 가능한 CDR입니다. 예 : 발신 통화, 발신 전송 통화, 수신 통화 등. 발신 통화는 비용이고 수신 통화는 통신 공급자의 수익입니다.

Interconnect Billing 시스템은 모든 수신 및 발신 Interconnect CDR의 가격을 책정합니다. 일반적으로 상호 연결 가격은 통화를 전달하는 수신 또는 발신 트렁크 상호 연결 경로를 기반으로 수신 및 발신 상호 연결 CDR 모두에 대해 결정됩니다. 가장 일반적으로 트렁크 ID는 상호 연결 결제 시스템에서 고유 한 상호 연결 파트너를 나타냅니다.

정산 프로세스

정산 프로세스는 상호 연결 소유자에서 다른 네트워크 운영자 대상으로 또는 그 반대로 통화를 전달하는 데 관련된 네트워크 운영자 / 운송 업체를 정산하는 데 사용됩니다.

이 프로세스는 결제를 위해 나가는 (상호 연결 소유자에 대한 비용) 및 들어오는 (상호 연결 소유자에 대한 수익) 트래픽을 가져옵니다.

정산은 수동 또는 자동 프로세스를 사용하여 매월 또는 격주 단위로 수행 할 수 있습니다. 파트너의 정산을 지원하는 방식은 과금 시스템과 과금 시스템에 따라 다릅니다.

네팅 프로세스

합의 된 제공자 / 운송 업체에 대한 정산이 완료된 후 수행하는 데 사용되는 상계. 네팅은 여러 서비스에 대해 여러 정산 기간으로 이루어지며 운영자 수준에서 동일한 통화를 지원합니다.

네팅 방법에는 두 가지 유형이 있습니다.

AFTER − 사업자와 사업자 / 운송 사업자 간 금액을 차감 한 후 사업자 상호 접속 비용 상계 후
BEFORE − 운영자와 제공자 / 운송 업체 간의 금액을 차감하지 않고 운영자의 상호 연결 비용을 상계하기 전에.

조정 프로세스

이는 나가는 CDR과 관련된 상호 연결 파트너로부터 오는 인보이스를 조정하는 프로세스입니다.

매월 상호 연결 파트너는 조정 목적으로 CDR을 교환합니다. 두 파트너가 제공하는 CDR에 불일치가있는 것은 매우 일반적입니다.

Billing Systems는 수신 및 발신 상호 연결 CDR의 조정을 용이하게하는 보고서를 제공합니다. 이러한 보고서는 통화 유형, 대상, 비용 대역 및 기간과 같은 매개 변수를 유지하므로 두 운영자가 이러한 CDR을 사용하여 해당 매개 변수를 일치시키고 누락 된 CDR을 식별 할 수 있습니다.

운영자 측에서 일부 CDR이 누락 된 상황이있을 수 있습니다. 문제가 해결되지 않으면 필요한 조정을 수행 한 후 파트너간에 다양한 협상이 이루어지며, 마지막으로 영향을받는 상호 연결 파트너에게 명목 금액을 지불하여 문제를 해결합니다.

상호 연결 통화 시나리오

서로 다른 운영자 간의 계약 유형에 따라 다양한 상호 연결 통화 시나리오가있을 수 있습니다. 가장 일반적으로 사용되는 몇 가지를 살펴 보겠습니다.

교환 원 A의 고객이 교환 원 B의 고객에게 전국 전화를 겁니다. 이 경우 운영자 A는 운영자 B에게 일정 금액을 지불합니다.
교환 원 A의 고객은 교환 원 B를 통해 국제 전화를 겁니다. 교환 원 A는 국제 교환 원과 직접적인 계약이 없기 때문입니다. 이 경우 운영자 A는 운영자 B에게 일정 금액을 지불하고 운영자 B는 국제 운영자를 정산합니다.
교환 원 A의 고객은 국제 교환 원을 통해 직접 국제 전화를 겁니다. 이 경우 사업자 A는 국제 사업자에게 직접 일정 금액을 지불합니다.

위의 모든 통화는 음성, SMS, MMS 및 데이터 등이 될 수 있습니다.

상호 연결 계약

성공적인 상호 연결을 위해서는 상호 연결 계약에서 또는 규제 기관의 규칙이나 명령에 따라 다음 문제를 처리해야합니다.

Prices and adjustments − 여기에는 초기 상호 연결 요금 수준, 상호 연결 요금이 지불되는 통화의 정의, 환율 변화 및 인플레이션을 고려하여 계약 기간 동안 가격이 조정되는 방식이 포함됩니다.
Points of interconnection − 상호 연결이 이루어지는 물리적 위치와 상호 연결에 사용될 기술 표준이 정의됩니다.
Transport and traffic routing − 통화가 라우팅되는 방법과 통화를 전달하기 위해 전송 될 항목에 대해 몇 가지 정의가 이루어져야합니다.
Quality of service − 특히 회선 공급 시간과 통화 차단 수준에 대한 품질 표준이 정의되어 있으며 이러한 표준이 충족되지 않을 때 구제책이 정의됩니다.
Billing and collection − 교통 데이터 수집시기와 방법, 청구서 교환시기 및 방법, 지불시기 및 방법을 지정해야합니다.
Reconciliation− 교통 데이터를 조정하고 상대방에게 문의하고 클레임을 처리하는 프로세스도 통합되어야합니다. 불일치를 해결하기위한 절차는 종종 중재, 규제 기관 또는 법원에 대한 구제를 포함하는 유용합니다.
Numbering Plan − 해당 국가의 번호 매기기 계획 및 번호 매기기 리소스에 대한 각 운영자의 액세스를 정의해야합니다.
Traffic Load − 상호 연결된 네트워크간에 흐르는 트래픽을 전달하고 수신하는 용량을 논의하고 문서화해야합니다.

계약 유형

운영자는 트래픽을 교환하기 위해 다양한 유형의 계약을 가질 수 있습니다. 가장 일반적으로 사용되는 계약은 다음과 같습니다.

Bi-Lateral Agreement− 본 계약에 따라 각 당사자는 상호 연결 지점 및 / 또는 하나 이상의 직접 상호 연결에서 네트워크를 통해 상대방과 디지털 통신 트래픽을 교환하는 데 동의합니다. 서로 다른 파트너 간의 지불 결제는 계약에 따라 매월 또는 격월로 이루어집니다. 이 계약에 따라 두 운영자는 서로의 네트워크에서 호출을 시작하고 종료 할 수 있습니다.
Uni-Lateral Agreement− 본 계약에 따라 한 당사자는 상호 연결에서 다른 당사자의 네트워크로 자신의 트래픽을 전송하고 다른 당사자로부터 트래픽을 회수하지 않습니다. 서로 다른 파트너 간의 지불 결제는 계약에 따라 매월 또는 격월로 이루어집니다.

로밍은 이동 통신 고객이 다른 운영자의 네트워크를 사용하여 홈 네트워크의 지리적 범위를 벗어나는 동안 자동으로 전화를 걸고 받고, 데이터를주고 받거나, 다른 서비스에 액세스 할 수있는 기능입니다.

로밍은 국내 로밍 또는 국제 로밍 일 수 있습니다. 전국 로밍은 모바일 가입자가 자신의 통신사가 서비스를 제공하지 않는 지리적 영역에서 다른 네트워크를 사용하는 것을 의미합니다. 예를 들어 한 국가에서 완전한 서비스를 제공하지 않는 사업자가 사용합니다. 국제 로밍은 모바일 가입자가 해외를 여행하고 외국에있는 사업자의 네트워크를 사용할 때 사용됩니다.

실제로 어떻게 발생합니까? 서비스 공급자가 특정 도시 또는 국가에 네트워크 서비스를 제공하지 않는 경우이 서비스 공급자는 해당 도시 또는 국가에 네트워크를 보유한 다른 서비스 공급자와 로밍 계약을 맺습니다. 이 계약에 따라 다른 서비스 공급자는 첫 번째 서비스 공급자의 로밍 고객에게 사용 가능한 모든 서비스를 제공합니다.

한 로밍 파트너의 영역에서 생성 된 CDR은 해당 로밍 파트너에 의해 수집 및 평가되고 마지막으로 로밍 고객의 실제 서비스 제공 업체로 전송됩니다. 실제 서비스 공급자는 사전 정의 된 서비스 요금에 따라 제공된 모든 로밍 서비스에 대해 최종 고객에게 요금을 부과합니다.

두 명의 로밍 파트너가 실제 로밍 CDR과 해당 CDR을 기반으로 한 보고서를 교환하여 매월 재정을 정산합니다.

HPMN 및 VPMN

그만큼 Home Public Mobile Network모바일 가입자가 구독하는 사업자의 네트워크입니다. 이 용어는Visited Public Mobile Network (VPMN).

Visited Public Mobile Network는 로밍 중에 모바일 가입자가 사용하는 네트워크입니다. 이 용어는 HPMN (Home Public Mobile Network)과는 반대로 사용됩니다.

정보 센터

MACH와 같이 서로 다른 로밍 파트너간에 상호 작용하여 CDR을 교환하고 로밍 계약을 설정하고 분쟁을 해결하는 데 도움을주는 잘 알려진 기관이 있습니다.

클리어링 하우스는 인바운드 로머에 대해 한 로밍 파트너로부터 청구 기록을 받고이 로머를 아웃 바운드 로머라고하는 다른 로밍 파트너에게 청구 기록을 제출합니다.

TAP3은 무엇입니까?

Transferred Account Procedure version 3(TAP3)은 방문 네트워크 사업자 (VPMN)가 로밍 가입자의 청구 기록을 각각의 홈 네트워크 사업자 (HPMN)에게 보낼 수 있도록하는 프로세스입니다. TAP3는 표준의 최신 버전이며 네트워크가 고객에게 제공하려는 새로운 서비스 호스트에 대한 비용을 청구 할 수 있습니다.

클리어링 하우스는 TAP3 프로토콜을 사용하여 서로 다른 로밍 파트너간에 모든 CDR을 교환합니다. TAP3은 네트워크 운영자간에 로밍 사용에 대한 정보를 전달하는 방법과 정보를 정의합니다. 이러한 파일은 간단한 FTP 연결을 사용하여 교환됩니다.

TAP에는 여러 버전이 있습니다. TAP는 TAP1에서 TAP2, TAP2 +에서 TAP3으로 발전했습니다. 최신 릴리스 인 TAP3에는 위성 네트워크, WLAN 및 UMTS 및 기타 3G 기술에서 표준 간 로밍에 대한 지원이 포함됩니다.

GSM TAP Standard TD.57− GSM Transferred Account Procedure (TAP)는 여러 국가의 이동 통신사간에 로밍 사용 정보를 전송하기위한 형식 및 검증 규칙을 정의합니다. TAP3은 표준의 세 번째 사양 버전입니다. 전송 된 파일을 TAP 파일이라고합니다.
GSM RAP Standard TD.32− GSM RAP (Returned Accounts Procedure)는 전송 된 TAP 파일 / 이벤트에서 발견 된 오류에 대한 정보를 반환하여 해당 파일 / 이벤트에 대한 재정적 책임을 거부하는 형식을 정의합니다. 전송 된 파일을 RAP 파일이라고합니다.

로밍 결제

모바일 가입자가 다른 국가로 이동하여 외국 네트워크에서 사용을 생성합니다. 가입자에게 요금을 청구하려면이 정보가 가입자의 홈 네트워크로 다시 전달되어야합니다. 외부 네트워크는 스위치 등에서 사용 정보를 수집 한 다음 표준에 설정된 정보를 포함하는 TAP 파일을 생성합니다.

그런 다음 파일을 홈 운영자에게 내보내고 (일반적으로 하루에 최소한 하나의 파일) 가져 와서 정보를 사용하여 구독자에게 청구합니다. 외국 교환 원은 통화를 평가 한 다음 파일 내의 모든 통화에 대해 가입자 홈 네트워크에 요금을 부과합니다. 홈 오퍼레이터는 수익을 창출하기 위해 통화를 마크 업하거나 재평가 할 수 있습니다.

MVNO는 무엇입니까?

MVNO는 Mobile Virtual Network Operator. MVNO (Mobile Virtual Network Operator)는 휴대폰 서비스를 제공하지만 자체 라이선스 주파수 할당 무선 스펙트럼을 가지고 있지 않으며 휴대폰 서비스를 제공하는 데 필요한 모든 인프라를 갖추고 있지도 않습니다.

MVNE는 Mobile Virtual Network Enabler, 모바일 네트워크 서비스를 제공 할 수 있도록 청구, 네트워크 요소 프로비저닝, 관리, 운영, 기지국 하위 시스템 및 운영 지원 시스템 지원, 백엔드 네트워크 요소 제공과 같은 모바일 가상 네트워크 사업자에게 서비스를 제공하는 회사입니다. 휴대 전화 연결과 같습니다.

실제로 MVNO는 실제 사업자가 제공하는 모바일 제품 및 서비스의 리셀러이지만 브랜드는 다릅니다.

예를 들어 네트워크, 스위치, 과금 시스템, 프로비저닝 시스템 및 고객 관리 시스템 등 모든 인프라를 갖춘 운영자 A가 있습니다. 이제 누군가가 최소한의 투자를하여 통신 사업을 시작하고 싶다면 MVNO가 옵션입니다. 계속하려면.

MVNO는 잘 확립 된 운영자로부터 서비스를 대량 구매하고 편의에 따라 브랜드 이름을 변경하고 해당 제품과 서비스를 운영자로서 마케팅합니다. 실제 운영자는 최종 고객으로부터 투명하게 유지되며 고객은 MVNO의 최종 고객이되고 싶은 느낌을 갖게됩니다.

상황에 따라 MVNO는 운영자로부터 하나 이상의 인프라 구성 요소를 구입하고 그에 따라 비용을 지불 할 수 있습니다. 예를 들어, MVNO는 운영자의 네트워크 만 사용하거나 MVNO는 운영자의 네트워크 및 충전 시스템을 사용할 수 있으며 고객 관리, 프로비저닝 등과 같은 나머지 구성 요소는 MVNO에서 설정할 수 있습니다.

MVNO's have full control over the SIM card, branding, marketing, billing, and customer care operations.

The first commercially successful MVNO in the UK was Virgin Mobile UK, [3] launched in the United Kingdom in 1999 and now has over 4 million customers in the UK.

MVNO Services

MVNOs typically do not have their own infrastructure, but some leading MVNO's deploy their own mobile IN infrastructure in order to facilitate the means to offer value-added services. MNVO's can treat incumbent infrastructure such as radio equipment as a commodity, while the MVNO offers its own advanced and differentiated services based on exploitation of their own intelligent network infrastructure.

In this way, each MVNO and the network operator could focus on their own niche markets and form customized detailed services that would expand their customer reach and brand.

Most of the MVNOs come in the market to target only pre-paid customers and provide them only pre-paid services like voice, SMS, MMS, data, broadband, etc., with some nice value-added services.

MVNO Billing

Assuming an incumbent operator sells their infrastructure to an MVNO, there could be different business models and agreements between incumbent and MVNO. Following are the most commonly used −

MVNO can brand their services and sell them in the market and MVNE will help in providing those services to the end customer. Here, a fixed percent of commission will go to the MVNE.
MVNO can buy products and services in bulk at special discounted prices and then brand them with their name and sell in the market.
MVNO sells the products and services, and based on the usage generated by the end customers, MVNO pays an amount to the MVNE.

In all the cases, MVNO may be required to pay some amount of security deposit to the MVNE and then monthly settlement happens using simple reports generated by the MVNE.

An MVNE can add an MVNO in its billing system as a corporate customer as long as MVNO is providing post-paid services and can add all the products and services provided to MVNO. By the end of every month or usually after every two weeks, invoice can be generated and collection can be followed up.

But usually, most of the MVNOs provide pre-paid services, which are handled in Pre-Paid system. In such a case, MVNO functionality is achieved either using built-in functionality in the pre-paid system or by simply defining a separate service class. All the usage CDRs and other information is dumped into data warehouse from where reports can be generated to prepare invoice.

What is Convergent Billing?

Assume an operator is providing different services mobile voice, fixed voice, data, IPTV, broadband, pre-paid, and post-paid, etc. A customer can have one or more of these services from the same operator. A typical customer would definitely like to have single invoice and single view of his account.

A convergent billing is the integration of all service charges onto a single customer invoice and a unified view of the customer. Customer should call a call center and should get complete account information for all the services opted. Customer receives a single bill and makes a single payment for all the services.

A truly Convergent Billing System should be able to consolidate any number and combination of products and services onto a single bill, regardless of the type of product and market segment, i.e., prepaid and postpaid services.

Another important parameter contributing in convergent billing is a single product and price catalogue for pre-paid as well as post-paid customers.

Benefits of Convergent Billing

Convergent billing would help operators in achieving the following major benefits −

Single product and service catalogue gives better time to market and reduced cost of implementation.
A unified bill enables cross-service discounts, so that customers who order multiple services can receive preferential pricing.
Convergent billing enables multi-service packaging and pricing, whereby existing customers are enticed to add new services and new customers are attracted by innovative service bundles.
Centralized customer care and support for both type of customers ( pre-paid and post-paid).

Major Bottlenecks

So far, it has been a dream of all the big telecom operators to achieve true convergence. May be tomorrow some billing system would come which will support true convergence of all the product and services, but today it has the following obstacles to achieve real convergence −

Real time Charging Systems like Ericsson IN or Nokia Siemens Charging System are very popular systems to provide solution for pre-paid product and services. These systems are not flexible enough to handle various functionalities required for post-paid customers for example: complex customer hierarchies, CDR re-rating, volume discounts, flexible reporting, roaming charging, interconnect charging, etc.
Post paid billing systems like Convergys Infinys or Amdocs Billing Systems are great for post-paid product and services. These systems are not capable to handle pre-paid traffic and charge the calls in real time. Importantly these systems can not be made highly available because of their base architecture.

Keeping the two above-mentioned constraints together, if we merge both the systems by doing a kind of interfacing between pre-paid and post-paid systems, then it may be possible to achieve a true convergence. Companies like Convergys and Ericsson are working in the same direction to merge the two systems and use required functionalities from both type of systems and make them single Convergent Billing System.

Support and maintenance is an integral and the most important part of a telecom operation. Customer satisfaction directly depends on how efficient and how good support is being provided to them. If customer is being put in the loop and he is not getting good response for the problem/issue raised, simply customer would switch to another available operator.

Support and maintenance covers the following major areas −

System support and maintenance − This includes keeping the BSS (Business Support Systems) and OSS (Operation Support Systems) running in good health. If there is any issue in any of the systems ( Billing, Provisioning, Network, Mediation, Customer Care, etc.,), then it is looked by the specialists and fixed within a minimum time frame.
Customer Support − This includes fixing all the issues related to customers. A customer complains through customer care or call center and then issue flows at different stages. This issue could be related to signals, call drop, voice or data download quality, wrong bill, some dispute, service activation, or termination, etc.
System upgrades − This includes upgrading an existing system with the latest version to provide more stability and flexibility in the business. New version of any system comes along with new features to cater new business requirements. This also includes hardware upgrade to maintain system performance and for more storage as well.

Support Levels

There are always different levels of support kept in place by the service providers. These levels handle different types of issues depending on their nature and severity. Most commonly used support levels are as follows −

Level 1 − Customer contacts the customer support, which could be a call center and customer support specialist listens to customer problem and suggests a solution on the spot. For example, there could be some problems, which can be resolved by simply restarting the phone. So, an efficient customer care specialist knows about such type of problems and can suggest a solution without escalating the issue (usually called a trouble ticket) to the next level.
Level 2 − If a customer care specialist is not able to resolve a problem, then issue is escalated to second level support, which is a group of technical specialists. These specialists belong to Information Technology (IT) department, and if they are able to understand the problem, then they can suggest a solution and send the issue back to level 1, otherwise they check the nature of issue to understand if issue is related to network or billing system or provisioning system or hardware, etc., and based on the nature of the issue, issue is assigned to next level, i.e., department.
Level 3 − These are different departments specialized in their areas like core engineering, radio planning, billing, provisioning, order management, etc. If issue is escalated to them, then they analyze the problem and try to find out the root cause of the problem. Most of the times, issue will be diagnosed and fixed by third level support because they are highly skilled engineers specialized in their area. There may be situation, when issue cannot be fixed at 3rd level support because it may be related to core functionality of the system, which is not modifiable by 3rd level support. In such a case, issue is further escalated to 4th level support.
Level 4 − These are actual vendors of the systems supporting business, for example, billing system, network switch, provisioning system, etc. So, if issue is found to be related to the core functionality of billing system, for example, billing system is not able to apply correct discount, then it would be escalated to the billing system vendor, and if issue is related to the core functionality of the provisioning system, then it would be escalated to the provisioning system vendor.

Service Level Agreements (SLA)

Support departments always work with a predefined service level agreement called SLA. These SLAs are defined and kept in place keeping various parameters in mind. For example −

Severity of the issue or operational task.
Business impact of the issue or operational task.
Whether issue or operational task is impacting a single customer or multiple customers.
Whether the issue or operational task is directly related to revenue loss or customer satisfaction.

Based on such type of parameters, different priorities are defined and assigned to different issues or operational tasks. Operational task could be report generation, invoice generation, database cleanup activities, or backup activities.

Finally, each issue and operational task comes along with an assigned priority and each priority will have associated SLA. For example, if there is a problem in creating customer order, then it would be assumed a high priority issue because it is directly impacting business. Such type of issues need to be resolved as soon as possible by the assigned department. So, a very tight SLA is defined for high priority issue.

SLAs are discussed and finalized with mutual agreement keeping business need on top priority. Usually, an SLA keeps the following information −

Parameters to qualify the nature of the issue whether it is priority 1st issue or 2nd priority issue or 3rd or 4th priority issue. Lower the priority number, higher is the criticality of the issue.
For a given type of priority and severity, how much time it would take to resolve the issue.
In case of failure of an SLA, what penalty would be applied.
Contact points of escalation for each level of support.
Process flow and communication medium during issue resolution.
Infrastructure availability and other constraints impacting the issue resolution.

SLAs can be defined between different departments, between vendor and operator and between different operators as well in case of interconnection.

The following diagram shows a typical architecture of a Billing System. This chapter will give a brief introduction of all the interfacing systems starting from top to bottom.

CRM/OMOF System

This is the first system from where a customer order is captured and customer is created into the system. CRM stand for Customer Relationship Management and OMOF stands for Order Management and Order Fulfilment.

There are systems like Siebel, which provides modules for CRM as well as OMOF. The CRM system keeps customer-related information along with product and services. The OMOF module is responsible to track order starting from its creation till its completion.

Here, we have two possibilities −

CRM (Customer Relationship Management)/OMOF (Order Management and Order Fulfilment) system contacts with the billing system and billing system contacts with provisioning system to provision the services and network inventory system as well to assign phone numbers or IP addresses, etc.
Second possibility could be that CRM/OMOF system itself contacts with provisioning system to provision the services and network inventory system as well to assign phone numbers or IP addresses, etc.

Provisioning System

This system takes commands either from the Billing System or CRM/OMOF System to activate, deactivate and suspend the services. Both the architectures are valid and depend on how architect designs the whole setup.

After taking provisioning commands, this system contacts with core network system to activate, deactivate or suspend the services. After a successful provisioning, this system sends a response back to either the Billing System or the CRM system depending on who sent it the last command.

Network Inventory System (NIS)

This system maintains all the network identifiers like phone numbers, MSISDN, IP addresses, e-mail addresses, etc., and technically it is called Network Inventory System.

Depending on the system architecture, either CRM/OMOF or Billing System contacts NIS to obtain a required network identifier and assigns it to the customer at the time of order creation.

This system is responsible to maintain the life cycle of network identifiers, which starts with available and then flows through different stages like activation, suspend, terminate, quarantine, and again available.

Network Switches

Generally, Billing System does not interact with network switches. Network switches are responsible to provide all the services to the end customers based on what services have been provisioned for the customer. These systems are responsible for controlling calls, data download, SMS transfer, etc., and finally generating Call Detail Records.

네트워크 스위치에는 MSC, SMSC, GGSN 및 MMSC가 포함됩니다. GSM, MSC, SMS, SMSC, GGSN, MMS, MMSC에 대한 자세한 내용은 GSM 자습서 를 참조하십시오 .

중재 시스템

중재 시스템은 모든 CDR을 처리하고 다운 스트림 시스템 (일반적으로 청구 시스템)과 호환되는 형식으로 변환합니다. 중재 시스템은 CDR에 다양한 규칙을 적용하여 처리합니다. 예를 들어, 중개 시스템은 전화를 건 번호 (B- 번호)를 기준으로 국제 전화를 표시하고, 중개 시스템은 A- 번호 및 B- 번호를 기준으로 온-넷 통화를 표시하는 것과 동일합니다.

통화 시간이 5 초 미만인 모든 통화를 필터링해야 할 수 있습니다. 이러한 유형의 통화를 필터링하는 가장 좋은 위치는 중재 시스템 수준입니다. 같은 방식으로, 청구에 중요한 CDR에 추가 정보가 필요한 경우 중재 시스템은 CDR 내에서 사용 가능한 다른 속성을 기반으로 이러한 정보를 제공하는 데 도움이됩니다.

DWH (Data Ware House) 시스템

이것은 Billing System의 다운 스트림 시스템이며 일반적으로 고객과 관련된 수많은 기록 데이터를 보관합니다. Billing System은 다양한 고객 정보를 DWH 시스템에 덤프합니다. 이 정보에는 서비스 사용, 청구서, 결제, 할인 및 조정 등이 포함됩니다.

이 모든 정보는 다양한 유형의 관리 보고서를 생성하고 비즈니스 인텔리전스 및 예측을 위해 사용됩니다.

DWH 시스템은 항상 대량 및 방대한 데이터에 대해 작업하기위한 것이며 작은 보고서가 필요한 경우 작은 작업에 DWH를 남용하는 대신 청구 시스템에서 직접 생성하는 것이 항상 가치가 있습니다.