В этой статье разберем, как данные iiko становятся входом для WFM TARGControl: как забирать из POS почасовую выручку и количество чеков, превращать их во временные ряды, использовать для прогноза нагрузки и дальше — для планирования смен и аналитики.

Прежде чем перейти к API и эндпоинтам, ответим на вопрос «зачем вообще тащить POS в планирование». В HoReCa расписание проверяется не отчетом в конце недели, а кассой и залом в ближайшие 1–2 часа: спрос распределен неравномерно по времени, каналам (зал/доставка/навынос) и дням недели. Поэтому устойчивое планирование начинается не с «графика в таблице», а с измеримых драйверов спроса, которые можно регулярно обновлять автоматически.

Кадровый дефицит только повышает цену ошибки: недокомплект в пиковое окно дает перегруз сотрудников, потери выручки и ухудшение сервиса, а избыток в «тихие» часы — прямые лишние часы ФОТ. В результате управляемая зона смещается в две практические вещи: точнее попадать сменой в почасовой профиль спроса и иметь механизм быстрых корректировок, когда фактическая картина отклоняется от плана. POS-контур iiko как раз и дает основу для такого подхода — данные, на которых можно строить прогноз и честно сравнивать «продажи ↔ часы».

Ключевые особенности HoReCa, которые ломают ручное планирование:

Почасовая волатильность: ланч/вечер, будни/выходные, зал/доставка — разные профили нагрузки.
Высокая цена ошибки: недобор в пике = очередь и потери; перебор в провале = лишний ФОТ.
Ролевая структура: важен не «N человек», а состав по ролям/навыкам (кухня/зал/бар/доставка).
Операционный шум: невыходы/опоздания/подмены — регулярность, а не исключение, значит нужен контур быстрых замен.

Что такое система WFM для общепита

WFM (Workforce Management) — это система, которая связывает фактическую нагрузку и график работы. По сути, она нужна, чтобы ответить на три практических вопроса:

Сколько людей нужно по часам и ролям?
Кого назначить с учетом навыков, доступности и ограничений?
Как реагировать на отклонения без ручного хаоса?

Базовая цепочка WFM

Прогноз драйвера по часам (выручка/чеки/структура каналов).
Расчет потребности: перевод прогноза в человеко-часы по ролям/зонам через нормы и SLA сервиса.
Построение смен: правила, доступность, навыки/допуски, нормы ТК, лимиты часов.
Учет факта: сравнение план/факт (невыходы, опоздания, переработки).
Замены и обмены: открытые смены/биржа/подработки в рамках правил и ограничений.
Аналитика план-факт: продажи↔часы, покрытие пиков, overtime, дефицит ролей.

Почему прогноз без POS — это «умные шаблоны», а не WFM

На практике ограничения WFM почти всегда упираются в данные:

без POS-драйверов прогноз становится «по шаблонам»;
без факта (учета выхода) план-факт не замыкается и модель не улучшается;
без норм и стандартов сервиса нельзя корректно перевести спрос в человеко-часы.

В российской HoReCa роль источника фактической нагрузки чаще всего выполняет POS, и в большинстве сетей — iiko. Поэтому интеграция iiko → TARGControl — это не «дополнение», а техническая база для цепочки «факт продаж → прогноз → потребность → график → факт выхода → план-факт».

Как устроена интеграция iiko → TARGControl

Основная задача интеграции — синхронизировать почасовые показатели из iiko: количество транзакций (чеков) и сумму выручки, чтобы далее использовать их в TARGControl для прогноза нагрузки и построения смен.

Интеграция с iiko реализована через API iikoServer. Этот API дает доступ к ключевым сущностям, которые используются в WFM-контуре: справочникам (в т.ч. номенклатуре), отчетам по продажам/выручке, данным по сотрудникам. (полную документацию можно найти на официальном сайте). Далее разберем практический минимум эндпоинтов, необходимых для выгрузки почасовой выручки и чеков.

1) Синхронизация локаций (ресторанов)

Прежде чем забирать продажи, нужно определить локации, чтобы разделять данные по отдельным ресторанам. В iiko такой локации соответствует подразделение типа “Торговое предприятие” — сущность DEPARTMENT.

Список подразделений получаем запросом:

GET {{baseUrl}}/resto/api/corporation/departments?key={{key}}

где

baseUrl - url нашего сервера (Например, http://localhost:8080)

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

В ответ мы получим данные в виде XML документа примерного вида:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<corporateItemDtoes>
    <corporateItemDto>
        <id>b5909f4b-bff1-4b80-bb42-0932e23e12cf</id>
        <parentId>1e1dab62-6074-4f80-8ffb-e9ad4d8ff80c</parentId>
        <code>1</code>
        <name>Ресторан 1</name>
        <type>DEPARTMENT</type>
        <taxpayerIdNumber>1111111111</taxpayerIdNumber>
    </corporateItemDto>
    …
</corporateItemDtoes>

Из списка corporateItemDtoes нас интересуют сущности структуры corporateItemDto с type DEPARTMENT. Именно их мы будем использовать в TARGControl в качестве локаций. Запомним id сущности, он нам пригодится далее для получения отчета по выручке.

2) Подготовка датасетов в TARGControl

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

3) Получение почасовой выручки и чеков через OLAP-отчеты

Для выгрузки показателей используем API построения OLAP-отчетов iiko.

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

GET {{baseUrl}}/resto/api/v2/reports/olap/columns?key={{key}}&reportType=SALES

Здесь в качестве параметра передаем reportType со значением SALES, чтобы получить поля отчет по продажам.

В ответ получаем JSON со списком полей. Для нашей задачи важны следующие:

{
    …
    "OpenDate.Typed": {
        "name": "Учетный день",
        "type": "DATE",
        "aggregationAllowed": false,
        "groupingAllowed": true,
        "filteringAllowed": true,
        "tags": [
            "Время"
        ]
    },
    …
    "HourOpen": {
        "name": "Час открытия",
        "type": "STRING",
        "aggregationAllowed": false,
        "groupingAllowed": true,
        "filteringAllowed": true,
        "tags": [
            "Время"
        ]
    },
    …
    "DishSumInt": {
        "name": "Сумма без скидки",
        "type": "MONEY",
        "aggregationAllowed": true,
        "groupingAllowed": false,
        "filteringAllowed": false,
        "tags": [
            "Оплата"
        ]
    },
    …
    "UniqOrderId": {
        "name": "Чеков",
        "type": "INTEGER",
        "aggregationAllowed": true,
        "groupingAllowed": false,
        "filteringAllowed": false,
        "tags": [
            "Заказ"
        ]
    },
    …
    "Department.Id": {
        "name": "ID подразделения",
        "type": "ID_STRING",
        "aggregationAllowed": false,
        "groupingAllowed": true,
        "filteringAllowed": true,
        "tags": [
            "Корпорация",
            "Организация"
        ]
    },
    …
}

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

Для этого выполним запрос:

POST {{baseUrl}}/resto/api/v2/reports/olap?key={{key}}

тело запроса:

{
  "reportType": "SALES",
  "buildSummary": false,
  "groupByRowFields": [
    "OpenDate.Typed",
    "HourOpen"
  ],
  "aggregateFields": [
    "DishSumInt",
    "UniqOrderId"
  ],
  "filters": {
    "OpenDate.Typed": {
      "filterType": "DateRange",
      "periodType": "CUSTOM",
      "from": "2026-02-01T00:00:00.000", 
      "to": "2026-02-07T00:00:00.000" 
    },
    "Department.Id": {
      "filterType": "IncludeValues",
      "values": ["b5909f4b-bff1-4b80-bb42-0932e23e12cf"]
    },
  "DeletedWithWriteoff": {
      "filterType": "IncludeValues",
      "values": ["NOT_DELETED"]
    },
   "OrderDeleted": {
      "filterType": "IncludeValues",
      "values": ["NOT_DELETED"]
    }
  }
}

В качестве ответа получим данные по часам:

{
    "data": [
        {
            "DishSumInt": 3570,
            "HourOpen": "09",
            "OpenDate.Typed": "2026-02-01",
            "UniqOrderId": 2
        },
        {
            "DishSumInt": 6530,
            "HourOpen": "10",
            "OpenDate.Typed": "2026-02-01",
            "UniqOrderId": 4
        },
        {
            "DishSumInt": 8825,
            "HourOpen": "11",
            "OpenDate.Typed": "2026-0201",
            "UniqOrderId": 5
        },
        …
        {
            "DishSumInt": 13205,
            "HourOpen": "20",
            "OpenDate.Typed": "2026-02-10",
            "UniqOrderId": 9
        },
        {
            "DishSumInt": 18405,
            "HourOpen": "21",
            "OpenDate.Typed": "2026-02-10",
            "UniqOrderId": 12
        },
        {
            "DishSumInt": 3230,
            "HourOpen": "22",
            "OpenDate.Typed": "2026-02-10",
            "UniqOrderId": 3
        }
],
    "summary": []
}

Значения OpenDate.Typed и HourOpen объединяем и получаем дату и время 2026-02-01T09:00:00.000+03:00. Соответственно в этот час было проведено 2 чека на общую сумму выручки 3570 у.е.

Таким образом, OLAP API iikoServer позволяет стабильно забирать почасовую выручку и количество чеков в разрезе локаций (DEPARTMENT). Эти данные загружаются в датасеты TARGControl и дальше используются как вход для прогнозирования нагрузки, расчета потребности в персонале, формирования и корректировки смен в WFM-контуре.

Вывод: что дает связка WFM + iiko для ресторанов

Интеграция WFM с iiko решает прикладную задачу: поднять почасовой контур спроса (чеки/выручка) из POS и превратить его в управляемый вход для планирования смен. На практике это позволяет уйти от ситуации, когда график строится «по ощущению» или «по среднему дню», и перейти к модели, где расписание проверяется и корректируется в метриках бизнеса: продажи ↔ часы ↔ ФОТ.

Ключевой результат интеграции — не сам факт выгрузки отчета, а то, что появляется общий язык данных для WFM-управления:

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

Что важно учесть при промышленной эксплуатации:

Качество мастер-данных: стабильные ID локаций, единые правила сопоставления, отсутствие дубликатов.
Согласование календаря и часовых зон: одинаковая интерпретация “учетного дня”, времени открытия, переходов суток.
Семантика метрик: что именно считается выручкой (до/после скидок, возвраты), что считается транзакцией (уникальный чек vs заказ), как фильтруются удаленные/списанные записи.
Регулярность и инкрементальная загрузка: как часто обновляем данные (час/день), как догружаем поздние правки, как контролируем полноту.

Почему это “фундамент WFM”, а не просто отчетность:
WFM опирается на динамику: чтобы прогноз работал, нужны регулярные временные ряды; чтобы план-факт был честным — нужны единые правила времени и фильтрации; чтобы управлять пиками — нужен быстрый пересчет потребности и механизм закрытия отклонений. POS-контур iiko дает именно эту базу: спрос становится измеримым и сравнимым с трудозатратами.

Итоговая рамка для HoReCa

Связка TARGControl WFM + iiko не “отменяет” дефицит персонала. Она делает дефицит управляемым:

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

Интеграция iiko и WFM: автоматизация расписания под почасовые продажи