Система тайминга

Не видит ценности в Юпитере

Нужно продавать эффективный учёт

 

Тайминг

1. Time to eat (от приёмки до доставки клиенту)
   1. От приёмки заказа до отправки в готовку
      (время создания заказа - это время появления заказа в Юпитере)
   2. Время готовки
      (от времени отправки в готовку до смены статуса на приготовлен - это у нас есть)
      
      1. Время ожидания заказа в очереди на готовку
         (его нет, если готовка по чекам - могут готовить параллельно)
      2. Время готовки конкретного заказа (монитор повара) - влияет на з/п поваров
         (его нет, если готовка по чекам - могут готовить параллельно)
         
      3. Время сборки - влияет на з/п администратора
         (бессмысленно, оно более-менее постоянно)
         
   3. Время доставки
      1. ожидание курьера
         (от статуса приготовлен до статуса назначен курьеру)
      2. время доставки (приложение курьера)
         (от назначения курьера до момента доставки или 1/2 времени от назначения курьера до закрытия заказа)
         (Юпитер умеет рассчитывать плановое время доставки по яндекс-картам (сейчас просто записывается в чек), в теории можно сравнить с фактическим и не дать премию)

 

Что у нас должен контролировать администратор

• • Одна колонка - Видеть сколько времени в минутах осталось на выполнение этого заказа  с учётом времени доставки (это то время доставки, которое мы обещали клиенту)
    • У каждого заказа должно быть время "Приготовить к". Либо указанное клиентом, либо рассчитанное автоматически. Различаться они не будут.
    • Автоматически  "Приготовить к" будет рассчитываться в момент ............. на основании
      • Если доставка, то берём из зоны доставки
      • если агрегатор - то там всегда есть "Приготовить к"
      • если не доставка и "Приготовить к" неизвестно, то считаем, что заказ нужно готовить немедленно - прибавляем к текущему времени время готовки и сборки. 
  • Другая колонка - с оставшимся временем для текущего статуса
    • там показывается "Начать готовить через Х мин", пока это время больше 0. Потом показывается "Отдать через Х мин"  (это и есть время, когда заказ должен быть приготовлен)
    • в зоне деталей выводятся эти два точных времени (во сколько)
    • Если статус больше или равен "готов к передаче клиенту", то ячейка пустая.
  • Показывать кассиру общую текущую длительность очереди заказов
    • время начала готовки первого заказа считаем как время окончания готовки последнего приготовленного заказа
• Если Администратор своевременно отдала заказ курьеру, то она и повара молодцы

Что на кухонном чеке

• • время, когда начать готовить (не позже, чем)
  • время, когда заказ должен быть собран (не позже, чем)

Работающие сотрудники:

• • Кнопка "Сотрудники", которая откроет стандартную форму с 4 полями:
    • Сколько поваров
    • Сколько курьеров на авто
    • Сколько курьеров на велосипеде
    • Сколько курьеров на общественном транспорте
  • Хранить в строках рабочего дня с датой/временем создания записи 
  • Пока считаем очередь на 1го повара

Аналититка

• Просроченные заказы
  • Просрочен в целом
    • Фактическое время передачи клиенту заказа > "Доставать\Приготовить к"
    • Если заказ на доставку, то в момент закрытия заказа нужно проверить указано ли время когда заказ передан клиенту. Если не указано, то нужно рассчитать и записать его. Рассчитывается как время закрытия заказа - 1/2 времени в статусе назначен курьеру.
  • Просрочен по готовке
    • Фактическое время готовки > плановому времени готовки
  • Просрочен по доставке
    • Фактическое время доставки > плановому времени доставки
    • Плановое время доставки это, всё то время, которое остается по заказу после приготовления и сборки по плану
• Длительность очереди в минутах
  • Расчет длины очереди
    
    • Считается и записывается в момент отправки заказа в производство
    • Сумма времен "Сколько нужно на приготовление" всех заказов, которые уже в производстве
    • Учитывать текущее кол-во поваров
  • Отображается в списке заказов вместе с признаком "Заказ просрочен"
• Длительность очереди в минутах
  • Выводить в виде графиков
    • Общая
    • Готовка + сборка
    • Доставка
  • На график выводить
    • Длина очереди
      • Линия максимальное время готовки
      • Линия средняя время готовки по заказам
      • Расчет длины очереди
        
        • Считается и записывается в момент отправки заказа в производство
        • Сумма времен "Сколько нужно на приготовление" всех заказов, которые уже в производстве + время "Сколько нужно на приготовление" текущего заказа
        • Относится к тому часу когда отправили в производство
    • Общее кол-во заказов
      • Гистограмма
    • Кол-во просроченных заказов
      • Гистограмма

Личный кабинет

• Добавить новый блок "Просроченные заказы"
  • Выводить кол-во и сумму просроченных заказов
  • Просрочен в целом
  • Просрочен по готовке
  • Просрочен по доставке
  • Добавить детализацию 2ым уровнем по источникам заказов
  • При нажатии на источник заказа открывать список просроченных заказов по этому источнику
• Расшифровка KPI
  • Переименовать в Аналитика
  • Заказы поднять в самый верх
  • Вывести в заказы
    • Признаки просрочки
    • Длительность очереди в минутах
    • Час отправки в производство
• Длительность очереди в минутах
  • Отображается в списке заказов вместе с признаком "Заказ просрочен"
• Везде в личном кабинете, вместо времени открытия заказа передавать время печати на кухню (если есть)

Что надо контролировать владельцу

• • Общее время доставки (минуты)
    • Через сколько минут заказ появился на точке
      • Во-время или нет
    • Через сколько минут его приготовили
      • Во-время или нет
      • Какова была длительность очереди приготовления в минутах при отправке заказа в готовку
    • Через сколько минут назначили курьеру
      • Во-время или нет
    • Сколько минут доставляли
      • Во-время или нет
• В отчётах для руководства нужно показывать отдельно две ситуации - если не уложились потому что не могли уложиться, и если не уложились, хотя могли уложиться.

 

Есть отчёт по премиям

• в настройке задаётся какой процент от выручки начислять на какой список должностей
  • если общее количество заказов, выполненных в срок больше 80%, то этот % от выручки распределяется между всеми работавшими сотрудниками указанных должностей пропорционально количеству отработанных часов.
  • отчёт проверяет, что статус "Собран" выставлен вовремя
• -плановое время готовки считается как сумма времён готовки изделий
  • - нужно какое-то время по умолчанию - например на подгруппу
  • - интервал времени просрочки Юпитером сейчас не фиксируется, он прописывался сервером  KDS
• Время просрочки готовки сейчас считается так:
  • Плановое время сборки: время, когда заказ появился на мониторе повара (хранится в чеке) + плановое время готовки  (на лету) + плановое время сборки (на лету) и сравнивает с фактическим временем
  • Если текущее время больше планового, то эта дата/время фиксируется как время сборки просроченного заказа
• Время просрочки доставки сейчас не считается, но в теории:
  
  • мы знаем плановое время доставки по яндексу (хранится в чеке) и знаем 1/2 от приёмки курьером до возврата курьера.
• Общее время обработки заказа - нужно сравнивать со временем, указанным в зоне

 

Информация о тайминге

Что такое хорошо и что такое плохо

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

• В списке заказов видеть заказы, где плохо с точки зрения тайминга с возможностью просмотра подробностей
• Где-то видеть индикаторы в целом за смену в оперативном режиме
• И "Красивые отчёты"

 

Принципы

• • На листочках готовить удобнее
  • Заказы возятся по одному, по FIFO
  • Мы на кухонных чеках выводим время, когда этот заказ нужно начать готовить и когда его нужно отдать курьеру (закончить сборку). Но порядок готовки заказов определяется самими поварами.
  • Порядок выполнения заказов определяется точкой, программа его не задаёт. В перспективе, такой порядок можно разработать и утвердить.
•  

Вопросы

• • Выгодно ли принимать заказы в зале в часы пик
  • Каждый отвечает за своё время или коллективно?
  • Позволяет приложение курьера от Яндекса обрабатывать сторонние заказы

 

Что ещё

• • Управление персоналом
    • Сколько надо и в какие дни/часы
      • Повара
      • Курьеры
    • З/п
    • Мотивация
  • Заказы поставщикам
    • чтобы не вводить приходные накладные
  • Финанасы
    • Ввод фин.операций
    • Просмотр БДР и ДДС

 

На будущее

Что может контролировать программа (на будущее):

• • Проверять, успеем ли мы выполнить этот заказ вовремя с учётом очереди готовки и очереди курьеров
    • Учёт очереди готовки
      • Мы знаем, во сколько этот заказ нужно начать готовить.
      • Если текущая очередь текущих заказов выходит за пределы этого времени, то:
        • красим красным цветом ячейку "когда начать готовить"
        • для этого нужно <<просчитать очередь>>
    • Учёт очереди курьеров
      • Пока не делаем - следующим этапом
      • Сделать можно, т.к. мы знаем время доставки и возвращения обратно по яндексу

Обсуждение от 07.12.2023

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

У всех заказов указываем время "доставить к", даже если его нет, по данным из зоны доставки или по предполагаемому времени приготовления блюд (если само вывоз). 

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

Фиксируем в заказе фактическое время готовки по времени когда заказ отправили в готовку и времени когда перевели в статус "готов к передаче". 

Сразу не даем администратору отмечать что заказа готов, только по предполагаемому времени готовки, усредненному времени с учетом кол-ва поваров на смене, и допустимым отклонением.

Запрещаем назначать курьеров. Чтоб курьер сам брал заказы.

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

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

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

Расчетное время возвращения курьеров нужно куда-то записывать.

 

Тех задание 2023-12-07

Комментарий разработчика
Информация по настройке
Доработки сделаны
Нужна доработка
Нужно обсуждение
Отказались

 

• Фиксировать в заказе время "Когда заказ начали готовить"
  • Сейчас фиксируется, когда повар берет заказ через приложение повара (KDS)
  • Если работа с KDS не включена, то фиксируем это время при первой отправке заказа в работу
• Рассчитывать и сохранять в заказ "Время необходимое для приготовление заказа"
  • При печати заказа в работу
    • Сейчас это происходит только если включена работа с KDS
    • Если работа с KDS не включена, то рассчитываем это время при каждой отправке заказа в работу
  • В настройку торгового зала добавить коэффициент времени приготовления, на который будет изменяться рассчитанное время приготовления
    • Настройка в холдинге\торговом зале "Коэффициент времени приготовления"

• Рассчитывать и сохранять в заказ "Когда заказ должны приготовить и собрать"

  • При каждой отправке в работу

  • По формуле "Время необходимое для приготовление заказа" + "Время на сборку заказа"

    • "Время на сборку заказа" задается в настройках холдинга\торгового зала

• Фиксировать в заказе время "Когда заказ приготовлен и собран"

  • При смене статуса на "Готов к передачи клиенту"

  • Добавить проверку, что прошло достаточно времени с начала приготовления.

    • В настройку холдинга и торгового зала добавить параметр с допустимым процентом отклонения
    • Настройка в холдинге\торговом зале "Разрешить отмечать заказ приготовленным, только если прошло не менее % от планового времени приготовления". Если настройка не задана или значение = 0, то проверка не выполняется.
  • Если "Когда заказ приготовлен и собран" больше чем "Когда заказ должны приготовить и собрать", то записывать в заказ 2 времени
    • "Когда заказ приготовлен и собран" = "Когда заказ должны приготовить и собрать"
    • "Когда заказ приготовлен и собран (с просрочкой)" = Текущие дата\время
    • Алгоритм аналогичный таймингу в KDS. Это нужно для работы отчёта по статусам, чтобы показать в нем на сколько времени заказ просрочен в готовке\сборке

• Фиксировать в заказе время "Когда передан курьеру"

  • • При смене статуса на "Передан курьеру"

      • Курьер сам назначает на себя заказ через мобильное приложение

      • Добавить возможность запретить администратору назначать курьеров

        • Настройка в холдинге\торговом зале "Назначение курьера на заказы только через мобильное приложение"

• Рассчитывать и сохранять в заказ "Когда заказ должны доставить"

  • Настройка в холдинге\торговом зале "Автоматически рассчитывать время Доставить к"
  • Для заказов на вынос и в зале. Всегда равно времени "Когда заказ должны приготовить и собрать"
    • Сохраняется в заказ при первой отправке в работу. Не пересчитывается если уже задано.

  • Для заказов на доставку. Рассчитываем по формуле "Время создания заказа" + "Время доставки до" из зоны доставки, и записываем в заказ

    • При создании нового заказа

    • При загрузке заказа с сайта

      • Если клиентом задано время "Доставить\приготовить к", то используем его. Даже если оно меньше чем заявлено в зоне

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

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

• Фиксируем время "Когда заказ передан клиенту"

  • Отмечается курьером через мобильное приложение

  • Если "Когда заказ передан клиенту" больше чем "Когда заказ должны доставить", то записывать в заказ 2 времени
    • "Когда заказ передан клиенту" = "Когда заказ должны доставить"
    • "Когда заказ передан клиенту (с просрочкой)" = Текущие дата\время
    • Алгоритм аналогичный таймингу в KDS. Это нужно для работы отчёта по статусам, чтобы показать в нем на сколько времени заказ просрочен по доставке
• Параллельно с таймингом заказов нужно считать тайминг курьеров:

  • • Рассчитываем "Когда курьер должен вернуться на точку"

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

      • Показать это время в приложении курьера

    • Фиксируем "Когда курьер вернулся на точку"

      • Через мобильное приложение, кнопка "Я вернулся"

    • Не делаем, т.к. цена на запросы очень высокая
      • 1 000 запросов в день стоит 150 000 рублей в года.  Каждые дополнительные 1 000 запросов стоит 300 рублей
      • По сети, в среднем 2 748 заказов в день (2 441 ф, 307 с)
      • Из этого расчета, понадобится пакет на 3 000 запроса в день, что будет стоит 319 000 рублей в год
  • Вывод данных в личный кабинет
    
    • Доработать отчёт "Статусы" в ЛК
      • Вывести колонку "Просрочен по доставке"
      • Убрать статус "Собирается"

    • Добавляем иерархический блок "Просроченные заказы на доставку"

      • Выводится информация только по закрытым заказам на доставку

      • % от общего кол-ва заказов и количество просроченных заказов

      • Разрезы:

        • По общему времени

          • Если выбрано несколько торговых точек, то показывать детализацию по торговым точкам

        • По времени готовки

          • Если выбрано несколько торговых точек, то показывать детализацию по торговым точкам

        • По времени доставки

          • Рассчитывать как разницу между общим кол-вом просроченных заказов и кол-вом просроченных заказов по готовке

          • Если выбрано несколько торговых точек, то показывать детализацию по торговым точкам

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

    • Добавляем иерархический блок "Время выполнения заказов на доставку"

      • Выводится информация только по закрытым заказам на доставку
      • Среднее кол-во минут нахождения в статусе

      • Общее время

        • От "Заказ открыт" до "Заказ доставлен"

      • Время готовки

        • От "Отправлен в работу" до "Готов"

      • Время ожидания курьера

        • От "Готов" до Назначен курьеру"

      • Время доставки

        • От "Назначен курьеру" до "Заказ доставлен"

    • Добавляем иерархический блок "Курьеры"

      • Количество курьеров
      • Сколько сейчас открытых заказов на одного курьера
      • Если выбрано несколько торговых точек, то показывать детализацию по торговым точкам
      • Блок отображает текущую информацию по смена курьера, без истории. Поэтому его нужно показывать только по текущей дате
      • Данные собираются по открытым рабочим сменам их Юпитера. Признак из мобильного приложения не учитывается, т.к. рабочая смена мобильного приложения по умолчанию открыта (т.к. не все используют мобильное приложение)
  • В приложении курьера вывести сколько заработал курьер
    • Данные рассчитывать по настройке начислений исполнителям
      • В расчет должны попадать заказы, которые не закрыты, но доставлены
    • Передавать при авторизации курьера и после отметки, что заказ доставлен

Анастасия

Общее время доставки заказа

 - среднее время

 - по каждому заказу

Сколько курьеров на смене и во сколько они пришли

Сколько сейчас доставок висит на одного курьера

 

 

Доработки 2024-04-03

Доработки мобильного приложения
Доработки Юпитера
Необходимые настройки

 

• Настройки в Юпитере
  • Сервер приложения курьера должен работать на 11.7
  • Касса доставки должна работать на 11.4
  • В настройках торгового зала нужно
    • Заполнить параметр "URL для проверки местоположения курьера". Задается адрес FRServer, например http://192.168.1.10:5500. FRServer должен отвечать на запросы из локальной сети (проверить настройки FRServer, брандмауэр).  Не работает. 
    • Заполнить параметр "API Key Яндекс "Матрица Расстояний и Построение Маршрута""
    • Включить опцию "Назначение курьера на заказы только через мобильное приложение"
  • В карточке торгового зала нужно задать "Координаты торговой точки (широта, долгота)" (вкладка Доставка)
  • Для доступа к списку курьеров включить в кнопках должности "Отображать кнопку "Курьеры""
  • Для доступа к отчётам по доставке (бэкофис), в т.ч. журнал поездок, включить роль ДОСТАВКА / Начальные сценарии / Отчеты по доставке

• Общее
  
  • Механизм открытия\закрытия смены в мобильном приложении упраздняется
    • Смену курьера будут открывать в Юпитере
  • Юпитер хранит состояние курьера:
    
    • Смена закрыта
      • В этом состоянии мобильное приложение не разрешает брать новые заказы, и показывает сообщение, что нужно открыть смену в Юпитере
      • После открытия смены в Юпитере, состояние курьера измениться на "Свободен"
    • Свободен
      • В этом состоянии мобильное приложение позволяет курьеру выбрать заказы и начать поездку
      • После того как курьер примет заказы и начнет поездку его состояние измениться на "Доставляет заказы"
    • Доставляет заказы
      • В этом состоянии мобильное приложение показывает информацию о поездке и список заказов в доставке
      • После того, как все заказы отмечены как доставленные, состояние курьера изменяется на "Возвращается"
    • Возвращается
      • В этом состоянии мобильное приложение позволяет завершить поездку
      • После завершения поездки, статус курьера изменяется на "Свободен"
  • Приложение может запросит состояние курьера с помощью запроса get_courier_state
    • Вместе с информацией о статусе курьера, запрос вернет необходимые для текущего состояния данные
  • Юпитер передает в мобильное приложение адрес FRServer (параметр frserver_address в запросе get_courier_state). Он будет использоваться, для определения местоположения курьера.
• Начало поездки (назначение заказов на курьера)
  • Назначение курьера, только через мобильное приложение
    • В настройках торгового зала включить опцию "Назначение курьера на заказы только через мобильное приложение"
  • В мобильном приложении курьер нажимает кнопку Взять заказы
    
    • Кнопка Взять заказы должна быть доступна только в состоянии "Свободен"
  • Мобильное приложение отправляет запрос на локальный FRServer (для проверки, что курьер находится на точке)
    • Если FRServer отвечает 200, то ОК
    • Если FRServer не отвечает, то выводится ошибка, что курьер не подключен к WiFi магазина
  • Мобильное приложение отправляет запрос get_courier_state в Юпитер на получение списка заказов, которые курьер может назначить на себя
  • Курьер выбирает один или несколько заказов из списка
    
    • Порядок выбора важен. В этом порядке будет построен маршрут.
    • При выборе нужно показывать курьеру порядковый номер заказа в маршруте
  • Курьер подтверждает выбор заказов кнопкой Я уехал
  • Мобильное приложение отправляет запрос appoint_courier в Юпитер со списком заказов, которые курьер взял
    
    • Юпитер назначает курьера на заказы
    • Юпитер строит маршрут через Яндекс
      • <!!!> Не проверялось, нужно купить API-KEY и проверить
      • Во всех заказах должны быть прописаны координаты. Если хоть в одном заказе не прописаны координаты, то маршрут не будет построен
      • В заказах фиксируется время, когда курьер должен привести заказ по Яндексу. К времени каждого заказа прибавляет 10 минут на взаимодействие с клиентом (разгрузку\погрузку)
      • Сервер должен работать на 11.7
      • В карточке торгового зала нужно задать "Координаты торговой точки (широта, долгота)" (вкладка Доставка)
      • В настройках торгового зала заполнить параметр "API Key Яндекс "Матрица Расстояний и Построение Маршрута""
    • Юпитер фиксирует начало поездки. Состояние курьера изменяется на "Доставляет заказы"
  • Мобильное приложение обновляет состояние курьера запросом get_courier_state
  • В мобильном приложении выводится данные о поездке (параметр trip)
    • Учесть, что этого времени может не быть
  • В мобильном приложении выводится список заказов
    • • Для каждого заказа выводится время, когда курьер должен доставить заказ по данным Яндекса (параметр delivery_time_from_routing)
        • Учесть, что этого времени может не быть
• Заказ доставлен
  • Курьер отмечает каждый заказ как доставленный с возможностью изменить вид оплаты (всё как сейчас, без изменений)
    • Заказы, которые уже отмечены как доставленные, нужно как-то отмечать\скрывать (параметр been_delivered) 
    • После того как все заказы из поездки отмечены как доставленные, состояние курьера изменяется на "Возвращается"
• Завершение поездки
  • Когда курьер вернулся на точку, он нажимает кнопку Я вернулся
    • Кнопка Я вернулся должна быть доступна только в состоянии "Возвращается"
  • Мобильное приложение отправляет запрос на локальный FRServer (для проверки, что курьер находится на точке)
    • Если FRServer отвечает 200, то ОК
    • Если FRServer не отвечает, то выводится ошибка, что курьер не подключен к WiFi магазина
  • Мобильное приложение отправляет запрос came_back в Юпитер
    • Юпитер завершает поездку, фиксирует время, когда курьер по факту вернулся
    • Состояние курьера изменяется на "Свободен"
  • Если запрос прошел без ошибок, мобильное приложение фиксирует завершение поездки и показывает кнопку Взять заказы

 

• В кассе Юпитера, нужно выводить список курьеров с информацией о поездках
  • Кнопка в списке заказов
    • Отмечается красным цветом, если есть курьеры, которые опаздывают
    • Касса доставки должна работать на 11.4
  • Включается в кнопках должности "Отображать кнопку "Курьеры""
• Юпитер должен предоставлять аналитический отчёт
  
  • В Юпитере, интерактивный список поездок с фильтрами
    • Находится в разделе Доставка / Отчёты Доставки. Доступ включается ролью ДОСТАВКА / Начальные сценарии / Отчеты по доставке
  • В личном кабинете (нужно обсуждать)

Доработки 2024-07-11

 

• После включения режима "Автоматически рассчитывать время Доставить к" в Суши-Сет, выяснилось, что такое поведение программы сбивает пользователей. Пользователь не понимает, какой заказ реально "Ко времени", а какой нет
  • Было принято решение упразднить этот режим
  • Время "Когда заказ должны доставить" нужно рассчитывать и сохранять в заказ при смене статуса на "Заказ доставлен"
• Изменить расчет параметра "Среднее время ожидания курьера (мин)" в ЛК
  • • Исключить из расчета заказы ко времени
    • Заказы ко времени, это заказы у которых время Доставить К задано клиентом на сайте или администратором, через через кнопку Доставить к)