Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Product Catalog and Events

  1. All product catalog entries have been entered.

  2. All product catalog entries have been matched with entries the previous billing in the Migration application.

  3. Product catalog settings have been verified by the Customer.

  4. Settings of Product catalog entries have been verified by Latera employees, including the following items:

    • Billing period

    • Charging scheme (postpaid/prepaid/daily)

    • Service providing scheme

    • Initial conditions for service providing

    • Aggregation period

    • Archiving period

      5. Each event has the following checkbox selected: “Cancel repeated events” and “Rebuild events when changing substitutions”.

Basic Contracts and Price Specifications

  1. All basic contracts have been entered in the system.

  2. All basic price specifications have been entered into the system:

    1. with the correct period

    2. at the correct tax rate

    3. in force

    4. linked with basic contracts

3. All individual price specifications have been entered into the system:

    1. with the correct period

    2. at the correct tax rate

    3. with a draft status

    4. have remarks concerning individual price specification bindings to contracts to be made after migration

    5. no mistakes have been detected while changing price specification status to “in force” during test migrations;

 

4. All price specifications have been verified by Latera employees. 

5. All price specifications have been verified by the Customer employees.

6. Automatic checking for the last test migration has detected no service subscriptions with prices that failed to be determined.

7. Provisioning of each price plan type has been proven to work in the test environment.

Customers

Within the multi-subsidiary version, tests for each section are performed separately for each company.

  1. Customers have been correctly grouped:

    1. random checks for customers belonging to different categories (individuals/entities, by regions, etc) have been performed without any faults;

    2. the number of customers per each group corresponds to those given by the Customer.

2. Customers have been subscribed to services:

    1. random checks for customers belonging to different categories (individuals/entities, by regions, etc) have been performed without any faults;

    2. the number of customers per each group corresponds to those given by the Customer.

3. Customers have access to Customer Self-Care Portal.

4. Temporary suspension and non-payment suspension services work properly (if they are going to be used).

5. The total balance of customer accounts for all customers corresponds to the one given by the Customer.

6. Random checks of account balances for customers of different categories have been performed.

7. Customer statuses are completely accurate.

a. Suspended customers and those with the Suspended status retain the corresponding status after the migration.

Test Environment

For RADIUS (DHCP) workflow:

  1. hard is set up as a cluster.

  2. Test authentication and authorization is successfully performed (attention: should be checked on the real network with real customers!).

  3. All IP addresses for access servers have been entered in the network service settings and in the FreeRADIUS configuration file.

  4. New IP addresses are assigned from the source pool.

  5. Real / fixed IP addresses are assigned by Hydra.

  6. Services are switched on/off on BRAS via event execution.

  7. Accounting packets are being received, traffic is accounted, there is no unaccounted traffic at the test database.

  8. Watchdog is set up for all FreeRADIUS instances. 

For Netflow accounting scheme:

  1. Netflow data is forwarded to the collector server (hcd).

  2. There are traffic class specifications entered in the system, and the traffic data is accounted accordingly;

  3. Within the registry for IP addresses, all IP addresses used for dynamic assigning are entered.

  4. All equipment for which traffic should be accounted is entered into the system (including provider equipment).

Telephony

  1. CDRs are rated properly (as per rating over the previous periods and reconciliation/checking).

  2. Files from PBX are automatically stored in the assigned directory at the server.

  3. CDR importing script runs periodically and performs the import.

Data Migration

  1. Все автоматические проверки, выполняемые в приложении «Миграция», проходят успешно.
  2. Последняя проверка миграции Заказчиком прошла без замечаний.
  3. Последняя проверка миграции сотрудниками Латеры прошла без замечаний.
  4. С момента последней успешной проверки прошло не менее двух рабочих дней, в течение которых в алгоритме выгрузки и миграции ничего не изменялось.

External systems

  1. Invoice export to ERP software is successfully performed by the Customer for the test customers. Importing script executes without faults.

Backup

  1. Production database dump is automatically collected daily and copied to a safe storage.

  2. The latest production database version with the pre-migration status is backed up and stored at the Latera server.

  3. Auxiliary backup of the server и production database dump and to the Latera server is turned off.

  4. Replication is set up and is properly performed (should be checked at the backup server).

Payments acceptance

  1. Payments acceptance via payment gateways has been successfully tested for faults.

  2. In hcd, certificates and logins/passwords are ready for production usage.

Business processes

  1. New customer connection process has been tested.

  2. The plan of actions for all frequently arising customer support issues has been clarified (viewing PPP sessions, password changing, etc.).

Administration

  1. Hardware server configurations correspond with Commercial Proposal requirements (CPU, RAM, storage). It applies both to the Customer’s servers and SaaS installations.

  2. All Hydra tasks required for system operation run without faults or warnings.

    1. For all scheduled tasks operating with CDRs and the RADIUS server correct parameters are set up (CDR closing timeout, deleting outdated CDRs, synchronizing RADIUS sessions).

3. Debug logging is disabled for all modules and agents.

4. The system servers have the latest stable versions of the following installed:

    1. Core (database)

    2. Web-apps

    3. Agents.

 

5. All Debian Linux security updates are installed.

 To install updates, it is necessary to perform the following command:

root@billing:~# aptitude update && aptitude upgrade

Note: When performing updates, it is obligatory to review the list of updates in detail. There should be no unexpected updates of Hydra modules.

9. Server monitoring has been set up for:

    1. free disk space  

    2. RAM

    3. CPU utilization

    4. other important factors

10. Monitoring of the billing system has been set up and tested:

    1. free space in HYDRA tablespace

    2. important system tasks:

      • closing charge logs and bringing them to In force status

      • Charge log creation

      • IP traffic rating

      • Check customer account balances

      • Forced closing or deleting outdated CDRs

c. any CDRs rated with errors or unrated.

11. For Service Provider Console and Customer Self-Care Portal:

    1. SSL access is set up

    2. A reminder is set up for updating SSL certificate before its expiration

    3. DNS records are set up and active

12. Default passwords to all services have been changed, including those

  1. for Oracle users:
    • AIS_NET
    • SYS
    • AIS_ISP_OFFICE
    • AIS_USER_OFFICE
    • AIS_RPC
    • others (if necessary)

13. Servers within Hydra are completely ready for going live (should be checked for each server separately):

    1. Configuration corresponds with the one in the commercial proposal.

    2. All necessary services are working after the system restart (should be checked via reboot!)

    3. IP address and server hostname are assigned

    4. Firewall is set up and turned on:

      • No Hydra services are unnecessarily exposed

      • Access to Service Provider Console is allowed only from internal Customer subnets and Latera servers

      • There is no access to 21902 and 21903 TCP ports which was previously granted during implementation stage for connections from IP address 144.76.78.80.

e. Correct timezone is set up, NTP time synchronization is enabled. 

14. Customer Technical Datasheet is created and stored in Latera database.

15. An up-to-date Oracle DST version is used.

16. The number of customers is the same as per the License:

SELECT COUNT(*)
FROM   SI_V_USERS U
WHERE  U.N_SUBJ_STATE_ID = SYS_CONTEXT('CONST', 'SUBJ_STATE_On')
AND EXISTS (
  SELECT N_SUBSCRIPTION_ID
  FROM   SI_V_SUBSCRIPTIONS
  WHERE  N_SUBJECT_ID = U.N_SUBJECT_ID
  AND    SYSDATE BETWEEN D_BEGIN AND NVL(D_END, SYSDATE)
  AND    C_FL_CLOSED = 'N');

Hydra OMS

  1. The logic of business processes complies with their description and expected behavior.
  2. Integration with external systems runs normally.
  3. Standard passwords for Hydra OMS, Activiti, and external systems have been changed.
  4. Implemented business processes have been tested for all possible usage scenarios.
  • No labels