Money trasnfers

Money transfers from the population have always been one of the most popular services in the postal system. The development of information technology and telecommunications has today made it possible to bring the provision of services to the population to a qualitatively new level. In order to increase the variety of services provided for retail transactions of individuals (transfer of funds, acceptance of utilities, etc.), maintain competitiveness in this market, as well as improve the provision of services based on the use of modern information technologies for the O'ZBEKISTON Joint Stock Company POCHTASI" an Automated Electronic Money Transfer System (PC AS EDP) was developed.

Solvable problems

1. Automation of technological processes for performing operations when providing services to individuals and legal entities for sending, paying for money transfers within the Republic of Uzbekistan in the system of O'ZBEKISTON POCHTASI JSC;

2. Creation and maintenance of a unified information database on money transfers of all postal services of O'ZBEKISTON POCHTASI JSC;

3. Centralized data processing and management of technological processes for providing services to the population and legal entities for money transfers in the system of O'ZBEKISTON POCHTASI JSC;

4. Organization of electronic document flow when providing services for money transfers to individuals and legal entities;

5. Automated accounting and control of transactions related to money transfers;

6. Obtaining operational, accounting and analytical reporting on the status and conduct of transactions related to money transfers.

Composition

According to the hierarchy levels and functional purpose, the AS EDP PC is divided into the following parts:

• Electronic Money Transfer Processing Center.
• Regional level (branches, Post Office).
• District level (District postal center).
• Post office level.

PC "AS EDP" consists of the following subsystems:

Payment Center subsystem

The subsystem is designed to automate the functions of the Electronic Money Transfer Processing Center (EDP Center): managing the Payment Center, receiving EDPs from postal departments, processing them, generating a response to the EDP for the sending department, generating an EDP for the recipient department. In this subsystem, all units admitted to the electronic money transfer system are registered, and these units are also managed. Management functions include functions such as setting a ban on interaction with the Payment Center, regulating the time of receiving/sending payments, monitoring payments (viewing how many payments and for what amount, from which departments it was accepted or sent).

Administrator subsystem

The “Administrator” subsystem is designed to manage the system at the following levels:

• Republican level.
• Regional level.
• District level.

The republican level is supposed to be combined with the EDP CO. At this level, global variables are regulated in the Administrator subsystem. For example, entering and changing tariffs, entering exchange rates, including departments in the system and managing system users at the republican level, etc.

At the regional and district levels, this subsystem manages employees. For example, creating employees, assigning certain roles to them, changing passwords.

Subsystem “Maintaining regulatory and reference documentation”

This subsystem is designed to keep regulatory reference information (RNI) up to date. Reference information refers to reference information, which is determined by departmental regulations and is used in the technological process of providing services for money transfers to the population and legal entities (directory of regions, districts, postal departments, directory of currencies, etc.). When changes are made to the master data, they must be updated from the date of activation.

Operational Day subsystem

The “Operational Day” subsystem is designed to open and close the operating day for PC AS EDP transactions. During the day, as a result of the functioning of the system, various types of data are generated and entered into the system: electronic money transfers, financial documents, transactions, protocols. Some of this data is not needed the next day and its accumulation in the current Database negatively affects system performance. Therefore, such data must be moved to the part of the database that contains data on the history of operations and actions in the system. The process of closing a business day is intended specifically to solve such problems and streamline (regulate) these processes of dividing data into “current” and “historical”. When the day opens, the actions necessary to prepare the system for the new operating day are performed - clearing the daily tables, initializing the opening balance, etc.

Subsystem “Approval and sending of money transfers”

Based on the current state of the corporate data transmission network of O'ZBEKISTON POCHTASI JSC, taking into account the network development trends for the near future, at the first stage of system implementation, postal departments in large cities and regional centers are connected to the EDP AS PC. Information on money transfers (MT) from post offices not connected to the EDP AS will be sent to the nearest units connected to the EDP AS PC in paper form, where it will be entered into the software system by system operators.

If the post office has a data network that allows it to be connected to the AS EDP PC software package, entry, control and sending of DP to the Payment Center will be carried out at the DP reception point.

Subsystem “Reception, payment, delivery, refund”

For post offices that are not connected to the EDP AS PC, DPs are received from the Payment Center at the regional node. For each post office, a statement of receipt of remittances is generated. Based on the results of actions, the DP may end up in one of the following states:

• received by the recipient (paid), in the system this DP status is set to “paid”;
• rejected (incorrect address, etc.), in the system this DP status is set to “rejected”;
• requires forwarding to another post office, in the system this DP status is set to “requires forwarding”;
• the storage period has expired, the status of this DP is set to “expired”;

For each DP, the relevant information about the payment results (feedback) is sent through the Payment Center.

Subsystem “Reporting”

The “Reporting” subsystem is designed for generating reports. Each level of mail departments is provided with its own list of reports. Reports are generated from the current database or from the historical database. It is possible to generate reports from history for all dates for which data is available. If data from the history is transferred to the archive, reports on it are generated in the “System Archive” subsystem.

Payment monitoring subsystem

The “Payment Monitoring” subsystem is designed to analyze and view the status of DP. The state of DP can be considered in various aspects:

• status of an individual DP - where it was entered, at what stage of processing it is, whether payment was made, etc.
• aggregated information - total amounts, number of DPs by periods, post offices, regional nodes, etc.

System Archive subsystem

The information located in the historical part of the Database, after some time, which is regulated by relevant regulations and instructional materials, must be unloaded from the system and stored separately in the form of an archive. However, if necessary, upon request, archived data should be available to obtain the necessary reports on it. At the same time, the archived system data is loaded into a separate schema (archive) in the ORACLE database. In this schema, data is created and updated in the following cases:

When archiving, it is assumed that data will be archived for a certain period (one year), if the standard deadline for placing this data in the system archive has arrived, i.e. the storage period for this data in the “historical part” of the database has expired;

When restoring data from archival storage media in order to obtain reporting information for certain past periods of system operation. Thus, the “System Archive” subsystem is designed to work with the “archive schema” of the Database when generating reporting information on data that, according to standard storage periods, was uploaded to the system archive.