
An Eight in a Million chance (consultants, interns, MS Access) - willvarfar
http://williamedwardscoder.tumblr.com/post/17282439831/
======
jholman
CDR reconciliation is still this comedic mess, btw. Including the silly
business with calls that cross midnight being sometimes split and sometimes
not, and weird rounding behaviour, and so on. And on top of this, calls would
be reported to be reconciled with arbitrary delays; just because they weren't
going to report a January 1st call until January 20th doesn't mean they
weren't going to bill for it on January 14th!

Indeed, the systems for generating the dollar value on our invoice were almost
entirely separate from the systems for generating the line-items on our
invoices, and they never did agree, and our upstream provider didn't even see
that as a problem.

My boss at one point, if I understood him correctly, claimed that (in 2009 or
2010), the process for the telco to know how much to bill us involved human
operators exporting to a reel of magnetic tape, moving the magnetic tape reel
across the room, and importing it into a different database. He wasn't much of
a one for leg-pulling, but I dunno.

~~~
bradleyland
I don't run in to many telecom folks these days. Are you still working in the
industry?

I used to do a lot of telecom consulting for a large customer who we
transitioned to a 100% SIP carrier. This particular carrier used AdTran TA 900
series gateways to provide T1-CAS/PRI to older phone switches. The project was
particularly interesting because the carrier let me (a third-party analyst)
have unheard of access to their infrastructure. Once I earned their trust, I
had access to all of the AdTran devices, as well as their core switching and
CDR reporting tools.

I actually just put wraps on a Ruby script that I use to analyze call
concurrency from CDR exports (from CDRTool [1]). I dropped it in a Gist if
you're interested. It takes a CDRTool query export (CSV data) and outputs a
tab-delimited concurrency datafile that can be used pretty easily with
gnuplot. The script could be easily adapted to any CDR report that uses
single-line call entries.

<https://gist.github.com/1706903>

1 - <http://www.ag-projects.com/CDRTool.html>

PS - If you find this at all interesting, hit me up on Twitter to keep in
touch <https://twitter.com/#!/bradleyland>

~~~
willvarfar
Nope, after I graduated I moved country and industry and wasted a good decade
programming the mobile phones that help people create the CDRs that torment
you.

These days I'm swung back more towards DBs and servers and stuff, but not a
CDR in sight thankfully.

Liked your ruby; not a ruby ninja myself but it looks quite readable and
almost pythonic :)

------
noedig
When I worked at AT&T some years ago they had an entire team of about 50
developers and testers working on identifying problems in AT&T's myriad
billing and provisioning systems. This team developed applications that
analysts used to reconcile billing with account features, usage, taxes,
discounts, etc. This team was very successful in finding both under billings
and over billings. One project identified something like $100M in annual under
billings. Another project found so many switch/bill mismatches that they just
decided to cancel it because they didn't have the manpower to manually correct
all the problems or deal with all the customers calling to complain that their
bill went up or their feature disappeared.

------
mason55
Interesting to learn that Amdocs started off as a billing system. I have
worked with it in plenty of spots where it's used as a CRM but was unaware of
its billing system roots.

I'm not sure why he called it an Israeli company though, it was founded in the
US.

~~~
willvarfar
you made me google and yeap, its an American company.

The whole consultancy team they shipped over was definitely Israeli, but then
Amdocs has big development offices there it seems so that's just where this
particular team came from.

Now we know :)

------
sdfjkl
Excellent story & writing, particularly the "cable unwind" bit.

------
ralphael
great story! thanks for posting.

