Telecom Billing - Generowanie faktur

Większość systemów bilingowych generuje ustrukturyzowany tekst ASCII zawierający treść informacyjną rachunku. Dane rachunku dla każdego rachunku są początkowo zapisywane w bazie danych lub w zwykłych plikach tekstowych. Format danych na tym etapie jest taki sam, niezależnie od tego, w jaki sposób dane mają być przetwarzane.

Te dane rachunku mogą być następnie przetwarzane przez jeden z wielu mechanizmów formatowania w celu uzyskania danych wyjściowych w żądanej formie. Na przykład papier, CD-ROM itp.

Dostępne są systemy rozliczeniowe, które zapewniają wewnętrzne narzędzia do formatowania rachunków. Jeśli system rozliczeniowy nie zapewnia odpowiedniego narzędzia do generowania sformatowanych rachunków, dostępne są narzędzia innych firm, takie jak DOC1, które jest jednym z najczęściej używanych narzędzi.

Oto typowy diagram przedstawiający przebieg formatowania rachunków -

Poniżej znajduje się migawka danych rachunku pobranych z systemu rozliczeniowego Infinys firmy Convergy -

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

Dane rachunku składają się z następujących po sobie wierszy tekstu ASCII. Każda linia ma postać -

TAGNAME tagvalue

TAGNAME i wartość tagu są oddzielone separatorem znacznika (tagsep) spacji. Wartość znacznika może być pojedynczą wartością lub listą wartości oddzielonych ogranicznikami (separatorami). Jeśli nie określono, używanym separatorem jest przecinek.

Bill Post Processor

Mechanizm rozliczeniowy może nie być w stanie wygenerować wszystkich informacji wymaganych na rachunku lub może istnieć potrzeba wykonania specjalnych obliczeń na danych podanych na fakturze. Nazywa się to przetwarzaniem rachunków i zwykle jest wykonywane przez niestandardowy składnik o nazwie Bill Post Processor (BPP).

BPP można napisać w preferowanym języku programowania, który czyta nieprzetworzony plik faktury i dokonuje wymaganych modyfikacji w tym pliku przed przekazaniem go do ostatecznego formatowania.

Nie ma dostępnych systemów rozliczeniowych, które zapewniają gotową funkcjonalność BPP, ponieważ wymagania różnią się w zależności od operatora, a tego procesu nie można znormalizować. Co najwyżej system rozliczeniowy może zapewnić punkt wtyczki do podłączenia niestandardowego BPP wraz z silnikiem rozliczeniowym.

DOC1 Bill Formatter

DOC1 to bardzo znane narzędzie Bill Formatter dostępne od PitneyBowes Company, które pomaga w formatowaniu rachunków do plików PDF lub Post Script.

Jak wspomniano powyżej, dane wyjściowe Billing Engine to tekst w formacie ASCII zawierający informacje o treści rachunku. Mapowanie jest tworzone między znacznikami pliku faktury źródłowej generowanymi przez system rozliczeniowy a znacznikami wymaganymi przez DOC1. DOC1 wymaga znaczników o stałej długości, jak pokazano poniżej.

Poniżej znajduje się hipotetyczna próbka z dostarczonego pliku faktury -

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
..........

Teraz korzystając z powyższych tłumaczeń, zostanie wygenerowany plik końcowy dla DOC1, a DOC1 zajmie się wygenerowaniem faktury końcowej na podstawie dostarczonych informacji.

Niektóre modyfikacje można również przeprowadzić na poziomie DOC1, ale nie zapewnia to dużej elastyczności w zakresie modyfikacji faktury. Możesz wypróbować najnowszą wersję, która może znacznie bardziej spełnić Twoje oczekiwania.

Generowanie końcowej faktury

Po zafakturowaniu wszystkich kont i sformatowaniu faktur przy użyciu wewnętrznego lub zewnętrznego programu do formatowania rachunków, faktury te są wysyłane do firmy Bill Print Company w celu ostatecznego wydrukowania.

Jeśli operator korzysta z funkcji elektronicznej poczty e-mail do wysyłania rachunku do swojego klienta, wówczas kopię tego samego rachunku można wysłać do systemu e-mail, aby wysłać ją do klienta końcowego.

Operatorzy poziomu 1 (mający 20-30 milionów lub więcej klientów) zazwyczaj zlecają to zadanie, w tym dystrybucję rachunków.

Co jest następne?

Po wygenerowaniu faktur trafiają one do klientów końcowych. Teraz czas na zebranie przychodu od klienta. Po jednym rozdziale omówilibyśmy proces poboru dochodów.

Zanim przejdziemy dalej, zajmijmy się częścią kontroli kredytowej, która jest bardzo ważna i powinna być pokryta przed pobraniem dochodów.