Docs for all releases
JeraSoft Billing proudly presents the new software version 3.20.0. The complete revision list can be found below.
Major Updates
Dynamic Routing
Dynamic Routing Policies
In order to give more flexibility the Routing Policies module has been completely reworked in the newest version. It is now possible not only to use predefined Routing Policies, but to create your own with set of factors that fits your business needs. Available factors are:
- Rate - vendor's rate for destination, vendors with lower rate will get higher position in routing;
- Quality (ASR, ACD, PDD, SCD) - vendor's quality, analyzed by Summary Report data for the duration given in the System Confirmation;
- Vendor Debt - consider the amount a vendor owes you, vendors that owe you the most are moved to a higher position in routing;
- Payment Due - consider next payment date to a vendor (as date of next invoice + due days), vendors with longer periods till due date get higher positions.
As you can see newly added factors are PDD, SCD, Vendor Debt and Payment Due. Latest two allow you to consider Cash Flow within routing procedure.
Screenshot: New Routing Policy add form
Generally, the Routing Policies section looks more insightful and simple now:
Screenshot: Routing Policies
As seen from the screenshot, the "Simple Quality", "Simple LCR" and "Proportional" policies are the same as before and include same factors. To simplify things and speed up the Routing Map generation, the "Complex Quality" and "Complex LCR" have been converted to simple ones respectively. We have also added "Cash Flow" policy to illustrate new factors available for routing. The overall speedup of the Routing Map generation (performed by Dynamic Routing Manager service) is 1.5-5 times depending on the specifics of your rates and settings.
Quality Factors
The quality based factors (ASR, ACD, PDD and SCD) are taken as before from the Summary Report for the last X minutes, defined by "Analyze Period" in the System Settings. It is possible to set "Minimal Statistics Quantity" as number of records to be present in the statistics to consider these factors as reliable. If vendor didn't have enough data for the given period, default values will be taken instead.
Screenshot: Dynamic Routing settings
Inline Quality Filters
For added convenience, you can now specify QoS filters (ASR and ACD) for each routing rule in the Routing Plan. This allows you to remove vendors with lower quality from the routing in real time.
Screenshot: Routing Plan rules
The filters are applied to the quality factors in the same way as it is done for Routing Map generation including "Analyze Period", "Minimal Statistics Quantity" and defaults values given in System Settings. The filters can be applied to both Dynamic and Static rules.
If you would like to notify administrator and/or vendor about drop in quality you have to use Factors Watcher in the same way as before.
DID Routing
We've improved how the DID routing is configured through the system to simplify things for a user. With this version, the "All destinations" option in the DID type routing was deprecated. Now it simply sticks to the "Full DID" match, which was default option before. In the UI, you will just need to indicate that a certain rule is of DID type:
Screenshot: Routing plan. DID routing
Additionally, if an account has multiple DIDs assigned with the same prefix, there's no need now to add full DID to the termination rate table. A rate for prefix can be added instead. It will save time and be more convenient during the import process.
Useful Tip
Let's assume we have one DID 38067101 assigned to the entity that has a rate for 38067. If the call will be placed for 38067102, the client will be among terminators, as it has a rate for 38067 (a.k.a. can terminate this kind of call). The workaround would be as follows:
- create a code deck with all existing DIDs;
- using Traffic Processing rules, assign the tag did to the calls that are going to DIDs;
- when adding the above-mentioned rate, add tag did.
It will ensure the vendor with assigned DID will terminate a call only if it goes to a real DID, not to some other 38067 destinations.
Routing Analysis
The Routing Analysis section has been visually reworked to make it more efficient for the client to analyze the query results. The new Output filtration options include:
Field Name | Description |
---|---|
Verbosity | Lets you control the routes' output based on them being accepted or rejected by the system:
|
Skip Reasons | Lets you control, which rejected routes to exclude from the output list. Available options are Reseller Mismatch, Blocked Reseller, Blocked Client, Blocked Account, Vendor Qty, Stop Hunting, Party ID Length, Profit Margin, Rate Increments, Orig Tags, Term Tags, Traffic Processing, Reseller Capacity, Client Capacity, Account Capacity, Rule Capacity, Quality. |
Screenshot: Routing Analysis settings
Now it is possible to define the routes to be skipped in results to avoid massive details on non-relevant routes (i.e. Reseller Mismatch). Additionally, if there are multiple reasons for rejecting a certain rule, all of them will be displayed, not only single or few as before.
As to the query result, it's more representative to enable the configuration check for the entities like Client, Account, or Rate.
Screenshot: Routing Analysis query
Billing Increment Check
To improve profitability check we've added Billing Increments matching between Customers' and Vendors' rates in the routing. To use the feature set Match Increments field under the Rules Processing section of the Routing Plan. If selected, it will exclude vendors with increments that do not match customers' rates from the routing list.
Screenshot: Routing Plan settings
The field has three options:
- disabled - the system does not check increments, selected by default;
- dynamic only - the check is performed only for dynamic rules;
- dynamic and static - the check is performed for dynamic and static rules.
The option checks that Customers' increments proportionally overlap Vendors' increments. Following table shows sample scenarios:
Customer Rate | Vendor Rate | Result | Notes | ||
---|---|---|---|---|---|
Min Time | Pay Internal | Min Time | Pay Interval | ||
60 | 60 | 60 | 60 | OK | Exact match |
30 | 6 | 30 | 1 | OK | Full overlap |
30 | 6 | 6 | 6 | OK | Full overlap |
1 | 1 | 30 | 6 | FAIL | Vendor Increments are higher |
7 | 7 | 6 | 6 | FAIL | Even though Customers increments are higher, with call duration of 7 seconds this case will lead to 7 seconds billed on customer and 12 seconds billed on vendor |
Multipartitioning routing
Add possibility to route between root resellers.
Functionality should support the following configuration.
Root Company A has
- originator client Customer (assigned routing plan, rate table)
- terminator client 'Company B' with term account CompanyA-CompanyB-Customer.
Root Company B has
- originator client 'Company A' with orig account CompanyA-CompanyB-Customer. RP assigned per account.
- terminator client Vendor
During the routing, we will first get routing from Customer under Company A which shows the route from Customer to Company B (term account under Company A).
If we found that termination actually belongs to the reseller in our system we should run re-routing from origination account under Company B (the one that corresponds to Customer account of Company A). Once we get the result - insert it in place of routing record corresponded to Company B in the original routing result.
During the file collecting, we should add an extra pair of legs to have internal accounts billed as well.
Rates
New rates import options
has been improved
Screenshot: Step 2: Import Settings
Remove duplicates mode
The system will detect if there is full duplicate by itself and if it's - skip it. If there is any change between the rate in the rate file and existing rate system will resave rate from the import file.
Proper import undo
All current rates which were marked as stashed due to the import process will have extra reference to import which caused them to be stashed.
Once the user runs undo procedure we will get all affected rates as well.
In addition, we should save the last modified date of the rate table for each import history record so once we will run undo we will set this date back. (?)
Add an extra 'On Warning' option
This option will tell import what should we do with records that caused a warning. Either save them, skip them, or abort the whole import cause of them.
Billing increment analysis
Add billing increment analysis during the import. If enabled raise error in case billing increments that are in file differs with billing increments in the system.
Add ex handler for the import analysis process.
Put all information we have about import (a type of errors/warnings, number of warnings, etc) to data for the external handler.
As extra we should save the email that sent a notification.
Clients
Vendor Credit Limit
We should add vendor credit limit field to client interface.
Vendor credit limit will be applied to vendors during the routing check.
If vendor balance + credit limit hit the threshold - remove respective routes from routing result.
Screenshot: Vendor Credit Limit in Client's settings
General Points:
Add vendor credit limit in the client interface (terminator section) and clients DB table (just a numeric number).
Add is_within_vendor_limit to get_dr_routes (don't forget about testing dr plan - dr_plans_id = -1)
if True - use vendor. If False - don't use.
Add a respective block to dynamic.py/getDrRoutes procedure (check is_profitable block as reference).
Add processing for this cause for routing analysis interface.
it is needed for routing ONLY.
Jurisdictional Module
NANP: add interMTA/intraMTA
Add support for interMTA/intraMTA based on lerg8 data.
Separate interstate/intrastate and interLATA/intraLATA tags.
Move NANP parsing to traffic rules functional.
Screenshot: NANP Processing in a Traffic Processing rule
Minor Updates
Provisioning API
Add ex handler to fire event between prepare and import process of the rates import.
In case the handler is defined - stop import after prepare process.
Screenshot: Email Rates Manager handler in Provisioning API
Number Portability
LNP: Lithuanian DB
Add support for Lithuanian LNP DB.
During the translation we should add tag that corresponds to operator in the database.
Example of the database and documentation is in the attached files.
Balance Report
Improvements in UI
- Payment Accounts filter accepts multiple values
- Start Balance renamed to Opening Balance
- End Balance renamed to Closing Balance
- Mode renamed to Report Basis
- accounting -> Accrual
- live balance -> Cash
Screenshot: Balance Report settings
CoreAPI
Clients authentication
Direct access to Clients Client Portal Credentials has been deprecated and a dedicated method created for these need with small example of the code.
Routing
Source Code routing
???????????
Currently routing map has only dst_code and while we creating it we are taking only rates with src_code = ''
.
As result we may use incorrect rate during profit margin check. So we have to add src_code
to the routing map, so that we will be able to check correct vendor rate and profitability.
Stop Hunt checkbox
Important change in existing logic. Before 3.20 checkbox "Stop Hunt" in routing rules was respected only if route under this rule was accepted and was skipped if route was rejected due to some reason. Now it will be always respected.
Traffic Processing
Improvements in UI
All changes are related just to UI of "Traffic Rules" section
- In Search form - "Tag" field now also includes search by "Add Tags" field, which allows to easily see all rules that set tag and then filter by this tag
- In Search form field "Add Tag" has been removed as not needed anymore
- In List - each tag is now clickable and returns all rules related to clicked tag
Rates
Pagination improvements
Unfortunately it is quite costly to estimated real number of pages, on top of this it is quite costly to get results of later pages as database has to basically iterate all the previous rows to get last ones. Why somebody needs to really access last page? Because of sorting? Just inver the sorting.
However to avoid confusions let's remove the last button from pagination at all if we do not know exact amount of pages. Check sections like Rates without full count and sections like Payment Terms which have full estimation of count.
Factors Watcher
Destination blockations
Client notification about destination block is not sent when Factors watcher has group by account