The status of the service does not change when it is resold

The logic of service status change in the reselling billing system

Checkevent is the process by which a service in the reselling billing system changes its status according to the selling billing system. When an event is received from checkevent in the Cron scheduler, a job of the form below is generated:

/usr/local/mgr5/sbin/mgrctl -m billmgr checkevent >/dev/null 2>&1

If the reselling billing system did not receive or did not correctly process the successful service activation checkevent from the selling platform, the service status will remain "in progress" or "pending issuance".

This can happen if the resale rule is not followed:

Use a separate account for each reselling BILLmanager in the selling BILLmanager. Otherwise, the interaction of billing systems can be disrupted.

In this case, the logic can be broken even if the processing module of one of the reselling billing systems is turned off, if they are connected to the selling system through one user.

For more details on the logic of reselling, see the article Step 1. Integration with selling BILLmanager in the BILLmanager documentation.

How does the checkevent process take place on the side of billing platforms?

The client orders the service on the side of the reselling system.
Chekevent sends information about a new order from the reselling system to the selling billing system.
The service is activated on the selling billing system's side.
Checkevent receives information from the selling billing system about the status change to "active" and transmits it to the reseller.

When multiple reselling platforms are integrated through the same account, the checkevent will receive an empty event list because it has already been zeroed for another processing module.

Thus, checkevent can transmit data about the status of a service to a platform on which these services do not exist. Therefore, the statuses will not be updated on the second platform.

Troubleshooting

For troubleshooting, examine /usr/local/mgr5/var/pmbillmgr.log — the log of the interaction between the selling and the reselling billing systems. Find the period of time in the log when certificates were issued, or the service was activated (it can be determined by the moment when in the selling billing system the certificates assumed the status of Issued or the service changed its status to Active).

To check the logs:

Connect to the server with the reselling platform via SSH.

Determine the thread required for troubleshooting by mentioning the service in the pmbillmgr.log:

grep 'elid=16643' /usr/local/mgr5/var/pmbillmgr.log

Comment

Example of output:

Nov 18 08:15:04 [23241:1] sbin_utils INFO QUERY: func=service.saveparam&sok=ok&elid=62991&name=last%5Fsync%5Fitem&value=2022%2D11%2D18%2005%3A09%3A02&crypted=off
Nov 18 08:15:04 [23241:1] sbin_utils NOTE Connect to billmgr
Nov 18 08:15:04 [23241:1] rpc EXTINFO Query('func=service.saveparam&sok=ok&elid=62991&name=last%5Fsync%5Fitem&value=2022%2D11%2D18%2005%3A09%3A02&crypted=off')

Comment

Check the log file for the thread found:

grep '23241:1' /usr/local/mgr5/var/pmbillmgr.log

Comment

Note any errors or warnings in the output. Example:

Nov 18 08:15:04 [23241:1] libmgr ERROR Error: Type: 'missed' Object: 'itemevent' Value: '1225058'
Nov 18 08:15:04 [23241:1] processing WARNING processing event for item '16643' failed: ' with '1225058' does not exist '

The error reports that no event was found for the service.

Solution

To prevent this behavior, you need to configure reselling according to the rules and replace the user for integration.

There are potential risks involved in tampering with the DB. We do not recommend making manual edits to the database, as it can disrupt the correct operation of the platform.

Any actions with the database should be performed only after backing up the platform.

To change the status of the current service:

Connect to the server with the platform via SSH.
Connect to MySQL:
```
mysql billmgr
```
Switch the service to a manual processing module by querying the database:
```
update item set processingmodule=<id_manual_pm> where id=<service_id>;
```
Comment

<id_manual_pm> — ID of the manual service processing module in the reselling billing system
<service_id> — ID of the service for which you want to change the status
Go to the web interface of the platform and perform any operation with the service to change its status, for example, turn it on with the on button. A task will be created to perform this operation.
Enter Tools → Tasks → select the task → click Edit button.
Click the Assign to me button.
Fill in all the service parameters.
Click the Send ticket/Save and Close the task buttons:

The service will change its status. You can then transfer the service back to your processing module.