Modules EN: различия между версиями

Материал из WiKi - UserSide
Нет описания правки
([IronBot] Sync EN localization from RU)
 
Строка 1: Строка 1:
[[Modules_EN|en]] | [[Модули|ru]]
'''en''' | [[Модулі|uk]] | [[Модули|ru]]


ERP "UserSide" modules are divided into internal and external modules. External modules are separate scripts or programmes that can operate remotely from the main system (with a connection to the system database), while internal modules are already built into the system and can be enabled/disabled in the "[[Settings - Modules]]" section.
ERP "UserSide" modules are divided into internal and external modules. External modules are separate scripts or programs that can run remotely from the main system, provided they have a connection to the system database. Internal modules are built into the system and can be enabled or disabled in the "[[Settings - Modules]]" section.


Frequent questions about modules are collected in the corresponding section "[[Frequently_Asked_Questions|Frequently Asked Questions]]".
Frequently asked questions about modules are collected in the "[[Frequently_Asked_Questions|Frequently Asked Questions]]" section.


== Installing modules. General information for all modules ==
== Installing modules. General information for all modules ==


1. For each module - allocate a separate directory.
1. Allocate a separate directory for each module.


2. During operation, all modules keep logs of their work. The path for the catalogue with logs is specified in the configuration file. It is highly recommended to create a separate catalogue for logs for each module. Do not forget to specify write permissions for this catalogue.
2. During operation, all modules write logs. The log directory path is specified in the configuration file. It is strongly recommended to create a separate log directory for each module. Do not forget to grant write permissions for this directory.


3. Modules are usually used for ongoing operation. They should be written to the system cron with a frequency of 5-15 minutes ''(depending on the load)''. At the first launch it is recommended to run the module manually from the system console and make sure that no errors occur and data are imported/processed correctly.
3. Modules are usually intended for continuous operation. Add them to the system cron with a 5-15 minute run interval ''(depending on the load)''. On the first start, run the module manually from the system console and make sure there are no errors and the data is imported or processed correctly.


== General information for billing interaction modules ==
== General information for billing integration modules ==


1. The customer's address is processed and recorded in the [[Address System|addresses]] accounting system built into ERP "UserSide". In case the required building does not exist in ERP "UserSide" it will be created. If the building already exists and is added to the system not by the resources of the module, it will still be correctly processed and assigned to customers.  
1. The customer address is processed and recorded in the [[Address System|address accounting system]] built into ERP "UserSide". If the required building is not present in ERP "UserSide", it will be created. If the building already exists and was not added by the module, it will still be processed correctly and assigned to customers.


2. If a customer is in ERP "UserSide", but is not found in billing, he is not deleted from ERP "UserSide", but is marked with the status "[[Customer status|not in billing]]". This is done for security purposes - otherwise in case of update failure - all customers may be deleted, as they will not be found in the billing.
2. If a customer exists in ERP "UserSide" but is not found in the billing system, the customer is not deleted from ERP "UserSide". Instead, the customer is marked with the "[[Customer status|not in billing]]" status. This is done for safety: otherwise, if an update fails, all customers could be deleted because they were not found in billing.


3. If a customer's [[Activity|Internet activity date]] is later than the online activity date, then the online activity date is equated to the online activity date.
3. If a customer's [[Activity|Internet activity date]] is later than the network activity date, the network activity date is set equal to the Internet activity date.


4. When updating data from billing - not all customer data is updated - e.g. name, address, phone number may remain unchanged. Loading of such data can be enabled in the "[[Settings - Billings]]" section for the required billing.
4. When data is updated from billing, not all customer data is updated. For example, full name, address, and phone number may remain unchanged. Loading such data can be enabled in the "[[Settings - Billings]]" section for the required billing system.


== A brief description of the modules ==
== Brief module descriptions ==
A detailed description is provided on the page of each module


[[usm_billing_EN|usm_billing]] - provides import of information about customers, addresses, tariff plans, etc. from billing into USERSIDE. It is possible to support your own self-written billing. On the basis of this module separate modules for standard billing systems are created: [[usm_abills_EN|usm_abills]], [[usm_bgbilling_EN|usm_bgbilling]], [[usm_hydra_EN|usm_hydra]], [[usm_lanbilling_EN|usm_lanbilling]], [[usm_nodeny_EN|usm_nodeny]], [[usm_nodeny_plus_EN|usm_nodeny_plus]], [[usm_utm5_EN|usm_utm5]]
A detailed description is provided on each module page.


[[usm_asterisk_EN|usm_asterisk]] - interacts with Asterisk telephony. When a call is received - instantly ''(even before picking up the phone)'' displays on the operator's screen the phone number of the caller and if this phone number belongs to a customer - information about the customer ''(name, balance, address, tariff plan, date of last activity, etc.)''. If this phone number belongs to an employee - this will be indicated. If it is an unknown phone number - you will be prompted to create a potential customer card.
[[usm_billing_EN|usm_billing]] imports information about customers, addresses, tariff plans, and other data from billing into USERSIDE. It can also support a custom in-house billing system. Separate modules for standard billing systems are based on this module: [[usm_abills_EN|usm_abills]], [[usm_bgbilling_EN|usm_bgbilling]], [[usm_hydra_EN|usm_hydra]], [[usm_lanbilling_EN|usm_lanbilling]], [[usm_nodeny_EN|usm_nodeny]], [[usm_nodeny_plus_EN|usm_nodeny_plus]], [[usm_utm5_EN|usm_utm5]].


[[usm_cabletest_EN|usm_cabletest]] - '''periodically''' polls switches and gets information from them from the cable tester about the length of switched copper cables. The list of supported switch models is given on the module page.
[[usm_asterisk_EN|usm_asterisk]] interacts with Asterisk telephony. When a call is received, it instantly ''(before the handset is picked up)'' displays the caller's phone number on the operator's screen. If this phone number belongs to a customer, the module shows customer information ''(full name, balance, address, tariff plan, last activity date, and so on)''. If the phone number belongs to an employee, this is indicated. If the number is unknown, the operator is offered to create a potential customer card.


[[usm_checker_EN|usm_checker]] - '''periodically''' polls ''(multithreaded pings)'' active network equipment or customer devices to identify which equipment is active and which has crashed ''(or which customers are no longer active)''.
[[usm_cabletest_EN|usm_cabletest]] '''periodically''' polls switches and receives cable tester information about the length of connected copper cables. The list of supported switch models is provided on the module page.


[[usm_gps 2_EN|usm_gps]] - accepts information from hardware and software gps trackers in order to display the location of vehicles and employees on a coverage map. Allows you to see who is closest to an accident. You can see who was travelling at what time and where. You can see violations of vehicle speed limits, etc. The list of supported tracker protocols is given on the module page.
[[usm_checker_EN|usm_checker]] '''periodically''' polls ''(multithreaded ping)'' active network equipment or customer devices to detect which equipment is active and which has gone down ''(or which customers are no longer active)''.


[[usm_iferr_EN|usm_iferr]] - '''periodically''' polls ''(via SNMP)'''  error counters on equipment interfaces. This allows you to see devices with errors on interfaces ''(both by interface and with the number of problematic interfaces for each device)''. It also builds the delta of error growth per day and per week, which allows you to see devices where problems continue right now.
[[usm_gps 2_EN|usm_gps]] receives information from hardware and software GPS trackers to display vehicle and employee locations on the coverage map. It helps identify who is closest to an incident, shows who moved where and when, and displays vehicle speed limit violations and similar data. The list of supported tracker protocols is provided on the module page.


[[usm_observer_EN|usm_observer]] - '''periodically''' polls ''(via SNMP)''' any equipment for any parameters and notifies ''(mail, sms, etc.)'' when parameters change or go out of limits. Allows flexible configuration of any monitoring of any devices: port number so-and-so has failed, alarm sensor has been triggered, battery operation has started, printer has run out of paper, etc.
[[usm_iferr_EN|usm_iferr]] '''periodically''' polls ''(via SNMP)'' error counters on equipment interfaces. This shows devices with interface errors, both by interface and by the number of problematic interfaces on each device. It also builds daily and weekly error growth deltas, making it possible to see devices where problems are still ongoing.


[[usm_peleng_EN|usm_peleng]] - '''periodically''' polls switches, gets FDB-table from them and accumulates information on MAC-addresses by equipment and its ports. It allows detecting rings, flooding on ports, viruses. Helps to find MAC-address spoofing. It is possible to exclude uplink/downlink ports, etc. from the display. Information about a customer or device is pulled from USERSIDE by MAC-address.
[[usm_observer_EN|usm_observer]] '''periodically''' polls ''(via SNMP)'' any equipment for any parameters and sends notifications ''(email, SMS, and so on)'' when parameters change or go beyond limits. It makes it possible to flexibly configure monitoring for any devices: a specific port went down, an alarm sensor was triggered, battery operation started, a printer ran out of paper, and so on.


[[usm_pon_EN|usm_pon]] - '''periodically''' [[PON_EN|queries OLT]], receives and accumulates information about enabled ONUs. Signal strength, distance to OLT, model, vendor, description, MAC, ID, etc. History of signal level changes by ONU. Information about the customer is pulled up by MAC address/ID of ONU from USERSIDE.
[[usm_peleng_EN|usm_peleng]] '''periodically''' polls switches, receives their FDB tables, and accumulates MAC address information by equipment and port. It helps detect loops, port flooding, and viruses, and helps find MAC address spoofing. UPLINK/DOWNLINK ports can be excluded from display. Customer or device information is pulled from USERSIDE by MAC address.


[[usm_radio_EN|usm_radio]] - '''periodically''' [[Radio|queries radio equipment]] and retrieves a list of connected radio customers. Signal strength, MAC address, connection speed, etc. The list of supported vendors is listed on the module page. Information about the customer or device is pulled from USERSIDE by MAC-address.
[[usm_pon_EN|usm_pon]] '''periodically''' [[PON_EN|polls OLTs]], receives and accumulates information about connected ONUs: signal level, distance to OLT, model, vendor, description, MAC, ID, and other data. It also stores the history of signal level changes by ONU. Customer information is pulled from USERSIDE by ONU MAC address or ID.


[[usm_stat_EN|usm_stat]] - '''periodically''' is launched and records the fact of [[Activity|activity]] of customers at the moment of launching. This allows you to further see for each of the customers in what days and hours he was active in the network. The total number of active customers at the moment of module launch is also recorded.
[[usm_radio_EN|usm_radio]] '''periodically''' [[Radio|polls radio equipment]] and receives a list of connected radio customers: signal level, MAC address, connection speed, and similar data. The list of supported vendors is provided on the module page. Customer or device information is pulled from USERSIDE by MAC address.


== Current versions of the modules ==
[[usm_stat_EN|usm_stat]] is launched '''periodically''' and records customer [[Activity|activity]] in the database at the time of launch. This makes it possible to see, for each customer, on which days and at what hours they were active in the network. It also records the total number of active customers at the time the module is launched.
 
== Current module versions ==
  [[usm_abills_EN|usm_abills]] - 3.318.310
  [[usm_abills_EN|usm_abills]] - 3.318.310
  [[usm_asterisk_EN|usm_asterisk]] - 1.0.20
  [[usm_asterisk_EN|usm_asterisk]] - 1.0.20

Текущая версия от 18:56, 23 мая 2026

en | uk | ru

ERP "UserSide" modules are divided into internal and external modules. External modules are separate scripts or programs that can run remotely from the main system, provided they have a connection to the system database. Internal modules are built into the system and can be enabled or disabled in the "Settings - Modules" section.

Frequently asked questions about modules are collected in the "Frequently Asked Questions" section.

Installing modules. General information for all modules

1. Allocate a separate directory for each module.

2. During operation, all modules write logs. The log directory path is specified in the configuration file. It is strongly recommended to create a separate log directory for each module. Do not forget to grant write permissions for this directory.

3. Modules are usually intended for continuous operation. Add them to the system cron with a 5-15 minute run interval (depending on the load). On the first start, run the module manually from the system console and make sure there are no errors and the data is imported or processed correctly.

General information for billing integration modules

1. The customer address is processed and recorded in the address accounting system built into ERP "UserSide". If the required building is not present in ERP "UserSide", it will be created. If the building already exists and was not added by the module, it will still be processed correctly and assigned to customers.

2. If a customer exists in ERP "UserSide" but is not found in the billing system, the customer is not deleted from ERP "UserSide". Instead, the customer is marked with the "not in billing" status. This is done for safety: otherwise, if an update fails, all customers could be deleted because they were not found in billing.

3. If a customer's Internet activity date is later than the network activity date, the network activity date is set equal to the Internet activity date.

4. When data is updated from billing, not all customer data is updated. For example, full name, address, and phone number may remain unchanged. Loading such data can be enabled in the "Settings - Billings" section for the required billing system.

Brief module descriptions

A detailed description is provided on each module page.

usm_billing imports information about customers, addresses, tariff plans, and other data from billing into USERSIDE. It can also support a custom in-house billing system. Separate modules for standard billing systems are based on this module: usm_abills, usm_bgbilling, usm_hydra, usm_lanbilling, usm_nodeny, usm_nodeny_plus, usm_utm5.

usm_asterisk interacts with Asterisk telephony. When a call is received, it instantly (before the handset is picked up) displays the caller's phone number on the operator's screen. If this phone number belongs to a customer, the module shows customer information (full name, balance, address, tariff plan, last activity date, and so on). If the phone number belongs to an employee, this is indicated. If the number is unknown, the operator is offered to create a potential customer card.

usm_cabletest periodically polls switches and receives cable tester information about the length of connected copper cables. The list of supported switch models is provided on the module page.

usm_checker periodically polls (multithreaded ping) active network equipment or customer devices to detect which equipment is active and which has gone down (or which customers are no longer active).

usm_gps receives information from hardware and software GPS trackers to display vehicle and employee locations on the coverage map. It helps identify who is closest to an incident, shows who moved where and when, and displays vehicle speed limit violations and similar data. The list of supported tracker protocols is provided on the module page.

usm_iferr periodically polls (via SNMP) error counters on equipment interfaces. This shows devices with interface errors, both by interface and by the number of problematic interfaces on each device. It also builds daily and weekly error growth deltas, making it possible to see devices where problems are still ongoing.

usm_observer periodically polls (via SNMP) any equipment for any parameters and sends notifications (email, SMS, and so on) when parameters change or go beyond limits. It makes it possible to flexibly configure monitoring for any devices: a specific port went down, an alarm sensor was triggered, battery operation started, a printer ran out of paper, and so on.

usm_peleng periodically polls switches, receives their FDB tables, and accumulates MAC address information by equipment and port. It helps detect loops, port flooding, and viruses, and helps find MAC address spoofing. UPLINK/DOWNLINK ports can be excluded from display. Customer or device information is pulled from USERSIDE by MAC address.

usm_pon periodically polls OLTs, receives and accumulates information about connected ONUs: signal level, distance to OLT, model, vendor, description, MAC, ID, and other data. It also stores the history of signal level changes by ONU. Customer information is pulled from USERSIDE by ONU MAC address or ID.

usm_radio periodically polls radio equipment and receives a list of connected radio customers: signal level, MAC address, connection speed, and similar data. The list of supported vendors is provided on the module page. Customer or device information is pulled from USERSIDE by MAC address.

usm_stat is launched periodically and records customer activity in the database at the time of launch. This makes it possible to see, for each customer, on which days and at what hours they were active in the network. It also records the total number of active customers at the time the module is launched.

Current module versions

usm_abills - 3.318.310
usm_asterisk - 1.0.20
usm_bgbilling - 3.318.111
usm_billing - 1.13.318
usm_cabletest - 1.1.5
usm_checker - 2.3.1
usm_gps - 2.5.0
usm_hydra - 3.318.178
usm_iferr - 1.3.0
usm_lanbilling - 3.318.349
usm_nodeny - 3.318.254
usm_nodeny_plus - 3.318.76
usm_observer - 1.3.0
usm_peleng - 3.26.123
usm_pon - 1.10.34
usm_radio - 3.13.14
usm_stat - 3.10.26
usm_utm5 - 3.318.685