Интеграция 1С с Kaspi: как это устроено и на чём проекты спотыкаются
Иван Недомолков · Жарияланды: · Жаңартылды:
Если магазин на Kaspi продаёт больше 10-20 заказов в день, ручной перенос заказов в 1С перестаёт быть “неудобством” и становится статьёй расходов: менеджер тратит на это 1-2 часа ежедневно, а каждая ошибка в остатках - это отменённый заказ и минус к рейтингу магазина.
В этой статье разбираем, как интегрировать Каспи в 1С: что именно умеет API, как устроен обмен технически и - главное - на чём такие проекты спотыкаются на практике. Мы внедрили собственный модуль интеграции 1С и Kaspi более чем в 50 компаниях Казахстана, поэтому список подводных камней ниже - не теория, а статистика.
Что даёт интеграция 1С и Kaspi
Интеграция 1С с Каспи закрывает четыре потока данных между учётной системой и кабинетом продавца:
| Поток | Направление | Что происходит |
|---|---|---|
| Цены | 1С → Kaspi | Прайс уходит на площадку по расписанию, вручную его никто не правит |
| Остатки | 1С → Kaspi | Продажа в офлайн-магазине уменьшает остаток на витрине Kaspi автоматически |
| Заказы | Kaspi → 1С | Заказ появляется в 1С документом сразу после оформления покупателем |
| Статусы | 1С → Kaspi | Принят → на сборке → передан в доставку; покупатель видит актуальное состояние |
Практический эффект измеряется просто. До интеграции: менеджер утром открывает кабинет продавца, переносит заказы в 1C руками, днём кто-то обновляет остатки “когда вспомнит”. После: заказы Kaspi загружаются в 1С в течение нескольких минут после оформления, остатки на витрине отстают от учёта максимум на интервал расписания обмена.
Побочные эффекты, о которых редко думают заранее, но которые оказываются не менее ценными:
- Резервирование. Заказ с площадки резервирует товар в 1С - вы не продадите одну и ту же единицу дважды (в магазине и на Kaspi).
- Документы. Реализации и возвраты создаются автоматически; бухгалтерия не перебивает ничего руками и не находит расхождения в конце месяца.
- Скорость сборки. Заказ виден кладовщику в 1С сразу, а не после того, как менеджер проверит кабинет.
Как это устроено технически
API кабинета продавца
Kaspi предоставляет продавцам API: авторизация по токену из кабинета, методы для работы с товарами, заказами и статусами. Kaspi API 1С напрямую “из коробки” не поддерживает - нужен модуль на стороне 1С, который умеет ходить в этот API, преобразовывать данные и создавать документы.
Принципиальные моменты, которые определяют архитектуру любого решения:
- Обмен инициирует сторона 1С. Модуль по расписанию опрашивает API: забирает новые заказы, отправляет цены и остатки. Отсюда следствие: частота расписания = максимальное отставание витрины от учёта.
- Товары сопоставляются, а не создаются. На Kaspi карточка товара живёт в каталоге площадки; задача выгрузки товаров в Каспи из 1С - привязать номенклатуру 1С к карточкам и передавать по ним цену и остаток.
- Заказ проходит стадии. У заказа на Kaspi есть жизненный цикл (новый → принят → собран → передан в доставку → выдан/возврат), и 1С должна двигать его по этим стадиям через API, иначе площадка отменит заказ по таймауту.
Расписания выгрузок
Типовая схема расписаний, обкатанная на десятках внедрений:
| Задача | Интервал | Почему так |
|---|---|---|
| Загрузка новых заказов | 2-5 минут | У Kaspi есть регламент времени на принятие заказа; опоздали - отмена и штраф к рейтингу |
| Выгрузка остатков | 5-15 минут | Компромисс между актуальностью витрины и нагрузкой на базу |
| Выгрузка цен | 1-4 раза в сутки | Цены меняются реже остатков; на демпинговых категориях - чаще |
| Обновление статусов | 5-10 минут | Синхронно с процессом сборки |
Интервалы - не догма: для магазина с 5 заказами в день и для сети с 500 они будут разными. Но структура именно такая: заказы - самый частый контур, цены - самый редкий.
Резервирование и остатки
Самая частая ошибка самописных интеграций - выгрузка “свободного” остатка без учёта резервов. Правильная формула: на витрину уходит остаток − резервы − страховой буфер. Буфер (1-2 единицы на ходовые позиции) защищает от гонки: покупатель на Kaspi и кассир в магазине пробивают последнюю единицу одновременно, и без буфера один из них получает отмену.
Подводные камни: что показали 50+ внедрений
Теперь честная часть. Подключение к API - это 20 % проекта. Остальные 80 % - ниже.
1. Грязная номенклатура и сопоставление карточек
Самый дорогой этап почти каждого внедрения. Типичная картина в базе со стажем: один и тот же товар заведён 2-3 раза (“Смартфон X 128GB”, “Смартфон Х 128 Гб чёрный”, “X 128”), штрихкоды заполнены у половины позиций, артикулы поставщика перемешаны с внутренними.
Сопоставить такую номенклатуру с каталогом Kaspi автоматически нельзя - и никакой модуль это не решит. Решается это так: автоматическое сопоставление по штрихкодам и артикулам закрывает обычно 60-90 % позиций, остальное разбирается руками с ответственным со стороны заказчика. На ассортименте в 5 000 позиций это дни работы, и их надо закладывать в план, а не обнаруживать в середине проекта.
2. Несколько магазинов и складов
У компании два магазина на Kaspi (разные юрлица или разные точки) и четыре склада в 1С. Вопросы, на которые придётся ответить до старта:
- какие склады “видит” каждый магазин;
- как делить остаток одной позиции между витринами;
- куда падает заказ каждого магазина и от какого юрлица создаются документы;
- что происходит, когда товар есть на складе другого магазина.
Ни один из этих вопросов не решается “настройкой галочки” - это схема товародвижения, которую надо спроектировать. Наш модуль поддерживает несколько магазинов и складов из одной базы, но проектирование схемы - обязательный этап, и мы делаем его до подключения, а не после.
3. API площадки меняется
Kaspi развивает API: появляются новые методы, меняются форматы, ужесточаются лимиты запросов. Для работающей интеграции это означает простую вещь: модуль, купленный один раз и оставленный без сопровождения, имеет срок годности. Мы наблюдали это не раз: интеграция работала месяцами, затем площадка обновила API - и обмен встал у всех, чей модуль никто не поддерживал.
Вывод не в том, что “нужна подписка”, а в том, что при выборе решения стоит спросить подрядчика: что происходит с модулем при изменении API и сколько это стоит. Ответ “ничего, он же работает” - красный флаг.
4. “Коробочный модуль не встал”
Готовые модули из интернета рассчитаны на типовую конфигурацию. В Казахстане типовая база старше 3-5 лет - редкость: доработанные документы, изменённые проведения, отраслевые конфигурации. Сценарий, с которым к нам приходят регулярно: куплен коробочный модуль за 60-150 тысяч тенге, при установке он конфликтует с доработками, вендор коробки разводит руками (“у вас нетиповая”), локальный программист не берётся чинить чужой закрытый код.
Деньги потрачены, интеграции нет. Это не значит, что коробки плохи - на чистой типовой “Рознице” они работают. Это значит, что перед покупкой надо честно ответить на вопрос “насколько доработана моя база”, а не после.
5. Перепродажи при работе на двух и более площадках
Компания торгует на Kaspi и, например, на Halyk Market или Satu. Товар в одном экземпляре, заказы приходят с двух площадок с интервалом в минуту - обе площадки его “продали”. Если каждая интеграция живёт своей жизнью и не знает о резервах другой, перепродажи неизбежны, а это отмены и штрафы на обеих витринах.
Решение - единая точка правды по остаткам и резервам в 1С: все площадки читают один и тот же свободный остаток, любой заказ с любой площадки немедленно резервирует товар для всех остальных. Именно поэтому интеграцию нескольких маркетплейсов правильно делать как одну систему, а не как набор независимых модулей.
Варианты решения: самописная разработка, коробка, внедрение под ключ
| Критерий | Самописная | Коробочный модуль | Внедрение под ключ |
|---|---|---|---|
| Стартовая цена | ”бесплатно” (время штатного программиста) | ~35 000 - 150 000 ₸ | от ~450 000 ₸ |
| Реальный срок | 1-3 месяца, часто дольше | дни - если база типовая | 1-3 недели |
| Нетиповая конфигурация | да, но всё пишется с нуля | часто не встаёт | адаптируется |
| Сопоставление номенклатуры | ваша задача | ваша задача | этап проекта |
| Изменения API Kaspi | чинит ваш программист, когда сможет | зависит от вендора и подписки | обновления в рамках сопровождения |
| Несколько магазинов/складов | как напишете | обычно ограниченно | проектируется под схему |
| Кто отвечает за результат | штатный программист | никто (модуль ≠ внедрение) | подрядчик |
Честные оговорки к каждому варианту:
- Самописная оправдана, когда у вас сильный штатный 1С-разработчик со свободным временем и нестандартные требования, которые не закрывает ни одно готовое решение. Скрытая стоимость: этот программист теперь навсегда “владелец” интеграции - отпуск, увольнение и изменение API становятся вашими рисками.
- Коробка - рабочий вариант для типовой базы, одного магазина и ассортимента, который вы готовы сопоставить с каталогом сами. Если все три условия выполнены - не переплачивайте за внедрение.
- Под ключ имеет смысл, когда база доработана, магазинов или складов несколько, ассортимент большой или цена ошибки высока (штрафы, рейтинг, перепродажи). Вы платите не за модуль, а за то, что схема спроектирована, номенклатура сопоставлена, цикл прогнан на тестовых заказах и есть кому позвонить, когда Kaspi обновит API.
Сколько это стоит: вилка рынка
Разброс цен на рынке Казахстана легко сбивает с толку: “интеграция 1С Каспи” продаётся и за 35 000 ₸, и за 500 000+ ₸. Это не жадность дорогих и не щедрость дешёвых - это разные продукты под одним названием:
- ~35 000 - 150 000 ₸ - лицензия на коробочный модуль. Установка, сопоставление товаров, настройка схемы - ваша забота. На типовой базе с сотней позиций этого может хватить.
- 150 000 - 400 000 ₸ - модуль плюс базовая настройка. Обычно один магазин, типовая или слегка доработанная конфигурация, сопоставление номенклатуры - частично на заказчике.
- от 450 000 ₸ - внедрение под ключ (наша вилка; финальная цена - после разбора схемы торговли, до старта работ). Сюда входит проектирование схемы магазинов и складов, адаптация под доработанную конфигурацию, сопоставление номенклатуры как этап проекта, тестовый цикл и запуск с сопровождением первых недель.
Ключевая мысль, которую мы повторяем на каждом пресейле: модуль - не то же самое, что работающая интеграция. Модуль - это код. Работающая интеграция - это код плюс спроектированная схема, чистая привязка номенклатуры, настроенные расписания и понятный ответ на вопрос “что делать при сбое”. Разница в цене - это цена второй части, и именно на ней экономят те, кто потом приходит с “купили модуль, не работает”.
Подробнее о нашем решении - модуле с 50+ внедрениями на конфигурациях “Бухгалтерия”, “Управление торговлей”, “Розница”, “Комплексная автоматизация” и УПП для Казахстана - на странице интеграции 1С с Kaspi. Вокруг модуля есть и обвязка: Telegram-бот с уведомлениями о заказах, интеграция POS-терминала Kaspi, выгрузка на соседние площадки, включая Halyk Market.
Чек-лист готовности к интеграции
Пройдите по списку до разговора с любым подрядчиком - сэкономите минимум одну итерацию переговоров:
- Конфигурация и её состояние. Название, версия, дорабатывалась ли (если да - есть ли живой программист, который знает доработки).
- Номенклатура. Сколько позиций пойдёт на Kaspi; заполнены ли штрихкоды и артикулы; есть ли дубли. Честная оценка “грязности” - до старта.
- Схема торговли. Сколько магазинов на Kaspi, сколько складов, какие юрлица, кто обрабатывает заказы сейчас.
- Остатки. Ведутся ли остатки в 1С оперативно (в день продажи) - если учёт отстаёт на неделю, интеграция будет честно транслировать на витрину неверные цифры.
- Другие площадки. Торгуете ли где-то ещё или планируете - от этого зависит архитектура резервирования.
- Доступ к кабинету продавца и право получить API-токен.
- Ответственный. Один человек со стороны компании, который принимает решения по спорным карточкам и схеме - без него сопоставление номенклатуры растягивается на месяцы.
Если по пунктам 2 и 4 всё плохо - это не приговор, а просто часть объёма проекта, которую надо увидеть заранее. Хуже всего, когда её “обнаруживают” на третьей неделе внедрения.
Коротко
Интеграция 1C и Kaspi - это четыре потока данных (цены, остатки, заказы, статусы) через API кабинета продавца, и техническая часть здесь давно решена. Проекты спотыкаются не об API, а о номенклатуру, схему складов, доработанные конфигурации и отсутствие сопровождения при изменениях площадки. Выбирайте не модуль по цене, а решение под вашу схему торговли - и требуйте от подрядчика ответа на вопрос “что будет, когда Kaspi изменит API”.
