Интеграция сайта с учётной системой — не одна кнопка, а несколько отдельных обменов: товары, цены, остатки, заказы, статусы, контрагенты. Каждый включается сам по себе, стоит своих денег и ломается по-своему. Начинать разумно с одного-двух: связка «заказ уходит в учёт, статус возвращается на сайт» снимает большую часть ручной работы и собирается быстрее полного двустороннего.
Почему заказы всё равно заводят руками
Сайт работает, заказы приходят, а дальше человек открывает второе окно и перебивает их в учётную программу: фамилию, телефон, состав, сумму. На двадцати заказах в месяц это полчаса в день. На двухстах — отдельная должность и первые ошибки: не тот товар, пропущенная строка, заказ, заведённый дважды.
Второй симптом — расхождение остатков: на сайте позиция в наличии, на складе её нет. Причина общая: сайт и учёт хранят одни и те же сведения порознь, и совпадают они настолько, насколько аккуратен человек посередине.
Что вообще передаётся
«Интеграция» разбирается на части. Их обычно шесть, и каждая — самостоятельный обмен со своим расписанием и правилами.
Товары и категории. Наименование, артикул, единица, группа. Самый капризный обмен: структура групп в учёте почти никогда не совпадает с каталогом — учёт устроен для склада и бухгалтерии, каталог для покупателя.
Цены. Отдельно от товаров, потому что меняются чаще. Главный вопрос — какой тип цены выгружается и что делать с персональными ценами постоянных клиентов.
Остатки. Самый частый обмен и самый простой: артикул и число. Осложняется, когда складов несколько, а остаток на сайте один.
Заказы. Обратная сторона: состав, покупатель, адрес, способ доставки и оплаты. Ядро всей затеи — ради него интеграцию обычно и заказывают.
Статусы. Из учёта на сайт: принят, собран, отгружен, выдан, отменён. Без них покупатель звонит спросить, где заказ, и экономия съедается телефоном.
Контрагенты и оплаты. Покупатель как запись в справочнике и факт поступления денег. Самая опасная пара: здесь рождаются дубли, а оплаты часто приходят из платёжного сервиса — в обмене участвует третья сторона.
Отсюда видно, что вопрос «сколько стоит интеграция 1С с сайтом» без уточнения ответа не имеет: два обмена и шесть — разные по объёму проекты.
В какую сторону ходят данные
Односторонний и двусторонний
При одностороннем обмене данные идут в одну сторону, одна система назначена главной: учёт главный по товарам, ценам и остаткам, сайт их только показывает. Дешевле и проще в отладке — некому спорить, чья версия правильная.
При двустороннем часть данных ходит туда и обратно: заказ уходит в учёт, статус и номер документа возвращаются. Появляется вопрос одновременных изменений: менеджер поменял состав заказа в учёте, покупатель в это же время отменил его на сайте. Отсюда правило, снимающее половину будущих споров с подрядчиком: по каждой сущности назначается ровно одна главная система. Товары, цены, остатки и документы — учёт. Заявка и её движение до оплаты — CRM.
По расписанию или мгновенно
Обмен по расписанию идёт по часам: раз в час, раз в 15 минут, ночью для тяжёлых выгрузок. Мгновенный запускается событием: оформлен заказ — сразу ушёл в учёт. Мгновенный дороже не передачей, а тем, что вокруг: если учётная система в этот момент недоступна, событие нельзя потерять — нужна очередь, повторные попытки и разбор того, что не доехало. Расписание проще: следующий запуск подберёт накопившееся.
Отсюда обычный компромисс. Остатки и цены — раз в час: за час каталог не устареет настолько, чтобы это стоило денег. Заказы — сразу или раз в несколько минут, здесь задержку видит покупатель. Товары — раз в сутки.
CRM и учёт — разные вещи
Заявка и заказ живут по разным правилам, поэтому интеграция CRM-системы с сайтом — amoCRM, Битрикс24 — проектируется отдельно от обмена с учётом.
Заявка — обращение, которого может и не случиться: её можно отложить или признать нецелевой, у неё нет номенклатуры, суммы и обязательств. Заказ — документ: состав, сумма, ответственность, след в отчётности. Его нельзя тихо удалить, он уже влияет на остатки и деньги.
Типовая ошибка — попытка сделать CRM складом: в карточку сделки заводят номенклатуру, руками проставляют остатки, ведут отгрузки. Работает до первого расхождения, после которого никто не скажет, где правда. Обратная ошибка реже, но тоже дорогая — учётную систему дописывают до CRM и получают инструмент, которым не пользуются.
Разделение простое. Всё до момента «клиент согласился» — в CRM: источник, переписка, стадии, задачи. Всё после — в учёте: документ, отгрузка, оплата. На стыке передаётся немногое: выигранная сделка уходит заказом, обратно возвращается номер документа и статус оплаты. Слой до стыка разобран в статье Автоматизация продаж.
Что ломается в обменах
Самая полезная часть разговора с подрядчиком — не технологии, а этот список.
Дубли контрагентов. Один покупатель появляется в справочнике трижды: «Иванов И.», «Иванов Иван», «ИВАНОВ». Причина почти всегда одна — сопоставление идёт по имени, а имя каждый раз пишут по-разному; телефон и почта устойчивы. Лечится ключом соответствия: заранее выбранным полем, по которому система ищет существующую запись, прежде чем создать новую.
Один заказ создаётся дважды. Сеть моргнула, ответ об успешной записи не дошёл, сайт отправил заказ повторно — в учёте два одинаковых документа. Лечится собственным идентификатором заказа: принимающая сторона перед созданием проверяет, нет ли уже такого. Вопрос подрядчику прямой: что происходит при повторной отправке одного заказа.
Ручная сверка осталась. Сотрудник по-прежнему раз в день открывает два окна и сравнивает — обычно потому, что перенесли только заказы, а оплаты и отмены остались за кадром. Проверка: посчитать до старта, сколько минут в день уходит на перенос данных, и померить то же через месяц.
Остатки расходятся с реальными. Три причины: обмен идёт слишком редко; часть позиций не сопоставилась и обновляется вручную; резерв под оформленный, но не оплаченный заказ нигде не учитывается. Третья самая коварная — товар физически на складе, но фактически продан.
Отмены и возвраты не доезжают обратно. Обмен спроектировали на счастливый сценарий: создан, оплачен, отгружен. Отмена на сайт не возвращается, покупатель видит «в сборке» у заказа, которого нет. Правило: любой статус, способный измениться в учёте, должен уметь вернуться на сайт, включая отрицательные.
Ошибка происходит молча. Самый дорогой дефект — обнаруживается через недели. Нужен журнал обменов со временем запусков, количеством записей и ошибками, плюс уведомление ответственному при сбое.
Первую неделю после запуска данные проверяются руками: выборочно сверяются заказы, остатки и суммы. Расхождения вылезают на реальном потоке, а не на тестовых примерах.
Сколько занимает и от чего зависит цена
Своих публичных цен у Dodigi нет. Рыночные ориентиры — по опубликованным прайсам студий: интернет-магазин от 200 000 ₽, веб-сервис на своём коде от 2 млн ₽ и от трёх месяцев, поддержка от 2 000 ₽/час. Интеграция обычно идёт внутри такого проекта отдельной строкой.
| Что влияет | Дешевле | Дороже |
|---|---|---|
| Количество обменов | остатки и заказы | все шесть сущностей |
| Направление и частота | односторонний, раз в час | двусторонний, мгновенный, с очередью |
| Поля | типовые | нестандартные реквизиты, свои справочники |
| Справочники | артикулы уникальны | номенклатура велась годами без правил |
| Доступ к учёту | система на сервере | локальный компьютер, включаемый на день |
Недооценивают чаще всего строку про справочники. Если один товар заведён трижды с разными артикулами, а половина позиций вообще без артикулов, интеграция это не исправит — она честно перенесёт беспорядок на сайт. Порядок в номенклатуре наводит заказчик, и по времени это нередко превышает разработку обмена.
По срокам: простой односторонний обмен товарами и остатками — дни. Полноценная связка с заказами, статусами и оплатами сопоставима с запуском самого магазина, около двух месяцев, и большая часть уходит не на код, а на согласование правил и разбор справочников. Что ещё входит в магазин — в статье Интернет-магазин под ключ.
Вопросы и ответы
Что делать, если 1С стоит на локальном компьютере в офисе? Обмен через промежуточное хранилище: сайт складывает туда заказы, программа на офисном компьютере забирает их по расписанию, когда включена. Второй вариант — перенести учётную систему на сервер или в аренду. Третий — оставить как есть и мириться с тем, что заказы попадают в учёт в рабочие часы; для небольшого потока это вполне рабочий вариант.
Нужен ли постоянный интернет? Для мгновенного обмена — да, на обеих сторонах. Для обмена по расписанию достаточно связи в момент запуска: пропущенный сеанс подберётся следующим. Ещё один довод за расписание там, где офисная сеть нестабильна.
Кто чинит обмен, когда учётная система обновилась? Обычно вместе — тот, кто обслуживает учётную систему, и тот, кто писал обмен: обновление платформы или конфигурации может изменить состав полей. Следствие: обслуживание закладывается в бюджет как абонентская плата или почасовая поддержка, а обновления разумно ставить не в пятницу вечером.
Можно ли обойтись выгрузкой в файл? Да, это нормальный первый шаг: выгрузка прайса и остатков раз в сутки закрывает задачу, пока заказов немного. Ограничения приходят с объёмом — файл не возвращает статусы, не защищает от дублей и требует человека, который его загружает. Переходить на полноценный обмен стоит, когда час ручного переноса дороже разработки.
Коротко
Обмены включаются по одному, и начинать дешевле с того, что режет больше всего ручной работы: заказы в учёт и статусы обратно. До старта стоит договориться о трёх вещах — какая система главная по каждому справочнику, по какому полю сопоставляются записи и где смотреть журнал обменов.
Разобрать состав обменов под конкретный процесс — контакты.