Call Detail Record (CDR) Reconciliation is an important process in telecommunication billing between carriers. Too often many carriers overlook the importance of reconciliation due to the complexity of the processes and the amount of resources required to reconcile invoices received with the information at hand.
Note: Obviously also encrypted data shareing might be important for some to share CDRs without having to agree on a password.
The function StoreCDR has only two parameters Data and Password. Data contains your CDR Records in CSV Format (optimally with a header) and Password is used to encrypt the data. The return value is a base58 encoded hash of the unique ID of the data.
As reconciliation compares to set of CDR’s to filter out the matches / mismatches your billing partner has to upload his CDR’s as well.
With the function ReadCDR you can read your CDR’s at any time (given that you know the encryption password)
The Reconcile function compares two sets of CDR files and filters out the matches or mismatched depending on the value of parameter ReturnType.
The parameters for the function are:
SourceCDR: Base58 encoded hash returned by function StoreCDR.
SourceCDRPassword: Encryption password used to upload the data via StoreCDR.
TargetCDR: Base58 encoded hash returned by function StoreCDR. (This second CDR File must have the same format as the first file)
TargetCDRPassword: Encryption password used to upload the data via StoreCDR.
Filter: The function Reconsile tries to be as format agnostic as possible. For that reason the two files to be compared must be of the same format (some formats can be converted during the upload process). Furthermore you need to specify via Filter which fields to compare and of which format those fields are. A typical filter is: 0=1,1=1,2=1,3=1,4=1,5=3,8=4,9=5,10=1
The first number specifies the column of the data file used followed by the type of that column. Types are:
1: StringData, 2: PhoneNumber, 3: TimeDate, 4=TimeSpan, 5=Number
TimeToleranceSEC: As it can never be assumed that clocks on both ends are exactly synchronized. For that reason a Time Tolerance in seconds can be defined. Default value is: 30
TimeSpanToleranceSEC: For the same reason call durations of the same calls can vary slightly in both CDR’s. The default value for the duration tolerance is 5.
OffSetMinutes: Ideally all data files use the Coordinated Universal Time (UTC). If that is not given you can specify the time offset in minutes between the two files with OffSetMinutes. Default value is 0.
ReturnType: As mentioned at the beginning of the page you can define yourself which type of data you want to be returned. Possible values are:
0: Matches of the first CDR file are returned.
1: Matches of the second CDR file are returned.
2: Unmatched records of the first CDR file are returned.
3: Unmatched records of the second CDR file are returned.
4: This option returns matches and mismatches of the first CDR file encapsulated in a JSON structure. It contains also additional values such as the success rate. Matches and Mismatches are automatically written back encrypted as new CDR Files to the blockchain and its base58 hashes included in the JSON.
Note: The unmatched CDR file can be kept for future reconciliation, passed to the dispute process or just used for a second reconciliation with a higher tolerance level.
Parameter 4 (JSON) is also valuable if you need to to include the CDR’s FileID’s in your billing for automatic settlement.
To demonstrate that the records are automatic available across different chains:
If you reconsile the above CDR’s you can see that you get different results depending on the tolerance settings.
You would like to test this function? Contact us via the contact form and we can assist you.