Трекер (KDS)

Ссылка на описание API сервера KDS

Обозначения

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

Цель

• Отслеживание времени исполнения заказов
• Мотивация сотрудников на быстрое исполнение заказов

Подход

• • Вводится принцип коллективной ответственности точки за соблюдение стандартов времени приготовления - нам не важно, кто крутил роллы, важно, чтобы заказ был сделан во-время.
  • Время приготовления включает в себя время приготовления всех блюд + время сборки для холдинга.
  • Для осуществления контроля вводятся планшеты поваров
    • На точке может быть одна или больше станций готовки (рабочее место повара, где есть всё необходимое для приготовления любого заказа)
    • Все станции готовки идентичны, любой заказ может быть приготовлен на любой станции
    • Система автоматически показывает тот заказ, который нужно выполнять. Повар заказы не выбирает. 

Схема работы

1. Все доработки изменения делаются в новой версии Юпитера (11.7)
2. Заказ приходит на точку
3. Администратор видит список всех заказов, находящихся в данный момент работе
   • Администратор видит заказы, отправленные в производство, в том порядке, как они будут отображаться на мониторе повара (S) +
     
   • В списке заказов напротив каждого заказа видна длительность его выполнения (S) +
     
   • Там же администратор видит в отдельном поле временнЫе требования к этому заказу (указываются администратором через кнопку "Когда приготовить")
     • Для агрегаторов - через сколько приедет курьер
     • Для заказов на время - к какому времени нужно доставить заказ
   • В списке заказов напротив каждого заказа видно, когда по расчёту будет выполнен этот заказ с учетом его места в очереди и длительности приготовления всех предыдущих заказов. 
   • Администратор видит, если заказ не укладывается в сроки
4. Если есть собранные заказы, не назначенные курьерам (заказы в статусе "Собран") , то администратору циклически проигрывается звук. (S) +
   
5. Администратор может поставить заказу признак "Срочно" - заказ ставится в самое начало очереди
   • (Нужно ли уметь двигать заказы в очереди относительно друг друга? Это сильно сложнее в реализации, чем просто признак "Срочно".)
   • (Может принять заказ на конкретное время или поставить заказу время - тогда система сама определит место заказа в очереди, чтобы он был приготовлен во-время - это тоже требует обсуждения. Потому что доставка к включает время доставки, агрегаторы не включают и ещё масса вопросов.)
6. Администратор отправляет заказ в работу (или заказ отправляется в работу автоматически)
   1. При отправке заказа в работу
      1. Рассчитывается длительность приготовления этого заказа и прописывается в заказ (S) +
         
         1. Это происходит при каждой отправке заказа в работу (S) +
            
      2. При приёме заказа администратор может установить признак "Сейчас" - такой заказ ставится в самое начало очереди
         1. Порядок заказов в очереди: 
            1. (Отработка функции "Заказы ко времени" требует отдельного обсуждения. Очень много вопросов возникает. Пока остановимся на том, что администратор может поставить заказ в верх очереди) Заказы на доставку или самовывоз "Ко времени" - в заказе указывается время, когда заказ должен быть доставлен клиенту (если на вынос, то когда приготовить). Для расчета времени, когда заказ должен быть приготовлен, от этого времени отнимается время доставки. Такие заказы должны сами уходить в готовку в нужный момент (появляться в ленте заранее) и ставиться в очередь в нужное место. Это важно.
            2. Заказы в зале
            3. Агрегаторы
            4. Обычные заказы на доставку
         2. Заказ автоматически ставится в какое-то место в очереди, согласно своему приоритету. Чем выше значение, тем выше заказ в очереди. 
            1. Обычный заказа - 490 (Если включена роль Повышенный приоритет для заказов в зале)
            2. Доставка и На вынос - 480
            3. Срочные заказы по кнопке Доставить к - 500 (Если включена роль Работа с кухонными мониторами)
            4. Для более тонкой настройки в параметрах Источника заказа добавлена возможность вводить свои значения для очереди.
7. Заказ появляется на табло электронной очереди
8. Работа повара:
   1. Повар активирует станцию  (нажимает на экране на кнопку "Начать работу")
      1. При этом планшет посылает на сервер запрос "get_order", в ответ получает первый в очереди заказ (товары + длительность приготовления всего заказа) и общее количество заказов в очереди
         1. Сеты раскрываются на роллы
         2. В идеале порядок следования блюд в заказе на экране планшета (вторая очередь)
            • Блюда
            • Имбирь, васаби, соус
            • Палочки
         3. Не должны отображаться те позиции, которые повар не готовит (напитки, гарниры и пр.) - сейчас отображаются все позиции, потому что так принято в сети, чтобы на кухонных принтерах печатался полный чек. Это настраивается в Юпитере в правилах печати, нужно проверить, как повлияет ли эта настройка на печать в других случаях и не вызовет ли это какие-то проблемы (S) - На экране сборщика позиций тоже не будет видно. +
            
   2. При поступлении заказа на монитор, монитор запоминает этот заказ и время, когда он поступил. (K)
      1. Для этого в LocalStorage добавляется запись с номером заказа и текущим временем планшета (K) +
         
      2. При начале работы станции вызывается процедура очистки LocalStorage, которая удаляет старые записи (старше указанного в настройках количества часов) (K) +
         
   3. Станция всегда готовит отображённый заказ целиком, - от и до.
   4. Если в заказ было что-то добавлено/удалено, пока заказ выполняется, то он будет обновлён на мониторе повара оставшееся время изменится.
   5. Если изменённый заказ поступит на монитор после того, как он был однажды выполнен, то отобразятся только новые позиции и новая длительность, но время начала приготовления будет тоже самое - при первом поступлении заказа на монитор. 
   6. Оставшееся время приготовления заказа отображается повару +
      
      1. Монитор показывает оставшееся время, сравнивая сохранённое в LocalStorage время поступления на планшет, длительность приготовления и текущее время планшета. (K)
         
      2. Отображение времени обновляется по параметру из настроек (K)
         
   7. По окончании приготовления:
      1. Повар отмечает заказ как выполненный, при этом:
         1. На сервер отправляется запрос "set_orderstatus" с номером заказа и кодом статуса 3.
            1. В ответ с сервера приходит Ok.
            2. После этого монитор посылает запрос "get_order" и отображается новый заказ (K) +
               
               1. В этом запросе отправляется timestamp, по которому сервер понимает когда был предыдущий запрос и поменялось ли что-то с того времени. Чтобы уменьшить нагрузку на сервер. (S)
         2. Либо по окончании приготовления заказа повар выключает станцию (нажимая на кнопку выхода), тогда:
            1. Выдаётся сообщение повару: "Отметить заказ как приготовленный и завершить работу станции" Да, Нет. (K) +
               
            2. Если Да, то отправляется запрос "stop_work" (K) +
               
            3. Сервер отмечает заказ как приготовленный и возвращает Ok.
            4. Станция завершает работу - отображается экран начала работы
         3. Получив эти запросы, сервер:
            1. Если заказ не просрочен: прописывает в заказ абсолютное время приготовления (S)
               
            2. Если заказ просрочен: прописывает в заказ время приготовления (расчетное) и отдельно - реальное время приготовления. (S)
9. Работа сборщика
   1. Выполненный поваром заказ начинает отображаться на планшете сборщика и начинается отсчёт времени на сборку заказа. - Время на сборку задается в Холдинге общее на сеть.
      Отсчет идет в момент когда заказ отобразился на экране упаковщика. Кол-во заказов на экране сборщика не влияет на логику отсчета времени.
   2. Сборщик собирает заказ, по окончании сборки сначала отмечает, что заказ собран, при этом:
      1. На сервер отправляется запрос "set_orderstatus" со статусом 1.
      2. На сервере меняется статус заказа на "Готов к передаче клиенту"
      3. На мониторе меняется цвет заказа
      4. И в этот момент заказ переходит в статус "Готов" на табло электронной очереди.
         1. В эл.очередь добавить названия зон - "В работе" и "Готово" и сделать фоны разным цветом (K)
            
   3. После этого сборщик может отметить заказ как переданный курьеру или клиенту, при этом:
      1. На сервер отправляется запрос "set_orderstatus" со статусом 2.
      2. На сервере статус заказа никак не меняется т.к. статус "Назначен курьеру" выставляется не здесь.
      3. Заказ исчезает с планшета сборщика
      4. Заказ исчезает из электронной очереди.
10. Основным KPI для начисления премии (поощрения) является % заказов, выполненных вовремя, в конкретный день (S)
    • Начисления будут производится как поощрение (в терминах программы)
    • Поощрения будет рассчитываться и начисляться при акцепте ведомости начислений, когда уже точно ничего меняться не будет. Полученные премии начисляются по количеству отработанных часов.
      Пример Сотрудник отработавший 12 часов получит за этот день премию 142.86 * 12 = 1714.32 р. А сотрудник отработавший за день 6 часов 142.86 * 6 = 857.16 р.
    • Нужен отчёт для персонала, чтобы было понятно почему такая премия. Отчёт можно будет формировать в любой момент, он будет работать от текущих значений рабочего времени, указанных в расписании
    • Для проверки правильности сделанных начислений можно будет использовать отчет по поощрениям, или какой-то близкий ему аналог
    • В системе поощрений участвуют сотрудники работающие на должности Поваров и Администраторов кассиров. 

    • Логика расчёта поощрения:

      • Допустим, размер премии составляет 10% от выручки за день.
        Пример из выручки 60000 10% это 6000.
      • Складываем сумму отработанных часов сотрудников Поваров и Администраторов.
        Пример 3 сотрудника по 12 + один 6 часов = 42 часа.
      • Рассчитываем поощрения на час работы, для этого 10 % выручки делим на сумму отработанных часов.
        Пример 6000 / 42 = 142 р. 86 коп. Премия на час работы.

11. Добавляем в программу новый тип документов - документы настройки поощрений. --

    • • Указываем % от выручки по которому начинаем рассчитывать премию.
      • Указываем список множество должностей к которым премия применима.
      • В целях начисления премии все перечисленные должности одинаковы

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

    • В торговых точках указывается ссылка на этот документ настройки, т.е. документов настроек может быть столько, сколько вариантов настройки. 
    • Должна быть возможность поэтапного подключения точек (по отдельности)
      • Если к точке такой документ не привязан, то на такой точке премии не начисляются.
    • % для должностей всегда один 
12. В отчёте по статусам заказов (в Юпитере и в ЛК) добавляются новые времена: (S)
    
    • "Просрочка выполнения" (после "Выполняется") - отдельное время, которое показывает на сколько позже был приготовлен заказ
      • •  

 

Трекер состоит из четырёх частей

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

 

Станция повара

• • Начало работы:
    • Повар активирует станцию  (нажимает на экране на кнопку "Начать работу"
      

      

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

        

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

 

Планшет сборки заказа

• • Отображает заказы целиком (вообще все позиции, не только роллы)
    • видит расшифровку сетов по роллам
    • Гарниры надо сворачивать как на бумажном чеке (S)
  • Отображает время, прошедшее с момента приготовления заказа поваром
  • Нужно два статуса - "Собрано" и "Отдано". 

 

Электронная очередь

• Смотрит в торговый зал, чтобы клиенты видели статус приготовления их заказов и общую очередь заказов
• Заказ появляется в очереди в момент отправки в готовку администратором
• Заказ переходит в состояние "Готов", когда сборщик отметит заказ, как собранный
• Заказ исчезает из очереди, когда сборщик отметит заказ как переданный (курьеру или клиенту)

 

 

 

Настройки

• • Делаем в программе перечень станций готовки, чтобы система могла распределять между ними заказы:
    • Кодификатор в проекте "Станция 1" - "Станция 4" с кодами от 1 до 4
    • На страницу настроек монитора повара добавляем поле выбора станции (из жёсткого списка) с кодами от 1 до 4 - т.о. каждая станция сама знает свой номер.
  • Нормативное время приготовления роллов указывается в каждом изделии - сете, ролле..
  • (Пока под вопросом) Нормативное время сборки заказа указывается одно для всех
  • Если возникли проблемы с старыми настройками сервера KDS - удалить файлы по пути папка пользователя\AppData\Roaming\Domino8\JUPITER\profile\_profile.217....

 

Приложение курьера

• После сборки заказа администратор через карту назначает курьера
• Одна из функций - функция мотивации
  • Соблюдение норматива времени доставки
    • Нормативное время доставки считается по роутингу Яндекса (время маршрута от текущего положения курьера до ресторана и до клиента + стандартное фиксированное время).
      • Если запрашивать длительность маршрута каждый раз при назначении курьера, то это будет точно (с учётом текущих пробок), но потребует большого количества запросов к геолокации Яндекса, кроме того, эти запросы могут подвисать на 10-20 сек.
        • При назначении заказа на карте нужно передать в Юпитер длительность самой доставки для определения расчётного времени (R)
        • Это время записывается в заказ для передачи в приложение курьера (S) 
      • Если один раз прописать в адрес клиента время доставки от ресторана, то это будет менее точно (без учёта текущих пробок), но потребует существенно меньшего количества запросов к Яндексу и будет меньше подвисаний. Запрос времени доставки будет происходить один раз для одного клиента. Для новых клиентов можно делать этот запрос при добавлении клиента.
  • Оплата курьеру
    • Почасовая
    • Если заказ доставлен во-время, то курьер получает одну сумму за доставку заказа, если не успел - то гораздо меньшую.
      
      • Сейчас сумма за доставку берётся из зоны доставки. Соответственно в зоне будут две суммы - одна за вовремя доставленный заказ, другая - за не вовремя доставленный.
      • Сейчас это работает так, курьеры получают за заказы день в день на точке. Предполагаем, что так и останется.
  • Курьер должен видеть в приложении рядом с каждым заказом обратный отсчёт времени (K)
  • Отметить доставку можно только рядом с пунктом назначения (должно работать, проверить) (K)
  • Тестируем
    • Железнодорожный
      • через Диму
    • Комендантский 17
      • Станислав