Римира

Ошибки при выгрузке в iiko

Что означают сообщения об ошибках накладных и актов и что с ними делать

Здесь разобраны сообщения, которые кабинет показывает при выгрузке документов в iiko. Часть из них Римира выдаёт сама, ещё до отправки: она проверяет документ и объясняет, чего не хватает. Часть приходит от iiko — такие сообщения показываются дословно, чтобы их можно было найти поиском и переслать в поддержку.

Найдите нужный текст в оглавлении справа или поиском по точной формулировке. Если документ уже в статусе «Ошибка», полный текст виден в его карточке — см. статусы документов.

Не указан склад в строках#

Укажите склад во всех строках (без склада: 3).

То же самое при отправке на сервер:

Укажите склад во всех строках (без склада позиций: 3).

Почему возникает. У накладной нет одного «склада документа»: она уходит в iiko одним документом, а склад берётся из каждой строки отдельно. Поэтому строка без склада делает выгрузку невозможной. Цифра в скобках — это количество незаполненных строк, а не номер строки.

Второй случай — склады выбрали на одном сервере, а документ отправляете на другой. Справочник складов свой у каждого сервера, и склад «чужого» сервера в iiko не найдётся: она ответит, что такого склада нет по идентификатору. Такой ответ Римира показывает дословно.

Что сделать.

  1. Откройте документ и заполните склад во всех строках. Быстрее всего — полем «Склад для всех строк» над таблицей: оно проставит склад сразу всем строкам.
  2. Убедитесь, что сервер iiko в документе выбран тот, который нужен: при смене сервера склады надо выбрать заново.
  3. Подробности — в статье сопоставление позиций.

Склады из разных юрлиц#

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

Почему возникает. Приходная накладная в iiko относится к одному подразделению (юрлицу). Если в строках стоят склады, принадлежащие разным подразделениям, документ создать нельзя. Римира проверяет это до отправки, чтобы не получать отказ от iiko. Если такой документ всё же уходит в iiko, она отвечает: Document department is not unique.

Что сделать.

  1. Посмотрите, какие склады перечислены в сообщении, и оставьте только склады одного юрлица.
  2. Если позиции действительно относятся к разным юрлицам, разнести их одной накладной нельзя — заведите документы отдельно в самой iiko.
  3. Проверьте, что документ отправляется на тот сервер, где эти склады «родные»: список складов зависит от выбранного сервера.

Разные счета в акте: revenueAccount#

iiko отвечает:

revenueAccount in item[N] does not match request revenueAccount

Кабинет показывает подсказку:

iiko Cloud требует один счёт на весь акт. В редакторе задайте «Счёт для всех строк».

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

Что сделать.

  1. Откройте акт и выберите общий счёт полем «Счёт для всех строк» — оно проставит его во все строки.
  2. Нажмите «Сохранить» и создайте акт заново.
  3. Если строкам действительно нужны разные счета, создайте на них отдельные акты.
  4. Про выбор счёта — в статье акт приёма услуг.

Нулевое количество в позиции акта#

iiko отвечает:

amount must be positive

Почему возникает. iiko не принимает позицию, у которой количество равно нулю или отрицательное. В УПД на услуги количество часто не заполнено вовсе.

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

Что сделать.

  1. Проверьте суммы в строках акта: строка с нулевой суммой в iiko не уедет.
  2. Если акт разносится по нескольким ресторанам, проверьте, что на нужный ресторан действительно разнесена сумма: пустая колонка означает, что сюда не уйдёт ничего.
  3. Если сообщение повторяется на документе с заполненными количествами и суммами, приложите его текст к обращению в поддержку.

Контрагент не найден в iiko#

При автоматической привязке:

Поставщик с таким ИНН не найден в iiko

Не удалось выбрать автоматически: несколько карточек этого ресторана — выберите нужную

После сохранения позиций накладной:

Товары сохранены, но поставщик (ИНН 7701234567) не найден в iiko. Нажмите «Привязать поставщика по ИНН» либо заведите этого поставщика в iiko.

При проведении уже выгруженного документа:

Поставщик не привязан.

Для акта, когда карточку выбирают на конкретный ресторан:

Карточка не найдена на этом сервере

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

Что сделать.

  1. Нажмите «Привязать поставщика по ИНН». Если карточка одна и она собственная для ресторана, она подставится сама.
  2. Если карточек несколько, выберите нужную из списка руками.
  3. Если карточки нет — заведите контрагента в самой iiko, затем нажмите «Обновить справочники iiko» и повторите привязку.
  4. Подробности — поставщик в накладной и что значит «нет в iiko».

Не выбрана номенклатура в строках#

Выберите номенклатуру iiko во всех строках (без товара: 4).

Почему возникает. У каждой строки накладной должен быть выбран товар iiko. Цифра в скобках — количество незаполненных строк. Автоматически подставляется только то, что удалось узнать по артикулу поставщика; для остальных строк товар выбирается вручную.

Что сделать.

  1. Заполните товар в каждой строке. Отдельно сохранять перед отправкой не нужно: «Отправить в iiko» сначала сохраняет правки, а потом отправляет документ.
  2. Проверка идёт по тому, что сейчас на экране. Если строка выглядит заполненной, а счётчик всё равно её считает, прокрутите таблицу и найдите строку с пустым полем товара.
  3. Если нужного товара нет в списке, заведите его в iiko и нажмите «Обновить справочники iiko».

Документ не распознан как УПД#

документ не распознан как УПД (0 позиций)

В карточке документа текст показывается так, как его записала загрузка, — с приставкой Error:.

Рядом встречаются сообщения при печати и переобработке:

в документе СБИС нет файла УПД

файл не является УПД в формате ФНС — печатная форма недоступна

нет сохранённого XML для переобработки

Почему возникает. Римира разбирает только УПД в формате ФНС. Из ЭДО она берёт лишь отгрузочные документы; счета на оплату, договоры, акты сверки и письма пропускаются ещё до скачивания вложения. Но и внутри отгрузочного документа вложение может оказаться не УПД — например, скан или произвольный файл. Тогда позиций получается ноль, и документ уходит в статус «Ошибка».

Что сделать.

  1. Откройте документ в СБИС и посмотрите, что во вложении. Если это не УПД в формате ФНС, перенести его в iiko нельзя — заведите документ в iiko вручную.
  2. Если поставщик прислал исправленный документ, загрузите его заново и работайте с новой строкой; старую можно скрыть.
  3. Какие типы документов вообще берутся — в статье загрузка документов.

Нет доступа к серверу iiko или к Cloud API#

Server API (накладные):

iiko: авторизация не удалась (401). Проверьте адрес и креды.

iiko auth: 401

iiko GET /corporation/stores: 500

Неполные креды iiko в подключении.

Cloud API (акты приёма услуг):

iiko Cloud auth: HTTP 401

Связь с iiko установлена, накладные будут выгружаться. Акты приёма услуг не готовы: Cloud API недоступен: iiko Cloud auth: HTTP 401.

Почему возникает. Накладные выгружаются через Server API вашего сервера iiko (адрес, логин, пароль), а акты приёма услуг — через iiko Cloud API (отдельный API-ключ). Это два независимых канала: один может работать, а второй нет. Ошибка 401 означает, что логин или пароль не подошли; другие коды — что сервер не ответил или ответил отказом.

Что сделать.

  1. Откройте «Подключения» → подключение iiko и нажмите «Проверить связь»: сообщение отдельно скажет про накладные и отдельно про акты.
  2. Проверьте адрес сервера и учётные данные; при смене пароля в iiko его нужно поменять и в подключении.
  3. Убедитесь, что у пользователя iiko есть право работать с документами и справочниками.
  4. Если сервер отвечает кодом 500 или не отвечает вовсе, повторите позже: это состояние самой iiko, а не настроек Римиры.
  5. Как заполняется подключение — подключение iiko.

Ключ Cloud API не задан или не выбран ресторан#

У выбранного сервера нет Cloud API-ключа или не выбран ресторан.

Не задан Cloud API-ключ подключения.

Сначала укажите Cloud API-ключ.

В проверке связи то же самое выглядит так:

Связь с iiko установлена, накладные будут выгружаться. Акты приёма услуг не готовы: не задан Cloud API-ключ.

Связь с iiko установлена, накладные будут выгружаться. Акты приёма услуг не готовы: не определён ресторан (проверьте API-ключ).

Связь с iiko установлена, накладные будут выгружаться. Акты приёма услуг не готовы: ресторан недоступен по этому API-ключу.

Почему возникает. Акт приёма услуг создаётся только через iiko Cloud API, и для этого у подключения должны быть заполнены две вещи: API-ключ и выбранный ресторан. Накладным ключ не нужен — поэтому подключение может отлично работать с накладными и не работать с актами.

Что сделать.

  1. Создайте API-ключ в своём iikoWeb: «Интеграции → API Keys».
  2. Вставьте его в поле «API-ключ iiko Cloud» на подключении iiko.
  3. Нажмите «Получить список ресторанов». Если ресторан один, он подставится сам; если несколько — выберите нужный.
  4. Нажмите «Проверить связь» и убедитесь, что про акты написано «готово».
  5. Подробнее — ключ Cloud API и ресторан.

Отдельный случай — сообщение про настройки самого сервиса:

Не заданы App ID / Client Secret приложения iiko Cloud (задайте в админке → Настройки).

Это настройка на нашей стороне, а не в вашем подключении. Напишите в поддержку — сами вы её исправить не можете.

Не нашли ответ? Напишите нам.