What’s new in MR109

With this release, you can store additional parameters for a SIM card in PortaBilling. For example, you can store PUK codes within the SIM card inventory, so if a user loses their code, the admin can quickly find it in PortaBilling. And by including information about the marketplace or the sales partner, you can keep track of SIM cards distributed via different sales channels.

So now, all the needed information about SIM cards is available in one place:

• Essential SIM card details
• Custom SIM card details
• SIM card allocation to sales partners and customers

You can change these details for multiple SIM cards at once using the group operations functionality in the SIM card inventory.

The SIM card inventory has been extended with the new default fields where you can now specify PIN for inactive cards, PUK1, PUK2, or the eSIM activation code for each physical (SIM) or virtual (eSIM) card. Previously, there were dedicated fields only for the basic identifiers like IMSI (International Mobile Subscriber Identity) and ICCID (Integrated Circuit Card Identifier).

PIN, PUK1, PUK2, and the eSIM activation code can be specified when you add SIM cards or upload them from a file to the SIM card inventory. You can also add/edit these details anytime.

If the default fields are not enough, you can also create custom fields to keep additional information about SIM cards, such as the marketplace where the SIM cards are being offered or the name of the SIM card provider. You will then be able to filter SIM cards by these custom fields, e.g., filter active SIM cards by the “Marketplace” parameter, e.g., to check how many active SIM cards are sold via Amazon.

The custom field data can then be retrieved for statistics/reporting.

You now have the ability to allocate SIM cards to your sales partners, such as distributors and representatives. This allows you to keep track of SIM cards that are being sold via distributors and representatives.

Also, SIM cards are now automatically allocated to the corresponding customer once it is assigned to an account of this customer. You can allocate SIM cards to a customer manually, e.g., if a business customer orders SIM cards for activating them in the future for the new employees.

You can filter SIM cards in the SIM card inventory by their allocation – by a specific distributor, representative, or customer.

An MVNO called Mega Telecom receives 1000 SIM cards and a file with the full SIM card data, including PIN, PUK1, and PUK2 codes from their MNO. Adam Smith is a distributor of Mega Telecom and will receive a batch of 100 SIM cards to sell. Also, Mega Telecom plans to sell 100 SIM cards via Amazon.

Mega Telecom’s admin uploads the file with the SIM card data to the SIM card inventory. Now, these SIM cards are ready to be assigned to new accounts.

To allocate 100 SIM cards to Adam Smith, the admin checks the physical SIM cards that will be shipped to Adam Smith (e.g., these are SIM cards with ICCID from 1949177921756150001 to 1949177921756150100). The admin filters these SIM cards by ICCID in the SIM inventory, and allocates them to Adam Smith using the Group operations panel.

Since there is no default field “Marketplace” in the SIM card inventory, the admin creates the corresponding custom field.

The admin filters the next 100 SIM cards to be sold via Amazon and sets “Amazon” in the “Marketplace” custom field using the Group operations panel as well.

At the end of the month, Mega Telecom can filter active SIM cards and check how many SIM cards are sold per sales channel.

• You can fully manage SIM cards in PortaBilling, instead of doing this in an external system and switching back and forth
• With full information about SIM cards, you can save time when addressing customers’ queries
• You can track the SIM cards that are being sold via a specific sales partner

• For clarity, the SIM card status “Free” was renamed to “Available.”
• You can add the data to the created custom fields when uploading SIM cards from a file the same way as adding the data to the default fields – you just need to add another column to the file for upload. For example, if you created a custom field “Marketplace,” you need to add the column with the header “Marketplace custom” or “Marketplace CUSTOM” to the file and fill in the corresponding values.
• Resellers can allocate the SIM cards they manage to their distributors and customers as well.

PortaBilling API 2.0 has been designated for faster and easier development of applications. The new version of API aligns with the common naming conventions used in business. For a start, MR109 introduces a few new API methods for managing data about products, product-groups, services. API methods to cover other entities (such as customer or account) will be added in the future releases.

Developers can specify which parameters should be returned in the response, while the unnecessary parameters will be skipped. For example, the /products method can return only the product ID, type, and name. This results in quicker processing of API requests and faster communication between the client and the server.

The new version of PortaBilling API is available alongside the existing API version, allowing for a gradual transition. If you want to test the new API version, please contact the PortaOne support team.

PortaBilling API 2.0 enables easier and faster application development.

With MR109, when the main site in site-redundant PortaSwitch goes down, features that provide real-time information about the status/availability of extensions or users, such as Shared Line Appearance, Busy Lamp Field (BLF), and Presence, still remain accessible.

This ensures that customers can continue using these features (e.g., to see whether a coworker’s phone line is busy or idle) even when the main site is unavailable.

You can provide reliable service to your customers when offering the Shared Line Appearance, BLF, and Presence features.

Say a service provider, Panda Telecom, has a site-redundant installation that includes the main and secondary sites.

Panda Telecom offers its PBX customers the Shared Line Appearance feature allowing them to share a single phone number on multiple IP phones and see the current state (appearance) of the shared line, e.g., idle, busy, on hold, on any IP phone.

When the main site is down due to a power outage, the secondary site activates the “stand-alone” mode, so the new calls will be sent through the secondary site. The user’s IP phone that was previously registered on the main site, re-registers on the secondary site and re-subscribes to notifications from PortaSIP regarding call status changes, allowing the user to see the status of the shared line on their IP phone.

When you apply a new configuration via the Configuration Server web interface, the corresponding service may need to be restarted for the changes to take effect. For instance, when SSL certificates are renewed, the configuration update prompts the restart of SIP services.

Previously, the services were always restarted on all servers simultaneously. Now, when applying the new configuration, you have the option to skip restarting services on specific servers to avoid service downtime. For example, if you have two SIP servers, you can choose to restart the SIP service only on one while letting the other continue functioning. This ensures that customers can continue making calls even during the configuration change.

The “skipped” servers are marked as such on the Сonfiguration server web interface. The service restart must be done manually for the configuration changes to take effect.

In general, the configuration should be the same across all PortaSwitch servers (which is the primary reason for creating the Configuration server). Temporarily skipping the application of configuration on specific servers may lead to system malfunctions. We strongly recommend that only experienced engineers with advanced knowledge of PortaSwitch utilize this option.

Avoid service disruptions for customers during configuration changes.

Find more details here.

With this release, an admin can explicitly see which invoices include charges and payments from previous billing periods for customers that are initially created with invoicing disabled. When the admin filters invoices for a specific customer or all invoices issued during a specific period, they can see the following info:

• Before the Paid amount field showed the total amount of payments made by the customer during the current billing period. Now this field also includes the payments for all previous billing periods when no invoices were produced. If there were any such payments, the paid amount is then underlined with a dotted line, and the corresponding tooltip is displayed.
• Now the Outstanding balance field shows the amount the customer must pay to cover the current invoice in full plus the sum of charges from all previous billing periods when no invoices were produced. If there were any such charges included, this amount is then underlined with a dotted line and the corresponding tooltip is displayed.
• The Period field now displays the start and end of the billing period in a single column. Customers with the daily billing period will see only one date in this field, e.g., 2023-07-05.

In September, an admin creates a customer with a monthly billing period and assigns them a $15 subscription. However, due to human error, the invoicing is enabled for this customer in PortaBilling only in November. The admin sees that the November invoice displays $45 in the “Outstanding balance” field with the “Includes the sum of charges for all previous billing periods” tooltip. This amount includes $15 for November, as well as the cumulative charges from all previous billing periods – $30: $15 for September and $15 for October.

Say, the customer makes a payment of $40 in December. This payment is reflected in the “Paid amount” field with the tooltip “Includes payment(s) for all previous billing periods” displayed and is recorded as $30 applied to the “previous balance” of the first invoice (since there were no invoices for earlier periods) and the rest ($10) applied to the November invoice total itself. Since the payment applied to the invoice is less than the invoice total ($15), the invoice status for November changes to “Partially paid” (the sum still pending is $5).

This enhancement simplifies invoice management on the web interface for customers for whom invoicing was activated much later than when the customer was created.

The Batch account update panel has been added to the distributor portal. This panel allows distributors to update multiple accounts within a batch or an entire batch at a time in just a few clicks.

The distributor can perform the following batch operations:

• activate or terminate accounts
• allocate accounts to a sub-distributor

The batch operations are available only when accounts are filtered by batch. After the distributor selects a specific batch and applies a filter on the Account search panel, the Batch account update panel opens automatically.

The distributor can also see the total number of Selected, Started, and Depleted accounts:

• Selected – the number of filtered accounts in the selected batch.
• Started – this shows how many accounts have been used at least once.
• Depleted – this is the number of accounts that have been used up (have zero funds or the amount of funds is less than the main product breakage).

Let’s say the administrator created a batch of 1000 mobile accounts with assigned SIM cards (e.g., “Unlimited calls with 2GB internet”) and allocated these accounts to distributor John.

The distributor receives the physical SIM cards and decides to sell 100 SIM cards via their own sub-distributor, Lisa.

To allocate the corresponding accounts to the sub-distributor, John logs into their distributor portal, goes to the account list, filters the accounts by the batch “Unlimited calls with 2GB internet” and the control number (e.g., from 1-100 to filter the first 100 accounts in the batch), and assigns the sub-distributor Lisa to selected accounts.

This enhancement simplifies account management for distributors.