View Source

This article in Russian: Миграция абонентов в Гидру версии 6.2+

General information

Customers are migrated to Hydra from other billing systems via an intermediate set of tables (intermediate data schema) represented by CSV files:

Customers data is exported from the old billing system in the intermediate schema format.
The resulting files are uploaded to the data migration application.
Various automated checks are performed to verify the correctness and integrity of the data.
The exported reference table records are compared with similar Hydra references.
Additional automated checks are performed to verify data correctness, taking into account the reference tables mappings.
Customers are imported to Hydra.

To debug the process of data export and the migration itself, all work is first performed iteratively on a test instance of Hydra:

The data dump is formed and a trial migration to the test Hydra is performed.
The results of the trial migration are being checked together (both teams involved):
- Reconciliation of aggregate indicators in reports;
- Selective reconciliation of individual customers with the original data in the old billing system;
- Identification of missing billing or technical details of customers for integrations and AAA;
- Detection of inconsistencies in price plans and services configured in Hydra: prices, service providing schemes, services availability for different groups of customers.
As many discrepancies and errors as possible are fixed:
- The data in the old billing is being corrected;
- Data export scripts are adjusted;
- Price plans and services are created and adjusted in the main instance of Hydra;
- Data migration application settings and workflow are being changed.
The Hydra test instance is reloaded with a snapshot of the data from the main one, a new data export from the old billing is formed, and the process repeats.
When the result of the trial migration is considered as good enough for going live, the process is repeated on the main Hydra instance.

Data format

Each table is exported to a separate CSV file, the name of which is identical to the table's one.
UTF-8 encoding is used for text.
Fields (columns) are separated by semicolons — ;
All field values are enclosed in double quotation marks — "
The first row is a header, i.e. it contains the names of the table fields (columns).
Line feed characters (LF, \n) are not allowed in field values.
- If a line break is necessary in a value (for example, for a comment in the REMARK column), it must be represented by a unique character, such as ¶ (pilcrow sign).
Primary keys (ID fields) and foreign keys (*_ID fields) are natural (positive integer) numbers.
All data files are packed into a combined ZIP archive.
- The archive must contain only CSV data files, with no directories or extraneous files.
- The archive must contain files for all tables of the intermediate schema. Tables are optional only in terms of their content, but a file with a header row must always be present.
For values of Date and DateTime types (fields *_DATE except BILLING_DATE), two formats are allowed:
- With time: DD.MM.YYYY HH24:MM:SS (in Oracle database terms), for example, 12.04.1961 09:07:00. The time part can be specified without minutes or seconds: missing data is considered to be zero.
- Without time: DD.MM.YYYY (in Oracle database terms), for example, 12.04.1961. In this case, the time part is considered to be midnight.
The decimal separator for numerical values is a period. For example, if the balance of a customer account is 123 dollars and 45 cents, the value should be 123.45 (in the BALANCE column of the ACCOUNTS table).

Examples

Archive with a complete set of files containing only header lines with no data:
Use this archive as a template for data export

Sample content of the ACCOUNTS.csv file for the ACCOUNTS table:

"ID";"CUSTOMER_ID";"ACCOUNT_NUMBER";"ACCOUNT_TYPE_ID";"CURRENCY_ID";"BANK_ID";"BALANCE";"CREDIT";"CREDIT_END_DATE";"BALANCE_DATE";"REMARK"
"10";"1";"14170";"1";"643";"";"802.00";"";"";"29.02.2024 23:59:59";""
"11";"1";"14170★";"3";"999";"";"560";"";"";"29.02.2024 23:59:59";"Opened upon signing the contract.Bonuses may only be redeemed with the consent of Bilbo Baggins."¶

Archive with simplified data export, including only the basic data set:
Archive with an advanced data export, including optional tables and fields:

Simplifications and assumptions of the migration process

Organizations and individuals are located in a common CUSTOMERS table and are distinguished by the value of the ORGANIZATION field.
Only Name, Legal form, and Tax ID are migrated for organizations by default.
The charges history migrates “as is” in the form of archived charge logs.
For current billing periods, during migration, charge logs are generated by Hydra core, based on configured service providing schemes and price specifications, taking into account exported start dates of billing periods and subscriptions to services.
- The volume of traffic services consumed in the current period, e.g. "megabytes" of Internet traffic or “minutes” of telephony services — does not migrate.
Price plans, services, and their features: frequency, quotas, prices, bandwidth policies — are not migrated. These settings are configured manually in Hydra beforehand and then mapped to the exported list (PRODUCTS table).
The internal identifiers of migrated entities in Hydra will differ from the exported ones. However, the correspondence between the exported and resulting identifiers during migration is stored in Hydra database for further processing.

Intermediate data schema tables

To better understand the relationships of the tables, we recommend that you check the ER diagram of the intermediate data schema.

ID columns are primary keys of tables: their values must be unique within the table.
*_ID columns are foreign keys of tables, references to records in other tables. Ensure their integrity:
- The export should not contain references to non-existent records.
  For example, the CONTRACTS table can't have contracts for customers who are not in CUSTOMERS table. If a particular customer is excluded from the export for some reason, there should be no data about them in any tables.
- References within the same record should not contradict each other.
  For example, in the SUBSCRIPTIONS table, references to the contract (CONTRACT_ID column) and customer account (ACCOUNT_ID column) are mandatory — these contract and account must belong to the same customer.

Mandatory tables and columns in the following description are marked with a icon.

Tables and columns that can be left blank to simplify export are marked with a icon.

By agreement, additional tables and extra columns of standard tables can be added to the schema.

Reference tables

This section lists tables whose data is not migrated but is used to map reference records of the source system with similar records in Hydra.

If the names in the export and in Hydra match, the entries correspondence can be automatically set by the data migration application.

Correspondences are preserved between migration iterations if the identifiers and names of records do not change.

ACCOUNT_TYPES — types of accounts

At least customer accounts are required for the ACCOUNTS table.

Column	Description
ID	Account type identifier.
NAME	Account type name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → Account types.

Examples: Customer account, Settlement (current) account.

AUTH_DOC_TYPES — types of identity documents

Leave the table blank if you are not exporting the identity details of individual customers.

Column	Description
ID	Document type identifier.
NAME	Document type name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → ID types.

Examples: Passport, Driving license.

BANKS — banks of settlement accounts and payment sources

Leave the table blank if you are not exporting settlement (current) accounts и payments history.

Column	Description
ID	Bank identifier.
NAME	Bank name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Banks.

Examples: NatWest International, Stripe, PayPal.

COMMENT_TYPES — types of comments

Leave the table blank if you are not exporting extended comments to customers or to their equipment.

Column	Description
ID	Comment type identifier.
NAME	Comment type name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → Comment types.

Examples: Technical support request, Customer feedback, Service outage.

CURRENCIES — account currencies

At least one currency is required, which is used for payments and charges on customer accounts.

Column	Description
ID	Currency identifier.
NAME	Currency name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → Currencies.

Examples: Gibraltar pound, Bonus.

CUSTOMER_GROUPS — groups of customers

At least primary groups required.

Column	Description
ID	Group identifier.
NAME	Group name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Groups → Subject group type: Customer.

Examples: Residential, Business, Enterprise, Employees.

CUSTOMER_STATUSES — customer statuses

At least two statuses are required: for active and disconnected customers customers.

Column	Description
ID	Status identifier.
NAME	Status name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Customers → Status.

Examples: Active, Suspended manually, Disabled.

EQUIPMENT_TYPES — types of customer and provider equipment

At least one type of customer premises equipment (service providing point) is required.

Specify only the types of customer equipment if you are not exporting its connections to the provider equipment.

Column	Description
ID	Equipment type identifier.
NAME	Equipment type name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Product Catalog → Material assets.

Examples: Terminal equipment, STB, ONU, ZTE OLT C300.

FIRMS — Hydra instance divisions

Leave the table blank if there is only one firm in your Hydra (single-division setup).

Column	Description
ID	Division identifier.
NAME	Division name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Organizational Structure.

Examples: Offline Telecom, Cloud Express.

NETWORK_SERVICES — network services and applications of Hydra

At least Customer Self-Care Portal is required.

Column	Description
ID	Network service identifier.
NAME	Network service name.
REMARK	Note for proper matching selection.

In Hydra: Equipment → Network Services.

Examples: Customer Self-Care Portal, PPPoE (Internet), SIP (VoIP), SMS-notifications.

PAYMENT_TYPES — payment types

Leave the table blank if you are not exporting payments history at all or are only exporting real payments and do not want to separate them by type (the common type from the migration application settings will be used).

Column	Description
ID	Payment type identifier.
NAME	Payment type name.
VIRTUAL	Y for virtual types and N — for real ones.
REMARK	Note for proper matching selection.

In Hydra:

Master Data → Reference Data → Virtual payments.
Master Data → Reference Data → Real payments.

Examples: Cash (real), Payment System (real), Correction (virtual), Bonus (virtual).

PHONE_TYPES — phone number purposes for organizations and individuals

Leave the table blank if you are not exporting the contact numbers of individuals and organizations to a separate CUSTOMER_PHONES table.

Column	Description
ID	Phone number purpose identifier.
NAME	Phone number purpose name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → Address purposes.

Examples: Mobile, Home, Notification, Work.

PRODUCTS — price plans, services and adjustments

At least current customers price plans and their additional recurrent services are required if you are not exporting the charges history.

Column	Source of values	Description
ID		Product identifier.
NAME		Product name.
TYPE		Y for price plans, N — for the rest.
UNIT_ID	UNITS.ID	Measurement unit identifier for quantitative services from the UNITS table. Must correspond to the measurement unit of the respective Hydra product catalog item. If the unit is not specified Hydra product catalog (dash), leave the field blank.
REMARK		Note for proper matching selection.

In Hydra:

Master Data → Product Catalog → Price plans.
Master Data → Product Catalog → Services.
Master Data → Product Catalog → Adjustments.

Examples: Ultimate (price plan), STB rent fee (service), Refund (adjustment).

PROVIDER_EQUIPMENT — the provider network devices, that customer ones are connected to

Leave the table blank if you are not exporting CPE's connections to the provider equipment for inventory or AAA purposes (e.g. DHCP Option 82 based IPoE authentication).

Column	Source of values	Description
ID		Equipment identifier.
EQUIPMENT_TYPE_ID	EQUIPMENT_TYPES.ID	Equipment type identifier.
CODE		Equipment code. Used for automatic matching.
IP		Equipment IPv4 address of Actual address purpose. Can be used for automatic matching instead of code.
FIRM_ID	FIRMS.ID	Firm identifier for multi-division Hydra setup. Leave the table blank if there is only one firm in your Hydra (single-division setup).
REMARK		Note for proper matching selection.

In Hydra: Equipment → Active Equipment.

Examples: OLT/Lomas/150645320095, SW-Cisco-C2950-24/12345.

STREET_ADDRESS_PURPOSES — street address purposes for organizations, individuals, and CPE

Leave the table blank if you are not exporting street addresses to separate CUSTOMER_STREET_ADDRESSES and EQUIPMENT_STREET_ADDRESSES tables.

Column	Description
ID	Street address purpose identifier.
NAME	Street address purpose name.
REMARK	Note for proper matching selection.

In Hydra: Master Data → Reference Data → Address purposes.

Examples: Actual address, Permanent residency address, Registered office, Service address.

UNITS — units of measurement for the quantity of services

Leave the table blank if you are not exporting quantitative services.

Column	Description
ID	Measurement unit identifier.
NAME	Measurement unit name.
REMARK	Note for proper matching selection.

In Hydra:

Master Data → Reference Data → Units of measurement.
Master Data → Reference Data → Time measurement units.
Master Data → Reference Data → Units of information.
Master Data → Reference Data → Data rate units.

Examples: Piece, Meter, Megabyte, Minute, Megabits per second.

Customers details to import

The data from these tables is used during migration to create Hydra entities of the corresponding type.

If the described intermediate data schema is insufficient for transferring all necessary details to Hydra, please contact Hydra Team to discuss extra columns or additional tables.

CUSTOMERS — customers and basic subjects

The main table, to which all others are linked in one way or another.

As a rule, each entry in this table corresponds to a single independent customer. If you need to combine multiple customers within a common basic subject (individual or organization), in addition to separate entries for each customer, export entries for their base subject, linking them to each other via PARENT_ID. In this case, the IDs of customers must be positive, and IDs of basics subjects must be negative.

Column	Source of values	Description
ID		Customer (or basic subject when exported separately) identifier. Subscribers must have positive identifiers, while basic subjects (individuals and organizations) must have negative identifiers.
STATUS_ID	CUSTOMER_STATUSES.ID	Customer status identifier. Basic subjects are always created in the Active status.
PARENT_ID	CUSTOMERS.ID	Basic subject identifier when exported separately. Leave blank for automatic generation of basic subjects and linking customers to them.
CODE		Customer code — a unique short name that identifies the customer. It is the default login for the Customer Self-Care Portal and network services.
ORGANIZATION		Y for organizations and N — for individuals.
NAME		Name of individual or name of organization.
SECOND_NAME		Middle name of an individual, leave blank for organization.
SURNAME		Last name of an individual, leave blank for organization.
ADDRESS		The actual street address of an individual or organization in the format `<locality_name> <locality_type>,<street_name> <street_type>,<building>,<entrance>,<floor>,<apartment>,<intercom>` If some details are missing, leave only commas. For example: `London City,Baker Street,221,2,,1,123` The house number can be supplemented with the corpus number: `London City,Baker Street,221 Corpus B,2,,1,123` Leave blank if you are exporting these addresses to a separate CUSTOMER_STREET_ADDRESSES table.
ADDRESS_REMARK		Actual street address remark. Leave blank if you are exporting these addresses to a separate CUSTOMER_STREET_ADDRESSES table.
AUTH_DOC_TYPE_ID	AUTH_DOC_TYPES.ID	Identity document identifier for individuals. Leave blank for organizations.
AUTH_DOC_SERIAL		Identity document serial number for individuals. Leave blank for organizations.
AUTH_DOC_NUMBER		Identity document number for individuals. Leave blank for organizations.
AUTH_DOC_DATE		Identity document date of issue for individuals in the format DD.MM.YYYY. Leave blank for organizations..
AUTH_DOC_ISSUING_AUTHORITY		Identity document issuer for individuals. Leave blank for organizations.
BIRTH_DATE		Date of birth of an individual in the format DD.MM.YYYY. Leave blank for organizations.
BIRTH_PLACE		Place of birth of an individual. Leave blank for organizations.
TAX_ID_NUMBER		Taxpayer identification number (Tax ID).
LEGAL_FORM_CODE		Code or name of the legal form. For example: SP or Sole proprietor, LLC or Limited liability company. All variants must be configured in Hydra beforehand: Master Data → Reference Data → Business entity types. Leave blank for regular individuals with no legal status.
W_PHONE		Contact work phone number in E.164 format: no spaces, hyphens, plus signs, or parentheses — only digits. You can specify multiple numbers by separating them with commas. Leave blank if you are exporting phones to a separate CUSTOMER_PHONES table.
H_PHONE		Contact home phone number in E.164 format: no spaces, hyphens, plus signs, or parentheses — only digits. You can specify multiple numbers by separating them with commas. Leave blank if you are exporting phones to a separate CUSTOMER_PHONES table.
M_PHONE		Contact mobile phone number in E.164 format: no spaces, hyphens, plus signs, or parentheses — only digits. You can specify multiple numbers by separating them with commas. Leave blank if you are exporting phones to a separate CUSTOMER_PHONES table.
EMAIL		Contact email address. You can specify multiple addresses, separating them with commas.
FIRM_ID	FIRMS.ID	Firm identifier for multi-division Hydra setup. Leave the table blank if there is only one firm in your Hydra (single-division setup).
REMARK		Brief note to the customer (or to the basic subject in the case of separate export).

CUSTOMER_GROUP_BINDS — customer participation in groups

Each customer must be a member of at least one group.

Column	Source of values	Description
ID		Group binding identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier.
GROUP_ID	CUSTOMER_GROUPS.ID	Group identifier.
PRIMARY		Y for the primary group, N for additional ones. Each customer must have only one primary group.
REMARK		Not used in the current version, leave blank.

CUSTOMER_COMMENTS — extended comments to customers

Multipart notes to customers, categorized by type, will be available on the Comments tab of the customer page in Hydra.

Column	Source of values	Description
ID		Comment identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier.
COMMENT_TYPE_ID	COMMENT_TYPES.ID	Comment type identifier.
COMMENT_TEXT		Comment text. Use the ¶ character to separate lines in the text.
CREATED_DATE		Date and time of comment in format DD.MM.YYYY HH24:MI:SS.
REMINDER_DATE		Date and time of comment reminder in format DD.MM.YYYY HH24:MI:SS.
EXECUTION_DATE		Date and time of comment execution in format DD.MM.YYYY HH24:MI:SS.

CUSTOMER_MAPPINGS — correspondence between exported customers and those already existing in Hydra

To be filled in only for the migration of additional details to previously created customers.

Column

Source of values

Description

CUSTOMER_ID

CUSTOMERS.ID

Exported customer identifier.

Primary key in this table: only one record is possible here for each exported subscriber..

CUSTOMER_DST_CODE

The code of the target customer in Hydra to whom the exported accounts, contracts, equipment, and subscriptions need to be added.

REMARK

Not used in the current version, leave blank.

CUSTOMER_PHONES — contact phone numbers for individuals and organizations

Extended version of assigning contact phone numbers of different kinds (purposes) with optional notes.

If you don't need notes and the standard purposes (Work, Home, Mobile) are sufficient — leave this table empty and use W_PHONE, H_PHONE, and M_PHONE columns of the CUSTOMERS table instead.

Column	Source of values	Description
ID		Contact phone number identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier. When exporting customers and basic subjects separately — the identifier of the basic subject.
PHONE_TYPE_ID	PHONE_TYPES.ID	Contact phone number purpose identifier.
PHONE		Contact phone number in E.164 format: no spaces, hyphens, plus signs, or parentheses — only digits.
REMARK		Brief note to the contact phone number.

CUSTOMER_STREET_ADDRESSES — detailed street addresses of individuals and organizations

Extended version of assigning street addresses of different kinds (purposes) to basic subjects.

If one actual street address in simplified format is sufficient, leave this table blank and use ADDRESS and ADDRESS_REMARK columns of the CUSTOMERS table instead.

Column	Source of values	Description
ID		Street address identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier. When exporting customers and basic subjects separately — the identifier of the basic subject.
ADDRESS_PURPOSE_ID	STREET_ADDRESS_PURPOSES.ID	Street address purpose identifier, if you are populating the STREET_ADDRESS_PURPOSES table. It's considered Actual address by default.
DISTRICT		A federal district that includes a locality. The region type in Hydra is District with the code REGION_TYPE_District.
CITY		Locality name. Region's code in Hydra registry of regions. For example: San Francisco.
CITY_TYPE		Full or short name of the type of locality. For example: City, Town, Set. or Settlement. All variants must be configured in Hydra beforehand: Master Data → Reference Data → Region types.
STREET		Street name. Region's code in Hydra registry of regions. For example: Line Wall, Baker, Trafalgar.
STREET_TYPE		Full or short name of the type of street. For example: Rd. or Road, St. or Street, Sq. or Square. All variants must be configured in Hydra beforehand: Master Data → Reference Data → Region types.
HOUSE		These four columns collectively define the building: HOUSE — house number, BUILDING — corpus (pavilion), CONSTRUCT — annex (structure), OWNERSHIP — ownership (property). At least one of the values must be filled in, otherwise the address will not be migrated.
BUILDING
CONSTRUCT
OWNERSHIP
ENTRANCE		Building entrance.
FLOOR		The floor number, numeric value.
FLAT		The number of the office, apartment or other premises.
INTERCOM_CODE		Intercom code.
CUSTOM_ADDRESS		The unstructured part of the equipment location address. For example: third door on the left.
REMARK		Brief note to the address.

ACCOUNTS — accounts of customers and basic subjects

Each customer must have at least one customer account in order to render services: an electronic wallet in the billing system, to which payments are credited and funds are debited for the provision of services.

Column	Source of values	Description
ID		Account identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier. When exporting customers and basic subjects separately — the identifier of the basic subject.
ACCOUNT_NUMBER		Account number Should be unique.
ACCOUNT_TYPE_ID	ACCOUNT_TYPES.ID	Account type identifier.
CURRENCY_ID	CURRENCIES.ID	Currency identifier.
BANK_ID	BANKS.ID	Bank identifier of the settlement (current) account, leave blank for customer accounts.
BALANCE		Personal account balance. Leave blank for a settlement account. A positive value indicates a deposit has been made, while a negative value indicates there is outstanding debt.
CREDIT		Customer account credit limit, leave blank if not required. Positive values only.
CREDIT_END_DATE		The date and time when the credit limit expires, in DD.MM.YYYY HH24:MI:SS format. Leave blank if there is no credit limit or if it is permanent.
BALANCE_DATE		Date and time of customer account balance calculation, in DD.MM.YYYY HH24:MI:SS format. For settlement accounts, populate with current date and time. The migrated closing balance will differ by the difference between PAYMENTS table and CHARGES table entries that occurred after the specified date.
REMARK		Brief note to the account.

CONTRACTS — service agreements

Each customer must have at least one contract in order to render services.

Column	Source of values	Description
ID		Contract identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier.
CONTRACT_NUMBER		Contract number. Should be unique.
SIGNATURE_DATE		Date of contract signing, in DD.MM.YYYY format.
START_DATE		The start date of the contract period, in DD.MM.YYYY format. This usually is the same as the date of signing.
END_DATE		The end date of the contract validity period (termination date), in DD.MM.YYYY format. For current contracts, this is usually not specified: the contract is valid indefinitely until terminated on purpose.
REMARK		Brief note to the contract.

EQUIPMENT — customer premises equipment (service providing points)

Customer equipment in Hydra is necessary for keeping the servicing address, CPE technical details, automatic provisioning and access control (AAA).

The necessity of certain technical requirements depends on the configured integrations with external services and hardware, i.e. the specifics of customer authorization and service access management.

Column	Source of values	Description
ID		Customer equipment identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier.
EQUIPMENT_TYPE_ID	EQUIPMENT_TYPES.ID	Customer equipment type identifier.
PROVIDER_EQUIPMENT_ID	PROVIDER_EQUIPMENT.ID	Provider equipment identifier (e.g., network switch or OLT) to which the CPE must be bounded to. Leave blank if binding is not required.
PROVIDER_EQUIPMENT_PORT_CODE		Provider equipment component code (e.g., port number). Leave blank if the CPE binding should be to the provider equipment itself, rather than to its component (port).
PROVIDER_EQUIPMENT_PORT_TYPE		The code of provider equipment component type, i.e. specification item of the provider equipment type. Leave blank if the provider equipment components has unique codes.
CODE		Customer equipment code, i.e. its short unique name
MAC		CPE hardware address, in XX-XX-XX-XX-XX-XX or XX:XX:XX:XX:XX:XX format. Must be individual (unicast). You can specify multiple addresses by separating them with commas.
IP		IPv4 address, or IPv4 subnet in CIDR notation. For example: 128.66.125.125 or 128.66.25.48/29. You can specify multiple addresses by separating them with commas.
IP6		IPv6 subnet. For example: 2001:db8:7df5::/64. You can specify multiple subnets by separating them with commas.
PHONE		The phone number to which calls should be billed in E.164 format: no spaces, hyphens, plus signs, or parentheses — only digits. For example: 17607339969. You can specify multiple phone numbers by separating them with commas.
VLAN		Not used in the current version, leave blank.
ADDRESS		The service providing street address in the format `<locality_name> <locality_type>,<street_name> <street_type>,<building>,<entrance>,<floor>,<apartment>,<intercom>` If some details are missing, leave only commas. For example: `London City,Baker Street,221,2,,1,123` The house number can be supplemented with the corpus number: `London City,Baker Street,221 Corpus B,2,,1,123` Leave blank if you are exporting these addresses to a separate EQUIPMENT_STREET_ADDRESSES table.
ADDRESS_REMARK		Service providing street address remark Leave blank if you are exporting these addresses to a separate EQUIPMENT_STREET_ADDRESSES table.
REMARK		Brief note to the CPE.

EQUIPMENT_COMMENTS — extended comments to customers premises equipment

Multipart notes to CPE (service providing points), categorized by type, will be available on the Comments tab of the customer equipment in Hydra.

Column	Source of values	Description
ID		Comment identifier.
EQUIPMENT_ID	EQUIPMENT.ID	Customer equipment identifier.
COMMENT_TYPE_ID	COMMENT_TYPES.ID	Comment type identifier.
COMMENT_TEXT		Comment text. Use the ¶ character to separate lines in the text.
CREATED_DATE		Date and time of comment in format DD.MM.YYYY HH24:MI:SS.
REMINDER_DATE		Date and time of comment reminder in format DD.MM.YYYY HH24:MI:SS.
EXECUTION_DATE		Date and time of comment execution in format DD.MM.YYYY HH24:MI:SS.

EQUIPMENT_STREET_ADDRESSES — detailed street addresses of customer equipment

Extended version of assigning street addresses of different kinds (purposes) to customer equipment.

If one service street address in simplified format is sufficient, leave this table blank and use ADDRESS and ADDRESS_REMARK columns of the EQUIPMENT table instead.

Column	Source of values	Description
ID		Street address identifier.
EQUIPMENT_ID	EQUIPMENT.ID	Customer equipment identifier.
ADDRESS_PURPOSE_ID	STREET_ADDRESS_PURPOSES.ID	Street address purpose identifier, if you are populating the STREET_ADDRESS_PURPOSES table. It's considered Service address by default.
DISTRICT		A federal district that includes a locality. The region type in Hydra is District with the code REGION_TYPE_District.
CITY		Locality name. Region's code in Hydra registry of regions. For example: San Francisco.
CITY_TYPE		Full or short name of the type of locality. For example: City, Town, Set. or Settlement. All variants must be configured in Hydra beforehand: Master Data → Reference Data → Region types.
STREET		Street name. Region's code in Hydra registry of regions. For example: Line Wall, Baker, Trafalgar.
STREET_TYPE		Full or short name of the type of street. For example: Rd. or Road, St. or Street, Sq. or Square. All variants must be configured in Hydra beforehand: Master Data → Reference Data → Region types.
HOUSE		These four columns collectively define the building: HOUSE — house number, BUILDING — corpus (pavilion), CONSTRUCT — annex (structure), OWNERSHIP — ownership (property). At least one of the values must be filled in, otherwise the address will not be migrated.
BUILDING
CONSTRUCT
OWNERSHIP
ENTRANCE		Building entrance.
FLOOR		Floor number, numeric value.
FLAT		The number of the office, apartment or other premises.
INTERCOM_CODE		Intercom code.
CUSTOM_ADDRESS		The unstructured part of the equipment location address. For example: third door on the left.
REMARK		Brief note to the address.

CUSTOMER_NET_SERVICE_BINDS — network services subscriptions with optional credentials

Leave the table blank if you do not want to provide customers with access to the customer portal, and no credentials (i.e. usernames and passwords) needed for Hydra to manage access to services.

Column	Source of values	Description
ID		Network services subscription (application access) identifier.
CUSTOMER_ID	CUSTOMERS.ID	Customer identifier.
NETWORK_SERVICE_ID	NETWORK_SERVICES.ID	Network service identifier.
EQUIPMENT_ID	EQUIPMENT.ID	Customer equipment identifier. Leave blank for Customer Self-Care Portal access and notification service subscriptions. Be sure to populate this for all subscriptions to external services provisioned by Hydra (e.g., PPPoE or SIP).
LOGIN		Login (username). Must be unique within the network service (application). Leave blank if no login is required, for example for subscribing to notifications.
PASSWORD		Password in plain text. In test exports, you can specify the same stub value for all of them for security reasons.. Leave blank if no password is required, for example for subscribing to notifications.
PASSWORD_HASH_TYPE		Not used in the current version, leave blank.
REMARK		Not used in the current version, leave blank.

SUBSCRIPTIONS — customer subscriptions to recurrent services

Service subscription represents that the customer wants to get particular service for certain period of time, paying for this from a specific customer account and under a specific service contract.

It is sufficient to export only current and future subscriptions; charges history migration does not use these subscriptions.

Column	Source of values	Description
ID		Subscription identifier.
ACCOUNT_ID	ACCOUNTS.ID	Customer account identifier.
CONTRACT_ID	CONTRACTS.ID	Contract identifier.
PRODUCT_ID	PRODUCTS.ID	Product (i.e. service or price plan) identifier. Only recurrent services can be subscribed to.
EQUIPMENT_ID	EQUIPMENT.ID	Customer equipment (i.e. service providing point) identifier. Must be specified for all services provisioned by Hydra. It is recommended to specify equipment for unmanaged services as well, so that the service is at least linked to the service address, but you can leave it blank for them.
START_DATE		The date and time when the subscription started, in DD.MM.YYYY HH24:MI:SS format, i.e. when the customer ordered this product.
END_DATE		Subscription end date and time in DD.MM.YYYY HH24:MI:SS format, i.e. when the service should end. Leave blank for current services and they will be provided indefinitely until disconnected on purpose. If the price plan change is scheduled in the future: in subscription to the plan, specify the date and time of its end; and in subscription to the new one, specify only the date and time of its start (one second after the end of the old one).
QUANTITY		The quantity of the service ordered in the PRODUCTS.UNIT_ID unit of measurement. This is a multiplier for the price of the service. For example, to render two STBs rent fee at $20 each, set 2 as quantity and the subscription fee will then be 2 × $20 = $40. Leave blank for products with no unit of measurement.
BILLING_DATE		Fixed monthly billing date — a natural number from 1 to 28. For business subscribers it's usually 1, i.e. billing periods are strictly tied to calendar months. Leave blank if the billing date should vary, i.e. determined by the date when a charge log is issued for a service. This mode is typically used for residential customers.
REMARK		Not used in the current version, leave blank.

CHARGES — charges history and current billing periods

Populating this table is not critical for migration, however, it is generally expected to contain at least the current billing periods for all customers subscriptions to services.

To migrate current charge logs properly, you must ensure that subscriptions to all current services are in the SUBSCRIPTIONS table: with appropriate validity period and with identical customer account, contract, product, and equipment.

If it is impossible to export this details, be sure to discuss options for initial charge logs issuing in Hydra with Hydra Team. By default, when running scheduled tasks after migration, Hydra will start providing services based on subscriptions from the current moment.

As a rule, it is sufficient to export charges history from the beginning of the current year in order to make financial reports from a single billing system. The charges history migrates “as is” in the form of archived charge logs, i.e. no historical price specifications and subscriptions required for this.

Column	Source of values	Description
ID		Charge identifier.
ACCOUNT_ID	ACCOUNTS.ID	Customer account identifier.
CONTRACT_ID	CONTRACTS.ID	Contract identifier.
CHARGE_DATE		Date and time of charge (funds debited from the customer account) in DD.MM.YYYY HH24:MI:SS format. During migration, it will be matched with ACCOUNTS.BALANCE_DATE to determine the final balance of the customer account. As a rule, it's identical to either start or end date of the billing period, however may differ. Must be within the billing period.
PRODUCT_ID	PRODUCTS.ID	Product identifier, i.e. the price plan, additional service, or adjustment this charge is for.
EQUIPMENT_ID	EQUIPMENT.ID	Customer equipment identifier. For current billing periods, it must match the one specified for this service in SUBSCRIPTIONS.EQUIPMENT_ID. You can leave this blank for the billing history if there is no need to link it to specific service providing points.
AMOUNT		Total amount (not price) charged for the service in the currency of the customer account for the entire billing period, multiplied by 100. Negative values are only allowed for adjustments that increase the balance of the customer account, e.g. refunds.
CHARGING_PERIOD_START_DATE		The start date and time of the billing period in DD.MM.YYYY HH24:MI:SS format. The time part for regular recurrent services is usually 00:00:00, i.e. midnight. For instant one-time services and balance adjustments, this should be equal to CHARGE_DATE value.
CHARGING_PERIOD_END_DATE		The end date and time of the billing period in DD.MM.YYYY HH24:MI:SS format. The time part for regular recurrent services is usually 23:59:59, i.e. the very last second of the day. For instant one-time services and balance adjustments, this should be equal to CHARGE_DATE value.
QUANTITY		The quantity of the service rendered in the PRODUCTS.UNIT_ID unit of measurement, multiplied by 100. Leave blank for products with no unit of measurement.
REMARK		Brief note to the charge.

PAYMENTS — payments history

As a rule, it is sufficient to export payment history from the beginning of the current year in order to make financial reports from a single billing system.

Column	Source of values	Description
ID		Payment identifier.
ACCOUNT_ID	ACCOUNTS.ID	Customer account identifier.
BANK_ID	BANKS.ID	Bank identifier, i.e. source of the payment.
TRANSACTION_DATE		Payment date and time in DD.MM.YYYY HH24:MI:SS format. During migration, it will be matched with ACCOUNTS.BALANCE_DATE to determine the final balance of the customer account.
PAYMENT_AMOUNT		The payment amount in the currency of the customer account, multiplied by 100.
PAYMENT_TYPE_ID	PAYMENT_TYPES.ID	Payment type identifier. Leave blank if only exporting real payments and do not want to separate them by type — the common type from the migration application settings will be used.
REMARK		Brief note to the payment.