Преобразовать 1с запрос в sql

Обновлено: 19.05.2024

Транслятор запросов и Linq-провайдер для 1С-Бухгалтерии

Latest commit

Git stats

Files

Failed to load latest commit information.

readme.md

This project is licensed under the terms of the MIT license.

Упрощаем интеграцию с 1С за счет двух основных функций:

умеем исполнять обычные запросы языка 1С ( выбрать * из Справочник.Контрагенты ) без участия самой 1С - напрямую через СУБД. Это может быть удобно при использовании механизма разделения данных чтобы выполнить запрос сразу на всех областях информационной базы или даже на нескольких информационных базах, если используется более одного сервера СУБД. Такая возможность становится особенно актуальной при большом числе различных организаций, работающих с одной типовой конфигурацией, например через технологию 1C-фреш.

Для установки Simple1C пакета, выполните следующую команду в NuGet-консоли

Преобразуем запрос в формате языка запросов 1С в чистый sql и исполняем его на реальной СУБД. Используем Irony для синтаксического анализа и построения AST.

На практике работает это следующим образом. Первым делом с помощью команды gen-sql-meta достаем через COM метаданные по объектам конфигурации и сохраняем их в отдельную схему simple1c в sql базе данных (пока поддерживается только PostgreSQL).

Эти метаданные нужны в первую очередь для установления соответствия между именами объектов и реквизитов конфигурации 1С и именами таблиц и колонок в БД. Затем для выполнения запроса используем команду run-sql следующим образом:

Результат выполнения запроса помещается в таблицу в базе, указанной параметром result-connection-string. Пока поддерживается только MS SQL Server в качестве такой базы. Имя таблицы берется из имени файла с запросом. Основные возможности:

Поддерживается большая часть конструкций языка - все стандартные элементы sql (подзапросы, union, group by, order by и т.п.), операторы Значение и Ссылка, функции ПРЕДСТАВЛЕНИЕ, ДАТАВРЕМЯ, ГОД, КВАРТАЛ и другие.

Поддерживается синтаксис для доступа к вложенным реквизитам через точку

При трансляции в sql к такому запросу будут добавлены необходимые цепочки join-ов на справочники контрагентов и договоров.

Можно использовать как русский, так и аглийский варианты синтаксиса - select * from Справочник.Контрагенты эквиваленто выбрать * из Справочник.Контрагенты .

Если вы используете 1С-Фреш и у вас несколько sql баз, то можно передать их все в параметре connection-strings. В этом случае запрос будет выпоняться параллельно на всех базах, а все результаты будут объеденены в одной общей таблице. Можно потом, например, через SQL Server Management Studio применить group by к этой таблице и получить группировку данных между различными базами.

Чтобы понять, какие объекты и реквизиты можно использовать в запросе, можно посмотреть в сгенерированные командой gen-sql-meta метаданные в схеме simple1c , а именно в таблицу tableMappings. В ней есть имена объектов, имена соответствующих им таблиц и такое же соответствие для реквизитов и колонок в таблицах.

Оператор Ссылка можно использовать для ускорения выполнения запроса. Дело в том, что в 1С реквизит может не иметь фиксированного статического типа, а допускать сразу несколько типов. Основной пример - это реквизит субконто, который для разных счетов может ссылается на разные объекты конфигурации: Контрагент, Статья учета и т.п. Если в запросе есть обращение через точку к свойствам такого реквизита ( doc.Субконто1.Наименование ), то единственный вариант получить нужные данные - это заджойниться на все возможные таблицы, в которых есть свойство Наименование . Если в запросе имеется в виду какой-то конкретный тип субконто, то можно воспользоваться оператором Ссылка следующим образом:

В этом примере будет сгенерирован только один джойн - с таблицей контрагентов, что существенно быстрее.

В схеме simple1c есть пара функций для работы с Guid-ами. to_guid преобразует байтовый массив, в котором 1С сохраняет ссылки между объектами, в стандартное строковое представление guid-а. date_from_guid получает дату из строкового представления guid-а. Так как 1С генерирует guid-ы на основе текущего времени, по этой дате можно судить о том, когда был создан объект с данным идентификатором. Эти функции можно использовать в любой части запроса, аналогично стандартным функциям языка запросов 1С.

Можно получить данные по остаткам и оборотам аналогично стандартному отчету ОСВ в 1С. Для этого доступны четыре таблицы. РегистрБухгалтерии.Хозрасчетный.Остатки - здесь лежат помесячные сальдо и обороты без субконто, РегистрБухгалтерии.Хозрасчетный.Субконто1 , РегистрБухгалтерии.Хозрасчетный.Субконто2 , и РегистрБухгалтерии.Хозрасчетный.Субконто3 - здесь тоже самое, только с субконто. Каждая транзакция по счету учитывается в остатках и в одной из таблиц Субконто, в зависимости от количества субконт по данному счету.

Вот статья на Хабре о том, как все это работает.

Автоматическая генерация классов объектной модели по 1С-конфигурации :

Такая команда создаст класс СписаниеСРасчетногоСчета в папке Документы. Этот класс будет обладать всеми свойствами исходного 1С-документа СписаниеСРасчетногоСчета, включая все табличные части. По классу так же будет создано для каждого из объектов конфигурации, на которые эти свойства ссылаются (транзитивное замыкание). Основные возможности:

Для имен генерируемых классов используем исходные русскоязычные идентификаторы из 1С. За счет этого модель становится проще - нет необходимости придумывать англоязычные аналоги для весьма специфических терминов 1С, одни и те же вещи называются одинаково по всей кодовой базе.

Не навязываем механизм управления коннекциями. Здесь возможны различные варианты (ThreadLocal, Pool, пересоздание по таймауту, пересоздание при обрыве и т.п.), многое зависит от приложения и конкретных потребностей. Простейший пример чтобы начать работать:

Абстрагируем ссылки, про них в прикладном коде можно просто забыть - создаем экемпляры классов объектной модели, присваиваем их свойствам других классов, при маппинге на соответствующие COM-объекты ссылки между ними будут проставлены автоматически.

Метод Save сохраняет все объекты, до которых может добраться по ссылкам. Пример выше можно упростить следующим образом

В запросах можно использовать стандартные Linq-операторы (Join, GroupBy пока не реализованы)

Умеем обновлять отдельные строки табличных частей. Так, например, в таком примере

на втором вызове Save будет сгенерирован единственный вызов метода Сдвинуть , меняющий местами две строки.

Инструмент "Транслятор запросов 1С в SQL" предназначен для быстрого и удобного получения SQL-запросов, которые генерируются платформой 1С в различных ситуациях: либо выполнение конкретного запроса на языке 1С, либо запуск кода встроенного языка, который также может формировать SQL-запросы к базе данных. Кроме этого, по полученным запросам можно посмотреть дополнительную информацию для диагностики их работы (затраченные ресурсы, планы запроса и другое). Ниже на анимации Вы можете видеть длинный пример работы транслятора. О каждой функции инструмента ниже будет рассказано подробнее.

Основными возможностями инструмента являются:

Перевод запроса 1С в SQL с учетом всех особенностей работы платформы. Например, если выполнять запрос к виртуальной таблице "Движения с субконто", то фактически будет выполнен не 1 запрос, а целая серия вспомогательных запросов. Инструмент это покажет. Также будут собраны все связанные служебные запросы (получение информации о метаданных, создание и очистка временных таблиц и др.).
Перевод запросов платформы 1С в SQL при выполнении конструкций кода встроенного языка. Вам когда-нибудь было интересно как работает функция "НайтиПоНаименованию(. )"? С помощью этой обработки Вы найдете ответы на все вопросы.
Получение информации о затраченных ресурсах каждого отловленного запроса. Для каждого запроса будут получены показатели использования CPU, логических и физических чтений, операций записи и количество возвращенных записей в запросе.
Возможность посмотреть план для каждого собранного запроса (если такой план есть на стороне СУБД). Вы можете сразу открыть его в SQL Server Management Studio или же сохранить его на диск в формате "*.sqlplan".
Инструмент может быть использован как на тестовом , так и на рабочем окружении . Сам сбор информации о запросах создает минимальную нагрузку на сервер. Подробнее о принципах работы инструмента Вы можете прочитать ниже.
Вывод служебной информации об анализируемой базе данных и СУБД.

Требования к работе:

Платформа 1С версии 8.3.5 и выше.
СУБД Microsoft SQL Server 2008 и выше. 2008 редакция поддерживается в ограниченном режиме в части получения данных расширенных событий по запросам, а также в скорости получения данных.
Возможность подключения через ADO c сервера 1С к экземпляру SQL Server с правами "sysadmin".
Только управляемые формы. Для использования в обычном приложении используйте известные обходные пути.

Из-за особенностей работы Extended Events для редакции SQL Server 2008 инструмент имеет следующие ограничения:

Не все данные по запросам могут быть получены (количество чтений, CPU и др.).
Из-за внутренних особенностей работы сессий Extended Events для достоверного получения данных расширенных событий приходиться делать паузку в 30 секунд перед получением данных из сессий.
Из-за ограничений условий для отбираемых событий в некоторых случаях может быть выполнена обработка большого массива запросов, чтобы исключить излишние данные при выводе.

В остальном больших отличий пока не было найдено.

Таким образом, данная разработка может оказаться отличным инструментом для диагностики работы запросов и кода встроенного языка в части взаимодействия с СУБД, а также для изучения работы платформы 1С с СУБД. Тем более если диагностику нужно выполнить на рабочем окружении!

Принцип работы

Код обработки открыт и Вы можете самостоятельно его изучить. Сейчас же опишем общий принцип работы инструмента:

Начинаем серверный вызов, в контексте которого и будет выполняться сбор информации.
Определяем идентификатор соединения с СУБД, которое выделено платформой 1С из пула соединений для текущего сеанса (серверного вызова). Т.к. платформа использует пул соединений, то для гарантии того, что это соединение не будет использоваться другими сеансами 1С выполняется несколько трюков с временными таблицами.
После того как мы определили идентификатор соединения, запускаем сессию Extended Events для сбора данных о выполняемых запросах с фильтром по базе данных и по соединению.
Выполняем запросы или конструкции кода встроенного языка для анализа.
Обрабатываем собранные данные и завершаем сессии сбора данных.
Очистка от служебных данных.

Профит! Вся информация получена. За счет "точечной" фильтрации по соединению мы можем собирать данные в многопользовательской среде, т.к. такие фильтры и подход сбора информации практически исключает попадание лишних запросов других сеансов в собранные данные.

Да, для сбора информации НЕ используется технологический журнал. Все базируется на расширенных событиях SQL Server, которые позволяют достаточно эффективно собирать данные для анализа, не мешая основной работе приложения. Об этом мы уже говорили в статье "Мониторинг SQL Server с помощью Extended Events (и не только) для 1С. Как держать руку на пульсе?". Единственный минус такого подхода - то, что запрос / конструкции кода все же выполняются, поэтому если в них будет запущено что-то тяжелое, то именно они и могут повлиять на производительность и стабильность работы. Это стоит учитывать, если Вы пользуетесь инструментом на рабочем окружении.

Примеры использования

Рассмотрим несколько небольших кейсов использования инструмента.

Начало работы

Первое, что нужно сделать для продолжения работы - это настроить подключение к базе данных с правами "sysadmin". Если этого не сделать, то продолжение работы будет недоступно.

Настройки изменяйте под свои задачи.

А теперь в путь!

Что скрывается за простым запросом

Теперь можно попробовать транслировать простой запрос. Как на счет вот такого запроса.

Регистр бухгалтерии "Хозрасчетный" есть во многих типовых конфигурациях. Думаю, что многие с ним знакомы.

Теперь выполним его через инструмент.

Один клик - и SQL-запрос в кармане!

Итого, у нас есть:

Простой запрос 1С - простой запрос SQL.

Запрос выполнялся 289 миллисекунд, с 9 логическими чтениями и возвращает 100 записей.

Перейдем к примерам интереснее.

Найти по наименованию

Запрос транслировать хорошо. А можно ли отловить запросы к базе данных при выполнении кода встроенного языка? Можно! Как на счет такого простого примера.

Тут все просто. Сначала находим ссылку на пользователя, а после выводим представление найденного элемента.

Результат получим следующий.

Первый запрос - это поиск по наименованию, а второй - получение представления найденного элемента. Как и в прошлом примере, мы получили информацию о затраченных ресурсах.

Таким же способом Вы можете сделать проведение конкретного документа или любую другую операцию из кода встроенного языка, а после отловить тяжелые запросы на стороне базы данных для дальнейшей оптимизации. Попробуйте!

Сложный запрос

Можно пойти дальше и выполнить запрос сложнее, чем обычный SELECT. Как на счет запрос к одной из виртуальных таблиц регистра бухгалтерии.

Запрос к виртуальной таблице остатков.

И тут также трансляция будет работать как надо. Плюс посмотрим план запроса.

Транслировали запрос и посмотрели план. Жизнь удалась!

Вроде ничего сложного.

Hardcore!

А теперь что-нибудь особенное. Вас когда-нибудь интересовал вопрос как платформа 1С выполняет пересчет итогов? А вот как!

Осталось только разобрать что каждый запрос делает, но это уже другая история.

Некоторые настройки

Описание некоторых настроек:

Вместо заключения

Инструмент специфический, но может пригодиться как для диагностики запросов и поведения платформы 1С, так и для исследования и изучения ее работы. Вместе с отчетом "Просмотр и анализ структуры базы данных (отчет на СКД)" может послужить для решения множества проблем производительности.

Это только первая версия, в будущем он будет развиваться.

В версии 2.0 будут следующие изменения:

Поддержка PostgreSQL
Поддержка файловых баз
Добавление комментариев к частям SQL-запроса для сопоставления с метаданными 1С и удобного чтения текста запросов.
Оптимизации для SQL Server 2016 и выше.
И много другое.

Выход 2 версии будет не раньше, чем во второй половине 2020 года :).

24.08.20 - Добавлена поддержка SQL Server 2008 и улучшена работа с планами запросов

Добавлена поддержка SQL Server 2008
Улучшена работа с планами запросов
Изменена фильтрация по базе данных для улучшения производительности
Добавлена служебная информация о базе и СУБД (версия СУБД, идентификатор и имя базы данных)
Рефакторинг и другие небольшие улучшения

07.01.20 - Опубликована основная версия

Другие ссылки

Авторские разработки

Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.

Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.

История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).

Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.

Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.

Помощник работы с идентификаторами объектов

Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.

Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.

Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.

Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С

Диагностика контекста выполнения (внешняя компонента) - небольшая экспериментальная внешняя компонента для получения дополнительной информации о контексте выполнения.

В первую очередь обработка будет удобна для анализа RLS, чтобы получить реально выполняемый запрос базы данных со всеми ограничениями в удобочитаемом виде.

Пример: у нас есть запрос 1С из конфигурации УПП 1.3, который медленно выполняется под некоторыми пользователями, и мы хотим понять, какой запрос по факту выполняется и по возможности ускорить его.

Видно, что к исходному запросу добавляется громоздкое условие проверяющее доступ пользователя к данной таблице. Предположим, что в организации не используется управленческий учет, тогда проверку доступа RLS можно упростить, отключив контроль по подразделению и оставив контроль по подразделению организации (Операции->Константы->Настройка параметров доступа на уровне записей). Обратите внимание, что при включенном флажке «Результат в терминах 1С», текст запроса максимально приближен к тексту запроса, корректного для выполнения в консоли запроса 1С. Что мне не удалось сделать, так это убрать из текста запроса проверки типа для составных полей, так как для этого пришлось бы использовать полноценный парсер языка запросов SQL. Чтобы запрос был полностью рабочим для консоли запросов, придется руками убрать проверку на составной тип, если такой используется в запросе. В приведенном примере нужно заменить строки

AND T7.ОбъектДоступа_RTRef = 0x000000B5

AND T7.ОбъектДоступа = T1.Подразделение на строку

AND T9.ОбъектДоступа_RTRef = 0x000000B6

AND T9.ОбъектДоступа = T1.ПодразделениеОрганизации

Тогда запрос будет полностью корректным для языка запросов 1с и его можно будет выполнить в консоли.

Дополнительный способ проверки результирующего запроса в SQL

Если при выполнении трансформации снять флажок «Результат в терминах 1С», то результирующий текст запроса будет корректным для языка T-SQL и его можно выполнить в SQL Server Management Studio или в консоли запросов, которая поддерживает выполнение прямых запросов SQL (например моя простенькая консоль SQL запросов). Для нашего примера со списком сдельных нарядов результат будет следующим:

Результат трансформации (снят флажок «Результат в терминах 1С»):

Теперь запрос представлен в исходном SQL виде с дополнительными комментариями к параметрам запроса с представлениями ссылок в 1с и его можно выполнить как обычный запрос на языке T-SQL.

Пример 2

Еще один способ использования обработки – в связке с технологическим журналом, без использования трассировки. Пример: в доработанной конфигурации Документооборот 1.4 под некоторыми пользователями очень медленно открывается список внутренних документов. Настраиваем тех. журнал на отлов событий DBMSSQL и смотрим запросы, которые генерировала платформа при открытии формы списка (для настройки и анализа тех. журнала удобно пользоваться инструментами разработчика, но для просмотра можно использовать и типовую обработку с ИТС ПросмотрТехнологическогоЖурнала.epf). Находим следующий запрос:

Не очень удобно разбираться с таким запросом – нет форматирования, вместо параметров стоят вопросы и т.д., поэтому прогоняем его через трансформатор(все опции включены) и получаем такой вид:

Видно, что однотипные ограничения RLS применяются 3 раза при выполнении запроса динамического списка (это можно понять по характерным конструкциям WHERE EXISTS() или по использованию области доступа «ДокументыИФайлы») и это может быть причиной медленной работы списка документов. С проверкой на доступ к таблице T1 «Справочник.ВнутренниеДокументы» сделать ничего не получится, так как это основная таблица списка, а вот оставшиеся 2 проверки под вопросом. «РегистрСведений.ОбщиеРеквизитыДокументов» T4 используется для получения реквизитов «КорреспондентыДляСписков», «ПредставлениеСостояния», «СодержитОригинал», а таблица «Справочник.ВидыВнутреннихДокументов» T12 используется для получения реквизита «ВидДокумента.ЯвляетсяКомплектомДокументов». Таким образом, можно либо не использовать поля на форме, которые приводят к вызову дополнительных проверок на права доступа, либо убрать проверку RLS для вспомогательного регистра с данными, так как проверка уже выполняется в основной таблице и эффекта от дополнительных проверок в данном запросе нет.

Пример 3

Еще один вариант использования обработки – исследование фактического запроса SQL при обращении к виртуальным таблицам 1с. Меня давно интересовал вопрос, как интерпретируется запрос к виртуальным таблицам. Если с таблицей остатков и оборотов регистров накопления все достаточно очевидно, то, например, с регистрами бухгалтерии было бы интересно посмотреть на фактический запрос при указании разных параметров. Рассмотрим достаточно простой запрос обращения к движениям с субконто за указанный период

Прогоняем запрос через трансформатор(все опции включены) и получаем такой вид:

Получен интересный листинг, который показывает, что фактически происходит выполнение нескольких запросов с формированием временных таблиц. Рассмотрим эти запросы:

1) Выполняется запрос к системной таблице актуальности итогов для всех регистров с отбором по регистру. Это нужно для определения необходимости использования служебных таблиц с итогами и периода, на который эти итоги существуют (может есть и другие функции этого запроса, но мои знания ограничиваются только периодами в итогах — дополняйте в комментариях:))

7) Выбирается максимальный регистратор и номер строки, для отделения следующей порции данных

Разобрав запрос, можно сделать вывод что производительность выборки из виртуальной таблицы ДвиженияССубконто полностью определяется объемами выбираемых данных и если не использовать отбор внутри виртуальной таблицы, то все записи физических таблиц будут прогоняться через временные таблицы порциями по 1000 записей, что очень медленно (даже продвинутая СУБД не сможет оптимизировать такой запрос).

Как настроить трассировку запроса из обработки

За трассировку запроса отвечает 2 поля:

Путь файла трассы — здесь указывается путь к папке, в которую будут сохраняться временные файлы трассировки и имя файла (например D:\Временные файлы\TraceTest). Имена файлов трассировки будут присваиваться автоматически, добавлением номера в конец имени (например TraceTest_54.trc)

Подключение SQL — строка подключения к базе данных (например «DRIVER=;SERVER=PC_1C_003;UID=sa;PWD=123;DATABASE=Localbase»). Строку подключения можно проверить на работоспособность, нажав на кнопку «Проверить подключение».

Трассировка запускается только если исходный запрос написан на языке запросов 1с, поэтому если введен SQL запрос, то поля «Путь файла трассы» и «Подключние SQL» можно не заполнять.

Выводы

Данную обработку можно использовать в связке с технологическим журналом с помощью инструментов разработчика или типовой обработки, а также можно использовать без ТЖ, используя трассировку запроса, встроенную в обработку или запуская трассировку вручную. Для понимания фактически выполняемого SQL запроса, гораздо удобнее видеть наименования таблиц и полей в терминах 1с, видеть представление ссылок 1с и читать форматированный текст запроса с отступами и пробелами.

Форма обработки анализа ТЖ из инструментов разработчика:

Форма типовой обработки с ИТС для просмотра логов ТЖ:

Ссылки

Update 19.09.2017

- При обращении к сервису форматирования убрано использование объекта ЧтениеJSON, для совместимости с 8.2 и версиями ниже 8.3.6

Vofka --> Vofka

Просмотр профиля

Данная обработка облегчает разработчику процесс перевода запросов в формате 1С, в формат T-SQL (Microsoft).

Данную обработку я писал для себя в тот момент когда активно занимался прямыми обращениями к базе данных 1С, в обход сервера приложений.

Обработка позволяет просматривать структуру хранения данных. А так же позволяет без особых усилий перевести наименования полей и таблиц в те наименования которые хранятся внутри СУБД.

Алгоритм использования прост.

1. Необходимо настроить подключение к базе данных.

2. Вставить из буфера обмена запрос в формате 1С, либо воспользоваться конструктором запроса для его построения.

3. Выделяем в текстовом поле где написан запрос, наименование объекта метаданных (Справочник, Документ, Регистр) из которого происходит выборка. Нажимаем кнопку "Транслировать объект".

4. Теперь можно либо по отдельности выделять каждое из полей объекта, либо можно выделить все поля объекта и нажать кнопку "Транслировать поля объекта". Поля будут переведены на внутренне представление. Если перевод массовый, напротив каждого поля будет добавлен комментарий, обозначающий представление поля в метаданных конфигурации.

5. После того как все объекты и их поля будут транслированы можно нажать на кнопку "Транслировать в SQL". Данная кнопка заменяет наиболее часто используемые операторы T-SQL из русского представления в английское, используемое в MS SQL.

Процедуры трансляции не идеальны и именно поэтому, все заточено таким образом, что замена происходит в выделенном фрагменте текста, что бы не испортить запрос.

Важно помнить что трансляция полей всегда происходит в пределах последнего переведенного объекта. Так же обработка не умеет переводить в формат SQL такие виртуальные таблицы как "СрезПоследних" или что-то подобное.

Но тем не менее обработка поможет облегчить процесс написания прямых запросов к СУБД MS SQL.

Данная обработка писалась для облегчения собственного труда и в план работ включена не была. Поэтому делал на скорую руку. Следовательно есть вещи которые можно было бы сделать лучше. А ещё на момент написания я не знал что в 1С можно использовать регулярные выражения, поэтому сейчас написал бы её несколько иначе. Но времени на это нет. Но как бы там ни было, даже в таком виде как сейчас, она мне значительно облегчила работу. Буду рад если данная наработка кому-то хоть как-то поможет.

Читайте также: