Skip to main content

Release 3.20

JeraSoft Billing proudly presents the new software version 3.20. The complete revision list can be found below.

Major updates​

Swap Deals​

One of the most significant developments in this current release is adding a new module for Swap Deals management. From now on, you'll save time and effort in configuring and monitoring the progress of the bilateral deals with your partners. The section is presented as a list:

Swap Deals section

info

As this version of the module is pilot, we are open to suggestions and comments as to how we can improve it both visually and functionally. Please send your insights to [email protected]. We are always happy to hear from our clients!

The section supports Swap Deals management for multiple services and destinations. You will be able to see forecasts per deal, revenue calculations, as well as informative alerts to ensure you'll fulfil your commitments on time.

Swap Deals section. Items List tab

You can get to know more about the Swap Deals configuration within the system in the respective User Guide article.

Dynamic Routing​

Dynamic Routing Policies​

To provide 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 a set of factors that fits your business needs. Available factors are:

  • Rate - vendor's rate for the destination, vendors with a 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 - considers the amount a vendor owes you, vendors, that owe you the most, are moved to a higher position in routing;
  • Payment Due - considers the next payment date to a vendor (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. The latest two allow you to consider Cash Flow within the routing procedure.

New Routing Policy add form

Generally, the Routing Policies section looks more insightful and simple now:

Routing Policies

As seen from the screenshot, the Simple Quality, Simple LCR, and Proportional policies are the same as before and include the 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 a 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 a number of records to be present in the statistics to consider these factors as reliable. If the vendor didn't have enough data for the given period, default values would be taken instead.

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. It allows you to remove vendors with lower quality from the routing in real-time.

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 the administrator and/or vendor about the drop in the quality, you have to use the Factors Watcher in the same way as before.

DID routing​

The routing to DIDs have been simplified in two ways:

  • All destinations option has been removed in favor of default Full DID match, now you can simply add a rule with Type "DID" and highest priority (typically = 0), to give the Routing Plan ability to route to DIDs Routing plan. DID routing
  • In the scenario when the customer has multiple DIDs with the same prefix, it is now possible to set a single rate for that prefix in the termination Rate Table instead of listing all of the DIDs (please check notes below for details)
Notes on DID Rates

Let's assume your customer has 2 DIDs (801001 and 801002). Now instead of adding rates for both DIDs, you can set a single rate for code 801. However, if the call will be placed for a number with an 801 prefix, that is not assigned to any customer, this specific customer will be selected as a vendor for this code not under DID rule, but regular Dynamic rules if they are present. To avoid this scenario, we suggest the following:

  • Create a Code Deck with all existing DIDs in your system and set the same name "DID" for all of them;
  • Use Traffic Processing with this Code Deck configured to match by Code Name "DID" and place tag "did";
  • When adding the abovementioned rate to the customer set tag "did" on it, to match only in case the number is actual DID.

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

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. The following table shows sample scenarios:

Customer Rate Min TimeCustomer Rate Pay IntervalVendor Rate Min TimeVendor Rate Pay IntervalResultNotes
60606060OKExact match
306301OKFull overlap
30666OKFull overlap
11306FAILVendor Increments are higher
7766FAILEven though the customers' increments are higher, with call duration of 7 seconds, this case will lead to 7 seconds billed on a customer and 12 seconds billed on a vendor

Stop Hunting rework​

The option Stop Hunt on the rules of the Routing Plans has been reworked according to the industry requirements. Before the current version, it was considered by the system only if the route under the rule was accepted. Now it will work in all cases, even if the route has been rejected due to some checks.

Stop Hunt checkbox

Stop Hunting rejection reason

However, to avoid stop hunting on rules, which are filtered based on an originator, not on the "quality" of the route itself, the logic is as follows. If Stop Hunt is enabled, but the rule was rejected due to Orig Tags mismatch or Reseller Mismatch - the Stop Hunt will be ignored.

Source Code routing​

The new version includes improvement in the Routing Map building for the rates with defined Src Code. Previous versions considered only rates without Src Code when building Routing Map. It leads to improved Profit Margin checks. While running Routing Analysis, do not forget to set Src Party ID in the filter section for correct analysis.

Routing Analysis query. Src Code Routing

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 options include:

  • Verbosity - lets you control the routes' output based on them being accepted or rejected by the system:
    • "Accepted and Rejected" - outputs all the possible routes;
    • "Accepted Only" - outputs only the rules that will be accepted during the actual routing.
  • Skip Reasons - lets you control routes under which checks should be removed from the result:
    • As an example, you may want to remove routes that failed due to "Reseller Mismatch" to remove overwhelming output if you have many resellers in the system;
    • Another example would be to remove routes failed under "Vendor Qty" check if you have vendors with dozens of accounts.

Routing Analysis settings

Other improvements are related to the columns shown in the Routing Analysis:

  • Status - for rejected routes with column shows all reasons for route rejection (in a tooltip), not only a single one as before
  • Routing Rule - rule details including Routing Code, Priority, Balancing, ASR/ACD filters if used and others
  • Vendor - both vendor and its Account name, both entities are now clickable leading to the details of either vendor or its Account
  • Account - Account Identification, including technical details such as Gateway, Protocol, Capacity, etc.
  • Code - Code and Code Name according to the vendor's Rate Table
  • Rate - vendor's Rate (marked in red for unprofitable routes) - this column (as well as customer's rate in the header) includes massive details:
    • The rate itself is clickable leading to the specific rate details
    • If the future rate is available, it will be shown right below the current rate
    • If the current rate has an end date specified, it will also be shown right below the rate
    • The tooltip includes details on Profit Value and Margin, future and current rate details, if present
  • Dst Party ID - destination number as it will be sent to the vendor, including details on all Traffic Processing performed and Tech Prefix added
  • Appeal - the value calculated based on the Routing Policy defined (for dynamic rules), used for comparison on the result values and testing of different Routing Policies
  • Reject Reasons - list of all reasons by which the route has been rejected (useful for export)

The last improvement is related to the grouping of the results:

  • Output Type "Grouped" - will split results into two sections - Accepted and Rejected, while the Rank column will show the actual rank of the routes independent from the group they fell into
  • Output Type "Plain" - will show results according to their Rank and mark their status accordingly

Routing Analysis query

Vendor Credit Limit​

To make routing management more versatile, the Client Info settings block has a new field added - Credit limit - for Terminator Settings. This setting lets you control the credit limit you have on the vendor's side.

Vendor Credit Limit in Client's settings

This credit limit will be applied to vendors during the routing check to remove them from the routing result if vendor balance + credit limit hits the entered threshold.

Routing Plans (≥3.20.1)​

To simplify the work logic of the Origination Limit in the Routing Plan parameters, it now functions as follows. If the mentioned limit is not set, it will work as before - allowed for the owner and all its sub-companies and/or sub-managers. If it is specified - it will include owner and selected companies and/or managers, but not their children. To actually include child companies, you'll need to select them.

Rates​

Rates Import​

To make the import process even more simple yet functional, we've added a few new options to the Step 2: Import Settings:

NameDescription
Billing Increments CheckIf enabled, the system will raise an error in case imported rates' billing increments differ from those already present in the Rate Table.
If UnchangedIf the system detects rates in the imported file with all the same settings as the ones already present in the Rate Table but Effective Date, you'll have the option to either preserve or skip them ("Save rows", "Skip rows").
On WarningsThis option manages alerts from the Analysis Settings section. If any, you'll have the option to either preserve them, skip or abort the whole import process ("Save rows", "Skip rows", "Abort import").

Step 2: Import Settings

Additionally, the On Duplicates mode has been deprecated as the system can automatically detect duplicates during import. If any are found, they would be skipped.

As for the general import flow, if there is any change between the rate in the rate file and the existing rate, the system will resave the rate from the import file.

Import reverting​

The import reverting process has been reworked for the ability to restore more accurate pre-import data. That is, if any changes were made to the Rate Table during import, by reverting a particular import, all of them would be discarded to leave the current rates as they were before import.

For instance, if you chose to stash the current rates during the import process, once you'd run the undo procedure, all of them will be again active. Also, the last modified date of the Rate Table would be restored to the one before the faulty import.

Import History

Jurisdictional Billing module​

NANP Processing functionality​

We've broadened the area detection functionality for the Jurisdictional Billing module. From now on, for those clients who have access to the LERG database, the system will be able to pull not only data on "interstate/intrastate" and "interlata/intralata" areas but also "interMTA/intraMTA" and "local". For that, we use the LERG 6, LERG 8, and LCA databases.

This functionality is available in the Traffic Processing section of the billing system. If enabled, it will check the filtered numbers (specified in the Match section of the Traffic Processing rule) through the North American Numbering Plan. You can set it up in the respective field of the rule creation form:

NANP Processing in a Traffic Processing rule

Minor updates​

Provisioning API​

Email Rates Manager handler​

To enable defined tasks between preparing certain import process and actually importing rates to a Rate Table, we've added a new event - Email Rates Manager - to Provisioning API.

Email Rates Manager handler in Provisioning API

With this handler, you will be able to stop the system processes right after the prep phase to execute any other needed tasks.

Import handler​

To allow notifications or any other third-party events on the import process results, we've added a new handler to the Provisioning API - the Import handler:

Import handler in Provisioning API

From now on, whether a particular import process failed or succeeded, you'll be able to pull this data (import status, types of errors/warnings, if any, number of errors/warnings, etc.) from the billing system to execute some other tasks.

Number Portability​

LNP: Lithuanian DB​

We've added support for Lithuanian LNP DB.

Lithuanian LNP Gateway

CoreAPI​

Clients authentication​

Direct access to client's Customer Portal credentials has been deprecated and a dedicated method created for this need. See the code example below:

client = coreapi.clients.authenticate(
cp_login="cp_jerasoft",
cp_password="password"
)

Authorize.Net​

Gateway currencies support​

We've broadened the Authorize.Net currencies support by adding "CAD" as one of the available Gateway Currencies for integration. You can set this up in Reseller settings → Autocharge Settings tab.

Improvements in UI​

Balance Report​

The Balance Report section faced a couple of renamings:

  • Start Balance was renamed to Opening Balance
  • End Balance was renamed to Closing Balance
  • Mode was renamed to Report Basis
    • "accounting" -> "Accrual"
    • "live balance" -> "Cash"

Additionally, the Payment Accounts filter now accepts multiple values for added convenience.

Balance Report settings

Traffic Processing​

All changes are related to UI improvements of the Traffic Rules section:

  • In the Search form, the Tag field now also includes search by Add Tags field, which allows easily seeing all rules that set tag and then filter by this tag. Therefore, the field Add Tag has been deprecated as redundant; Traffic Processing section advanced search

  • In List - each tag is now clickable and returns all rules related to the clicked tag. Traffic Processing rules list

Pagination improvements​

In sections where no exact count of rows estimated in order to improve performance, we have removed the Last Page button to avoid confusion.

Deprecations​

Please be noted that the following sections are marked as deprecated:

  • Calling Cards
  • Top-up Cards
  • Call Shops

They will be fully removed in the next versions.