Предпосылки разработки пятого поколения WMS от AXELOT: 

  • Недостаточная производительность по причине использования регистров накопления на последних версиях платформы 1С (подробнее см. отчет по анализу архитектуры с точки зрения производительности);
  • Сложность и трудоемкость настройки процессов;
  • Архитектурные ограничения по дальнейшему развитию типовой функциональности;
  • Недостаточная скорость работы мобильного клиента, особенно в медленных и нестабильных сетях;
  • Отсутствие возможности реализации оффлайн-работы на мобильном клиенте.

Для решения этих и других проблем было решено разработать WMS 5-ого поколения. Система подверглась 100% технической переработке всех ее компонент, так как, в противном случае, невозможно было добиться поставленных целей. 

Ниже перечислены основные нововведения в AXELOT WMS X5 относительно предыдущего поколения WMS, разработанного AXELOT. Анализ проводился относительно функциональности межотраслевого релиза 1С:WMS, который содержит расширенный функционал по сравнению с версией коробочного решения, поставляемой фирмой 1С.

AXELOT WMS X5 в настоящий момент активно развивается, и лючает в себя все больше новой функциональности. Актуальный список нововведений можно получить в компании AXELOT по запросу. 

Общие и технологические аспекты

  • Существенно переработаны интерфейсы системы в сторону их упрощения и повышения удобства работы.

  • Система получила полный англоязычный интерфейс.

  • В среднем достигается увеличение производительности системы в 2-3 раза. В некоторых сценариях достигается увеличение производительности до 10 раз.

  • Изменен подход к реализации механизма настроек алгоритмов планирования, очередей задач, событий и пр. За счет этого скорость исполнения запросов выросла в 2 раза.

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

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

  • Добавились простые и расширенные настройки, что существенно в разы упрощает и ускоряет настройку системы в типовых сценариях

  • Существенно повышена стабильность и скорость обработки и реакции на складские события за счет улучшенного управления сеансами, в которых обрабатываются события.

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

  • Обновлена библиотека стандартных подсистем до версии 3.0

  • Разработано более 500 автоматических тестов, контролирующих качество выпускаемых релизов в ежедневном режиме.

Топология

В AXELOT WMS X5 топология склада создается при помощи специализированного визуального редактора. В отличие от традиционного способа формирования топологии склада (когда топология формируется через создание записи о ячейке в справочнике ячеек), визуальное формирование топологии склада в AXELOT WMS X5 позволяет:

  • получить полное визуальное представление о том, какие зоны и ячейки были созданы и насколько корректно;
  • использовать географическую позицию зон и ячеек относительно друг друга в алгоритмах планирования, что обеспечивает более точное планирование складских операций, минимизирует пробеги и повышает производительность операций;
  • сформировать оперативную и аналитическую отчетность с визуализацией информации на плане склада.




  • Реализован автоматический расчет расстояний между стеллажами и ячейками, которые учитываются во всех алгоритмах системы для оптимизации операций.

  • Такой подход лучше отражает реальную жизнь, а также повышает производительность системы при работе с зонами.

  • Появились конфигурации стеллажей для упрощенного создания стеллажей и ячеек на складе и уменьшения количества ошибок при их создании.

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

Учет товара

  • Это необходимо для описания правил работы с товаром, который имеет упаковки различной кратности, например, коробки по 20 и по 24 штуки.

  • Кконтрольно-идентификационных знаков в соответствии с 487-ФЗ.

  • Учет SSCC-кодов алкогольной и подобной продукции.

  • Для случаев, когда учет товара на складе ведется в упаковках, а на входе и выходе фиксируется масса.

Управление задачами

  • Теперь система может чередовать задачи, например, размещения и отбора паллет.

  • Теперь исполнители могут не только получать задачи из выбранной вручную очереди в порядке приоритета («вытягивающая» схема), но и очереди задач могут быть автоматически назначены исполнителю исходя из текущей загрузки на том или ином участке склада.

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

  • Например, теперь система может учитывать количество исполнителей, уже работающих с заказом.

  • Теперь исполнитель может брать более удобную паллету в системах хранения с ограниченным доступом (хранение в штабеле, в набивных или гравитационных стеллажах и т.п.).

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

  • Реализован отдельный механизм для ведения истории операций по всем местам хранения (ячейкам и паллетам), что позволяет быстро получать оперативную информацию по всей истории операций в разрезе выбранных мест хранения.

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

  • Это необходимо, когда нужно приостановить работу по задаче, но при этом сохранить планы/резервы по ней.

  • Теперь они единые для выполнения задач на ТСД, по бумажной технологии и со стационарного АРМ.

  • При работе по гибридной технологии (ТСД + бумага) задачи, включенные в лист задач, не доступны на ТСД.

Интеграция

  • Для целей интеграции в WMS реализованы объекты ERP (номенклатура, контрагенты, заказы) в том виде, как они чаще всего представлены в популярных ERP-решениях. Таким образом, чтобы обмен данными с ERP выполнялся «один-к-одному», т.е. один объект в ERP соответствует одному объекту в WMS и не требует преобразования при передаче данных. Преобразование из объектов ERP в объекты WMS осуществляется уже на уровне WMS простой параметрической настройкой без необходимости программирования. Это существенно упрощает и ускоряет интеграцию с ERP-системой.

  • Реализован типовой механизм взаимодействия с 1С:ERP на базе интеграционной платформы DATAREON для обеспечения взаимодействия в реальном времени.

  • Обеспечена бесшовность логистического процесса с другими компонентами в рамках платформы AXELOT SCM. Реализован единый подход к совместимости справочной и транзакционной информации для обеспечения целостности логистического процесса. Реализован типовой механизм взаимодействия на базе интеграционной платформы DATAREON для обеспечения взаимодействия в реальном времени.

  • Появилась компонента взаимодействия сервера «1С:Предприятие» с автоматизированным оборудованием: принтеры этикеток, весы, измерители ВГХ, pick-by-light контроллеры, лифтовые стеллажи и т.п.

Входящий поток

  • Приемка теперь выполняется отдельными задачами и работает в единой концепции, как и все остальные операции, что существенно упрощает понимание объема запланированных и выполненных задач.

  • Появился вариант приемки напрямую в места хранения минуя стадию размещения.

  • Появился вариант приемки с раскладыванием по поддонам, в случае поступления продукции внавал.

  • Добавлена возможность контроля план/факта поступления не только в разрезе товарного состава, но и в разрезе грузовых мест.

  • Расчет статусов ожидаемого поступления теперь происходит с учетом настроенного процесса поступления. 

  • Это существенно упрощает процесс настройки условий алгоритмов размещения и их понятность.

  • В алгоритмах размещения появилась возможность указывать произвольные фильтры по ячейкам, в которые можно размещать товар.

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

  • Теперь контроль поступления на ТСД может выполняться в двух режимах – свободном и по плану.

Исходящий поток

  • Добавлена возможность контроля план/факта отгрузки не только в разрезе товарного состава, но и в разрезе грузовых мест.

  • Расчет статусов заказа на отгрузку происходит с учетом настроенного процесса отгрузки.

  • Это существенно упрощает процесс настройки условий алгоритмов отбора и их понятность.

  • В алгоритмах отбора появилась возможность указывать произвольные фильтры по остаткам товара, которые можно планировать для отбора. 

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

  • Данный механизм используется для схем работы cash&carry.

  • Появилась возможность спланировать заказ на разборку комплекта для отбора комплектующих, а также обратно – спланировать заказ на сборку комплекта под заказ на отгрузку.

  • Этот механизм позволяет пользователю отлаживать алгоритм планирования отбора (или выяснять почему так спланировалось). Существенно помогает при настройке процессов.

  • При объединении заказов в рейсы/группы/волны появилась возможность учитывать дополнительные параметры: объем товара, количество строк и другие. Также есть возможность выравнивать создаваемые группы по объему вошедших в них задач.

  • Рейс теперь используется и в заказах на отгрузку, и в ожидаемых поступлениях, тем самым схема его использования стала универсальной, что существенно упрощает взаимодействие с AXELOT TMS или любой другой TMS-системой.

  • Рейс теперь включает в себя функциональность документа «Задание транспортному средству», что упрощает работу с функциональностью управления двором.

  • Группа отбора получила собственный статус, а не вычисляется только по статусу заказов, входящих в нее.

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

  • Используется в случае, если в машине не хватило места для отгрузки целого поддона, но при этом возможно догрузить отдельно несколько коробов. 

  • Используется для исключения заблокированных акцизов и КИЗов из заказов на отгрузку.

  • Контроль отгрузки на ТСД может выполняться в двух режимах – свободном и по плану.

  • Добавлена операция на ТСД для контроля отгрузки по местам хранения (ячейкам/поддонам).

Внутренние операции

  • Схема унифицирована со стратегиями размещения и отбора.

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

  • Округление в меньшую сторону может использоваться при пополнении в несколько проходов, когда остаток пополняется из другой зоны.

  • Реализована возможность сбора нескольких комплектов по одному заказу на комплектацию.

  • Может использоваться при настройке процессов инвентаризации, сбора пустых поддонов и т.п.

  • Это позволяет в оперативном режиме подбирать ворота для прибывших на склад машин.

Биллинг

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

  • Каждая услуга хранения может иметь отдельный график объема запасов остатков, находящихся на складе.

  • Появился новый способ расчета стоимости услуг – по тарифной сетке нарастающим итогом.

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

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

Отчет по анализу архитектуры WMS с точки зрения производительности

В данном отчете рассматривается изменение архитектурных подходов в различных поколениях WMS-систем, разработанных AXELOT. Отчет предназначен для технических специалистов, эксплуатирующих или планирующих эксплуатировать какую-либо WMS-систему, разработанную компанией AXELOT.

Данный отчет включает последние 3 поколения WMS-систем, разработанных AXELOT, которые в настоящий момент доступны для приобретения:

  • 1С-Логистика: Управление складом – система 3-его поколения (далее WMS 3). Тиражируется фирмой 1С с 2008 года по настоящее время. Анализируемый релиз: 3.1.9.3.
  • 1С:WMS Логистика. Управление складом – система 4-ого поколения (далее WMS 4). Тиражируется фирмой 1С с 2012 года по настоящее время. Анализируемый релиз: 5.0.4.1
  • AXELOT WMS X5 – система 5-ого поколения (WMS 5). Тиражируется компанией AXELOT c 2018 года. Анализируемый релиз 5.0.7.18.


Архитектура WMS 3

В WMS 3 для хранения остатков используются Регистры сведений. С точки зрения практики использования платформы 1С, это не совсем стандартное решение, т. к. для такого рода задач традиционно используются Регистры накопления. Тем не менее, решение использовать Регистры сведений для хранения остатков было обусловлено гораздо более высокой производительностью системы в реальном времени, чем это возможно в случае использования Регистров накопления. Логика построения архитектуры в этом случае опиралась не на бизнес-суть объектов метаданных, а рассматривала, каким образом эти объекты метаданных будут отражены в СУБД.

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

Минусом архитектуры WMS 3 является то, что данная система работает с многострочными документами, в которые объединяются строки с задачами, и исполнитель работает с этими документами как с чем-то единым. Такой подход не дает нужной гибкости в настройке и управлении складскими процессами, особенно там, где процессы довольно сложны.

Таким образом, именно нехватка функционала в WMS 3, обусловленная архитектурными ограничениями, поставила вопрос о необходимости разработки нового поколения WMS-системы, более гибкой, которая работала бы с потоками единичных задач и имела в своей основе событийную модель – WMS 4.


Архитектура WMS 4

По причине необходимости существенных архитектурных изменений в 2010 году было принято решение разрабатывать WMS 4 с нуля, без использования каких-либо компонент WMS 3.

При начале разработки WMS 4 встал вопрос о выборе архитектуры хранения остатков. Анализировались 2 варианта: оставить проверенное решение с Регистрами сведений или рассмотреть новую архитектуру с Регистрами накопления.

В конце 2009-ого года фирма 1С выпустила новую платформу 8.2.9, в которой появился функционал Агрегатов. Этот функционал позволял построить Таблицу итогов нужной структуры, которая обеспечивала нужную производительность системы при использовании Регистров накопления. В итоге было принято решение использовать новые возможности платформы 1С и вернуться к более классической схеме хранения остатков на Регистрах накопления. Такое решение позволило использовать стандартные механизмы и проверки при формировании движений по остаткам, уже реализованные внутри платформы, и не требовало написания их аналога на уровне прикладного кода (как это требовалось в случае использования Регистров сведений).

В 2012 году была выпущена финальная версия WMS 4, которая не только покрывала необходимый новый функционал, но и показывала хорошую производительность при работе. Данная система успешно внедрялась и эксплуатировалась на десятках складов под управлением платформы «1С:Предприятие 8.2».

В 2013-ом году фирма 1С выпустила платформу 8.3, которая несла большое число новых возможностей, но кроме того в данной платформе были пересмотрены некоторые уже существующие механизмы, в т. ч. механизм Агрегатов. Эти изменения привели к тому, что использование Агрегатов для целей WMS 4 стало гораздо менее эффективным, а после выхода версии платформы 8.3.8 в 2016 году полностью невозможным.

После проведенного анализа различных вариантов найти полноценную замену механизму Агрегатов без полного переписывания WMS 4 оказалось невозможно. Это сказалось существенным образом на производительности системы WMS 4 на интенсивных складах.

Ниже более детально рассмотрим проблему использования Регистров накопления (оборотных) и Агрегатов на примере одной из задач.

Технические особенности работы агрегатов в разных версиях платформы 1С

В контексте WMS 4 есть ситуация, когда нам нужно посмотреть общий оборот по заказу на отгрузку или ожидаемому поступлению, чтобы понять: «а на сколько мы уже отгрузили, собрали или спланировали по заказу?». При этом нам не интересно, когда был сделан данный оборот по заказу – в прошлом месяце или в текущем, нам надо увидеть сколько всего было.

Для решения данной задачи было принято решение использовать настроенный вручную непериодический Агрегат. Как известно, у Таблицы агрегата строится следующий индекс: 

Период+Измерение1+Измерени2+…+ИзмерениеN

Источник: https://kb.1c.ru/articleView.jsp?id=68
Источник: https://kb.1c.ru/articleView.jsp?id=68

В нашем случае мы не включали Период в Агрегат, остальные измерения включались в порядке следования. В итоге мы получали кластерный составной индекс Заказ на отгрузку + Номенклатура + Состояние + … . В нашей системе 90% запросов строится по связке Заказ на отгрузку + Номенклатура, а остальные 10% — это запросы с отбором только по Заказу на отгрузку, тем самым мы имели идеальный индекс для решения наших задач.

Именно такой подход использовался в WMS 4 при работе в платформе 8.2.

Все изменилось после выхода платформы 8.3, в которой фирма 1С оптимизировала хранение данных в агрегатах. Платформа позволяет построить большое число агрегатов к одному регистру, это увеличивает объем хранимой информации. Чтобы уменьшить этот объем была изменена структура хранения агрегата. Таким образом, если в платформе 8.2 в измерениях хранились настоящие ссылки на объекты или значения, а это в большинстве случаев тип Binary(16), то начиная с платформы 8.3 значения в измерениях агрегатов изменились на числовые (это более легкий тип данных), также добавились таблицы словарей (_AccumRgAggDict*), в которых прописываются соответствия между числовым значением и настоящей ссылкой на значение в таблице.

В итоге запрос к агрегату вида (в 8.2):

Заменился на следующий (в 8.3):

И если в первом случае работал составной индекс, который сразу находил нужные строки по сочетанию Заказ на отгрузку + Номенклатура, то теперь поиск стал работать только по одной из таблиц-словарей, либо по Заказу на отгрузку, либо по Номенклатуре. В таких условиях использование агрегатов стало бессмысленным, и было решено вернуться к Таблице итогов Регистра накоплений.

Действительно, таблица итогов Регистра накопления (оборотного) имеет в 8.2 и первых версиях 8.3 (8.3.1 – 8.3.7) подходящие индексы:

Источник: https://kb.1c.ru/articleView.jsp?id=68
Источник: https://kb.1c.ru/articleView.jsp?id=68

Поставив свойство «Индексировать» измерениям Заказ на отгрузку и Номенклатура, мы получили на Регистре накоплений полный аналог того, что начал предоставлять нам Агрегат, начиная с версии 8.3. Такое решение хуже того, которое было описано выше для платформы 8.2, т. к. в этом случае приходилось искать нужную номенклатуру в заказе простым перебором, однако при заказах, не превышающих 1000 строк, это было вполне удовлетворительно.

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

Источник: https://its.1c.ru/db/metod8dev#content:1590:hdoc
Источник: https://its.1c.ru/db/metod8dev#content:1590:hdoc

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

Как говорилось ранее, наша задача подразумевает, что мы будем смотреть обороты по заказу целиком без разреза периода. И WMS 4 ни в одном из обращений не накладывается условие по периоду. Итого, мы получили глобальную проблему: теперь у нас нет ни одного подходящего индекса для наших запросов. И чтобы прочитать любые данные из данной таблицы, нам надо перебрать каждую запись (сделать полный «scan» таблицы). На таблице в 20-30 млн. записей это занимает порядка 30 секунд. А выполняются такие операции на каждом шагу: при планировании отбора (считаем, сколько еще надо планировать), при выполнении отгрузки каждой палеты (проверяем, что не отгружаем больше плана), при контроле отгрузки, при упаковке и т. д.

При проектировании WMS 4 под платформу 8.2. предполагалось, что обращение к данной таблице будет длиться 0.02-0.04 секунды. Но после описанных выше изменений в платформе 1С, начиная с версии 8.3, с ростом таблицы скорость начинает падать все сильнее и сильнее. Допустим, за первый месяц работы системы в таблице накопились 100 000 записей, и запрос длится 0.1 секунду, что не так критично. Но уже через год в таблице будет 1.2 млн записей, и запрос будет длиться 1-2 секунды, что уже может создать определенные неудобства. Окончательно система встанет, когда запрос будет достигать 20 секунд.

Оценить, когда таблица достигнет критического размера, можно следующим образом. Нужно умножить количество строк в заказах на отгрузку на 2 – это и будет примерно то число, на сколько увеличится таблица контроля отгрузки. Если вы ежедневно отгружаете 10 000 строк заказов (200 заказов в среднем по 50 строк), то 1 млн строк вы получите через 50 дней работы, а 20 млн через 3 года. Если же вы отгружаете ежедневно 100 000 строк заказов, то уже через 3 месяца WMS 4 встанет окончательно.

Бороться с этой проблемой можно регулярной «срезкой» базы данных, однако это сложная и ресурсоемкая процедура, которая требует значительного времени и невозможна при коротких технологических окнах современных складов.

Варианты оптимизации, которые можно было бы реализовать настройкой базы на уровне СУБД, приводят к нарушению лицензионного соглашения по платформе «1С:Предприятие». Согласно лицензионному соглашению, лицензиат обязуется не вносить какие-либо изменения в содержимое баз данных и других наборов данных, в которых система хранит информацию, за исключением тех изменений, которые вносятся штатными средствами, входящими в состав «1С:Предприятие» и описанными в сопроводительной документации. Это требование обусловлено в т. ч. контролем со стороны платформы за структурой БД. В случае изменения структуры БД на уровне СУБД платформа автоматически приводит ее к изначальному виду, требуемому платформой.

Все остальные варианты оптимизации WMS 4 сводились к необходимости полного изменения архитектуры системы – де-факто ее полному переписыванию.


Архитектура WMS 5

Решение о создании WMS 5 было принято в 2016 году после того, когда стало окончательно понятно, что архитектура, реализованная в WMS 4, зашла в технологический тупик и не дает дальше развиваться продукту по причине быстрой деградации производительности. В целом, это нормальный процесс – если развивается технологическая платформа, то должны развиваться и продукты, построенные на этой платформе.

Как и ранее, по причине необходимости существенных архитектурных изменений было принято решение разрабатывать WMS 5 «с нуля», без использования каких-либо компонент WMS 4. Надо сказать, что и сама фирма 1С часто использует такой подход написания «с нуля» при глобальных изменениях платформы. Например, «1С:Управление производственным предприятием 1.х», созданное для платформы 8.1, 8.2, которому на смену пришло написанное с нуля «1С:ERP 2.х», созданное для платформы 8.3.

В WMS 5 было решено вернуться к хранению остатков в Регистрах сведений, хорошо себя показавшему в WMS 3, но уже с опытом, приобретенным при разработке и внедрении WMS 4. При этом также были решены некоторые проблемы WMS 3 (такие, как хранение истории движений по остаточным регистрам). Был проведен еще один анализ структуры запросов данных и частоты их использования. Структура хранения остатков на Регистрах сведений была спроектирована таким образом, чтобы покрыть все запросы минимальным числом индексов. Разделение же хранения истории движений и остатков на 2 независимых объекта метаданных позволило построить независимые по структуре индексы для каждой из таблиц (в регистрах накопления установка свойства «Индексировать» приводит к появлению индекса и в движениях, и в итогах, что не всегда необходимо в рамках решения задачи).

Рассмотренная выше проблема WMS 4 – не единственная, которая появилась в результате развития платформы. Все архитектурные проблемы WMS 4 были проанализированы и перепроектированы под требования и функциональность новой платформы. В WMS 5 были внесены десятки прочих изменений, которые задействовали новые возможности платформы и позволили использовать ее более эффективно, в т. ч.:

  • Пересмотрено хранение той информации, которая приводила к существенной неравномерности плотности индекса по значениям столбца.
  • Был учтен опыт использования конструкторов произвольных настроек в WMS 4 и перестроена схема работы с результатами этой настройки. Это повысило процент переиспользования плана запроса, построенного СУБД по таким конструкторам, что сказалось на скорости планирования отбора, размещения и пополнения, а также на скорости получения задачи из очереди.
  • Реализован переход на более легкие REST-сервисы при работе с ТСД, а также реализована работа с переиспользуемыми сеансами на стороне сервера 1С.
  • Пересмотрена структура кэшируемой информации и точки обновления кэша.
  • И многие другие задачи.