Фискальный API: чеки и 54-ФЗ

Фискализация в МойСклад строится вокруг розничных документов и смены ККТ. Разработчику важно понимать, какие поля JSON API 1.2 отвечают за реквизиты чека по 54-ФЗ, как открывается и закрывается смена и где проходит граница между учётной системой и фискальным регистратором.

Как устроена фискализация в МойСклад

С точки зрения API фискальный чек рождается из розничного документа. Базовый URL сервиса — https://api.moysklad.ru/api/remap/1.2, а ключевые сущности розницы: retailstore (точка продаж), retailshift (смена ККТ), retaildemand (розничная продажа) и retailsalesreturn (возврат). Сам оттиск чека на фискальном накопителе формирует не МойСклад, а драйвер ККТ на стороне кассового приложения — API же хранит данные документа и признаки фискализации.

Схема ответственности выглядит так: приложение МойСклад Касса общается с фискальным регистратором по локальному протоколу, печатает чек и передаёт данные в ОФД, а через JSON API эти же продажи доступны для интеграций — выгрузки в 1С-Битрикс, аналитики, сверки с ОФД.

• Учётный слой — сущности retaildemand и retailshift в JSON API;
• Фискальный слой — ФН, драйвер ККТ, отправка в ОФД;
• Регуляторный слой — требования 54-ФЗ к реквизитам чека.

Работа со сменой ККТ

Ни одна розничная продажа не может быть проведена вне открытой смены. Смена — это сущность retailshift, связанная с точкой продаж retailstore, кассиром (cashier) и организацией. По 54-ФЗ длительность смены ограничена 24 часами: если смену не закрыть Z-отчётом, ФН перестанет формировать чеки.

Типичный жизненный цикл при интеграции:

1. Открыть смену — POST на коллекцию /entity/retailshift с указанием retailStore и organization;
2. Проводить продажи, ссылаясь на открытую смену через поле retailShift;
3. Закрыть смену переводом в состояние закрытия (Z-отчёт печатает касса).

Список продаж смены удобно получать фильтром: GET /entity/retaildemand?filter=retailShift=<href>. Для контроля пересчёта наличных используйте поля proceedsCash и proceedsNoCash в объекте смены.

Реквизиты чека и признаки расчёта

Розничная продажа retaildemand несёт все данные для чека. В массиве positions каждая позиция описывает товар или услугу, а на уровне документа хранятся суммы оплат. Ключевые поля оплат: cashSum (наличными), noCashSum (безналичными) и prepaymentSum (зачёт предоплаты).

По 54-ФЗ в чеке обязательны признак способа расчёта и признак предмета расчёта. В МойСклад они определяются типом номенклатуры и типом операции:

Суммы в JSON API везде передаются в копейках целым числом: цена "price": 12000 означает 120,00 ₽. Это принципиально при расчёте итога чека и НДС — округление до копейки должно совпадать с тем, что пробьёт ККТ.

Предоплата, аванс и возвраты

54-ФЗ требует пробивать чек не только на отгрузку, но и на аванс/предоплату, а затем на зачёт. В МойСклад это отражается признаком способа расчёта и суммой prepaymentSum в розничной продаже. Возврат оформляется отдельной сущностью retailsalesreturn со ссылкой на исходную продажу через поле demand.

• Полная предоплата — чек с признаком «предоплата 100%», товар отгружается позже;
• Аванс — сумма без привязки к конкретной номенклатуре;
• Зачёт предоплаты — при выдаче товара пробивается чек с признаком «полный расчёт» и заполненным prepaymentSum;
• Возврат прихода — retailsalesreturn с теми же позициями и суммами оплат.

При интеграции с сайтом на 1С-Битрикс важно не задваивать чеки: если предоплата уже пробита онлайн-кассой платёжного сервиса, повторно фискализировать её в рознице не нужно — иначе сумма в ОФД задвоится.

Сверка с ОФД и контроль ошибок

Данные, отправленные в ОФД, должны биться с учётом. Разработчику стоит предусмотреть регулярную сверку: выгружать закрытые смены и продажи через JSON API и сопоставлять с реестром чеков ОФД по номеру ФД и ФН.

Практический скелет запроса выборки продаж за период:

GET /entity/retaildemand?filter=moment>=2026-07-01 00:00:00;moment<=2026-07-16 23:59:59&limit=100

Обратите внимание: даты в API передаются в формате yyyy-MM-dd HH:mm:ss по часовому поясу аккаунта, без указания зоны. Расхождения по времени — частая причина «потерянных» чеков в сверке.

Типовые ошибки: несовпадение сумм из-за округления, попытка провести продажу в закрытой смене (ответ 412), отсутствие ставки НДС у позиции при включённом налогообложении.

Что требует 54-ФЗ от интеграции

Даже когда печать чека берёт на себя МойСклад Касса, ответственность за корректность реквизитов лежит на всей цепочке. Минимальный чек-лист соответствия для разработчика:

• у каждой позиции заполнены наименование, количество, цена и ставка НДС;
• для товаров указан признак предмета расчёта, для услуг — свой;
• маркированные товары передают код маркировки (тег 1162) — см. отдельную статью по маркировке;
• для авансов и предоплат формируются отдельные чеки с корректным признаком расчёта;
• e-mail или телефон покупателя передаётся, если чек электронный (тег 1008).

Формат фискальных данных (ФФД 1.05/1.2) определяется прошивкой ФН и настройками кассы, а не JSON API. Задача интеграции — отдать полные и валидные данные, чтобы драйвер ККТ собрал из них корректный чек.

Итог

Фискальный контур МойСклад для разработчика — это сущности retailshift, retaildemand и retailsalesreturn плюс дисциплина в реквизитах 54-ФЗ: НДС, признаки расчёта, предоплаты и суммы в копейках. Печать и отправку в ОФД выполняет касса, а API отвечает за полноту и сверяемость данных.

Мы в B2Bsite связываем розницу МойСклад с сайтами и порталами на 1С-Битрикс так, чтобы чеки не задваивались, а суммы сходились с ОФД до копейки. Если нужна надёжная интеграция кассового контура или её сопровождение — поможем спроектировать обмен и взять его на поддержку.