Address system: различия между версиями

Материал из WiKi - UserSide
(Новая страница: «en | ru»)
 
Нет описания правки
 
(не показано 10 промежуточных версий этого же участника)
Строка 1: Строка 1:
[[Address_system|en]] | [[Адресная_система|ru]]
[[Address_system|en]] | [[Адресная_система|ru]]
'''ATTENTION: This section is relevant for ERP "UserSide" versions 3.13 and later. For versions earlier than 3.13 - use separate pages [[Regions]] and [[Settings - Addresses]].
<youtube>https://youtu.be/BP5tm3ThYqI</youtube>
In ERP "UserSide" most of the objects ''([[Customer list|users]], [[Communications installations card|communication nodes]], [[Cable lines EN|FOCL]] etc.]'' have different addresses or may be without address.
The concept of ''Address/address unit'' and 'Building/house' must be clearly differentiated. An address is simply a name. A sign on a building, if you prefer. A building is a complete, unified structure. One large building can have many addresses at the same time ''(e.g. a house which is standing on 4 streets at once)''. In the same way - one address may hide many buildings ''(for example - a property complex, [[Coverage maps|polygon]] or an area with many buildings)''.
In ERP "UserSide" we have tried to make all address hierarchies of different countries flexible. Cities can include other cities, streets can include districts and so on.
The scope of objects in the system depends on the availability of a particular address object to the current employee. This makes it possible, for example, to forbid employees of some localities to see users of other localities.
If the objects are not linked to an address, they are available to all employees who have the option "Objects without address" selected.
[[Файл:Available_adresses.png|thumb|800px|center]]
[[Файл:All_available_objects.png|thumb|800px|center]]
<br>
'''Starting from version 3.18:'''
<span id="anchor_318_75_en">In the form for editing an address unit, the address type selector displays its token in addition to the type name.</span>
[[Файл:2023-05-22_17-32.png|thumb|800px|center]]
== Address unit tokens ==
"Address unit tokens" are used for interaction with external systems, for use in APIs, for operation of billing interaction modules.
[[Файл:2023-05-22_17-33.png|thumb|800px|center]]
For example, in the ERP "UserSide" you can add the types of address units "City" and " Village" and specify the token "city" for both of them. In this case, when interacting with billing, the address objects from these address units will be equal and all will be considered as settlements.
For interaction with billing, the following tokens are used: "province", "district", "city", "area", "street", and "house".
== Types of address units ==
" Settings => "Addresses" => "Types of address units"
This section is used to create types of address units - they can be completely optional - countries, continents, streets, avenues, water areas, etc.
[[Файл:2023-05-22_17-34.png|thumb|800px|center]]
Despite the fact that the configuration of the address hierarchy is very flexible, there are still basic categories that can be assigned to these address units ''(e.g. street, locality)'' for compatibility with external systems.
[[Файл:2023-05-22_17-35.png|thumb|800px|center]]
In the "Object name template" field, you can specify how the name of an address unit of this type will look in the system. This is usually mainly required for buildings. TWIG markup is used. For example:
Address of the building: Kyiv Petrovsky district, Gagarina street 25
<nowiki>
template:
{{ city }}, {{ street }}, {{ house }}
return: Gagarina Street 25, Kyiv
template: {{ street }}, {{ house }}
return: Gagarina Street 25
template: {{ city }}, {% if area %} {{ area }}, {% endif %} {{ street }}, {{ house }}
return: Kyiv, Moskovsky district, Petrova 17
if the address unit does not have a higher district, the address will be: Kyiv, Gagarina Street, 25 (thus the district name and comma will be omitted)
</nowiki>
In the "Prefix" or "Postfix" field, you can specify abbreviated names for object types - e.g. "c.", "st.", "v.", etc.
== Alias types ==
"Settings => "Addresses" => "Alias types"
Aliases allow you to add additional names to address units. This is particularly useful for streets and localities which have changed names. Alternatively, names can be specified in several languages.
[[Файл:2023-06-01_17-23.png|thumb|800px|center]]
[[Файл:2023-06-01_17-24.png|thumb|800px|center]]
Once the alias types have been set, it will be possible to fill in these aliases in the address bar.
[[Файл:2023-06-01_17-38.png|thumb|800px|center]]
== Address units ==
<youtube>https://youtu.be/EojBhZ1Et34</youtube>
"Settings" => "Addresses".
This section is used to add address units manually. It should also be considered that adding new address units is possible via "[[Import of manuals]]", when working with [[Supported billings|billings]], as well as via [[API EN|API]].
[[Файл:2023-06-01_17-48.png|thumb|800px|center]]
The form for creating a new address unit allows you to specify its type, name and relationship to the parent address unit.
[[Файл:2023-06-01_17-48_1.png|thumb|800px|center]]
When it comes to adding an entry for a building, you should consider the possibility of specifying multiple address units for that building:
[[Файл:2023-06-01_17-50.png|thumb|800px|center]]
[[Файл:2023-06-01_17-55.png|thumb|800px|center]]
<span id="anchor_317_124">Since version 3.17, the address selector now shows the type of address object (country, province, city...)</span>.
[[Файл:2023-06-01_17-57.png|thumb|800px|center]]
For any address unit, you can select the coordinates on the map as a polygon or a point.
[[Файл:2023-06-01_17-59.png|thumb|800px|center]]
You can choose if you would like to display this object on the map, what colour should be used, and whether or not a separate link should be displayed in the main menu for this object ''( highly relevant for populated areas or districts)''.
== Adding buildings to the coverage map ==
<youtube>https://youtu.be/c9GGSinDag8</youtube>
It is reasonable to place all buildings on a geo-service map. It's convenient, visual, and practical.
[[Файл:2023-06-01_18-00.png|thumb|800px|center]]
First of all, you should read the FAQ about it. The "[[Frequently Asked Questions#Maps and Addresses|Maps and Addresses]]" section.
Adding a building to the map is done from the building's editing card ''(see page above)''.
It should be noted that when adding a building to the map you can use geocoder services ''(OpenStreetMap Nominatim, Yandex Geocoder)''
[[Файл:2023-06-01_18-01.png|thumb|800px|center]]
Then, if the address of the building to be added is known to the geocoder - it will orient the map to the correct location and possibly offer the correct polygon indication based on its database, which contains the specific coordinates of the corners of that building.
== Removing unused addresses ==
'''Starting from version 3.18:'''
<span id="anchor_318_69">A link to view and mass removal of unused addresses has been added to the "Settings - Addresses" section.</span>
[[Файл:2023-06-01_18-02.png|thumb|800px|center]]

Текущая версия от 14:12, 1 ноября 2024

en | ru

ATTENTION: This section is relevant for ERP "UserSide" versions 3.13 and later. For versions earlier than 3.13 - use separate pages Regions and Settings - Addresses.

In ERP "UserSide" most of the objects (users, communication nodes, FOCL etc.] have different addresses or may be without address.

The concept of Address/address unit and 'Building/house' must be clearly differentiated. An address is simply a name. A sign on a building, if you prefer. A building is a complete, unified structure. One large building can have many addresses at the same time (e.g. a house which is standing on 4 streets at once). In the same way - one address may hide many buildings (for example - a property complex, polygon or an area with many buildings).

In ERP "UserSide" we have tried to make all address hierarchies of different countries flexible. Cities can include other cities, streets can include districts and so on.

The scope of objects in the system depends on the availability of a particular address object to the current employee. This makes it possible, for example, to forbid employees of some localities to see users of other localities.

If the objects are not linked to an address, they are available to all employees who have the option "Objects without address" selected.


Starting from version 3.18:

In the form for editing an address unit, the address type selector displays its token in addition to the type name.

Address unit tokens

"Address unit tokens" are used for interaction with external systems, for use in APIs, for operation of billing interaction modules.

For example, in the ERP "UserSide" you can add the types of address units "City" and " Village" and specify the token "city" for both of them. In this case, when interacting with billing, the address objects from these address units will be equal and all will be considered as settlements. For interaction with billing, the following tokens are used: "province", "district", "city", "area", "street", and "house".

Types of address units

" Settings => "Addresses" => "Types of address units"

This section is used to create types of address units - they can be completely optional - countries, continents, streets, avenues, water areas, etc.

Despite the fact that the configuration of the address hierarchy is very flexible, there are still basic categories that can be assigned to these address units (e.g. street, locality) for compatibility with external systems.

In the "Object name template" field, you can specify how the name of an address unit of this type will look in the system. This is usually mainly required for buildings. TWIG markup is used. For example:

Address of the building: Kyiv Petrovsky district, Gagarina street 25 

 template:
 {{ city }}, {{ street }}, {{ house }} 
 return: Gagarina Street 25, Kyiv
 
 template: {{ street }}, {{ house }} 
 return: Gagarina Street 25
 
 template: {{ city }}, {% if area %} {{ area }}, {% endif %} {{ street }}, {{ house }}
 return: Kyiv, Moskovsky district, Petrova 17
 if the address unit does not have a higher district, the address will be: Kyiv, Gagarina Street, 25 (thus the district name and comma will be omitted)
 

In the "Prefix" or "Postfix" field, you can specify abbreviated names for object types - e.g. "c.", "st.", "v.", etc.

Alias types

"Settings => "Addresses" => "Alias types"

Aliases allow you to add additional names to address units. This is particularly useful for streets and localities which have changed names. Alternatively, names can be specified in several languages.

Once the alias types have been set, it will be possible to fill in these aliases in the address bar.

Address units

"Settings" => "Addresses".

This section is used to add address units manually. It should also be considered that adding new address units is possible via "Import of manuals", when working with billings, as well as via API.

The form for creating a new address unit allows you to specify its type, name and relationship to the parent address unit.

When it comes to adding an entry for a building, you should consider the possibility of specifying multiple address units for that building:

Since version 3.17, the address selector now shows the type of address object (country, province, city...).

For any address unit, you can select the coordinates on the map as a polygon or a point.

You can choose if you would like to display this object on the map, what colour should be used, and whether or not a separate link should be displayed in the main menu for this object ( highly relevant for populated areas or districts).

Adding buildings to the coverage map

It is reasonable to place all buildings on a geo-service map. It's convenient, visual, and practical.

First of all, you should read the FAQ about it. The "Maps and Addresses" section.

Adding a building to the map is done from the building's editing card (see page above).

It should be noted that when adding a building to the map you can use geocoder services (OpenStreetMap Nominatim, Yandex Geocoder)

Then, if the address of the building to be added is known to the geocoder - it will orient the map to the correct location and possibly offer the correct polygon indication based on its database, which contains the specific coordinates of the corners of that building.

Removing unused addresses

Starting from version 3.18:

A link to view and mass removal of unused addresses has been added to the "Settings - Addresses" section.