Интеграция 1С с iiko 2026: продажи, склад, оплаты и возвраты без ручной сверки

Интеграция 1С с iiko нужна не для красивой стрелки между двумя системами, а для закрытия дня без ручного переноса чеков, актов реализации, списаний, оплат и возвратов. В ресторане операционный контур живёт в iiko: касса iikoFront закрывает заказы, iikoOffice считает склад и себестоимость, iikoCloud API отдаёт справочники, меню, типы оплат и заказы доставки. 1С обычно остаётся контуром бухгалтерского, налогового и управленческого учёта: юрлица, счета, НДС, зарплата, поставщики, регламентированная отчётность.

Главная ошибка — считать обмен «выгрузкой Z-отчёта». На практике ломаются не только суммы продаж, а связки: блюдо -> техкарта -> ингредиент -> склад -> статья затрат -> счёт учёта -> тип оплаты -> возврат. Если это не описать до настройки, бухгалтер всё равно будет каждый месяц вручную объяснять расхождения между iiko и 1С.

Ключевые факты

• iikoCloud API в 2026 году документирован через OpenAPI: есть методы для организаций, групп терминалов, номенклатуры, типов оплат, стоп-листов и заказов доставки, включая выборку изменённых заказов по revision.
• iikoFront API — это отдельный контур плагинов на кассовом терминале: через него обрабатываются внешние оплаты, предоплаты, silent-оплаты и возвраты, но складской обмен с 1С обычно строится не внутри Front-плагина.
• iikoOffice отвечает за ресторанный склад: после продажи iiko списывает продукты по техкартам, пересчитывает остатки и себестоимость, а документы инвентаризации живут в складском разделе Office/Web.
• Для бухгалтерии критичны не «чеки вообще», а раздельные разрезы: организация, торговая точка, склад, кассовая смена, ставка НДС, тип оплаты, скидка, возврат, доставка, агрегатор.
• Типовая выгрузка в 1С подходит для базового регламентированного учёта, но сетям и доставке часто нужна прослойка: очередь, журнал ошибок, маппинг GUID, повторная отправка и сверка контрольных сумм.
• Стоимость настройки Синхрон1С для сценария iiko -> 1С — 30 000 ₽ за проект, если нет доработки нестандартной конфигурации 1С.

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

Что синхронизируется между iiko и 1С

Как устроены контуры iiko: Cloud, Front и Office

iikoCloud API нужен для серверной интеграции. Через официальную документацию api-ru.iiko.services/docs проверяются методы /api/1/access_token, /api/1/organizations, /api/1/terminal_groups, /api/1/nomenclature, /api/1/payment_types, /api/1/deliveries/by_revision, /api/1/stop_lists. Для обмена с 1С это удобно: можно забрать справочники, типы оплат, меню и изменения заказов, не ставя плагин на каждый кассовый терминал.

iikoFront API работает внутри кассового Front и нужен, когда интеграция должна участвовать в оплате. В документации описаны Pay, PaySilently, EmergencyCancelPayment, ReturnPayment и ReturnPaymentWithoutOrder. Практический вывод: если платёж уже проведён внешней системой, в 1С нужно хранить transactionId/внешний идентификатор, иначе возврат нельзя надёжно связать с исходной оплатой.

iikoOffice / iikoWeb — контур товарно-складского и управленческого учёта. Официальная страница iiko по ресторану прямо описывает автоматическое списание продуктов со склада после пробития чека и пересчёт остатков при исправлении старых документов. Документы инвентаризации отображаются в складском разделе, а выгрузка в 1С упоминается в финансовом блоке iiko как штатный сценарий внешнего обмена.

Синхрон1С связывает iikoCloud/iikoOffice и 1С: продажи, склад, оплаты, возвраты и журнал ошибок обмена.

Практическая диагностика перед запуском

Перед настройкой мы не начинаем с кода. Сначала берём одну уже закрытую кассовую смену, один возврат, одну доставку с агрегатором и один складской документ iikoOffice. По ним видно, будет ли обмен работать в реальной бухгалтерии, а не только на тестовом заказе.

Минимальная проверка занимает 60-90 минут:

1. Получить токен iikoCloud через /api/1/access_token и сразу проверить, какие организации вернул /api/1/organizations. Если нужного юрлица нет в ответе, дальше обмен не настраиваем: сначала исправляем права api-login.
2. Сравнить terminalGroupId с фактической точкой продаж и проверить /api/1/terminal_groups/is_alive. Для доставки это критично: заказ может быть принят в облаке, но не дойти до конкретного Front.
3. Выгрузить номенклатуру и типы оплат. В отдельной таблице фиксируем пары iiko id -> 1С справочник: блюдо, ингредиент, склад, тип оплаты, ставка НДС, статья движения денег.
4. Взять закрытую смену и сверить не только итоговую выручку, а четыре контрольные суммы: наличные, карты, внешние оплаты/агрегаторы, возвраты. Если они сходятся только общей суммой, в 1С потом не сойдутся банк и касса.
5. Проверить склад на одном блюде с модификатором: что списалось в iikoOffice, каким документом это должно стать в 1С и на какой склад попадёт себестоимость.
6. Прогнать повторную отправку того же документа в тестовую 1С. Если создаётся дубль, значит, не хватает идемпотентного ключа или таблицы соответствий GUID.

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

Риски интеграции 1С и iiko

Типовые сбои обмена iiko -> 1С

1. 401 или пустой список организаций в iikoCloud. Обычно это не «сломался API», а неверный api-login, истёкший токен или нет прав на нужную организацию. Токен нужно получать через /api/1/access_token, а доступ проверять по /api/1/organizations.
2. Терминальная группа недоступна. Перед отправкой заказов доставки полезно проверять /api/1/terminal_groups/is_alive: если Front спит или терминал недоступен, заказ может зависнуть до ручного вмешательства.
3. Продажи есть, списаний нет. Часто в 1С выгружают только чеки, а склад iikoOffice не забирают. Для ресторана это половина обмена: без списаний и актов реализации бухгалтерия видит выручку, но не видит себестоимость.
4. Возврат попал в другой день. В iikoFront возврат может инициироваться с экрана закрытого заказа или как возврат внешней оплаты. В 1С нужно явно выбрать правило: сторнировать исходный день или отражать возврат датой операции.
5. Агрегаторы доставки портят сверку. Заказ оплачен гостем в приложении агрегатора, ресторан получает деньги позже и за вычетом комиссии. В 1С это не «оплата картой», а задолженность агрегатора плюс комиссия.
6. Один GUID переиспользован после тестов. При первичной настройке разработчики часто гоняют тестовые заказы в боевой базе. Если не отделить тестовый источник и не хранить идемпотентный ключ, повторная загрузка создаёт дубли.
7. Инвентаризация проведена после выгрузки остатков. В iikoWeb инвентаризации могут иметь статусы активная/завершённая/просроченная. В 1С надо брать только проведённые документы и не смешивать плановый подсчёт с фактической корректировкой.
8. Скидки и бонусы уменьшают не ту сумму. Для бухгалтерии важно, где скидка уменьшает выручку, где является маркетинговым расходом, а где оплатой бонусами. Это задаётся не в API, а в правилах отражения в 1С.

Как настроить обмен за 3 шага

Шаг 1. Разобрать учётную модель. Напишите @onoutnoxon: сколько ресторанов, юрлиц, складов, касс, агрегаторов доставки и конфигураций 1С участвуют в обмене. Отдельно фиксируем, где ведутся поставщики и закупки: в iikoOffice или в 1С.

Шаг 2. Подключить iiko и 1С. Получаем доступ к iikoCloud API, проверяем организации, терминальные группы, номенклатуру, типы оплат и заказы. В 1С создаём технического пользователя, правила маппинга и документы: реализация/отчёт о розничных продажах, списание, поступление, возврат, корректировка остатков.

Шаг 3. Запустить контроль закрытия дня. Первый период не автоматизируем «вслепую»: сверяем 3-7 закрытых смен по суммам оплат, выручке, возвратам, складам и себестоимости. После сверки включаем расписание, очередь повторов и Telegram-уведомления по ошибкам обмена.

Когда типовой выгрузки достаточно, а когда нужна доработка

FAQ

Что лучше считать источником номенклатуры: iiko или 1С?

Для ресторана чаще источником меню и техкарт является iiko, потому что там живут блюда, модификаторы, технологические карты и списания. 1С может оставаться источником поставщиков, закупочных цен и регламентированного учёта. Главное — не разрешать двум системам независимо создавать один и тот же товар.

Можно ли выгружать только Z-отчёт?

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

Как часто запускать обмен?

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

Поддерживаются ли возвраты и частичные возвраты?

Да, но их нельзя сводить к одной отрицательной строке. iikoFront API различает возврат оплаты, экстренную отмену оплаты и возврат без исходного заказа для внешних типов оплаты. В 1С нужно хранить связь с исходным заказом/платежом и правило отражения даты.

Что делать с оплатами агрегаторов доставки?

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

Можно ли настроить без программиста 1С?

Если конфигурация типовая и нужен стандартный набор документов, да: доступы, правила и расписание настраиваются через Синхрон1С. Если база 1С сильно доработана, есть нестандартные счета, распределение по ЦФО или фабрика-кухня, потребуется точечная доработка правил.

Смотрите также

• Интеграция 1С с онлайн-кассой: Атол, Эвотор
• Мониторинг 1С: уведомления в Telegram
• Автоматическая выгрузка из 1С по расписанию
• Интеграция 1С с Эвотор: синхронизация продаж и остатков
• Отчёты СКД 1С и дашборды

Стоимость интеграции — 30 000 ₽ за проект, включая разбор текущего обмена, маппинг оплат/складов, настройку расписания и журнал ошибок. Напишите в Telegram: @onoutnoxon.

Подробнее о возможностях — на странице Синхрон1С.

Источники:

• iikoCloud API, официальная OpenAPI-документация (/organizations, /terminal_groups, /nomenclature, /payment_types, /deliveries/by_revision, /stop_lists): https://api-ru.iiko.services/docs
• iikoAPI, форматы доступа Custom/Connector/Solution и условия доступа к документации: https://api.iiko.ru/
• iikoFront API: внешние типы оплаты, Pay, ReturnPayment, EmergencyCancelPayment, ReturnPaymentWithoutOrder: https://iiko.github.io/front.api.doc/v6/ru/PaymentProcessor.html
• iikoFront API: добавление оплат, внешних оплат, предоплат и ограничения возвратов из плагина: https://iiko.github.io/front.api.doc/v6/ru/Payments.html
• iikoFront API: сторнирование заказа через API V8Preview7: https://iiko.github.io/front.api.doc/2023/10/18/storno-order.html
• iikoWeb Help: инвентаризация, статусы документов и складской процесс: https://ru.iiko.help/article/iikoweb/inventory
• iiko.ru: ресторанный склад, автоматическое списание продуктов после чека, пересчёт остатков и выгрузка в 1С: https://iiko.ru/solutions/iikorms-tableservice
• Руководство iikoOffice 8.0, разделы по возвратам поставщикам, инвентаризации, iikoKitchen и отчётам продаж: https://ru.iiko.help/resources/Storage/archive/PDF/RU_iikoOffice_8.0.pdf
• Платформа 1С:Предприятие, механизмы обмена данными, XML-сериализация, повторная отправка и устойчивость к потере сообщений: https://v8.1c.ru/platforma/obmen-dannymi/

Для статьи использован AI-ассистент для структуры и поиска источников; факты по методам iikoCloud API, внешним оплатам/возвратам iikoFront, складским операциям iikoOffice и механизмам обмена 1С проверены вручную по источникам выше. Финальную редактуру выполнил Александр Руин, основатель habab.ru. Обновлено: 2026-05-04.