Краткое содержание:
Формулирем функциональные требования к гипотетическому мобильному приложению
Реализуем функциональные требования
PS1: Листинг скрипта карты Яндекс
PS2: Листинг процедуры определения расстояний
PS3: Листинг процедуры определения текущих геокоординат
Многие энтузиасты, за неимением штатного платформенного механизма, давно уже начали успешно внедрять в 1С-приложения гео-инструменты сторонних производителей: API Яндекс.Карт, API Google Карт. Скрипты этих API встраиваются в элемент управления типа «Поле HTML документа» интерфейсной формы как обычной, так и управляемой. Парой команд подавляются ошибки скрипта несовершенного платформенного браузера, и все выглядит вполне благопристойно. Причем отрисовку изображения можно готовить как заранее перед открытием формы, так и динамически в процессе работы пользователя с формой, программно добавляя или удаляя на карту различные объекты и действия (балуны, иконки, надписи, регионы, маршруты, центрирование, масштаб …), посылая java-команды через Документ.parentWindow.eval(). А самые продвинутые энтузиасты научились отлавливать события карты, например клики или перемещения балунов, забирая геокоординаты, в общем устраивать полноценную дуплексную связь между картой и 1С-приложением. Идиллия! (например, //infostart.ru/public/254764/)
И все ничего, кабы ни два обстоятельства:
- пользовательское соглашение API Яндекс гласит: Сервис может использоваться Пользователем только в рамках сайтов или мобильных приложений, доступных для бесплатного открытого использования неограниченным кругом лиц. Сервис не может использоваться для проектов, требующих оплаты, или иным образом ограничивающих доступ к ним третьих лиц. Необходимость зарегистрироваться не считается ограничением доступа в рамках настоящего пункта.
- пользовательское соглашение Google говорит примерно то же самое, но они предлагают коммерческую версию при превышении определенного суточного лимита запросов.
Т.е. API карт обоих производителей можно использовать только при бесплатном и неограниченном доступе пользователей к карте, что в принципе невозможно из 1С-приложения, где каждая сессия платная. А вышеупомянутые энтузиасты по сути своей нарушители, и они об этом знают. А кто хочет это опровергнуть, пусть попробует опубликовать тиражный продукт - арбитражка обеспечена! Но мобильная платформа 1С пока остается бесплатной. Это нелицензируемое мобильное приложение, в простейшем случае оно может работать автономно, без подключения к серверу центральной базы, значит, никакие соглашения не нарушаются!
Едем дальше. Читаем описание изменений к платформе 8.3.3:
Для мобильной платформы реализовано поле HTML-документа. Поле HTML-документа обладает следующими особенностями:
-
Не поддерживаются свойства Документ и Вывод.
-
Событие ПриНажатии срабатывает только при попытке перехода на другую страницу. При этом все свойства параметра ДанныеСобытия, кроме Href, содержат значение Неопределено. Свойство Href содержит адрес, по которому выполняется попытка перехода.
Т.е. досылать команды через Документ.parentWindow.eval() пока нельзя и отлавливать события HTML-документа тоже. Возможно, просто не успели реализовать, а возможно для дополнительной популяризации нативного инструмента, который сам ничего из этого пока не умеет, но будущее покажет: просачиваются таки наши хотелки в зазеркалье или нет? :) Короче, на данный момент в мобильной платформе вообще нет обратной связи ни с какой картой, и это досадно, потому что лишает ее новых возможностей применения и дальнейшей популяризации!
Разбираемся далее. Почему разработчики 1С для Android-устройств выбрали именно Google maps API? История умалчивает, возможно, для облегчения будущего выхода на мировой рынок, в чем я лично, как истинный 1С-евангелист нисколько не сомневаюсь! :) Но скорее всего именно из-за возможности использования коммерческой версии, которой у Яндекса увы нет. Для iOS-устройств особого выбора не было - только Apple MapKit. Но я далее буду рассматривать только Android-устройства как наиболее перспективные для российского бизнеса. Мой прогноз: большинство мобильных 1С-приложений будут писаться именно под Android, потому что:
-
цены на такие устройства доступнее, а ассортимент шире
-
процесс отладки проще: приложение можно выкладывать на устройство сразу после сохранения конфигурации. Что ни говори, а эмулятор никогда не заменит живой аппарат.
-
GooglePlay дешевле AppStore, а выпуск новых релизов быстрее
На этом заканчиваю теоретическое вступление, и перехожу к практической части статьи, предлагаю такой план действий:
-
сформулировать максимально прикладную задачу для автоматизации бизнеса мобильными средствами
-
постараться реализовать ее средствами, встроенными в платформу, сравнить с тем же самым на Yandex API
-
проанализировать, что получилось и выдать рекомендации 1С по дальнейшему развитию инструмента геопозиционирования
Представим себе компанию, оказывающую массовые недорогие услуги, короткие по времени, частично на регулярной основе по договору абонентского обслуживания, частично разовые, возникающие спонтанно, с разной степенью длительности и срочности. По городу постоянно шастают агенты компании, заезжают к клиенту, что-то там делают, подписывают таймшиты, фотографируют их, отправляют данные в интернет и уматывают к следующему клиенту. Где-то в офисе сидит диспетчер, который принимает заказы клиентов, распределяет наряды на выезд, а на основании фото-сканов подписанных тайм-шитов выставляет клиентам счета и акты. Агенты могут передавать в учетную базу не только время и состав работы, но и некоторые технические параметры, которые будут полезны для следующих выездов к этому клиенту. У каждого агента в начале дня на мобильном устройстве уже есть список нарядов, местоположение клиентов он видит на карте, и может нарисовать маршрут с расчетным временем передвижения между клиентами. И он готов по ходу дня принимать новые наряды, отказываться от старых и изменять предопределенные маршруты. Если это первый выезд к клиенту, агент может уточнить геокоординаты клиента и отправить в центральную базу. В офисе такой агент может появляться раз в неделю, а то и реже, все инструменты у него с собой. Ничего не напоминает? :) На самом деле это не обязательно 1С-франчайзинг, это могут быть любые ремонтники принтеров, кондиционеров, автомобилей, слесари, сантехники, электрики, уборщики, ревизоры, инспекторы электросчетчиков, торговые представители, проверяющие ассортимент своей продукции в розничных точках…
Формулируем обоснование для ЛПР (лиц, принимающих решения):
-
агент, используя мобильную навигацию, будет меньше тратить времени на дорогу, значит больше успевать
-
тайм-шиты будут доставляться в офис быстрее, значит быстрее будут выставляться счета и акты
-
техническая информация, доставляемая в офис станет точнее, т.к. будут использованы предопределенные классификаторы, значит в будущем будет меньше холостых выездов
Кстати, это хорошая практика - функциональные требования описывать языком сценарного поведения и снабжать технико-экономическим обоснованием на языке ЛПРов. ЛПРы не любят много читать, зато быстро выхватывают из контекста профит. Облегчите им работу, и они быстрее примут решение.
Переходим к этапу моделирования, при подготовке требований к демонстрационному макету сформулируем ряд допущений и ограничений:
-
в модели не будет механизмов обмена с центральной базой, поступление контактов и нарядов будет имитироваться программно
-
в модели предусмотреть две карты, встроенную и Яндекс, что бы провести визуальное сравнение
-
в мобильном устройстве может быть отключен или вообще отсутствовать GPS, в этом случае текущее местоположение определять по сотовой телефонии
-
выводить список клиентов, в порядке увеличения расстояния от текущего местоположения (по аналогии Чекин в Foursquare)
-
строковый адрес нового клиента преобразовать в геокоординаты, если не определяются, то предусмотреть возможность установить координаты текущего местоположения или с клика на карте
-
предусмотреть цветовую градацию клиентов в журнале и на карте: выполненные или отмененные серым, сегодняшние зеленым, будущие желтым, просроченные красным
-
предусмотреть возможность прокладывать маршрут к выбранному клиенту как от текущего местоположения, так и от ближайшей к клиенту станции метро
-
предусмотреть возможность прикреплять к документу Наряд фотографии
Переходим к реализации задачи. Если вы еще ни разу не разрабатывали на мобильной платформе, но очень хотите, то вам для начала надо прочитать статью DirtiX: “Что такое мобильная платформа 1С и с чем ее едят?”//infostart.ru/public/242857/. Там есть все что нужно. Я остановлюсь только на некоторых, как мне кажется, важных моментах.
Для разработки и отладки ничего особенного не требуется! Запуск готового приложения на мобильном устройстве может происходить практически мгновенно после нажатия F7 в конфигураторе на вашем компе, если вы сделаете следующее:
-
на своем компе поднимете web-сервер и настроите публикацию мобильного приложения
-
установите и настроите на своем мобильном устройстве мобильную платформу (файл 1cem-arm.apk из дистрибутива мобильной платформы)
-
теперь из под оболочки мобильной платформы ваша конфигурация моментально скачивается с web-сервера, налету компилируется и запускается в пользовательском режиме, лепота!
Но если вы хотите массово тиражировать свое мобильное приложение, то вам придется его собирать с помощью мобильной платформы, предварительно установленной и настроенной на вашем компе (детали см со следующего параграфа). А если вы планируете периодически выпускать новые релизы и автоматически заливать их всем вашим пользователям, то вам не обойтись без службы Google Play. Про настройку Google Play рассказывать не буду, там все интуитивно понятно. Единственная сложность чисто психологическая - один раз заплатить Гуглу 30$ за неограниченную возможность выкладывать свои приложения и релизы к ним!
Я использовал дистрибутив мобильной платформы 8.3.4.14: http://downloads.v8.1c.ru/get/Info/mobile/8_3_4_14/mobile.zip. Из него разворачиваем конфигурацию “Сборщик мобильных приложений” 1.0.2.8.
Первое что надо сделать - через “Сервис” настроить “Настройки приложения” и “Редактировать поставщика”. В контекстной помощи можно найти пути ко всем дистрибутивам, их надо скачать, установить и указать пути:
-
Android SDK - http://developer.android.com/sdk/index.html.
-
Требования к Android SDK:
-
Версия Android SDK Tools - 20.0.3 и выше;
-
Версия Android SDK Platform-tools - 14 и выше;
-
Версия SDK Platform - строго API 17.
-
-
JDK - http://www.oracle.com/technetwork/java/javase/downloads/index.html.
-
Apache Ant - http://ant.apache.org/bindownload.cgi.
-
PuTTY - http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
Все пути должны быть заполнены, даже если вы не будет использовать iOS. Чтобы не запутаться с путями, вот подсказка, что нужно Сборщику:
Каталог Android SDK должен содержать:
папку: \platforms\android-17\aux
файл: \platforms\android-17\build.prop
файл: \platforms\android-17\source.properties
файл: \platforms\android-17\source.properties
файл: \tools\source.properties
Каталог JDK должен содержать:
файл: \bin\jar.exe
Каталог Apache Ant должен содержать:
файл: \bin\ant.bat
Каталог PuTTy должен содержать:
файл: \pscp.exe
файл: \plink.exe
Но если вы в группе "Мобильные приложения" снимите галочку "Для ОС iOS", то достаточно указать пустую папку.
Так же, в справочник “Мобильные платформы” надо загрузить zip-файл, в котором должны лежать папки “Android” и “iOS” из дистрибутива.
В справочнике “Мобильные конфигурации” создайте элемент и загрузите туда выгруженный из конфигуратора файл 1cema.xml.
В справочнике “Мобильные приложения” для каждого приложения надо создать сначала группу и заполнить интуитивно-понятные параметры, а под группой создать элемент - это и будет основной точкой сборки и выгрузки файла мобильного приложения.
Теперь внимание, достаточно важный момент! Пока вы запускали свое приложение из-под мобильной платформы на мобильном устройстве, встроенная карта работала нормально. Но если вы собранное мобильное приложение попытаетесь запустить как самостоятельное приложение, то встроенная карта отображаться не будет. Потому что для каждого мобильного приложения необходимо получить ключ карты у Google и ввести его в Сборщике в группе “Мобильные приложения” в поле “Ключ для работы с картами Google”. У мобильной платформы 1С для Андройда такой ключ есть. Но как получить свой ключ в Google нигде не написано. Я спрашивал у разработчиков 1С на партнерском форуме, в итоге пришлось самому разобраться:
-
Авторизуемся на google.com
-
Заходим на https://cloud.google.com/console/project и нажимаем CREATE PROJECT
-
Заполняем Project name, Project ID, ставим галку “ have read and agree ...”. Имя должно быть уникальное, система сама подскажет.
-
Дальше запускается механизм авторизации через SMS, если вы ее не проходили при создании google - аккаунта
-
Дальше в вертикальном меню “APIs&auth” открываем дерево “APIs”, находим пункт “Google Maps Android API v2” и ставим STATUS = ON
-
Дальше в меню “APIs&auth” открываем “Credentials” и нажимаем кнопку CREATE NEW KEY в боксе “Public API access”
-
В промежуточном окне нажимаем “Android key”
-
В следующем окне в поле ввода копируем из Сборщика “Параметр получения ключа для работы с картами Google” и нажимаем Create
-
Теперь появился бокс “Key for Android applicaion”, а в нем нужный нам ключ “API key” примерно такого формата: AIzaSyAYHQodtybccavFJP0YLDwp35kZE2be5J8
А вообще есть инструкция на английском языке https://developers.google.com/maps/documentation/javascript/tutorial, лучше ходить туда, т.к. за три месяца Гугл уже успел слегка поменять интерфейс, поэтому моя инструкция в скором времени может стать неактуальной. (За ссылку спасибо DitriX!)
Теперь что касается самого программирования. Все методы геокодирования выполняются только в обрамлении препроцессора “#Если МобильноеПриложениеКлиент Тогда … #КонецЕсли”. Изучите их описание в синтакс-помощнике в разделах:
“Общие объекты” - “Геопозиционирование”:
-
ИнформацияПровайдераГеопозиционирования
-
СредстваГеопозиционирования
-
ГеографическиеКоординаты
-
ДанныеМестоположения
-
ДанныеАдреса
И в “Глобальный контекст” - “Процедуры и функции работы с геопозиционированием”:
-
ПолучитьАдресПоМестоположению
-
ПолучитьМестоположениеПоАдресу
-
ПоказатьНаКарте
Честно говоря, возможностей пока мало, что называется для галочки. Вот все, что мы пока можем сделать:
-
определить текущие координаты мобильного устройства
-
перевести строковое представление адреса в географические координаты и обратно
-
вывести список точек на карту, причем надписи можно увидеть только по клику, а цвет и форма не кастомизируются
А хотелось бы делать то, что уже умеют карты Яндекс и Google в обычных и управляемых формах (но, как мы выяснили, не совсем легально!), в порядке убывания важности:
-
играть цветами и формами наносимых на карты объектов (например, не просто закрытый балун выводящий надпись по клику, а сразу надпись)
-
двигать объекты на карте и передавать в модуль формы новые геокоординаты, перехватывать клики как на карте так и на объектах
-
строить маршруты между точками и возвращать в модуль формы расстояния, причем как для автомобилей, так и для пешеходов
-
показывать пробки
-
показывать гео-слои (схема, спутник, гибрид, народная карта)
-
Ну и как бонус, поиметь функцию вычисления расстояния между двумя точками по прямой, хотя я и реализовал свою формулу, но зачем изобретать велосипед?
В итоге, вот список того, что получилось реализовать из требований к нашей задаче:
|
Задача |
Встроенными средствами |
Яндекс API |
|
в мобильном устройстве может быть отключен или вообще отсутствовать GPS, в этом случае текущее местоположение определять по сотовой телефонии |
да |
- |
|
выводить список клиентов, в порядке увеличения расстояния от текущего местоположения (по аналогии Чекин в Foursquare) |
да |
- |
|
строковый адрес нового клиента преобразовать в геокоординаты,если не определяются, то предусмотреть возможность установить координаты текущего местоположения или с клика на карте |
да, кроме клика на карте |
нет |
|
предусмотреть цветовую градацию клиентов в журнале и на карте: выполненные или отмененные серым, сегодняшние зеленым, будущие желтым, просроченные красным |
в журнале да, на карте нет |
да |
|
предусмотреть возможность прокладывать маршрут к выбранному клиенту как от текущего местоположения, так и от ближайшей к клиенту станции метро |
нет |
нет |
|
предусмотреть возможность прикреплять к документу Наряд фотографии |
да |
- |
В приложении к этой статье два файла “checkin.cf” и “com.e1c.Checkin-arm.apk”. Скопируйте файл *.apk на устройство и запустите - произойдет установка приложения. “checkin.cf” - это конфигурация для платформы 8.3.4.
Все управление я разместил в одном окне - журнале документов "Наряды". Изначально база пустая, заполнение демонстрационными данными - по кнопке “Заполнить демо-данные”.
Автоматическое преобразование адресов в геокоординаты там, где они еще не заполнены - по кнопке “Заполнить гео координаты”. Если геокоординаты определены, в журнале Наряды в колонке "Гео" вместо серого шарика появится зеленый. Если все еще серый, тогда можно зайти в Наряд, потом в Адрес и нажать кнопку "Установите текущие координаты".
В окне журнала Наряды в самом низу есть поле "Текущие координаты". Его можно заполнить нажатием на кнопку “Текущее местоположение”.
Нажатие на кнопку “Checkin” выводит список нарядов в обратном порядке удаленности адреса от текущего местоположения, и в этом списке можно одним нажатием открыть документ Наряд.
Так же есть кнопки “Показать на встроенной карте” и “Показать на Yandex карте”. Кстати, для карты Яндекс я использовал новомодный API 2.1-beta. Про сравнение с прошлой версией API 2.0 можно почитать здесь: http://api.yandex.ru/maps/api21.xml
В общем, получилось чисто демонстрационное приложение для изучения текущих возможностей мобильной платформы и облегчения формулировки предложений 1С-разработчикам по ее дальнейшему развитию.
Спасибо за внимание, смотрите скриншоты, скачивайте архив, ставьте на мобильное устройство, дорабатывайте конфигурацию, пишите свои пожелания 1С-разработчикам в форуме под статьей. Надеюсь, письмо дойдет! ;)
Barelpro.
PS1. Выкладываю скрипт отображения карты Яндекс:
<!DOCTYPE html>
<html >
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<script src="http://api-maps.yandex.ru/2.1-dev/?lang=ru-RU&load=package.full"" type=""text/javascript">script>
<script type="text/javascript">
//убираем глюк встроенного в платформу браузера: ошибка сценария Script error при повторном отрытии окна
window.onerror = myOnError;
function myOnError(msg, url, lno) {return true}
var myMap;
ymaps.ready(function ()
{
myMap = new ymaps.Map('YMapsID',
{
center:[//Здесь добавим текущие координаты],
zoom://Здесь установим зум,
controls: ['geolocationControl', 'typeSelector', 'trafficControl'],
behaviors:['default','scrollZoom']
});
//Здесь добавим точки
});
script>
<style type="text/css">
html, body {
width: 100%;
height: 100%;
}
style>
head>
<body>
<div id="YMapsID" style="width:100%;height:100%;"div>
body>
html>
Вместо тега "//Здесь добавим точки" я программно вставляю такой код:
Для А = 0 ПО Буфер.Количество() - 1 Цикл
Строка = Буфер[А];
Если Строка.Широта <> 0 И Строка.Долгота <> 0 Тогда
ТекстСкриптаДобавленияТочекНаКарту = ТекстСкриптаДобавленияТочекНаКарту + "
|myPlacemark" + А + " = new ymaps.Placemark(
| [" + СтрЗаменить(Строка.Широта, ",", ".") + ", " + СтрЗаменить(Строка.Долгота, ",", ".") + "],
| {balloonContent : '" + Строка.Представление + "'},
| {preset: '" + Строка.Цвет + "', draggable: 'true'}
| );
|myMap.geoObjects.add(myPlacemark" + А + ");
|";
КонецЕсли;
КонецЦикла;
В качестве значений Строка.Цвет я использую:
- islands#grayDotIcon
- islands#grayDotIcon
- islands#darkGreenDotIcon
- islands#redDotIcon
А вообще все возможные балуны можно посмотреть здесь: http://api.yandex.ru/maps/doc/jsapi/beta/ref/reference/option.presetStorage.xml
PS2. Выкладываю процедуру рассчета расстояния между двумя точками по прямой по заданным координатам в градусах.
Было взято на Мисте и слегка подправлено:
Функция РасстояниеПоКоординатам(StartLat, StartLong, EndLat, EndLong)
// Передаваемые широта/долгота в градусах и сотых долях
//StartLat: double; // Начальная широта
//StartLong: double; // Начальная долгота
//EndLat: double; // Конечная широта
//EndLong: double; // Конечная долгота
//// Переменные, используемые для вычисления смещения и расстояния
//fPhimean: Double; // Средняя широта
//fdLambda: Double; // Разница между двумя значениями долготы
//fdPhi: Double; // Разница между двумя значениями широты
//fAlpha: Double; // Смещение
//fRho: Double; // Меридианский радиус кривизны
//fNu: Double; // Поперечный радиус кривизны
//fR: Double; // Радиус сферы Земли
//fz: Double; // Угловое расстояние от центра сфероида
//fTemp: Double; // Временная переменная, использующаяся в вычислениях
//Distance: Double; // Вычисленное расстояния в метрах
//Bearing: Double; // Вычисленное от и до смещение
// Константы, используемые для вычисления смещения и расстояния
D2R = 0.017453; // Константа для преобразования градусов в радианы
R2D = 57.295781; // Константа для преобразования радиан в градусы
a = 6378137.0; // Основные полуоси
b = 6356752.314245; // Неосновные полуоси
e2 = 0.006739496742337; // Квадрат эксцентричности эллипсоида
f = 0.003352810664747; // Выравнивание эллипсоида
fdLambda = (StartLong - EndLong) * D2R;
fdPhi = (StartLat - EndLat) * D2R;
fPhimean = ((StartLat + EndLat) / 2.0) * D2R;
// Вычисляем меридианные и поперечные радиусы кривизны средней широты
fTemp = 1 - e2 * (Pow(Sin(fPhimean), 2));
fRho = (a * (1 - e2)) / Pow(fTemp, 1.5);
fNu = a / (Sqrt(1 - e2 * (Sin(fPhimean) * Sin(fPhimean))));
// Вычисляем угловое расстояние
fz = Sqrt(Pow(Sin(fdPhi / 2.0), 2) + Cos(EndLat * D2R) * Cos(StartLat * D2R) * Pow(Sin(fdLambda / 2.0), 2));
fz = 2 * ASin(fz);
// Вычисляем смещение
fAlpha = Cos(EndLat * D2R) * Sin(fdLambda) * 1 / Sin(fz);
fAlpha = ASin(fAlpha);
// Вычисляем радиус Земли
fR = (fRho * fNu) / ((fRho * Pow(Sin(fAlpha), 2)) + (fNu * Pow(Cos(fAlpha), 2)));
// Получаем смещение и расстояние
Distance = (fz * fR);
Возврат Distance/1000;
КонецФункции
PS3. Выкладываю процедуру определения текущих геокоординат. Код оптимизировался на основании 2-недельных испытаний на планшете Samsung Galaxy Tab3.
&НаКлиенте
Функция ОпределитьТекущиеГеокоординаты(ТекущееМестоположение) Экспорт
#Если МобильноеПриложениеКлиент Тогда
ТекущийПровайдер = "gps";
Попытка
ДМ = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ТекущийПровайдер);
Исключение
ДМ = Неопределено;
КонецПопытки;
Если ДМ = Неопределено Тогда
ТекущийПровайдер = "network";
Попытка
ДМ = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ТекущийПровайдер);
Исключение
ДМ = Неопределено;
КонецПопытки;
КонецЕсли;
Если ДМ = Неопределено Тогда
Возврат Неопределено;
КонецЕсли;
Если ТекущаяДата() - МестноеВремя(ДМ.Дата) > 300 Тогда
СредстваГеопозиционирования.ОбновитьМестоположение(ТекущийПровайдер, 5);
ДМ = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ТекущийПровайдер);
КонецЕсли;
ДА = ПолучитьАдресПоМестоположению(ДМ.Координаты);
Если ДА = Неопределено Тогда
ТекущееМестоположение = "Lat: " + ДМ.Координаты.Широта + ", Lon: " + ДМ.Координаты.Долгота;
Иначе
ТекущееМестоположение = СтрЗаменить(ДА.Представление, Символы.ПС, ", ");
КонецЕсли;
ТекущееМестоположение = ТекущееМестоположение + "Date: " + МестноеВремя(ДМ.Дата) + ", Provider: " + ТекущийПровайдер;
Возврат ДМ.Координаты;
#Иначе
Возврат Неопределено;
#КонецЕсли
КонецФункции
