Version

03.1.1

Commercial Management System

CMS

Operating system

CMS
 USER’S MANUAL
OPERATING CMS
INDRA
ISLAB - NAIROBI
CMS
Version 03.1.1-MLT-GH
 OPERATING CMS

CMS v16.08.05

Table of Content:
1 CONCEPT CMS .................................................................................................................................... 5
1.1 Database Server ..................................................................................................................................... 5
1.2 Application Server .................................................................................................................................. 5
1.3 Client ......................................................................................................................................................... 5
2 SYSTEM OPERATION .......................................................................................................................... 6
2.1 On-line Operation................................................................................................................................... 6
2.2 Batch Processing..................................................................................................................................... 6
2.3 Out of Batch window mass processing (permanent batch) ......................................................... 6
2.4 System Operation Time Map ................................................................................................................ 7
3 SYSTEM COMPONENTS ...................................................................................................................... 8
3.1 Database server...................................................................................................................................... 8
3.2 Application Server .................................................................................................................................. 8
3.3 Backup ...................................................................................................................................................... 8
4 ON-LINE OPERATION .......................................................................................................................... 9
5 BATCH OPERATION CMS ................................................................................................................. 10
5.1 Describing Programs of Respective PPASE Batch Modules ......................................................... 11
5.1.1 Customer Services Processes ...............................................................................................11
5.1.2 Reading Processes ................................................................................................................11
5.1.3 Billing Processes ...................................................................................................................20
5.1.4 Collection Processes .............................................................................................................25
5.1.5 Accounting Interface Processes .............................................................................................36
5.2 Operator’s Menu, PPASE Batch process .......................................................................................... 40
5.2.1 Operator’s Menu Function Description ...................................................................................50
5.2.2 Detailed Description Of Operator’s Menu ...............................................................................50
5.2.3 Programs In Ppase Directory .................................................................................................53
5.2.4 Programs In Subscripts Subdirectory .....................................................................................54
5.2.5 Description of Operator menu – part Batch (PPASE Batch) ....................................................55
5.2.6 Detailed Description Of PPASE BATCH Process ...................................................................55
5.3 Batch Operation IGEA/PENTAHO/EBM............................................................................................. 57
5.3.1 IGEA......................................................................................................................................57
5.3.2 PENTAHO .............................................................................................................................57
5.3.3 EBM ......................................................................................................................................57
5.4 Monitoring, Error Checking and troubleshooting ........................................................................... 57
5.4.1 Monitoring..............................................................................................................................57
5.4.1.1 CMS ...............................................................................................................................................57
5.4.1.2 IGEA ..............................................................................................................................................58
5.4.1.3 PENTAHO ......................................................................................................................................58
5.4.1.4 EBM ...............................................................................................................................................58
5.4.2 Error Checking .......................................................................................................................58
5.4.2.1 CMS ...............................................................................................................................................58
5.4.2.1 IGEA ..............................................................................................................................................58
5.4.2.2 PENTAHO ......................................................................................................................................58
5.4.2.3 EBM ...............................................................................................................................................58
5.4.3 Troubleshooting .....................................................................................................................58
5.4.4 Technical Problems ...............................................................................................................59
6 EXAMPLES......................................................................................................................................... 59
6.1 Examples Of Files................................................................................................................................... 59
7 TERMINOLOGY .................................................................................................................................. 64

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 4

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

1 Concept CMS
By means of the logical structure, the CMS is divided into components working independently. The
system is working properly as long as each of the components is functional. The CMS consists of three main
components:

1) Database server
2) Application server
3) Client
a) On-line system application
b) Night processing of batch programs

1.1 Database Server

The database server serves in general as an instrument for settling the information administration
problems. It serves to organise and administer relational database data, provides for simultaneous data access
for several users, protect data against unauthorised access and protect data in case of disaster.

1.2 Application Server

The application server provides for so-called business logic of the whole system. The rules used in any
data administration are defined in the kernel of this component.

1.3 Client
On-line – this component serves to allow the user to access the company data and perform defined operations
with these data.

Batch – provides for mass processing of the data stored in the production computer after they had been
modified on-line by a CMS client.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 5

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

2 System Operation
The system operation means a set of actions whose aim it is to provide for company data access for
users by means of the CMS on-line application. From the point of view of the time, the system is operated
according to the company needs. The daytime system operation consists of two stages and a nightly batch
operation:

a. On-line operation (Daytime Operation)

b. Night processing, limited on-line access (Night Operation)
c. Out of batch window mass processing (Daytime Operation)

2.1 On-line Operation

In On-Line operation the system is fully accessible to all users. It is necessary to check the functions of
the respective system components at this stage. It is recommended to elaborate exact proceedings providing
for the on-line operation.

2.2 Batch Processing

The processing is performed by the operator by means of some already prepared tools. The backup of
production database is performed nightly by DBA team each morning and follow general backup rules defined
in company. Also, it is allowed backup before running batch. This backup can be selective, and can be
performed manually at request. Manually backup is just for reference and it is NOT the backup of the last
instance from which will be possible to recover production database. During the night processing the access
of on-line users is limited only to READ ONLY.

2.3 Out of Batch window mass processing (permanent batch)

This process is indeed to run in the day period, when nightly batch is not running. Before running nightly
batch, it will be necessary to stop permanent batch processes. Once Nightly batch finishes, it is then necessary
to start permanent batch.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 6

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

2.4 System Operation Time Map

During system operation it will be necessary to follow some time-map, which is defined by default and
can be adjusted during system operation as and when necessary. By default, the system operation will
start with the following time-map:

Batch/Maintenance window definition

Permanent
ONLINE Batch Env backup(TAR/GZ) DB Backup(RMAN+FULL dump) Batch
CMS CMS CMS CMS CMS
7:00 END END START
8:00
9:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00 END START END
20:00
21:00
22:00
23:00
0:00
1:00
2:00
3:00
4:00
5:00 START END START START
6:00 START

Legend
Online Availability Read Only
Batch window
Backup Window Start
PERMANENT BATCH

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 7

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

3 System Components

3.1 Database server

CMS system data are stored into an Oracle database. An administrator takes care of this database
administration. His task is to ensure the running of this database, monitoring of this database, performance
tuning and necessary backups of this database.

Database Administrator will administer database server using any available administration tool. Batch
Operator will be able only to move database to enable/disable restricted mode or execute limited export of
current database.

3.2 Application Server

The UNIX administrator takes care of the application server. The basic functionality of Openlink
administration is available through the Operator menu. Batch modules also is available from Operator Menu.

3.3 Backup
The system backup has to be done regarding the intense availability and continuity of operation and
according to the requests of client for backup and recovery.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 8

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

4 On-line Operation
The on-line operation covers commercial management functions – customer care. The system end user
gets in touch with the “CMS on-line client” system component. The location of this component in the logical
structure of the CMS is displayed in the picture in the Concept CMS chapter. This component contains the
CMS. This application is described in these manuals: CMS Installation and Configuration Manual and
application operating manuals. The end users working with the CMS must be properly trained. Training is
organised by the system administration.

The on-line operation contains the following levels:

a) Users
b) System administration
c) Support
d) Maintenance

USERS

SYSTEM ADMINISTRATION

SYSTEM MAINTENANCE

SYSTEM SUPPORT

Scheme of mutual relations is the following:

In case of problems with an on-line application, the users contact System Administration Unit (SAU) and inform
the responsible person about the problem that has been raised in working with the application. The System
Administration Unit analyses the problem and decides how to resolve it. If the problem solution comes under
their responsibility, SAU resolves it. If the problem does not come under their responsibility, SAU passes it,
according to the kind or type of problem, to the System Support Unit or to the System Maintenance Unit.
Similarly, these units (SSU and SMU) contact the SAU in case if they cannot resolve the problem that has
been raised during their activities and it clearly becomes the responsibility of the SAU. The hierarchy of
relations is displayed on the picture above.

During on-line operation, problems may arise that cannot be resolved by SAU, SSU or SMU. This kind of
problem becomes to the category of incidents. The management of incidents and their resolution is performed
according to the processes and rules that were sold to the company.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 9

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5 Batch Operation CMS

Batch processes run whole day, independent of type of running, nightly batch run during batch window,
permanent batch is running out of batch window. Parallel running of nightly batch and permanent batch
is forbidden.

However, all the pre-set advances must be carried out and the data files coming from enterprises and reading
centres must be accepted first of all.

The batch operation assumes that the processes are carried out on daily basis, though some of them operate
with activities of different periodicity.

To make you better understand the system operation the main operation processes in each module and their
periodicity is described below.

The operator is responsible for the course of processing in the Batch process. He reports the errors occurring
in this process to the UNIX administrator, the ORACLE administrator and the operating programmer – CMS
specialist who are responsible for removing them.

Batch programs used in Batch process, the sequence in which they are run, the conditions under which they
are run in the respective company are determined by the operating programmer – CMS specialist. He is also
responsible for preparing CONDICION files that are followed by the Batch processing.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 10

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.1 Describing Programs of Respective PPASE Batch Modules

5.1.1 Customer Services Processes
The guarantee batch process will retrieve the accounts with guarantees that are due and sets the indicator to ‘expire- 2’ to enable sending of notices to the
customer to alert them of the expiration.
The batch also keeps track of the number of notices sent to the customer by maintaining the indicator for the number of weeks since last notice.

PROCESS DESCRIPTION PERIODICITY NOTES

1) Guarantee management The processes takes the following steps: Daily - Batch Window
- Retrieve all the accounts with
expired guarantees
- Update status of the guarantees
which are due

Programs description:

Program Description Inputs Outputs

1 PROCESS Guarantee Management
1) CBC3101 The batch sets the indicator for expired guarantees FECHAB SUMCON
COB_3101_guarantee_notice to 2 or 3 depending on whether the guarantee has FUSUARIO
.unx expired and a first notice has been sent SUMCON
PARAMETROS
Controlparse
/man
COBROS_CBC3101
NULL
/commit
/batch
Reading Processes
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 11
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Reading processes (part “batch”) consist of two main processes:

 Itineraries generation
 Processing of received itineraries (interface with billing)

PROCESS DESCRIPTION PERIODICITY NOTES

1) Generating readings This process takes the following steps: Daily -Batch Window
1. Deleting of itineraries history
2. Extracting itineraries
3. Generating itineraries
4. Distributing itineraries
5. Distributing text files
2) Processing accepted readings This process takes the following steps: Daily – Batch Window
1. Unlocking records
2. Interface generation for the billing of
service point with direct connection
3. Text files collection
4. Text files processing
5. Accepted itineraries processing,
control of accuracy and
completeness, interface with billing.
6. Locking records.
7. Deleting ABONADOS_AUSENTES
and ITIFACT_VO.
8. Deleting ITIFACT_VO and
ITIFACT_VO_APA
9. Maintenance of history of reading
routes and itineraries + automatic re-
planning of reading routes

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 12

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

I. Itineraries generation

Before the process of itineraries generation is started, the employee of a concrete reading centre who responsible for readings scheduling, prepares the data
on-line: he plans theoretical dates of reading for every itinerary of given reading route (using the function „Planning of theoretical reading dates“). So, he prepares
so called calendar of readings, which is, together with the properties positioned within the individual reading routes, the base for itineraries generation.

1. Deleting the history of itinerary

Deleting the itinerary history after expiring the period indicated by parameter YRS_ST_READ_HST.

2. Extraction of itineraries – selection of itineraries that have to be generated in given day.

The cycles of itineraries are selected, for which is valid the following condition:
Date of theoretical reading – parameter at the level of reading centre <= current date
Where the parameter at the level of reading centre express the number of days for itineraries generation before the theoretical date of reading. For this, the
working days are taken into account.

Example: If the theoretical reading date for given itinerary is April 17, and the parameter at the level of reading centre is 5, it means that the required itineraries
will be generated on April 12.

3. Generation of itinerary data – Data for all properties in itinerary are generated that are necessary for reading performance: reading cycle type, properties,
meter chambers, meters, consumption types, geographical data, horizontal geographic key, name of customer, tariff and power corresponding to the service
point. The maximum and the minimum values are calculated too, that means, supposed range for the reading value, according to the previous reading, and
the per cent of deviation. This will warn the reader for errors. These data are saved to the table ITINER.

The day after the generation of itineraries is possible to start another processing of itineraries – scheduling (planning), loading to HHT or reading sheets printing
and itineraries assigning to the individual readers.

4. Distribution of itineraries
Itineraries are distributed in accordance with the configuration of reading route, to which they belong. Possible variants are the following:
- ToOnline – itineraries are scheduled using online application.
- ToSend – for every itinerary is generated text file, itineraries are waiting for reading reception from an external entity.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 13

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5. Distribution of text files

Text files containing generated itineraries are distributed to the folder for their upload, using FTP according to the number of reading centre, and to the backup
folder. After the process is finished, they are deleted from work folder.

II. Processing of received itineraries

The second part of readings batch process allows the preparation of received readings for billing.

The process of locking and unlocking of records stored in the table ITIFACT_VO assures that to the process of billing will pass only a certain number of records
that can be physically processed during the night batch process. This number is determined by a parameter. On the next day, the older locked records are
released for billing in the first instance, together with actual processed readings. If their number exceeds again the dose that can be processed at once, redundant
records prepared for billing will be locked again.

The process of collection and processing of text files consists of copying files from folders for their upload from reading centres to backup folder, then the files
are processed – the data about readings are inserted to the database. Once the file is processed, it is deleted from upload folder.

The readings processing means processing of readings and reading exceptions that have been entered on-line (by HHU or manually), readings delivered by
file, by customer, etc. The data consistence (their comprehensiveness or redundancy) and accuracy are controlled.
Correct readings or estimations are loaded to the table for billing preparation.
If there are readings with exception, the following possibilities can arise:

– Billing based on reading

– Waiting for reading delivered by customer
– Billing based on estimation
– Resolution of exception
– Generation of service order for exception resolving.

Finished the readings processing, the records are deleted from temporal reading and billing tables.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 14

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Programs description:
I.
Program Description Inputs Outputs
1 PROCESS Generating readings
1) LECC0050 Deleting the itinerary history FECHAB HITINER
/man LECTUR_LECC0050 NULL Deleting the itinerary history after expiring the period FUSUARIO HCICLOS_ITIN
/commit [/rollback] indicated by parameter YRS_ST_READ_HST. CICLOS_ITIN HCICLOS_RUTA
CICLOS_ITINDCL MITIN
ITIDCL RUTAS
2) LECC0100 Extracting itineraries for generation. FECHAB UNICOM
/man LECTUR_LECC0100 NULL Selection of itineraries for generation based on FUSUARIO LESE0100
/commit [/rollback] theoretical date of reading and parameter UNICOM
determining the number of days in advance. The FIESTAS
result is registered to the text file LESE0110 FIESTAS_NAC
CICLOS_ITIN
CICLOS_RUTA
RUTAS
3) LECC0200 Preparation of SPs with direct connection for FECHAB SUMCON
/man LECTUR_LECC0200 NULL billing. FUSUARIO CONTROL
/commit [/rollback] The process is selecting all SPs with direct SUMCON ITIFACT_VO
connection that are not the short-term supplies. CONTROL
Dates parameterisation for every year and for GRUPOS_REL
individual types of SPs in saved in the table HFACTURACION
CONTROL.
4) LECC0300 Generating itineraries FECHAB ITINER
/man LECTUR_LECC0300 NULL The Function of this process is to select necessary FUSUARIO FINCAS_PER_LECT
/commit [/rollback] data for itinerary readings performance or LESE0100 CICLOS_ITIN
estimation, the list of itineraries are located in the file RUTAS
LESE0100. CICLOS_ITIN
- Itinerary data are checked and the data that the ITINER
itinerary is composed of are loaded in given order: APMEDIDA_AP
reading cycle type, properties, meter chambers, APMEDIDA_CO
meters, consumption types, geographical data. APMEDIDA_PARAM
CALLEJERO
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 15
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

- The maximum and minimum values are calculated CICLOS_RUTA
between the reading can oscillate according to the CLIENTES
previous reading, and the per cent of deviation. This CODIGOS
information warns the reader from possible error in DEPTOS
reading. LOCALIDADES
- Horizontal geographic key is decoded to obtain the MUNICIPIOS
property location, the name of client, tariff and PUNTOMED
power according to the service point are loaded. PUNTOMED_PARAM
- Finally, the records with loaded data are saved into SUMCON
the table ITINER. Finally, an itinerary status is TIPOS
actualised, and the number of generated service FINCAS
points is loaded to the table CICLOS_ITIN. FINCAS_PER_LECT
GRUPOS_REL
ITIFACT_VO
5) LECC0350 Itineraries are distributed basing on the FECHAB CICLOS_ITIN
/man LECTUR_LECC0350 NULL configuration of their reading route type. Possible FUSUARIO AMR files with itineraries
/commit [/rollback] variants are as follows: CICLOS_ITIN
- ToOnline – itineraries are scheduled using an RUTAS
online application ITINER
- ToSend – text file is generated for each itinerary, UNICOM
itineraries are waiting for reading from an external
entity

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 16

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

II.
Program Description Inputs Outputs
2 PROCESS Accepting itineraries
1) LECC0400 Unlocking of records prepared for billing locked from FECHAB ITIFACT_VO
/man LECTUR_LECC0400 NULL previous days. FUSUARIO
/commit [/rollback]
2) F_SIC_Amr01 Read data from AMR table AMR_TRANS_EXT and TS AMR_SYS_CODE USUARIO F_ACTUAL
/man SIC_AMR01 NULL /commit insert into AMR_TRANS_LOC ACCOUNT_NUMBER PROGRAMA TS
[/rollback] CUSTOMER_NAME AMR_SYS_CODE NIS_RAD
METER_MODEL CUSTOMER_NAME
METER_NUMBER METER_MODEL
READING_DATE METER_NUMBER
BILLING_PERIOD READING_DATE
ALARM_CODE BILLING_PERIOD
TOU_STD_KWHTOU_STD_K ALARM_CODE TOU_STD_KWH
VAH TOU_STD_MAX_KVA TOU_STD_KVAH
TOU_PEAK_MAX_KWH TOU_STD_MAX_KVA
TOU_PEAK_KVAH TOU_PEAK_MAX_KWH
TOU_PEAK_KVA TOU_PEAK_KVAH
TOU_OFFPEAK_KWH TOU_PEAK_KVA
TOU_OFFPEAK_KVAH TOU_OFFPEAK_KWH
TOU_OFFPEAK_MAX_KVA TOU_OFFPEAK_KVAH
EXPORTED EXPORTED_TS TOU_OFFPEAK_MAX_KVA
SEC_NIS EST_TRANS
3) LECC2200 Process readings from the Amr system from the AMR readings from ITINER
/man LECTUR_LECC2200 NULL table AMR_TRANS_LOC and update the table AMR_TRNS_LOC AMR_TRANS_LOC
/commit [/rollback] ITINER with correct readings as received from the
AMR system
5) LECC0500 Interface with billing FECHAB ABONADOS_AUSENTES
/man LECTUR_LECC0500 NULL - Process the records in the table ITINER (check FUSUARIO ITIFACT_VO
/commit [/rollback] the readings registered by phone, completing the ITINER ITIFACT_VO_APA
records of SP…) CICLOS_ITIN TRABPEND_AF
- According to the Action value will be decided, if SUMCON AN_TRABPEND_AF
the billing will be carried out base on reading or HSUMCON ORDENES
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 17
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

estimation and the data are entered to AN_LECT CICLOS_ITIN
ITIFACT_VO and ITIFACT_VO_APA, respective ABONADOS_AUSEN- ITINER
the are some control reading (there control TES CICLOS_RUTA
readings are written into the table UNICOM APMEDIDA_CO
APMEDIDA_CO as control readings). The RUTAS
estimation will be entered as null reading + ORD_PRIO
exception causing the estimation. APMEDIDA_AP
- If there are some exception, the decision on the CODIGOS
following activities is taken: TIPOS
- billing based on reading FIESTAS
- waiting for reading by phone FIESTAS_NAC
- billing based on estimation
- exception resolving
- service order generating to resolve an exception
According to the given activity, enter records to
the ITIFACT_VO, ITIFACT_VO_APA, or
ABONADOS_AUSENTES, or TRABPEND_AF,
AN_TRABPEND_AF, or ORDENES.

- The records are entered to ITINER

6) LECC0600 Locking of redundant records prepared for FECHAB ITIFACT_VO
/man LECTUR_LECC0600 NULL billing. FUSUARIO
/commit [/rollback] - This program stops records ITIFACT_VO in the ITIFACT_VO
amount that would overlap the limit designated for
daily billing process. Data about this limit are stored
in the table PARAMETROS.
7) LECC0850 Deleting ABONADOS_AUSENTES. FECHAB ABONADOS_AUSENTES
/man LECTUR_LECC0850 NULL - The module deletes records that have been billed FUSUARIO
/commit [/rollback] and that are older than NUM_DIAS_FACT CICLOS_ITIN
- The module deletes records that were not used
during the billing and that are older than
NUM_DIAS_PEND_LECT

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 18

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

8) LECC0950 FECHAB ITIFACT_VO
Deleting ITIFACT_VO
/man LECTUR_LECC0950 NULL FUSUARIO ITIFACT_VO_APA
/commit [/rollback] - The module deletes records from ITIFACT_VO
ITIFACT_VO_APA and from ITIFACT_VO that
have been billed and that are older than
NUM_DIAS_FACT.
9) LECC0999 ITINER HITINER
/man LECTUR_LECC0999 NULL Maintenance of route and itinerary history + CICLOS_ITIN HCICLOS_ITIN
/commit [/rollback] automatically planning the routes CICLOS_RUTA HCICLOS_RUTA
- The module updates the records in
CICLOS_RUTA and move the processed records
from tables ITINER, CICLOS_ITIN, CICLOS_RUTA
do HITINER, H CICLOS_ITIN and
HCICLOS_RUTA. If necessary it makes the
replanting of cycles for next year.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 19

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.1.2 Billing Processes

It is necessary to take the following billing processes:

PROCESS DESCRIPTION PERIODICITY NOTES

1) Erasing of bills Process erases the bills which were not sent Daily-Batch Window It must be active parameter
to customer and put on hold. If there are bills FACC1019_ONHOLD
put on Hold in the status “Generated”, they
have to have records in ITIFACT_VO with
the status “Bill on Hold”.
After the batch program is finished, all the
bills have to be erased and the status of the
records should be “Erased Bill”
2) Processing absent customers Selecting the non-read service points whose Daily-Batch Window Define the number of waiting days
readings have been announced via phone (NUM_DIAS_FACT, NUM_DIAS_PEND_LECT)
by the customer. These service points are in the PARAMETROS table
then entered into the billing process:
3) Pre-billing This process performs the test billing of the Daily-Batch Window Only the SP with code mask (SP type and
service points assigned for pre-billing. service) included to the actual setting of
These service points are entered in the table parameter PROCESAR_PREFACT will be
ITIFACT_VO in status IT001. processed in the process of pre-billing.
The type of billing can be arbitrary. The
process of pre-billing serves to detect errors
and problems of billing with the possibility to
delete outputs of this process (and to correct
the inputs).
4) Real Billing from pre-billing After the SP transfer from pre-billing to the Daily-Batch Window The same condition as previous is controlled –
real billing parameter PROCESAR_PREFACT.
(confirmation of billing results)
(ITIFACT_VO in status IT004), the SPs are
processed by this process. This process is
irreversible, with the record to the DB.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 20

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5) Billing without prebilling This process perform a direct billing of the Daily-Batch Window Only those SPs are processed whose code mask
SPs assigned for billing. The SPs are in the is not included in actual setting of parameter -
table ITIFACT_VO in status IT001. PROCESAR_PREFACT. It should be included in
This process is irreversible, with the record a logical supplement of parameter setting.
to the DB. Is used for SPs where is not necessary pre-billing
and control of results.
6) Billing miscellaneous charges This process is processing records Daily-Batch Window
generated by daily operation or by batch to
the table of miscellaneous charges
(cargvar).
For those records creates a standard bill
(Recibos).
7) Preparing data for parallel billing This process is preparing parameters for Daily-Batch Window
parallel billing
8) Bulk accounts Billing(BA) This process performs the direct billing BA Daily-Batch Window The input data for billing are created by billing
defined for billing. process for the services belonging to BA.
These are the SP written into the table
ITIFACT_VO in status IT001, having
TIP_REC TR230 and F_PROC_MIN <=
than FECHAB.
The process is irreversible with a saving into
the database.
9) Elimination erroneous SPN from Change the state in ITIFACT_VO from Daily-Batch Window
billing IT999 to IT001

Programs description:

Program Description Inputs Outputs

1 PROCESS Process of erasing of bills
FACC1019.pc The process erases bills which were not sent to ITIFACT_VO ITIFACT_VO
Controlparse customer and put on hold. Puts on Hold in the status ITIFACT_VO_APA ITIFACT_VO_APA
/man FACTUR_FACC1019 “Generated”, they have to have records ITIFACT_VO
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 21
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

NULL with the status “Bill on Hold”. After the batch program
/commit is finished, all the bills have to be erased and the
status of the records should be “Erased Bill”.
2 PROCESS Absent customers processing
FACC00005.pc This process selects not read SPs and SPs with the ABONADOS_AUSENTES ITIFACT_VO
Controlparse reading delivered by customer. After the selection, HAPMEDIDA_AP ITIFACT_VO_APA
/man FACTUR_FACC0005 the SPs are transferred to the billing process. APMEDIDA_AP
NULL SUMCON
/commit HSUMCON
3 PROCESS Pre-billing
This process performs a test billing of service points ITIFACT_VO HFACTURACION
FACC10002.pc assigned for pre-billing. ITIFACT_VO_APA CONC_TECNICOS
Controlparse Those SP are entered in the table ITIFACT_VO in SUMCON IMP_CONCEPTO
/man FAC_1004_prebilling status IT001. HFACTURACION IMP_DETALLE_CONCEPTO
NULL The type of billing can be arbitrary. The process of APMEDIDA_CO IMPRIMIR_DATOS
/commit pre-billing allows detecting errors and problems of HAPMEDIDA_CO TRABPEND_AF
billing with the possibility to delete outputs of this PREC_CONCEPRO AN_TRABPEND_AF
process (and to correct the inputs). MOD_CALC ME_TRABPEND_AF
CTE_MOD SU_TRABPEND_AF
MOD_CALC_PARM CS_TRABPEND_AF
CU_TRABPEND_AF
4 PROCESS Billing of pre-billed data
FACC1001.pc After the SP transfer from pre-billing to the real billing ITIFACT_VO RECIBOS
Controlparse (confirmation of billing results) ITIFACT_VO_APA EST_REC
/man (ITIFACT_VO in status IT004), the SPs are CONC_TECNICOS IMAGENES
FAC_1005_real_billing processed by this process. This process is SUMCON HFACTURACION
NULL irreversible, with the record to the DB. HFACTURACION CONC_TECNICOS
/commit APMEDIDA_CO IMP_CONCEPTO
HAPMEDIDA_CO IMP_DETALLE_CONCEPTO
PREC_CONCEPRO APMEDIDA_CO
MOD_CALC IMPRIMIR_DATOS
CTE_MOD TRABPEND_AF
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 22
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

MOD_CALC_PARM AN_TRABPEND_AF
ME_TRABPEND_AF
SU_TRABPEND_AF
CS_TRABPEND_AF
CU_TRABPEND_AF
5 PROCESS Billing without prebilling
FACC1003.pc This process performs a direct billing of the SPs ITIFACT_VO RECIBOS
Controlparse assigned for billing. The SPs are in the table ITIFACT_VO_APA EST_REC
/man ITIFACT_VO in status IT001. OUTAGE IMAGENES
FAC_1006_billing_without_pr This process is irreversible, with the record to the DB. SUMCON HFACTURACION
ebilling HFACTURACION CONC_TECNICOS
NULL APMEDIDA_CO IMP_CONCEPTO
/commit HAPMEDIDA_CO IMP_DETALLE_CONCEPTO
PREC_CONCEPRO APMEDIDA_CO
MOD_CALC IMPRIMIR_DATOS
CTE_MOD TRABPEND_AF
MOD_CALC_PARM AN_TRABPEND_AF
ME_TRABPEND_AF
SU_TRABPEND_AF
CS_TRABPEND_AF
CU_TRABPEND_AF
6 PROCESS Miscellaneous charges billing
COB_2050.pc This process is processing records generated by CARGVAR RECIBOS
daily operation or by batch to the table of MCARGVAR EST_REC
Controlparse miscellaneous charges (cargvar). IMAGENES
/man COBROS_CBC2050 For those records creates a standard bill (Recibos). IMP_CONCEPTO
500
NULL /commit
7 PROCESS Preparing data for parallel billing
FACC1016.pc This process is preparing (divide) services in status ITIFACT_VO CONTROL
IT001 for parallel billing process
Controlparse
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 23
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

/man
FACTUR_FACC1016
NULL
/commit

8 PROCESS Bulk accounts Billing (BA)

Controlparse This process performs a direct billing of BA defined ITIFACT_VO RECIBOS
/man for billing. EST_REC
FACTUR_FACC1006 These are the SP written into the table ITIFACT_VO IMAGENES
NULL in status IT001, having TIP_REC TR230 and HFACTURACION
/commit F_PROC_MIN <= FECHAB. RECIBOS_GS
The process is irreversible with a saving into the IMP_CONCEPTO
database. IMPRIMIR_DATOS
TRABPEND_AF
AN_TRABPEND_AF
ME_TRABPEND_AF
SU_TRABPEND_AF
CS_TRABPEND_AF
CU_TRABPEND_AF
9 PROCESS Elimination of erroneous SPN from billing
Controlparse Program for elimination of erroneous SP from the Sequential file ITIFACT_VO
/man billing process (FACC1003, FACC1002, FACC1001) FACTUR_FACC1001.cd
FACTUR_FACC1999 [ FACTUR_FACC1002.cd,
NULL FACTUR_FACC1003.cd ]
/commit
factur1_3.unx Script for billing start (FACC1003, FACC1002, Program title as parameter in
FACC1001) with condition for elimination of command line.
erroneous SPs and repeated run of program. E.g.:
factur1_3.unx FACC1001

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 24

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.1.3 Collection Processes

Collection processes consist of three parts:
I. Collection updating – inserts the information on collected and non-collected bill to the system, based on the data received from banks, control of remittances
that were sent but still were not returned, although the date for return lapsed, introduction of performed or non-performed
payments.
II. Sending for collection – generation and preparation of bill printing files, generation and preparation of bill data files for accounting in banks (generation of
collection orders)
III. Bad Payers Management– set of individual operations, which are performed in case that the bill is not covered after its due date, records generation to
„imprimir_datos“ for printing (debt reminder, supply disconnection settlement)
IV. Prepayment Transaction Processing – This program retrieves the data in the prepaid system interface table and loads into CMS ready for processing by
the collection batch.

Before the collection updating process:

 the sequential files from the bank institutes and the local application must have been transferred into the system (carried out by System Administration)
 the readings must have been processed

Before making deposits for collection process:

 the billing must have been processed

Before the bad payer management is processed,

 collection must have been updated
 collection deposit process must have been processed

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 25

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Process description:
I.
PROCESS DESCRIPTION PERIODICITY NOTES
Updating collection
1) Reception of payments from the Reception of payments from the local Daily-Batch Window
Local Collection application application of collection
2) Reception of payments from the Reception of payments from the Daily-Batch Window
SISTAFE system SISTAFE system
3) Reception of payments for Direct Processing the file from the bank. Daily-Batch Window
Debit from Bank Processing the collection orders:
 Rejecting the non realised payment
orders.
 Receiving the payments from
customers with direct debit.
4) Receiving of payments for Mobile, All these 3 payments are using the Daily-Batch Window
ATM systems and Payments at Bank unified interface(Payments from different
systems can be received in the same file)
5) Preparing of payments pairing In this process, the records based on Daily-Batch Window
process parameter MAX_PROC_COBRO are
prepared for introduction to the
payments pairing process.
6) Collection update The payments pairing with bills and Daily-Batch Window Parameters for erroneous collection including are in the
budget plans is carried out and the table MODULOS_COBROS.
payments are introduced to the system.
Unpaired payments are introduced to the
erroneous collection module.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 26

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

II.
PROCESS DESCRIPTION PERIODICITY NOTES
Making a deposit for collection

1)Late payments processing When the bill of Low Tension tariff goes Daily-Batch Window
out of due date, system generates the
Late Payment Charge (penalty)
2) Sending for collection Status update, calculation of due dates, Daily-Batch Window
printing groups creation for bills printing.
3)Generation of direct debit For the customers with Direct Debit Monthly-Batch Window
payments collection the bills with debt are selected
and included into new generated file
which should be sent to the bank for
Direct Debit payment.
4)Internal compensation of negative The bills with negative and positive Daily-Batch Window
bills amounts will be compensated
5) Generation of printing outputs Generation of bill printing outputs Daily-Batch Window

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 27

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

III.
PROCESS DESCRIPTION PERIODICITY NOTES
Managing bad payers (Debt
recovery)
1) Managing bad payers Changing statuses with bills unsettled Daily-Batch Window
during the due period and preparing the
sequence of the respective operations
performed in case the bill is not settled
during the due period (requesting for
payment, disconnecting electric power
supply)
Generating service orders concerning
disconnection, inspection, and
instalment plan due date check-ups.
Preparing the request for payment files
and the electric power supply
disconnection notice files.
2) Generating sequential files Generating sequential files to print Daily-Batch Window
notices (debt and disconnection notices).
3) Generating sequential files Generating of notices about bad debt Daily-Batch Window

IV

PROCESS DESCRIPTION PERIODICITY NOTES

Prepayment Transaction Processing
1) Retrieve transactions in the The program picks all the pending Daily or hourly,
prepaid system transactions in the prepaid systems and according to the
loads them in CMS if they have valid parameterisation-
data. Batch Window

Programs description:
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 28
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

I.
Program Description Inputs Outputs
Collection update
1 PROCESS Payments reception from banks for the customers
with direct debit I.
COB_1010_paym_aplicloc.unx Payments reception from the local application of Seq. file with the payments EXTRACTO_BANCARIO
collection I. from bank COBTEMP
Controlparse CENCOBRO GESTIONES_COBRO
/man GESTIONES_COBRO
COBROS_CBC2000 $F /commit EXTRACTO_BANCARIO
2 PROCESS Reception of payments from the SISTAFE system
1) COB_1057_SISTAFE.unx Reception of payments from the SISTAFE system Sequential file from bank EXTRACTO_BANCARIO
CENCOBRO COBTEMP
controlparser GESTIONES_COBRO GESTIONES_COBRO
/man COBROS_SISTAFE EXTRACTO_BANCARIO
$FILEPATH /commit

3 PROCESS Reception of payments for Direct Debit from Bank

1) COB_1056_receive_DD.unx Processing the files from bank. Processing the Sequential file with the payments EXTRACTO_BANCARIO
controlparser collection orders: from direct debit customers or COBTEMP
/man COBROS_PAYM_DDEBIT  Rejecting the non-realised collection orders. with the non realised collection GESTIONES_COBRO
$FILEPATH /commit  Receiving the payments from customers with direct orders.
debit. CENCOBRO
GESTIONES_COBRO
EXTRACTO_BANCARIO
CODIGOS
4 PROCESS Receiving of payments for Mobile, ATM systems and
Payments at Bank
1) COB_1070_receive_BAM.unx Payments for Mobile, ATM systems and Payments at Sequential file with the RECIBOS
Bank are using the unified interface(Payments from payments. EST_REC
controlparser /man different systems can be received in the same file) CENCOBRO CARGVAR
COBROS_PAYM_BAM GESTIONES_COBRO PAGOS
$FILEPATH /commit EXTRACTO_BANCARIO PAGOS_CONCEPTO
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 29
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

CODIGOS IMP_CONCEPTO
5 PROCESS Pairing process parameterisation
1) COB_1100_before_collec.unx The number of records in cobtemp is prepared for the PARAMETROS COBTEMP
pairing process, based on parameter COBTEMP
Controlparse MAX_PROC_COBRO.
/man
COBROS_CBC1300
NULL
/commit
/batch
6 PROCESS Collection update
1) COB_1110_act_collect.unx Payments pairing process GRUPOS_REL, COBERROR
GRUPO_EST RECIBOS
Controlparse PARAMETROS EST_REC
/man MODULOS_COBROS COBTEMP
COBROS_CBC1400 ORDENES CARGVAR
NULL REC_ORD ORDENES
/commit COBERROR REC_ORD,
/batch SUMCON PAGOS
HSUMCON PAGOS_CONCEPTO
CLIENTES IMP_CONCEPTO
CUOTAS_PL
RECIBOS
COBTEMP
REL_NIS_RUTAFOL
PAGOS
IMP_CONCEPTO
PAGOS_CONCEPTO

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 30

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

II.
Program Description Inputs Outputs
Sending for collection
1 PROCESS Late Payment charges generation
1) COB_1800_late_payment.unx When the bill of Low Tension tariff goes out of due RECIBOS CARGVAR
controlparser date, system generates the Late Payment Charge IMP_CONCEPTO
/man COBROS_CBC0800 /commit (penalty) GRUPOS_REL
/batch Also that process performs validation of TAXA DE MTARIFAS
JURO value PARAMETROS
2 PROCESS Sent for collection
1) COB_2040_send_bill_ee.unx The process of sending bills to collection PARAMETROS RECIBOS
controlparser GRUPOS_REL EST_REC
/man COBROS_CBC0100_NORM IMAGENES IMAGENES
NULL /commit /batch FIESTAS_NAC IMPRIMIR_DATOS
DOMICILIACION SEND_QUEUE
CUENTAS_CU
RECIBOS
RECIBOS_GS
SEND_QUEUE
IMP_CONCEPTO
2) COB_2041_send_bill_bulk.unx The process of sending for collection of bills with bulk PARAMETROS RECIBOS
Controlparse account, for standard customers. GRUPOS_REL EST_REC
/man COBROS_CBC0100_BULK IMAGENES IMAGENES
NULL FIESTAS_NAC IMPRIMIR_DATOS
/commit DOMICILIACION SEND_QUEUE
/batch CUENTAS_CU
RECIBOS
RECIBOS_GS
SEND_QUEUE
IMP_CONCEPTO
3) COB_2042_send_bill_hand.unx The process of sending bills to collection based on PARAMETROS RECIBOS
reading routes, which makes possible to distribute GRUPOS_REL EST_REC
controlparser bills by readers. IMAGENES IMAGENES
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 31
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

/man COBROS_CBC0100_HAND FIESTAS_NAC IMPRIMIR_DATOS
NULL /commit DOMICILIACION SEND_QUEUE
CUENTAS_CU
RECIBOS
RECIBOS_GS
SEND_QUEUE
IMP_CONCEPTO

3 PROCESS Remittances extraction

1) COB_2110_send_rem.unx All the bills with debt for Direct Debit are CIERRE Seq. file=collection order
controlparser loaded to the output sequential file which CENCOBRO
/man COBROS_CBC0700 $PATH should be sent to the Bank. CLIENTES
/commit RECIBOS
CUENTAS_CU
DOMICILIACION
GESTIONES_COBRO

4 PROCESS Internal compensation of negative bills

1) COB_2080_compensation.unx The bills with negative and positive amounts RECIBOS RECIBOS
controlparser will be compensated GRUPOS_EST
/man COBROS_CBC1200 /commit
/batch
5 PROCESS Printed reports generation
1) COB_2120_print_fact_normal.unx Generation of bill printing files for normal IMPRIMIR_DATOS IMPRIMIR_DATOS
controlparser clients PARAMETROS Sequential file in the format PCL5
/man COBROS_PRN_FACT_N FORM_DATA
NULL /commit FORM_BODY
FORMS, SUMCON
MENSAJES_FACT
PARAMETROS_MEN_FACT

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 32

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

2) COB_2120_print_fact_special.unx Generation of bill printing files for special IMPRIMIR_DATOS IMPRIMIR_DATOS

controlparser clients PARAMETROS Sequential file in the format PCL5
/man COBROS_PRN_FACT_S FORM_DATA
NULL /commit FORM_BODY
FORMS, SUMCON
MENSAJES_FACT
PARAMETROS_MEN_FACT

III.
Program Description Inputs Outputs
1 PROCESS Bad payers management
1) COB_3010_debt_recover.unx Selection of bills supposed for the process of FECHAB, FUSUARIO RECIBOS
bad payers management (processing based PARAMETROS EST_REC
Controlparse on the parameterisation camb_est, RECIBOS ORDENES
/man camb_est_param.) ORDENES SUMCON
COBROS_CBC3100 REC_ORD ITIFACT_VO
NULL GRUPOS_REL ITIFACT_VO_APA
/commit GRUPO_EST ORDENES_LECT
/batch CAMB_EST CARGVAR
CAMB_EST_PARAM
CAMB_EST_FUNCION_AR
G
CAMB_EST_FUNCION_DEF
UNICOM
PERSONAL
FINCAS
SUMCON
CUENTAS_CU,
ORDENES_LECT
MACUERDOS
CUOTAS_PL
HFACTURACION
APMEDIDA_CO
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 33
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

HAPMEDIDA_CO
2 PROCES Sequential files generation
1) COB_3020_print_debt_normal.unx For normal clients: Generation of printing IMPRIMIR_DATOS IMPRIMIR_DATOS
outputs for debt reminders and FORM_DATA Sequential file in the format PCL5
controlparser disconnection notifications that have to be FORM_BODY
/man COBROS_PRN_DLH_N generated in the process of bad payers’ FORMS
NULL /commit management. SUMCON
PARAMETROS
MENSAJES_FACT
PARAMETROS_MEN_FACT
2) COB_3020_print_debt_special.unx For special clients: Generation of printing IMPRIMIR_DATOS IMPRIMIR_DATOS
outputs for debt reminders and FORM_DATA Sequential file in the format PCL5
controlparser disconnection notifications that have to be FORM_BODY
/man COBROS_PRN_DLH_S NULL generated in the process of bad payers’ FORMS
/commit management. SUMCON
PARAMETROS
MENSAJES_FACT
PARAMETROS_MEN_FACT
3 PROCESS Generating sequential files
1) COB_3030_print_bad_debt_normal For normal clients: Generating of print IMPRIMIR_DATOS IMPRIMIR_DATOS
.unx outputs for bad debts. FORM_DATA Sequential file in format PCL5
FORM_BODY
controlparser FORMS
/man SUMCON
COBROS_PRN_BAD_DEBT_N PARAMETROS
NULL /commit MENSAJES_FACT
PARAMETROS_MEN_FACT
2) COB_3030_print_bad_debt_cpecial For special clients: Generating of print IMPRIMIR_DATOS IMPRIMIR_DATOS
.unx outputs for bad debts. FORM_DATA Sequential file in format PCL5
FORM_BODY
controlparser FORMS
SUMCON
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 34
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Program Description Inputs Outputs

/man PARAMETROS
COBROS_PRN_BAD_DEBT_S MENSAJES_FACT
NULL /commit PARAMETROS_MEN_FACT

IV.
Program Description Inputs Outputs
1 PROCESS Prepayment Transaction Processing
1) SIC_PREPBATCH01.unx The program will attempt to process all data CMSEXPORT PREP_TRANS_LOAD
in the prepaid system interface table PREP_CONC_MAP
Controlparser CMSEXPORT where the exported column is SUMCON
/man equal to 0. CENCOBRO
SIC_PREPBATCH01 GRUPOS_REL
NULL
/commit

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 35

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.1.4 Accounting Interface Processes

Accounting interface processes generate data for company internal accounting system and prepare data for customer balance calculation and balance for the
MIS overview. .
They are divided into 2 basic processes:
Data extraction
Preparing data of a new day

PROCESS DESCRIPTION PERIODICITY NOTES

I. extracting data Daily
II. preparing the accounting period Daily this process runs first before

Before the accounting interface processes are run:

 the bad payer management must have been processed
 all the operations connected with accounting must have been performed

Parameters for running the accounting interface modules are listed in the MODULOS_COBROS table. Monthly day-end process dates are listed in the CIERRE
table. Dates at which the accounting interface modules were run for the last time are listed in the PARAM_FECHAS table.
The activity of data extractor important for accounting interface, customer balance and MIS balance is conditioned by interface parameterisation. Interface
parameterisation is placed in the tables SIE_RECIBO_OPERACION, SIE_OPERACIONES_CONCEPTO, SIE_GRUPO_CONCEPTO, SIE_PARAM_OPER,
SIE_REL_LOGICA, SIE_COST_CENTRES, SIE_PARAM_ALIAS, SIE_ALIAS_OPERACION, SIE_PARAM_ALIAS_ACCOUNT, SIE_ACCOUNT,
BALANCE_PARAM, GRUPOS_REL, REVENUE_CODES, CENCOBRO, and UNICOM.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 36

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

Programs description:

Program Description Inputs Outputs

Accounting Interface - Extracting
I PROCESS
the data
Control of existence of interface
INT_1000_check_ic_files.unx sequential files from the previous ICSE* files
ppase batch in the working file.
1 INT_1010_extr_ic_mi001.unx Extractors of data for Module 1 BDG_MOVIMIENTOS ICSE1100
controlparser /man COBROS_INTC1000 (billing) SIE_ASIENTOS_DET
MI001 /commit
2 INT_1020_extr_ic_mi002.unx Extractors of data for Module 2 BDG_MOVIMIENTOS_OTROS ICSE1200
controlparser /man COBROS_INTC1000 (miscellaneous charges billing now SIE_ASIENTOS_DET
MI002 /commit under module 1)
3 INT_1030_extr_ic_mi003.unx Extractors of data for Module 3 SIE_PAGOS ICSE1300
controlparser /man COBROS_INTC1000 (payments) SIE_ASIENTOS_DET
MI003 /commit
4 INT_1040_extr_ic_mi004.unx Extractors of data for Module 4 (not PRESUNY_PLATIEB ICSE1400
controlparser /man COBROS_INTC1000 in use) SIE_ASIENTOS_DET
MI004 /commit
5 INT_1050_extr_ic_mi005.unx Extractors of data for Module 5 (not SIE_CUOTAS_PL ICSE1500
controlparser /man COBROS_INTC1000 in use) SIE_ASIENTOS_DET
MI005 /commit
6 INT_1060_extr_ic_mi006.unx Extractors of data for Module 6 SIE_COBERROR ICSE1600
controlparser /man COBROS_INTC1000 (Erroneous collections and SIE_ASIENTOS_DET
MI006 /commit resolution)
7 INT_1070_extr_ic_mi007.unx Extractors of data for Module 7 (not AMORTIZA_REC ICSE1700
controlparser /man COBROS_INTC1000 in use) SIE_ASIENTOS_DET
MI007 /commit
8 INT_1080_extr_ic_mi008.unx Extractors of data for Module 8 SIE_MOVCAJA ICSE1800
controlparser /man COBROS_INTC1000 (Banking) SIE_ASIENTOS_DET
MI008 /commit
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 37
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

9 INT_1090_extr_ic_mi009.unx Extractors of data for Module 9 (not SIE_LETRAS ICSE1900

controlparser /man COBROS_INTC1000 in use) SIE_ASIENTOS_DET
MI009 /commit
10 INT_1200_extr_ic_mi010.unx Extractors of data for Module 10 (not EXTRACTO_BANCARIO ICSE2000
controlparser /man COBROS_INTC1000 in use) SIE_ASIENTOS_DET
MI010 /commit
11 INT_1210_sort.unx Merging respective module outputs, ICSE1100 ICSE1010
assigning sentence numbers and ICSE1200 ICSE1010-FECHAB.Z
creating backup sequential files. (not ICSE1300 ICSE1000
in use) ICSE1400
ICSE1500
ICSE1600
ICSE1700
ICSE1800
ICSE1900
ICSE2000
12 INT_1220_sum.unx Summarising output from the SIE_ASIENTOS_DET SIE_ASIENTOS
controlparser/man proceeding batches.
COBROS_INT_LOAD_SIE_ASIEN
"ICSE1010|../tmp" /commit

13 INT_1999_backup_ic_files.unx The process compresses and zips Seq. files ICSE* Backup files“
data from generated ICSE* YYYYMMDD_backup_INT*.
sequential files and back-ups them to tar.gz
the set folder. (not in use)
14 INTC2000.unx Module: Accounting Interface SIE_ASIENTOS SIE_TRANSACTIONS
controlparser /man COBROS_INTC2000 1000 Generating data for accounting PARAM_FECHAS PARAM_FECHAS
/commit /batch interface
15 INTC3000.unx Module: Formatting data into the SIE_TRANSACTIONS FINANCE_REGISTERS
controlparser /man COBROS_INTC3000 1000 accounting system required formats. PARAM_FECHAS PARAM_FECHAS
/commit /batch Handling negative amounts and
CR/DR data columns
16 INTC4000.unx Module: Balance Reconciliation SIE_ASIENTOS_DET BALANCE_ANOMALIES
CUENTAS_CU CUENTAS_CU
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 38
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

controlparser /man COBROS_INTC4000 1000 Comparison of calculated customer RECIBOS

/commit /batch balance based on interface extraction PAGOS
processes with actual customer CARGVAR
balance from operational part of the
database. (Not in use)
17 INT5000.unx Posting Accounting date to the FINANCE_REGISTERS GIAF system’s
controlparser /man COBROS_INTC5000 1000 finance system FINANCE_REGISTERS
/commit /batch
18 BDGC5000.unx Module: MIS Balance SIE_ASIENTOS SIE_ASIENTOS
controlparser /man COBROS_BDGC5000 SIE_OPERACIONES_CONCEPT PARAM_FECHAS
/commit \n O
PARAM_FECHAS
19 INTC2100_XJ200.unx Generation of sequential IMT files for SIE_INTERFACE SIE_INTERFACE
controlparser /man COBROS_INTC2100 XJ200 the purposes of accounting (MOFNE) REVENUE_CODES Seq. files:
/commit (not in use) MOFNE_XJxxx_YYYYMM
DD
20 INTC2100_XJ999.unx Generation of sequential IMT files for SIE_INTERFACE SIE_INTERFACE
controlparser /man COBROS_INTC2100 XJ999 the purposes of accounting (MOFNE) REVENUE_CODES Seq. files:
/commit (not in use) MOFNE_XJxxx_YYYYMM
DD
Accounting Interface – preparing
II PROCESS
the accounting interface
1 INT_2010_periodo_cont.unx Defining the actual date of new sysdate CONTROL
commercial day

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 39

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.2 Operator’s Menu, PPASE Batch process

First of all it is need to connect to server using any SSH client. Recommended under Windows is putty.

a. Connect to Server:
 Start the putty client. You will get the window below:

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 40

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

 Input the IP address of the server in the Host Name (or IP Address) field
 Fill in the fields as below; click on Save (this is keep your settings for another time) then click on Open.

2
1

4 3
5

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 41

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

 Login with username and password (will be invisible even as you type)

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 42

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

b. Selecting your environment

 After login to server, it is required to select working environment. This can be done by command selenv. This command will display a list of
environments installed on server, and will allow to choose one of them. It is recommended to use virtual terminals inside the servr to run the
batch, as sometime client terminal loose conection to batch server, and batch menu is loosed while virtual terminal permit to reconect to it. As
a virtual terminal we recomment to use screen. Screen is a standard utility in RHEL.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 43

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

After selecting for example number 3, all environment will be configured to use cmstrain.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 44

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

a. Next step is to type the command start_batch. You can also change directory to ppase directory using cd, or use the command alias ppase.
From this window you can select the number which defines the environment to run in; 1 – CMSPRE environment, etc.
Run batchmenu.sh. After running batchmenu.sh you will go into batch control program.
From this program it is possible to confiure batch parameters and run batch module or run some specific program.

After the process above, you enter into the MAIN batch window below.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 45

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 46

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

b. To configure batch it is required to select menu point 1. Settings. Here user can change batch date, batch database, batch user.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 47

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

c. To run Batch by modules, in main batch window menu, user should choose option 2

After configuring current date(it should be adjusted each day), the batch can be started. As we said, batch can be run by modules(option 1) or by
individual program(option 2).

Also user can monitor batch process status from option 3 (to monitor batch running status, it is necessary to open second terminal, select the same
environment, run ppase, run start_batch.sh, and select appropriate option).
The batches in production have been put in the cron and hence, will start automatically but monitoring is needed to adress any challenges
that may arise requiring manual inputs.
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 48
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

To run permanent batches it will be necessary to run command start_pbatches. To stop permanent batches it will be necessary to run command
stop_pbatches, in this case permanent batch will wait until current running batch will not finish. Sometime this can take long time.

All batch logs are stored in directory /project/cmstrain/ppase/OPEN_FILES/log_ppase/logs

To see logs it is necessary to select desired environment, and change current directory to indicated one, or to use command alias pplogs. Alternative
way is to access logs by a Browser (Ask CMS administrator to provide to you URL to access ppase logs).

Logs are sorted in directories by batch date.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 49

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.2.1 Operator’s Menu Function Description

The operator’s menu is a program containing respective menu screens, running (by pressing a key) the submenu or the program performing the required
function upon request.

The operator’s menu program is called batchmenu.sh in the system. The main variables necessary for running the operator’s menu and the batch
process are set in the batchmenu.exp file. The database export variables are in the export.exp file. Batchmenu.txt is a configuration text file for the respective
language. These configuration files are located in the conf. subdirectory. The execution scripts are in the subscripts subdirectory.

5.2.2 Detailed Description of Operator’s Menu

Program batchmenu.sh (operator’s menu) consists of the main menu with the following options:

1. Settings
2. Batch
3. System
4. Database
5. Openlink
6. Permanent Batch (can be missing)

1. Settings
This option includes a submenu containing the following functions:
1. Displaying the initialisation parameters - displaying the setting of parameters from ini file
2. Changing of initialisation parameters - modification of parameters of ini file
9. Previous menu - Previous menu
0. Exit - end of operator’s menu

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 50

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

2. Batch
This option includes a submenu containing the following functions:
2. includes the PPASE process running submenu, in which the batch process of the respective modules are run by means of A to X options:
A. Reading 1
B. Reading 2
C. Billing 1
D. Collection 1
E. Collection 2
F. Collection 3
G. Collection 4
I. Interface 1
J. SIC
K. Interface 2
L. Billing 2

Q. MED
R. REP
S. SGI
T. SGT
X. TEST of process PPASE
9. Previous menu - Previous menu
0. Exit - end of operator’s menu

3. Running one BATCH program - running one batch program

4. PPASE monitor - running the text monitor
5. Listing the PPASE report - report list of the entered processed module
6. Listing the output of one BATCH program - output list of the entered processed program
7. Clearing old BACKUP directories -Deleting old files from BACKUP directories
9. Previous menu - Previous menu
0. End - end of operator’s menu

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 51

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

3. System
This option includes a submenu containing the following functions:
1. Listing users having logged in the system - making a list of the users which logged in the system
2. Listing processes - making a list of all processes of the system
3. Stopping user’s processes - stopping all the processes of the entered user
4. Listing free disk space - information on disk space efficiency
5. Operator password change - system password change
6. System shutdown - shutting down the whole system
9. Previous menu - previous menu
0. End - end of operator’s menu

4. Database
This option includes a submenu containing the following functions:
1. Listing users having logged in - listing users having logged in the given database
2. Starting the database... - starting the database
1. Start-up DB (normal) - normal
2. Start-up DB (force) - forced (shutdown abort + start-up)
3. Shutting the database down... - shutting the database down
1. Shutdown DB (normal) - normal
2. Shutdown DB (immediate) - immediate
3. Shutdown DB (abort) - forced
4. Exporting the database - exporting the database
1. Setting the export parameters - setting the data export parameters
2. exporting the database - export according to set parameters
9. Previous menu - previous menu
0. End - end of operator’s menu
In batchmenu.exp set the OS_DBA_USER variable – operating system user from dba group, and the DB_DBA_USER variable database user sysdba.

5. Openlink
This option includes a submenu containing the following functions:
1. Listing current openlinks - making a list of current openlinks
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 52
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

2. Starting the openlink - starting the openlink

3. Stopping the openlink - stopping the openlink
9. Previous menu - previous menu
0. End - end of operator’s menu
6. Permanent Batch
1. Start
2. Stop
3. Status

In the batchmenu.exp, set OPLDIR – directory containing openlink start/stop scripts, UP_OPL, DOWN_OPL - openlink start/stop script.

Before the batchmenu is started, it is necessary to check or set the variables in the batchmenu.exp. Check correct location of the configuration text file
and assignation of its title to the variable TEXT_FILE. The examples of files are listed in the supplement.

5.2.3 Programs in Ppase Directory

DESCRIPTION
Batchmenu.sh Operator’s menu
Batchmenu.exp Setting and exporting the variables necessary for operator’s menu run
Monitor PPASE process monitor
Ppase PPASE process program
Ppasebg PPASE process program
Prgbg PPASE process program
arch_pgm_logs Archiving outputs

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 53

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.2.4 Programs in Subscripts Subdirectory

DESCRIPTION
ini_file.sh Displaying and modification the initial programs
run_ppase_XXX.sh Running the XXXX module processing
run_one_pgm.sh Running one batch program
report_ppase.sh Displaying the ppase report
run_monitor.sh Running monitor
displ_out_pgm.sh Displaying program outputs
displ_con_users.sh Displaying users connected in the system
displ_process.sh Displaying system processes
kill_usr_proc.sh Killing user’s processes
diskfree.sh Displaying free space in the system
ch_passwd.sh Changing system password of the operator
schutd_system.sh Shutting down the system
displ_con_user_db.sh Displaying users connected in the database
st_db_normal.sh Starting the database
st_db_force.sh Starting the database - forced
sh_db_normal.sh Stopping the database
sh_db_immediate.sh Stopping the database immediately
sh_db_abort.sh Stopping the database - abort
displ_run_opl.sh Displaying current openlinks
start_opl.sh Starting the openlink
kill_opl.sh Killing the openlink
set_exp_parms.sh Setting the database export parameters
export_db.sh Database export

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 54

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.2.5 Description of Operator menu – part Batch (PPASE Batch)

The PPASE Batch software provides for regular batch processing in the system. It is run from the operator’s menu. It consists of the PPASE Batch
(ppase) processing management program, the COND file (ppasebg) information processing program, the respective Batch (prgbg) programs running program
and the PPASE Batch (arch_pgm_logs) output and report archiving program.

In the PPASE Batch menu, once the module (collection1, collection2, collection3, billing, interface, readings, reports, customer services (SIC)) has been
selected, the ppase program, controlling the way in which the respective module is being processed and communicating with the operator by means of terminal
message, is run. Then the ppase program runs the ppasebg program, processing the CONDICION file of the respective module and running the respective
Batch programs by means of the prgbg program, as long as the conditions are fulfilled when running them. The prgbg program provides for running the
respective Batch program and processing the return value once it has been terminated. Once all the batch programs of the respective module have been
processed, the ppasebg, ppase program run is terminated.

5.2.6 Detailed Description of PPASE BATCH Process

 INIBATCH – a concrete name of the file is defined in batchmenu.exp. The file is located in the directory $OPEN_BIN and includes the batch initiation
variables of individual modules divided in sections.

 COND.* - file of conditions for processing the respective PPASE Batch module located in the Cond directory

 LOGPROG – file containing statistics of running the Batch programs located in the $OPEN_FILES directory – format : processing_date
Batch_program_name date_and_time_of_running date_and_time_of_terminating return_status – where ”0” means terminated OK and ”1” means
carried out erroneously

 JLOG – file containing information on the current processing status– format: status_of_processing Batch_program_name where status_of_processing
can be:
n – Program is prepared to be run
r – Program is running
o – Program has run correctly
e – An error occurred in the program
S – Program has not run correctly (program has either ended up erroneously and the operator has chosen the restart option or the programs set in
the condition concerning running this program have not run correctly)
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 55
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

 JLOGF – semaphore allowing access to the JLOG file ( null file = access permitted, not null file = access denied)

 LOGPROGF – semaphore allowing access to the LOGPROG file (null file = access permitted, not null file = access denied)

 ALLSTOPF– semaphore showing whether it is necessary to forcedly terminate processing of the PPASE Batch module (null file = processing can run,
not null file = terminate processing)

 FINISHFF – traffic light, indicating that the processing PPASE Batch was done completely, and you can close the program ppase (null file = processing
running, not null file = processing is completed)

 Log files – standard and errors outputs are stored using the files out_*, err_* into the directory $OPEN_FILES/ log_ppase/log.

 Report files – reports from processing of individual modules PASE Batch are stored into the directory $OPEN_FILES/log_ppase/report.

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 56

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.3 Batch Operation IGEA/PENTAHO/EBM

5.3.1 IGEA
Batches will be configured as cron process. Cron will be configured to run each night respecting batch schedule. IGEA batch will run respecting defined
batch window (system schedule is attached as xls object to this file).

5.3.2 PENTAHO
Batches will be configured as cron process. Corn will be configured to run each night respecting batch schedule. IGEA batch will run respecting defined
batch window (system schedule is attached as xls object to this file). It will be necessary to adjust in deep time when this batch will run, as this batch do
mass data extraction, and can have bad side effect on DB server performance, which will affect other systems.

5.3.3 EBM
Batches will be configured as cron process. Corn will be configured to run each night respecting batch schedule. IGEA batch will run respecting defined
batch window (system schedule is attached as xls object to this file).

5.4 Monitoring, Error Checking and troubleshooting

5.4.1 Monitoring

5.4.1.1 CMS
Monitoring of the batch process can be done in many ways. First way is to check if control parser binary is working by finding it in process list with
following command:
ps –ef | grep controlparser
If in output of this command you will see some control parser command, this mean that batch is running
Other way to check is by batchmenu. To check using batchmenu, user have to open new terminal and create new connection, to the same server, select
same environment, and run batchmenu as was described upper. From batch menu user have to select option BATCH, and from Batch option items
have to select item monitor. In this case on terminal will appear the status of the batch processes

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 57

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.4.1.2 IGEA
N/A

5.4.1.3 PENTAHO
N/A

5.4.1.4 EBM
N/A

5.4.2 Error Checking

5.4.2.1 CMS
Error checking can be done by checking each program log. Program logs can be found in log directory (which is grouped by date), in each directory
there will be a folder with module name. Inside there are module execution logs. To see if there was thrown some error in batch process it is need to
open log files and read it, in order to find some abnormal behaviour of the batch program. For example, there should not be present ORA errors, ERROR
of the batch programs, TERMINOMAL word or other strange logs.

5.4.2.1 IGEA
Should be checked log files in order to detect errors. Log files can be accessed by web browser on URL provided by CMS administrators

5.4.2.2 PENTAHO
Should be checked log files in order to detect errors. Log files can be accessed by web browser on URL provided by CMS administrators

5.4.2.3 EBM
Should be checked log files in order to detect errors. Log files can be accessed by web browser on URL provided by CMS administrators

5.4.3 Troubleshooting
Once some abnormal output is detected in log file, CMS responsible should be informed immediately.
In case if there was some error in some module, next module should not be run.
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 58
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

5.4.4 Technical Problems

In case of some technical problems occur, like power outage, connection problem or other problem, which don’t permit to run batch, it is necessary to inform
CMS administrators and CMS responsible about the problem. CMS Administrator will be responsible to manage solving the technical problems with other
administrators, once CMS responsible, will take decision about which batch to run or not to run after technical problem is solved

6 Examples

6.1 Examples of Files

batchmenu.exp
Example:
###########################################################
export BASE_DIR=.
export TMPDIR=/tmp
export S_DIR=${BASE_DIR}/subscripts
export C_DIR=${BASE_DIR}/conf
#
export OPEN_BIN=${SGC_HOME}/tbatch/bin
export INIBATCH=${OPEN_BIN}/OPENBATCH.ini
export OPEN_FILES=${BASE_DIR}/OPEN_FILES
export PPASEBG=ppasebg
export PRGBG=prgbg
export STDERRPREF=OUT/err_
export STDOUTPREF=OUT/out_
export NUM_PARAL_PROC=1
export APLOCLEC_DIR=${SGC_HOME}/TEST
export PRN_OUT=${BASE_DIR}/OUT/PRN
#
export TEXT_FILE=${C_DIR}/batchmenu_SK.txt
# export TEXT_FILE=${C_DIR}/batchmenu_UK.txt
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 59
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

export ARRAY_ASSIG=$TMPDIR/array.${RANDOM}${RANDOM}
export NULL=/dev/null
export TTY=/dev/tty
#
export OS_DBA_USER=dbadmin
export DB_DBA_USER=system
#
export OPLDIR=${SGC_HOME}/openlink/bin
export UP_OPL=UP_Server
export DOWN_OPL=UP_Server
#
export DMPF_PREF=$(date '+%Y%m%d')
export EXP_PARF=$C_DIR/export.exp
#
#
UNIMPLEM=${S_DIR}/unimplemented.sh
#
DISPL_DB=${S_DIR}/displ_DB_user.sh
CH_DB=${S_DIR}/change_DB_user.sh
#
PPASE_LEC1=${S_DIR}/run_ppase_lec1.sh
PPASE_LEC2=${S_DIR}/run_ppase_lec2.sh
PPASE_FAC1=${S_DIR}/run_ppase_fac1.sh
PPASE_FAC2=${S_DIR}/run_ppase_fac2.sh
PPASE_COB1=${S_DIR}/run_ppase_cob1.sh
PPASE_COB2=${S_DIR}/run_ppase_cob2.sh
PPASE_COB3=${S_DIR}/run_ppase_cob3.sh
PPASE_INT=${S_DIR}/run_ppase_int.sh
PPASE_BDG=${S_DIR}/run_ppase_bdg.sh
PPASE_SIC=${S_DIR}/run_ppase_sic.sh
PPASE_SGI=${S_DIR}/run_ppase_sgi.sh
PPASE_SGT=${S_DIR}/run_ppase_sgt.sh
PPASE_MED=${S_DIR}/run_ppase_med.sh
PPASE_REP=${S_DIR}/run_ppase_rep.sh
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 60
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

PPASE_TEST=${S_DIR}/run_ppase_test.sh
RUN_ONE_PGM=${S_DIR}/run_one_pgm.sh
MONITOR_PPASE=${S_DIR}/run_monitor.sh
REPORT_PPASE=${S_DIR}/report_ppase.sh
DISPL_OUT_PGM=${S_DIR}/displ_out_pgm.sh
#
DISPL_CON_USER=${S_DIR}/displ_con_users.sh
DISPL_PROCESS=${S_DIR}/displ_process.sh
KILL_USR_PROC=${S_DIR}/kill_usr_proc.sh
DISKFREE=${S_DIR}/diskfree.sh
CH_PASSWD=${S_DIR}/ch_passwd.sh
SCHUTD_SYSTEM=${S_DIR}/schutd_system.sh
#
DISPL_RUN_OPL=${S_DIR}/displ_run_opl.sh
START_OPL=${S_DIR}/start_opl.sh
KILL_OPL=${S_DIR}/kill_opl.sh
#
DISPL_CON_USER_DB=${S_DIR}/displ_con_user_db.sh
ST_DB_NORMAL=${S_DIR}/st_db_normal.sh
ST_DB_FORCE=${S_DIR}/st_db_force.sh
SH_DB_NORMAL=${S_DIR}/sh_db_normal.sh
SH_DB_IMMEDIATE=${S_DIR}/sh_db_immediate.sh
SH_DB_ABORT=${S_DIR}/sh_db_abort.sh
EXPORT_DB=${S_DIR}/export_db.sh
SET_EXP_PARMS=${S_DIR}/set_exp_parms.sh
#
export DELIMIT='--------------------------------------------------------'
export DELIMIV='--------------------------------------------------- v1.1'
export DELI_SH='---- '
##########################################################

batchmenu.txt
Example:
###########################################################
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 61
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

File contains texts for operator’s menu

1 enter option:
2 bad choice, press <enter>
3 previous menu
4 end
5 end, press <enter>
.. …….
.. …….
##########################################################

INIBATCH
Example:

[DataBase]
Username = open_uBATCH
Password = xxxxxx
DBName = cmsdb

[BatchDate]
Date = 20050513

[SGT]
PRESUP_MIN = 1000
FECHA_ACTUALIZACION = 20050608
FECHA_TRASPASOS = 20050608
FECHA_INICIO = 20050608
PORC_INCREMENTO =2
MES_PERMANEN =3
COD_EMPRESA =4

##########################################################

LOGPROG
Example:
CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 62
REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

##########################################################
20060530 CBC1800 19980531 08:30 20060531 09:03 0
20060530 CBC5100 19980531 09:04 20060531 09:05 0
20060530 CBC1400 19980531 09:05 20060531 09:45 1
##########################################################
CONDITION file
Example:
##########################################################
# COND.TEST
1#PGM00001###
1#PGM00002#PGM00001#$UFE -eq $FB#
1#PGM00003.unx#PGM00001,PGM00002#$UFE -eq $FB,$USA -eq 0 -a $UFE -eq $FB#
##########################################################

JLOG
Example:
##########################################################
o COB_1500_cheque.unx
s COB_1100_before_collec.unx
r COB_1110_act_collect.unx
##########################################################

FECHASPASE
Example:
##########################################################
20050814
20050814
20050815
##########################################################

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 63

REV: MUSTAPHA ASHLEY DATE: 22.08.2016
 OPERATING CMS

CMS v16.08.05

7 Terminology
BATCH program - program providing for a part of data batch processing in the CMS database
CONDICION - files containing conditions for running batch programs according to the
respective modules
Module PPASE - precisely bounded part of data batch processing in the CMS database - (readings1, readings2,
collection1, collection2, collection3, accounting interface, billing1, billing2)
PPASE (PPASE Batch)- - utility providing for data batch processing in the CMS database
- controls normal running of batch programs (according to CONDICION) and their parallel run
Report - final report on processing the respective PPASE module processing
TERMINOBIEN - message on normal termination of a program or a part of it
TERMINOMAL - message on an error in the run of a program or a part of it

CMS Operation Manual.docx PREP: CUSNIR RUSLAN VERSION: 16.08.05 Page 64

REV: MUSTAPHA ASHLEY DATE: 22.08.2016