Агентские признаки

Агентские признаки нужны, когда в расчете участвует посредник: агент, комиссионер, поверенный, платежный агент, банковский платежный агент или иная платформа, принимающая деньги не только за собственный товар.

Главная ошибка — считать агентские реквизиты дополнительным текстом в чеке. Они описывают юридическую роль участников расчета и влияют на состав позиции, поставщика, предмет расчета и ответственность за чек.

Что определить перед payload

Вопрос	Что дает ответ
Кто фактический поставщик товара или услуги	Нужны supplier-реквизиты: наименование, ИНН, телефоны и другие поля.
Кто принимает деньги	Определяется агентский тип и роль платежного участника.
От чьего имени продается позиция	Выбирается агентский признак и предмет расчета.
Есть ли собственное вознаграждение агента	Оно может идти отдельной позицией с другим предметом расчета.
Можно ли смешивать товары разных поставщиков	Обычно позиции нужно разделять по поставщику и налоговой логике.

Типы агентской роли

Роль API	Когда встречается
bank_paying_agent	Банк или банковский платежный агент участвует в приеме платежа.
bank_paying_subagent	Субагент банковского платежного агента.
paying_agent	Платежный агент принимает платеж в пользу поставщика.
paying_subagent	Субагент платежного агента.
attorney	Поверенный действует по поручению.
commission_agent	Комиссионер продает товар комитента.
another	Иная посредническая схема, если она предусмотрена контрактом и ФФД.

Нельзя выбирать роль по названию, которое похоже. Сначала описывается договорная модель, затем выбирается ФФД-реквизит и конкретное значение API.

Supplier-реквизиты

Реквизит	Зачем нужен
Наименование поставщика	Показывает, чей товар или услуга продается.
ИНН поставщика	Связывает позицию с фактическим поставщиком.
Телефон поставщика	Может быть обязательным у конкретного провайдера.
Данные агента	Описывают посредника и его роль в расчете.

Практическая разница провайдеров важна: один API может принять supplier без телефона, другой потребует supplier_info.phones. Поэтому агентская схема проверяется не только по ФФД, но и API-прогоном выбранного кассового сервиса.

Пример смысловой структуры

{
  "items": [
    {
      "name": "Товар поставщика",
      "payment_method": "full_payment",
      "payment_object": "commodity",
      "agent_info": { "type": "commission_agent" },
      "supplier_info": {
        "name": "Поставщик",
        "inn": "7700000000",
        "phones": ["+79990000000"]
      }
    }
  ]
}

Это не универсальный payload для всех провайдеров. Это модель, которую нужно переложить на конкретный API: у АТОЛ, Эвотора, Ferma и Бизнес.Ру могут отличаться имена полей, типы enum и обязательность вложенных реквизитов.

Ошибки интеграции

Ошибка	Последствие
Передать товар поставщика как собственный товар агента	Чек искажает роль продавца.
Смешать товар поставщика и агентское вознаграждение в одной позиции	Неверный предмет расчета и налоговая интерпретация.
Не передать supplier-реквизиты при агентской продаже	Провайдер может отклонить чек или сформировать неполный документ.
Проверять только публичную страницу ОФД	Не все агентские реквизиты видны на витрине, нужен report/ФД.

Практический порядок

1. Описать договорную модель: поставщик, агент, покупатель, получатель денег.
2. Разделить позиции поставщика и собственное вознаграждение.
3. Выбрать значения агентского признака и предмета расчета.
4. Сверить обязательность supplier-реквизитов по ФФД 1.2.
5. Проверить контракт провайдера: имена полей, enum, обязательность телефонов и ИНН.
6. Прогнать тестовый чек и сверить registration, report, ФД и доступное отображение ОФД.