Download Migration from a 2-tier to 3-tier web application of NEWRUTF

INTERNATIONAL MASTERS
IN INFORMATION TECHNOLOGY
IMIT 4TH EDITION
2007-2008
Migration from a 2-tier to 3-tier web
application of NEWRUTF
(tax management software)
By: Sachin G. Singhal
In partnership with:
ALTRAN ITALIA S.p.A.
Corso Sempione, 66/68
20154 Milano, Italy
Company Tutors:
Alessandro Fontana
Consultant- Altran Italia
Davide Raimondi
Senior Consultant-Altran Italia
1
TABLE OF CONTENTS
Chapter 1: Introduction ................................................................................................................. 4
1.1 Company Overview (Altran Italia):.....................................................................................................4
1.2 Client Overview:...................................................................................................................................4
1.3 Project Statement:.................................................................................................................................4
1.3.1 Advantages of the above mentioned Project: ..............................................................................5
Chapter 2: Background of the existing system related to natural gas market ...................... 6
2.1 Overview of Italian natural gas consumption tax system: .................................................................6
2.2 Introduction of the existing system: ....................................................................................................6
2.3 Objectives of the existing system:.......................................................................................................7
2.4 Functional behavior of the existing system: .......................................................................................9
2.4.1 Functional representation of the existing system: ..................................................................... 11
Chapter 3: Description of the new system ................................................................................. 14
3.1 Introduction of the new system: ........................................................................................................14
3.2 Tasks performed by the new system:.................................................................................................14
3.3 Functional representation of the new system:...................................................................................14
3.4 Logical Building blocks of the new system:.....................................................................................16
3.4.1 The Presentation Layer: ..............................................................................................................17
3.4.2 The Business Rules Layer...........................................................................................................17
3.4.3 The Data Access Layer: ..............................................................................................................17
3.4.4 The Database Layer:....................................................................................................................17
3.5 Business Logic: design considerations..............................................................................................17
3.6 PROS of the design of our system:....................................................................................................19
3.7 CONS of the design of our system:...................................................................................................19
3.8 Conclusion: .........................................................................................................................................19
Chapter 4: Results and future work........................................................................................... 20
4.1 Results: ................................................................................................................................................20
4.2 Future work:........................................................................................................................................20
2
ACKNOWLEDGEMENTS
It is with pride that I dedicate my work to my Parents and I want to thank them for standing and
supporting me in every phase of my life.
I would like to take this golden opportunity to thank the dedicated Professors of Scuola Superiore
Sant’Anna for their continuous motivation, dedication and support.
I would also like to thank the senior faculty of Sant’Anna for organizing this fully sponsored masters
course which gave me a wonderful platform to enhance my knowledge.
I would like to thank all the Professors of the university, my tutor, and the staff members for their
continuous help and support throughout the Masters course.
My sincere thanks to Altran Italia, who helped me in completing my stage in their dynamic work
environment. I really appreciate the efforts put by the company to give me a platform where I could
learn new skills and at the same time enhance my existing skill set.
My special thanks to my tutor Alessandro Fontana, for guiding me in each and every step of my
project, for creating a wonderful atmosphere for me to work and last but not the least for taking pain, in
translating every single Italian word into English which really helped me in achieving my goals.
I would also like to thank my Team Leader Davide Raimondi, my business manager Andrea Camargo
and my whole team in Altran for their continuous motivation and support.
3
Chapter 1: Introduction
1.1 Company Overview (Altran Italia):
Created in 1982 in France, Altran is today the European leader in innovation consulting. Built on an
original model, then decentralized to give free rein to initiative, Altran assists its clients at every stage
of the innovation cycle in three complementary fields:



Technology and innovation consulting (accounting for nearly half the turnover).
Organization and information systems consulting (a third of the turnover).
Strategy and management consulting.
Altran Italia was born in 1996 and actually it is present in a lot of part of the national territory,
occupying over 2300 engineers.
My project was based in the Italian Gas And Energy domain with some part also related to the Italian
Taxation system in the Gas and Energy market.
The project was for one of the prominent clients of Altran Italia.
1.2 Client Overview :
The client is one of Italy’s top energy companies, with operations in the procurement, production and
sale of electric power and natural gas.
In the last few years, it has realized itself as one of the most important energy investments’ plans all
over Europe. It aims to consolidate its role of leader operator into energy field, thanks to the
development of new infrastructures of European relevance into gas field and innovative costumers’
services.
It has an electric energy share of nearly the 17% of the Italian production market and the 20% of the
sales market addressed to companies. It, thanks to 7.000 MW of new highly efficient and compatible
plants, has now a total installed capacity of more than 12.000 MW.
1.3 Project Statement:
The project is basically a migration/development project which involves the merger of several different
2-tier architecture applications into a new single 3 tier web application.
The migration basically involves the merger of two applications in Gas domain and 1 application in
Electric domain into a single web application. The current applications are build around the 2 tier
architecture with the front end being in Oracle forms for the Gas application and GUPTA technologies
in case of the Electric application. The back end in either case is in Oracle 9i. The business logic is
partially stored in the front end (especially for the Electric application) while the major part of it is
stored in the database based on the Stored Procedures, Triggers, etc.
The new application will be a single 3 tier web application which will be hosted on the IIS server and
the front end will be in ASP.NET which is built around the latest dot net framework version 3.5.
The back end remains the same but the business logic will be completely transferred from the front end
4
of the Oracle forms to the back end.
1.3.1 Advantages of the above mentioned Project:
The new web application will boost about the following advantages:




The generic scalability advantage of the web applications. At any point of time, the application
can be made available to a lot of additional users.
The web application is built in such a way that it is almost completely independent of the back
end. Because of this loose coupling between the front end and back end any changes in the
business logic or the database wont effect the front end. Actually the layer between front end
and back end (IoDAO library) supports Oracle Database as well as SQL server.
The web application helps in solving release management problems. The new releases are easy
to deploy. For e.g. In the existing application, whenever the client used to open the application,
the application used to compare its version with the version from the database.
If the version is different, then an upgrade would be carried out. But, during the upgrade there
can be potential problems like connection time out ,etc . And moreover every client would have
to undergo the same tedious procedure to get the latest version of the application.
The solution to the above problem is a web application. Any new release can be directly
deployed on the server and all clients would be able to see the latest version of the application.
And last but not the least, web applications are always flexible in nature. This helps to keep the
application updated amidst the changing Italian laws for the calculation of the taxes.
For e.g.: In the existing application, it was not possible to select the fiscal year. Only the details
of the current fiscal year were visible. Whereas in the web application, its very simple to display
data of different fiscal year since it can be shown as a menu tree which is made in XML.
Building the same menu tree would have taken considerable effort in Oracle forms.
Apart from the above mentioned advantages, Altran will be benefited by this web application since it
can target other Major Gas industries in Italy.
5
Chapter 2: Background of the existing system
related to natural gas market
2.1 Overview of Italian natural gas consumption tax system:
To understand the contents of the project, its necessary to have at least a basic understanding of the
Italian consumption tax system.
This chapter describes the natural gas consumption tax system because I worked mainly on the gas
sector of the application.
A brief overview about the Italian natural gas taxation system is as follows:
The Ministry of Finance, through the “Agenzia delle Dogane” (one of the five Italian Fiscal Agencies),
requires from the manufacturers and distributors of natural gas, the annual presentation of a series of
"Explanations of consumption", containing the necessary data for purpose of fees (calculating the duty)
and regional tax (determination of Additional regional taxes) and a periodic statement concerning the
usage (industrial uses, automotive, production and self electricity and exempted uses). The statements
must be submitted in January , February or March of the year following the competence of the data,
while the declaration of the list of customers facilitated is done periodically at the request of UTF of
competence.
For the production of UTF accounts data are required various kinds relating to:





Definition of tax warehouses (e.g. code duty).
Production of methane gas and / or purchased from other suppliers.
Amount of methane gas extracted without payment of duty.
Billing adjustments.
Tax rates applied to the calculation of consumption taxes.
2.2 Introduction of the existing system:
As described earlier, the existing systems are built around the 2 tier architecture. These systems are
mainly divided into two different sectors. 2 applications for the Gas domain and 1 application for the
Electric Domain.
The existing systems are built around the 2 tier architecture with the front end being in Oracle Forms
and back end being in Oracle 9i.
The Italian tax system consists of the below described 3 vital terms:

Deposito Fiscale (Filing tax) : Each entity that is directly supplying the product methane gas to
consumers, and is uniquely identified on a national scale by a Code excise, given by Finance
competent technician.
In general, tax deposits of interest to the application can be divided into two groups:
- Metanodotti owned by the Client Group
6
-
Clienti vettoriati (ex – clienti SNAM)

Technical Department of Finance (UTF): It is the body by the ”Agenzia delle Dogane” to
collect statements of annual consumption for calculating the methane and other taxes.
Rendiconto UTF: This term is used indiscriminately as a synonym for "declaration annual
consumption of natural gas."
Accisa: Italian term used as synonym for “consumption tax”


2.3 Objectives of the existing system:
Both the existing application and the new application are built considering the below objectives.
The primary objectives of the application are:
o to generate the consumption tax report (both to file .DIC and paper format report) that must be
produced annually for each ”Deposito Fiscale” and delivered both to all responsible UTF and
to “Agenzia delle Dogane”
o to calculate the monthly payments to be paid for each province .
o to generate the client registry report that must be produced monthly for each ”Deposito
Fiscale” and delivered to all responsible UTF.
This consumption tax report contains data necessary for the calculation and payment of four chapters of
consumption tax:
7




National consumption tax 1412 (Automotive): It is the tax applicable for automotive uses that
must be paid for methane turnover and / or used.
National consumption tax 1421 (Combustion): This chapter includes all taxes / fees for
combustion uses, that is to be paid for methane turnover and / or used.
Additional regional (only for regions with ordinary statute): It is the regional tax that must
be paid for methane turnover and / or used.
Substitutive tax: It is a particular regional tax that must be paid for methane used by special
customers (e.g. embassies, NATO departments, etc) without payment of duty to the central
government.
The report consists of a series of prospectuses or sections, whose layout is described in the
Circular No 181 / D of 30/08/1999 of the Ministry of Finance. Let's see what these sections are:
1.
2.
3.
4.
Title.
Prospectus for methane introduced in filing tax. (section A) .
Prospectus for methane extracted from filing tax (section B).
Prospectus for methane bought by the company or filing tax with monthly and annual details
(section C).
5. Prospectus for methane sold to wholesalers or final customers with monthly and annual details
(Section D)
6. Prospectus for amount of methane billed free from national taxes (one for each province where the
delivery took place) with monthly and annual details (Section E)
7. Prospectus for amount of methane billed with payment of regional taxes (one for each province
where the delivery took place) with monthly and annual details (Section F)
8. Prospectus for amount of methane billed with payment of national taxes (one for each province
where the delivery took place) with monthly and annual details (Section G)
9. Prospectus for billing adjustments (Section H)
10. Prospectus for amount of methane billed with payment of national taxes (one for each province
where the delivery took place) with the detail of the rate used in billing process and of the amount
of money collected by filing tax (Section I)
11. Prospectus for the summary and balance duty, containing also the amounts of accrued monthly due
to the Central Government (Section L).
12. Prospectus for amount of methane billed with payment of regional taxes (one for each province
where the delivery took place) with the detail of the rate used in billing process and of the amount
of money collected by filing tax (Section M)
13. Prospectus for the summary and balance duty, containing also the amounts of accrued monthly due
to the local Government (Section N).
14. Prospectus for amount of methane billed with payment of substitutive tax (one for each province
where the delivery took place) with the detail of the rate used in billing process and of the amount
of money collected by filing tax (Section O)
15. Prospectus for the summary and balance duty, containing also the amounts of accrued monthly due
to the local Government and free from national taxes (Section P).
16. List of customers facilitated in the provision of expertise in the declaration.
8
2.4 Functional behavior of the existing system:
The below diagram describes about the functional behavior of the existing system:
As seen from the below diagram the RUTF application interacts with lot of other systems to produce
the tax reports. The main outputs of the system are as follows:






Annual consumption tax paper format report related to Gas Sector
Annual gas consumption tax report in electronic format: .DIC file to be used both by the
software (“Software Gas Naturale”) provided by UTF and to the telematic transfer of the data to
the Agenzia delle Dogane
Annual consumption tax paper format report related to Electric sector
Annual electric power consumption tax report in electronic format: .DIC file for Electric sector
to be used both by the software (“Software Energia”) provided by UTF and to the telematic
transfer of the data to the Agenzia delle Dogane
Monthly report for gas market containing data of clients who make facilitated uses of methane
gas.
Monthly report for electric market containing personal data of clients of company who have to
pay tax.
In order to produce the above output, the system receives the Registry data(Anagrafic data)and billing
data from SicomGas, SicomSel, SAP ISU, and NETA which are the billing and invoicing system used
by the client. It also receives the registry data (information about customers) from New CRM system.
Data are transferred in various different formats and using different technology solutions.
For e.g. The registry data is transferred from Sicomgas by use of ORACLE trigger whereas from NETA
system its done using an excel file.
Similarly, for transferring billing data, SAP-ISU and NETA system produce .CVS files which is then
transferred using the SQL Loader. Also, from SicomGas, SicomSel the data is transferred based on the
Oracle stored procedures.
With the help of the above received data, the system computes the desired outputs as mentioned above.
9
10
2.4.1 Functional representation of the existing system:
The existing applications can also be depicted as shown in the below diagram:

For Gas Sector:
AS IS – Mapping application area Gas
Billinginformationfor the AnnualStatement
of Society 1
Sicomgas
Society 1
Data for monthlyreport
of Society 1
Alliances
Data for the Annual
Declarationof other
companies/ DepositsTax
RUTF gas
Society 1.
Billinginformation
for the Annual
Statement
Sicomgas
Society 2
Data for monthly
report
RUTF gas
Society 2
NETA
Data for monthly
report(1excel)
Data for annual
statements( “ CVS file +1
excel)
As seen from the above diagram, all the billing information are provided to the RUTF gas system by
the SicomGas instance of Society 1., SicomGas instance of Society 2 and NETA systems. These data
also include the data for monthly and annual reports.
The data format of the transferred file is of type .cvs or excel.
11
The same scenario can be seen in the electric sector as well:

For Electric Sector:
AS IS – Mapping application area Electricity
Billing information
for the Annual
Statement
SicomSel
Data for monthly
report( 1 CVS file)
SicomSel
Modulo Bilancio
SAP IS-U
Data for annual
report
(1 CVS file)
New CRM
Data for mothly
report ( 1 CVS file)
The SicomSel Module actually used for the annual and monthly report, named Bilancio, receives data
from various systems like SicomSel, SAP-ISU and New CRM. Data from SicomSel Billing system,
used for the annual report, are directly selected by the computation Engine of “Bilancio”,
while data from other system are actually uploaded to “Bilancio”with .cvs file format using
SQL*Loader
The actors involved in the entire process are summarized in the below diagram:
12
AS IS – Attori coinvolti
RUTF gas
Society 1
Alliances
Annual Statement of
gas companies other
than Society 1 and
Society 2
Area Gas
RUTF gas
Society 2
Ufficio RUTF
Declaration of annual and
monthly statements for
gas Society 1 and
Society 2.
Declaration of Electrical
annual and monthly
statements for Society 1
and Alliances
SicomSel
Modulo Bilancio
Area Energia
13
Chapter 3: Description of the new system
3.1 Introduction of the new system:
The new system is a 3 tier web application which is hosted on the IIS server and the front end is build
around the latest Dot net framework version 3.5 and the back end is in Oracle 9i.
The application is powered with the AJAX Control toolkit which enhances the look and feel of the
application. Moreover, Crystal Reports is used along with the application to deliver efficient and
customized reports in different formats (e.g. PDF formats) to the clients.
The entire front end is build in ASP.NET which servers as the presentation layer, the back end consists
of tables, stored procedures, triggers, views etc written in PL-SQL in Oracle 9i.
3.2 Tasks performed by the new system:
The major tasks performed by the new system are as follows:
 It incorporates functionalities of both Gas and Electric Sector.
 It provides the basis for calculation and amount on the following taxes:
- Accise erariali (national consumption taxes)
- Addizionali Regionali (Regional consumption taxes)
- Imposte sostitutive (taxes that might be given to local government and not central
government based on the type of consumption and related to special customers such as
embassies)
 Ensures integration with existing data systems of Client (such as the custom billing system
SicomGas).
 It allows the creation of statement for UTF in printed format and in electronic format stipulated
by the regulations.
 Allows for management of integrated data that are currently available only in paper format.
 It allows the adjustment of monthly installments during the year.
 Manages the history of statements which allows automatic retrieval of data of earlier
statements in the calculation of new accounts
 It allows the inclusion of new provinces acquired during the year
 It allows the inclusion of new types of consumption taxes and new rates (aliquote) defined
during the year
3.3 Functional representation of the new system:
The functional representation of the new system is as shown in the below diagram.
As shown in the below diagram, there is one single Application which is formed as the result of the
integration of couple of applications in Gas and Energy Sector.
The billing information for the Gas domain will be received from the Sicomgas instance of Society 1,
the SicomGas instance of Society 2, and from some other Alliances (manual input).
Similarly, for the Electric domain the data is received from SicomSel and NewCRM.
14
TO BE – Mapping Application
Sicomgas
Society 1
Billing information for the
annual and monthly reports of
Society 1
Billing information for the annual
and monthly reports of Society 2
Sicomgas
Society 2
Data for the declaration of
Annual tax for other
companies
Alliances
Billing information in electric
domain for the annual and
monthly tax reports
.
SicomSel
Billing information in Electric
domain for annual
declaration.
New RUTF
Gas &
Power
-U
SAP IS
Data in gas domain for the
annual and monthly tax
reports
NETA
Data for the electric
monthly report
New CRM
The actors involved in the transition of the above application is shown in the below diagram:
15
TO BE – Attori coinvolti
Alliances
Annual Statement of
gas companies other
than Society 1 and
Society 2
Area Gas
New RUTF
Gas &
Power
Ufficio RUTF
Declarationof annual and
monthly statements for
gas Society 1 and
Society 2.
Area Energia
Declaration of Annual
and monthly statements
for Society 1 and
alliances
3.4 Logical Building blocks of the new system:
The logical building blocks of the 3 tier web applications are as
follows:
16
3.4.1 The Presentation Layer:
Also called as the client layer comprises of components that are dedicated to presenting the data to the
user. For example: Windows/Web Forms and buttons, edit boxes, text boxes, labels, grids, etc.
In our application, the presentation layer is completely made in ASP.NET, HTML, JavaScript, CSS,
AJAX Tool Kit etc.
3.4.2 The Business Rules Layer :
This layer encapsulates the Business rules or the business logic of the encapsulations. In our
application, this act as a thin layer since most of the logic is concentrated on the back end.
3.4.3 The Data Access Layer:
This layer comprises of components that help in accessing the Database. This layer provides a level of
abstraction for the database structures. The changes made to the database, tables, etc do not effect the
rest of the application because of the Data Access layer. The different application layers send the data
requests to this layer and receive the response from this layer.
The database is not accessed directly from any other layer/component. Hence the table names, field
names are not hard coded anywhere else. This layer may also access any other services that may
provide it with data, for instance Active Directory, Services etc. Having this layer also provides an
additional layer of security for the database. As the other layers do not need to know the database
credentials, connect strings and so on.
In our application, this layer is exclusively built using the Reflection and run time meta data properties
of Dot Net. Incorporation of the Data access layer provides all the above mentioned benefits.
3.4.4 The Database Layer:
This layer comprises of the Database Components such as DB Files, Tables, Views, etc. The Actual
database could be created using SQL Server, Oracle, Flat files, etc.
The application is implemented in such a way that there are some characteristics which make it
independent of the actual Database. For instance, you could change the Database Location with
minimal changes to Data Access Layer. The rest of the Application should remain unaffected.
3.5 Business Logic: design considerations
The new system closely resembles the general 3 tier web application architecture. The system includes
the Presentation Layer, Data Access layer and Database Layer. But the system does not include any
separate business rules layer. This layer is not included in our system because all the business logic is
concentrated in the database layer itself.
In our application, there is a tight coupling between the database and the business logic. This tight
coupling is due to the fact that the business logic is completely stored on the database. So there is a
very high dependency between these two. If suppose in future, the data is migrated to another database
like SQL Server, the application developers will have to rewrite the entire business logic. This makes
the application dependent.
17
But at the same time, very less changes would be required in the front end since the data access layer is
designed in such a way that it can support different Databases. So minimal changes would be required
in terms of access logic and front end. This feature makes the application independent to some extent.
The different design solutions are represented in the below figures:
Reques t
Document
Application Server with
Business Logic
Browser
Database Server without
Business Logic
Figure 1: Design Solution with business logic on Application Server
Reques t
Document
Browser
Application Server without
Business Logic
Database Server with
Business Logic
Figure 2: Design Solution with business logic on Database Server
In our application, we have implemented the layout described in Figure 2.
The main reason behind choosing such a design pattern is because of the following reasons:
-
The business logic contains lot of code which is concentric on the Oracle database. Moving
it into a separate layer can itself be a huge and a complex task.
-
Secondly, due to strict timing constraints it was not feasible to move the logic into a separate
layer since more time would have been consumed in development and testing phases.
Because of the above mentioned reasons, it was decided by the application designers to go forward
with a 3 layer design pattern instead of a general 4 layer design.
18
3.6 PROS of the design of our system:
-
Development Time: Significant reduction of time during development phase.
-
Complexity: Less complexity involved during migration.
-
Testing Time: No additional time required for testing since the existing logic is already
tested and running.
-
Performance: As per Oracle, it is advisable to keep the business logic as close as possible
to the database. This is because ,if the business logic is kept on a separate layer, like
application server and the application contains millions of records then it will be very much
costly and time consuming to transfer data to and fro from the database and the application
server. Since our application was designed considering the future scalability, the business
logic is kept close to the database which results in a better performance.
-
Scalability: Since the application does not have a separate business logic layer, the
application server need not be powerful. Then entire computation power can be given to the
database server since the logic resides over there. Due to this, the application server can
even reside on the same database server. This design improves vertical scalability but
reduces horizontal scalability.
3.7 CONS of the design of our system:
-
Flexibility: Due to the absence of a separate business rules layer, the system is less flexible
in incorporating new changes in the business logic. Any major changes in the business logic
will result in changes to the other layers too. This reduces the flexibility of the application.
-
Tight Coupling: Absence of business rules layer causes a tight coupling between the
database and the business logic. For e.g. If suppose the database is migrated to another
database like SQL Server, the application developers will have to write the entire business
logic from scratch.
-
Scalability: Since the application does not have a separate business layer, the computation
power of the application server cannot be increased. That is multiple application servers
cannot be added to increase the computational power of the system. The selection of the
current design hampers the horizontal scalability.
-
Algorithm Compatibility: It could be much simpler to develop some algorithms in OO
languages than in PL-SQL, But, the Business Logic of NEWRUTF doesn’t require complex
algorithms. Keeping this fact in mind, the business logic was developed in PL-SQL .
3.8 Conclusion:
Although layers are good and they are also loosely coupled to minimize impact to other layers, too
much of loose coupling can also increase the complexity of the system and will affect the opacity (i.e.
the code becomes difficult to understand) . Hence the application designers decided to go for a middle
approach where the application can take advantages of the layers and at the same time can help in
19
reducing the complexity of the entire system. However, in future, if the need arises the application
designers might even try to move the business logic into a separate layer.
Chapter 4: Results and future work
4.1 Results:
We have successfully completed the first phase of the migration . The first phase involved the
migration of the data that helps in the calculation of the monthly tax reports in the gas and energy
sector. I actively contributed in the development of most of the web pages/reports that are used for the
production of the monthly report.
The web site is ready and hosted on the server. The clients can view all the data related to the Anagrafic
framework(i.e. Personal data about the companies like name, identification, location, codes, etc)
The various reports and monthly reports are also available from the website.
The functionality actually implemented and accessibly by users are:
o Access to registry data (e.g., the list of Italian consumption tax and rate values, the list of
existing Italian district and so on).
o The production of the monthly report for gas market.
o The production of the monthly report for electric market.
o The computation of the proposed amount of money that monthly the company has to pay to
central government and local government.
o The accounting of the payment.
4.2 Future work:
The 2nd major part of the migration is for billing information which used for annual consumption tax
reports.
This is expected to be completed by end of November 2008.
Once this is done, the migration project will be completed.
Plans are also made to incorporate an existing system NewLogas/ProLogas, application actually used
by the client for logistic and forecast purpose, to merge with the web application. This applications can
send useful data for the computation of some framework of the annual report that don’t contain data
strictly connected to invoicing and billing.
20
TO BE – Mapping Application: Future Scenario
Sicomgas
Society 1
Billing information for the
annual and monthly reports of
Society 1
Billing information for the
annual and monthly reports of
Society 2
Sicomgas
Society 2
Data for the declaration of
Annual tax for other
companies
Alliances
Data introduced, extracted
and sold by the filing tax.
New Logas/
Pro Logas
New RUTF
Gas &
Power
Billing information in Electric
domain for annual
declaration.
-U
SAP IS
Data for the electric
monthly report
New CRM
21