Comprehensive details and group operations in SIM card inventory
You can now store additional parameters for a SIM card in PortaBilling – for example, you can store PUK codes within the SIM card inventory so that admins can quickly find them in PortaBilling when a user loses their code. And by including information about the marketplace or the sales partner, you can keep track of SIM cards distributed via different sales channels.
The following information about SIM cards can now be stored in one place:
- The SIM card inventory has now been extended with dedicated fields for the PIN for inactive cards, PUK1, PUK2, and the activation code for each physical (SIM) or virtual (eSIM) card.
- You can also create your own custom fields for the SIM card inventory in order to keep additional information, such as where the SIM cards are being sold (e.g., via Amazon).
- To track SIM cards that have been distributed among your sales partners (such as distributors and representatives) and customers, you can now allocate SIM cards to the corresponding entities in PortaBilling.
Additionally, you can change the details for multiple SIM cards at a time using the group operations functionality in the SIM card inventory.
For example, say the admin for an MVNO called “Mega Telecom” uploads a file with the data for 1000 SIM cards to the SIM card inventory. To allocate 100 of those SIM cards to Mega Telecom’s distributor, the admin gets the ICCID for the physical SIM cards that will be shipped to the distributor (say, from 1949177921756150001 to 1949177921756150100) and then filters the SIM inventory for those ICCID numbers to find those cards. Then, the admin simply selects the distributor on the “Group operations” panel and applies the changes to allocate the cards.
At the end of the month, Mega Telecom can filter by active SIM cards to check how many of the allocated SIM cards have been sold by that distributor.
What’s improved?
Easier administration
Manage all the information about SIM cards in one place and save time by updating details for multiple SIM cards at a time.
Find more details here.
New version of the PortaBilling API
PortaBilling API 2.0 is now available, which means application development is now easier. The updated API aligns with widely used design principles (such as REST or OpenAPI). It represents data structures via objects and attributes named in a way that can be easily understood by developers with basic telecom experience, eliminating the need for them to have prior knowledge of PortaBilling or its internal data structures.
To get started, MR109 introduces a few new API methods – for managing data about products, product groups, and services.
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 the quicker processing of API requests (since the server accesses fewer tables in the database to collect the required info) and faster communication between the client and the server (since less data has to be sent).
The new PortaBilling API version is available alongside the existing API version, allowing for a gradual transition. API methods to cover other entities (such as customer or account) will be added in future releases.
What’s improved?
Easier development
Save resources with easier application development.
Find more details here.
Availability of Shared Line Appearance, BLF, and Presence features during main site outages
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.
Let’s say a service provider, ABC Telecom, has a site-redundant installation that includes the main and secondary sites. ABC 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.
If a power outage or some other factor causes the main site to go down, the secondary site activates the “standalone” mode. The user’s IP phones re-subscribe to notifications from PortaSIP with call status changes, and the users can continue to see the status of the shared line on their IP phones.
What’s improved?
Reliable service
Provide reliable service to your customers when offering them the Shared Line Appearance, BLF, and Presence features.
Find more details here.
Additional clarity for invoices when invoicing was previously disabled for a customer
Sometimes there is a situation where invoicing has been disabled for a customer, e.g., due to human error, and, after a few billing periods, invoicing is enabled. By that time, the customer may already have accrued an outstanding balance from the billing periods that were not invoiced. Previously, this was not reflected on the web interface, potentially causing a need for time-consuming investigation. Now, when invoices are generated in such cases, the following information is displayed per invoice in the invoice list:
- Outstanding Balance – If there are owed amounts from previous billing periods when no invoices were issued, the displayed value will include these amounts. This way, the admin will be able to see the total amount the customer owes. Previously, in this case, this field only displayed the owed amount for the period covered by the invoice.
If amounts from the previous billing periods are included, this value is underlined with dots, revealing the corresponding tooltip.
- Paid Amount – If the customer made a payment that covered the charges from previous billing periods where no invoices were issued, the payment amount will still be included in the displayed value and the admin will be able to see how much the customer has actually paid. Previously, this field only displayed the paid amount applied to this invoice’s period.
If the paid amount covers the previous billing periods, the admin will see a dotted underline, and the corresponding tooltip will be displayed when the admin hovers over it.
To illustrate this, say a customer with a $15 subscription and a monthly billing period is created in PortaBilling in September. Due to human error, the invoicing is enabled for this customer only in November. By that time, the customer already owes $45 ($15 x 3, for September, October, and November).
When the admin opens the invoice list with the November invoice, the corresponding record shows an “Invoice total” of $15, while the corresponding “Outstanding balance” is $45. The admin sees the tooltip saying that the $45 amount includes the owed amounts from previous billing periods.
Suppose the customer pays $40 in December. When the December invoice is generated, its “Invoice total” will be $15, while the corresponding “Outstanding balance” will be $20. The admin checks the “Paid amount” and finds out that the customer made a payment of $40, covering the previous billing periods.
What’s improved?
Save time on troubleshooting
Manage reconciliations with customers more quickly and with less investigation.
Find more details here.
The “batch account update” functionality for distributors
The Batch account update panel has been added to the distributor portal, so that distributors can now update a group (batch) of accounts at a time. For instance, a distributor can activate multiple accounts within a given batch or assign the entire batch to a sub-distributor in just a few clicks.
For example, let’s say an admin of “Mega Telecom” created a batch of 1000 mobile accounts in PortaBilling (e.g., “Unlimited calls with 2GB”) and allocated these accounts to Mega Telecom’s distributor, Adam. The distributor receives the physical SIM cards assigned to these accounts, and decides to sell these SIM cards via their own sub-distributor in the local supermarket chain. To allocate the corresponding accounts to the sub-distributor, Adam logs into their distributor portal, goes to the account list, filters the accounts by “Unlimited calls with 2GB” batch, and assigns the sub-distributor to all the accounts within the batch.
What’s improved?
Easier administration for distributors
Distributors can apply changes to multiple accounts at a time.
Find more details here.
