Синхронизация магазина

С помощью этой статьи вы передадите товар и остаток из своей системы, подключите их к Application и проверите результат тем же запросом, который использует магазин.

Этот сценарий подходит для переноса старого каталога, ночной синхронизации остатков и обмена с учётной системой.

Подготовка

Подготовьте:

  • Bearer сотрудника — для запросов управления;
  • ID Application и его App Token;
  • ID склада, уже привязанного к Application;
  • актуальные значения kind_id, category_id и других справочников.

Bearer сотрудника храните только в доверенном серверном коде. В примерах он обозначен как <employee_token>.

Шаг 1. Подготовьте склад и Application

Создайте склад и привяжите его к Application в интерфейсе Gigma. На складе должна быть настроена платёжная интеграция.

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

Шаг 2. Создайте товар

POST /api/nomenclatures HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json
Accept: application/json

{
	"name": "Кофе в зёрнах, 1 кг",
	"kind_id": 2,
	"category_id": 5,
	"price": "1290.00",
	"pieces_per_pack": 6
}

В ответе сохраните nomenclature.id.

Получайте kind_id методом GET /api/nomenclature_kinds. В примере 2 означает физический товар. Не переносите справочные ID между проектами.

Для товарной витрины укажите category_id: без категории товар не попадёт в клиентский каталог. pieces_per_pack понадобится, если Application работает в оптовом режиме.

Полный контракт — создание номенклатуры.

Шаг 3. Добавьте цену и остаток

POST /api/inventories HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json
Accept: application/json

{
	"nomenclature_id": 34786,
	"warehouse_id": 7,
	"price": "1290.00",
	"quantity": 40,
	"markup": 15,
	"discount": 10
}

Одна запись остатка связывает товар с конкретным складом и задаёт доступное количество и цену.

Для массовой загрузки используйте импорт остатков. Полный контракт одной записи — создание остатка.

Шаг 4. Подключите категорию и бренд

POST /api/applications/12/categories HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json
Accept: application/json

{ "category_id": 5 }

Клиентские справочники возвращают только категории и бренды, подключённые к текущему Application.

Перед запросом сверяйте application_id: вложенные методы категорий и брендов находят объект по переданному ID без отдельной проверки проекта.

Описание методов — категории Application и бренды Application.

Шаг 5. Проверьте каталог

GET /api/counterparty/products HTTP/1.1
Host: api.gigma.ru
Token: <application_token>
Accept: application/json

Найдите созданный товар в products.data.

Если товара нет, проверьте три условия:

  1. у товара задан category_id;
  2. склад с товаром привязан к Application;
  3. свободный остаток больше нуля.

Шаг 6. Получайте заказы

GET /api/orders?order_status_id[]=1 HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Accept: application/json

Этот метод возвращает заказы для серверной синхронизации. Клиент создаёт заказ через POST /api/counterparty/orders.

Полные методы работы с заказами сотрудников находятся в разделе «Заказы и исполнение».

Готово

Товар добавлен в Gigma, остаток создан, категория подключена, а результат проверен через клиентский каталог.

Ограничения автоматизации

  • Статус заказа нельзя изменить через API обновления. PUT /api/orders/{id} принимает реквизиты заказа, но не меняет этап выполнения.
  • Удаление заказа не описано в опубликованном контракте. Не рассчитывайте на DELETE /api/orders/{id}.
  • Сверяйте ID перед изменением вложенных ресурсов. Категории, бренды и некоторые складские записи находятся по ID без отдельной проверки проекта.
  • После неизвестного результата сначала читайте состояние. Не повторяйте записывающий POST после тайм-аута, пока не проверите, был ли объект создан.

Дальнейшие шаги