Release 3.27

JeraSoft presents a major release of JeraSoft Billing 3.27 featuring several logical and functional improvements. Please find a complete revision list below.

Major updates

EU PEPPOL Invoices

To keep up with industry demands, we have enabled the possibility to generate Invoices according to the EU PEPPOL specification (in XML format). Originally developed as an EU standard, PEPPOL allows companies to send electronic invoices and other business documents directly to the supplier's system and software.

To allow for the seamless integration, the following adjustments have been introduced:

1. From now on, the Postal Address in Clients and Legal Entities should be specified in separate fields: Street Address, City, Country, Postal Code and US state (for the US). All these fields will be combined and displayed on the Invoice together.

2. New fields related to EU invoicing have been added:

   • Endpoint ID: Seller's / Buyer's electronic address, to which the Invoice is delivered;
   • Endpoint Scheme: electronic address format according to the following list.
   • Buyer Reference (≥3.27.2): the reference used for internal routing at recipient

info

For more info on how to setup PEPPOL XML Invoices, please refer to the respective User Guide materials.

Packages & Subscriptions

Incoming calls

In this release, we have improved the tracking of paid incoming calls within a Package for customers. The scope of this improvement includes the following modifications:

1. In Packages:

   • The Type field has been completely removed.
   • The Origin field has been added to the Limits section ("orig", "term", "both").

2. In Subscriptions:

   • The Origin field has been added to the Limits section.

3. In Client Panel:

   • The Origin is visible in the Limits section respective to the limits.

Differences from the previous implementation

The previous implementation (through Vendor-type Packages) has been misleading in some scenarios and implemented in the way that it hasn't been covering the most required scenario end to end. That's why we provided added fluidity in current realization through having an "origin" for the Package limits, rather than having separate types of Packages.

If you currently have Vendor-type Packages, they will be archived and marked respectively during the update.

Invoicing

Following this rework, we've synchronized the logic of statistics selection for the Invoices and xDRs attached to them.

1. Outgoing Invoices include items that the customer is charged for, i.e., those with negative cost before Package application.
2. Incoming Invoices include items that the vendor charges us, i.e., those with positive cost before Package application.

Differences from the previous implementation

Let's review a simple example: the customer has a call that was fully covered by the assigned Package:

• in the previous implementation, this call would have been included only to the attached xDR file, but not the Invoice;
• in the current implementation, this call will be included both to the Invoice (in the aggregated data that serves as the source for the "Stats" table) and the attached xDR file.

Fraud monitoring

Active Sessions report

Starting from JeraSoft Billing v3.27.0, we have enhanced the Active Sessions report to align with the unified system framework. This rework to a more standard form allows utilizing it in Reports Monitoring smoother, enabling proactive fraud detection and management. With this feature, you can:

• Monitor for suspicious activities in real-time using filters by quantity and duration.
• Automatically respond to potential fraud cases with actions such as notifications or traffic blocking.

Currently available report filters include:

• Statistics block:
  • Quantity
  • Duration
• Clients block:
  • Orig / Term company
  • Orig / Term owner user
  • Orig / Term client
  • Orig / Term account
• Rates block:
  • Orig / Term code
  • Orig / Term code name

Differences from the previous implementation

1. Possibility of the export (CSV or XLSX) has been removed. Given the real-time nature of active sessions, exporting for post-processing is not practical.
2. Information previously provided in the "Info", "Originator", and "Terminator" columns have been split and migrated into respective separate columns. Existing Report Queries will be migrated to maintain compatibility with the updated format.
3. The layout now mirrors other system reports like Summary and Orig-Term, ensuring consistency. The updated Group by options provide granular control, while output columns focus on aggregated data.

CoreAPI

API reference is now available in our documentation portal. We are making more API methods publicly accessible, ensuring greater flexibility for developers.

REST API

CoreAPI is now available over REST in addition to an existing JSON-RPC 2.0 protocol.

Authorization

The CoreAPI authorization has been aligned with industry-standard practices to simplify its usage:

1. Added support for X-Api-Key HTTP header. This should be populated with the API Key of the respective account used to make API requests.
2. Deprecated JWT-based authorization for machine-to-machine communication.

DIDs search

The possibility to search for DIDs by Account ID has been added.

Subscriptions

We've added the ability to override default package fees during assign of the subscription via CoreAPI or to update them later. Please check details for the "Override Package Fees" setting for clients.subscriptions.assign and clients.subscriptions.methods.

warning

If you are upgrading from the version prior to 3.19 and using JSON-RPC, make sure that your requests are sent to http://{HOSTNAME}:3080/ (nothing after the final /).

Minor updates

Custom Fields (≥3.27.1)

We have expanded the possibility to add Custom Fields not only for Clients and Packages but also DIDs. In this rework, the Custom Fields themselves have been improved. In addition to the existing ability to specify field keys and names, the following has been added:

Field	Description
Data Type	You can specify the type of data to enter for the Custom Fields. The available types are: string, integer, decimal, and datetime picker.
RegExp Match	You can specify POSIX regular expressions to validate the input data against (for the "string" type only).

Accounts

To control the security of the Client Accounts, we have added additional options into the System Settings:

1. "Require password for accounts" – makes password a mandatory field for the Client Accounts.
2. "Enforce strong passwords" – ensures passwords are at least 12 characters long and include a mix of uppercase and lowercase letters, digits, and special symbols.

Invoices

We've improved clarity in the Invoices by omitting zero-line items. Here is how the Transactions for Packages are now distributed:

• charges for Packages with positive fees go to Outgoing Invoices,
• charges for Packages with negative fees go to Incoming Invoices,
• charges for Packages with zero fees do not go to Invoices.

Invoice Templates

Packages

To make management of the Invoice Template variables related to Package period smoother, we have introduced the following changes:

• The previous {period_start_dt} and {period_stop_dt} Invoice Template variables (from the Packages table) were replaced by a new universal one – {period_dt}.
• The {period_dt} variable will be filled with:
  • <package activation date> – for Activation Fees,
  • <period start date> – <period end date> – for Subscription Fees.

Balances

To align our approach in displaying balances in the Invoices with industry expectations, we have introduced some adjustments:

1. Variables renaming/replacing:
   • balance_previous was renamed to balance_opening,
   • balance_current was renamed to balance_closing,
   • balance_final was replaced with balance_closing,
   • to_pay_gross was replaced with to_pay.
2. Logic of display is similar to Balance Report:
   • if a customer overpaid, the balance is shown as a negative value,
   • if a customer owes something, it is shown as a positive value.

tip

In the existing Invoice Templates, the variables were renamed and replaced accordingly.

The to_pay variable considers how much there is to be paid, taking into account possible overpayment. If there is an overpayment on the balance, the amount "to pay" will be displayed as zero.

Images upload

It is now possible to add your own images to the Invoice Templates:

Zero-value Package charges (≥3.27.4)

We provide an option to include zero-value Package charges to Invoices to accommodate for cases when the customers need to be informed regardless of the charge value. You can set this up in the Invoice Templates.

Routing Analysis

To make the debugging process through the Routing Analysis more convenient, we have reworked how the output information is displayed. Here's how the following cases are now handled:

1. No suitable origination rate found (≥3.27.1)

All possible information about origination part of the call will be displayed even if the call is not allowed to pass with current settings.

Example

If there will be no suitable origination rate for a requested call, the information still will be displayed about the TP rules processed prior to the rate identification stage ("initial" and "after client").

2. Blocked origination rate (≥3.27.2)

The tracking of blocked origination rates has been improved. Now you can distinguish between blocked and unidentified destinations.

Subscription Currency

As of v3.27.0, the currency of a Subscription should match the currency of an associated Client. This requirement ensures consistent results and prevents discrepancies in billing and reporting.

Reports

Report Queries

To support more cases that need temporary monitoring rules, we have expanded the ability to set an expiration period in Report Queries. The rules now can expire at the end of a given hour/day/month/year.

Code Name based Report Monitoring (≥3.27.2)

The following adjustments have been introduced:

1. If Code Names should be matched in a monitoring rule, the corresponding Code Deck must be specified in the report query. Previously, there was no such explicit restriction, which led to errors when creating the traffic rules;
2. When matching Code Names in Report Queries → Monitoring tab, the created Traffic Processing rules will have "Name Prefixes (any)" filters instead of just "Code Name" filters.

Reports in the "comparison" mode (≥3.27.1)

The overall filtering in the comparison reports has been improved. The aggregative filters (i.e., "Cost" and "Volume") are applied only to the main interval statistics that allows to correctly display the comparison interval data even if it doesn't fit the filtering.

If for the previous period the statistics is completely absent, it will be presented with empty values (zeroes for quantity-related and "N/A" for quality-related fields).

Such display allows for relative comparison between periods if the relative output columns are selected.

Orig-Term Report data visibility

We have adjusted how data is obfuscated in the Orig-Term Report when the origination and termination Clients belong to the same Company. This change supports scenarios where users need to see profits for their managed clients (e.g., origination clients, while termination clients may be managed by other users).

Differences from the previous implementation

Previously, if a User had permission to view only one of the Clients (orig or term), the report hid restricted fields, replacing them with "***" or "N/A".

Now, when both Clients (orig and term) are under the same Company, the report will display the following fields even if one Client is restricted for the User:

• Orig and term costs
• Orig and term volume
• Profit, profit rel, margin, orig rate avg, and term rate avg

All other fields will still be hidden according to the User’s permissions.

Invoicing Report (≥3.27.4)

It is possible now to see the list of Transactions related to a specific Invoice item from Invoicing Report by clicking the corresponding icon.

This functionality is currently available for Packages and Custom Charges only.

Rates

Import

The number of rows allowed to be skipped during import process has been increased to 150.

Rate Tags

To optimize system usage for the cases with lots of Tags on Rates, we've returned the Tag field to the Rates settings. Now, there is an ability to assign Tags on both Rates and Rate Tables.

tip

In terms of Tags on Rates, everything is back to how it was before 3.25: tags on rates will work the same as they did before - that is, they will be used during routing, you can search for them in rates' list, use them in Rates generator, etc.

In addition to this, there are also Tags on Rate Tables. They are also used during routing and are selected depending on the tags on the call.

Thus, the routing flow will be as follows:

• First, the system selects a Rate Table that matches the tags from the ones assigned on a client or account. If none of them match, the default one with a '@' is selected.
• Then, out of this Rate Table, the Rates are selected that match the tags. If the Tags do not match, the ones with a default '@' are selected.

Advanced Search

To make selection easier for cases with huge amounts of Rate Tables in the system, we have changed the type of Rate Table name selection from drop down list to search by typing.

Rerating (≥3.27.1)

To visualize rerating scheduling for users, we've added an extra counter in the top right corner. It represents the number of enqueued rerating requests.

Tax providers

Suretax

To simplify Invoice generation process for Suretax, we are removing the unused Services mode (processing taxes for each xDR separately) leaving just the Safe Harbor mode.

Mail Manager

We have improved processing for the "Recipient address rejected" errors received from mail servers. In case of multiple emails for recipients, if only one of them is faulty or cannot be reached, the mail itself will not cause an error.

Cluster

To maintain full redundancy, the capacity processing has been adjusted for the cases when the Master node is down. If this happens, the Slave node will process all calls skipping the capacity check.

Provisioning API Logs

To make sure regular tracebacks are fully visible in Provisioning API error log messages, we've increased the message limit to 4096 bytes.

Other updates

UI changes

Blocked Rates

The style of all system mentions of blocked Rates has been unified to be red highlight.

Integration

FreeSWITCH (≥3.27.1)

If there are incorrect rows present in CDR files, they will be skipped in processing. Previously such cases led to dropping whole files into corrupted. For now, this works for FreeSWITCH files integration.

Software updates

The database management system has been upgraded to PostgreSQL 17. As part of your update to the newest JeraSoft Billing version, our engineers will fully take care of this migration.

Within v3.27.0, we have finalized the migration to Debian 12 (Bookworm), which was introduced as a supported platform in v3.26. As part of this transition, CentOS 7 is no longer supported.

info

Please contact our support department to update your JeraSoft Billing. We will help you migrate as smooth as possible.

CoreAPI Docs

The Integrations → CoreAPI Docs module has been removed from the UI. The documentation has been moved to docs.jerasoft.net.

Deprecations

Rate Tables

CoreAPI

List of deprecated methods and fields:

1. In clients.create, clients.update, accounts.create and accounts.update:

   • orig_rate_tables_id
   • term_rate_tables_id

2. In rates.search:

   • tag
   • services_id
   • policy

3. In rates.exports.query (search argument):

   • tag
   • services_id
   • policy

Additive Policy

The "additive" Policy will be completely removed as redundant in future versions.

Number length

The "Number Length" parameter in Rates settings will be completely removed in future versions. Please utilize the Traffic Processing rules for the purpose of billing control for various lengths of dialed numbers.

Import

The deprecated rates.imports.save_import_template method has been completely removed and is no longer supported.

Traffic Processing

To prevent issues with customers' traffic schemes, the "Set Service" option was completely removed from Traffic Processing Rules.

CoreAPI

JWT-authorization

The JWT-based authorization for machine-to-machine communication has been deprecated in CoreAPI in the favour of more industry-common X-Api-Key HTTP header.

Dry run

The dry run mode has been removed – the __check meta argument is not supported anymore.