Знакомая сцена. Звонит клиент: «я вчера заказал по вашей цене». Менеджер открывает 1С — цена там другая, выше. Кто прав, сразу и не скажешь: в учёте цену подняли ещё позавчера, а на сайте она так и висела старой. И вчера тоже. Разбираться будут час, извиняться перед клиентом, а отдать товар придётся по той цене, которую он видел и заказал.
Это не сбой программы. Это последствие решения, которое приняли на старте — и, скорее всего, не заметили, что вообще что-то решают))
А задача-то звучала просто: «пусть товары и остатки из 1С попадают на сайт, а заказы с сайта — в 1С». За этой фразой прячется десяток таких решений и принимаются они обычно молча — а всплывают через полгода, когда цены на сайте разъехались с учётом и часть заказов доехала до менеджера с неправильной ценой.
Разберу честно, где такие связки ломаются на самом деле и что стоит заложить сразу. Без конкретных клиентских случаев — рассказывать чужие цифры я не буду, а закономерности одни и те же почти везде.
Сначала: что вообще обменивается
Обмен данными почти никогда не бывает одним потоком. Обычно это несколько независимых обменов и у каждого свой тип со своим набором данных (а что технически стоит за словом «обмен» — рассказывал отдельно и «на пальцах»: что такое API простыми словами):
- номенклатура — товары, описания, характеристики, картинки; меняется редко, объём большой;
- цены — меняются чаще, объём небольшой;
- остатки — меняются постоянно, и именно из-за них обычно всё и затевается;
- заказы с сайта — идут в обратную сторону и потеря каждого стоит денег;
- статусы заказов и оплаты — обратно на сайт, чтобы клиент видел, что происходит;
- контрагенты и реквизиты — если у вас оптовые клиенты со своими условиями.
Разделять их важно, потому что требования у них разные. Остатки нужны актуальные, а номенклатуру достаточно обновлять ночью. Если сделать всё одним тяжёлым обменом «раз в час», вы получите и несвежие остатки, и лишнюю нагрузку одновременно.
Правило первое: у каждого поля есть один хозяин
Самая частая причина «интеграция ерунду творит» — не техническая. Просто никто не решил в своё время, кто главный по каждому полю обмена.
Цена: главная в 1С или на сайте (и менеджер может её поправить прямо на сайте)? Описание товара: пишет контент-менеджер на сайте или оно приезжает из учётной системы? Статус заказа: меняется (автоматически/вручную менеджером) в 1С или на сайте?
Если ответа нет, начинается перетягивание каната. Маркетолог правит описание на сайте, ночью приезжает выгрузка и затирает его обратно. Все возмущаются, разработчик добавляет исключение, потом второе, третье — и получается тот самый «костыль», который через год никто не может объяснить.
Правильно — сесть и по каждому типу данных решить: кто хозяин (он один), остальные только читают. Записать это. Дальше техника становится в разы проще.
Правило второе: частота — не «в реальном времени»
«Хотим, чтобы всё обновлялось мгновенно» — понятное желание, но обычно ненужное и всегда дорогое.
Практичнее так: остатки — часто, каждые несколько минут или по событию; цены — по расписанию, несколько раз в день; номенклатура/контрагенты — раз в сутки, ночью; заказы — сразу, потому что тут задержка стоит денег.
Проверить себя просто. Спросите: что случится, если остаток на сайте отстанет на пять минут? Обычно — ничего. А если отстанет на день? Продадите то, чего нет и будете извиняться. Или не продадите и не получите деньги сегодня за тот товар, который снова есть в продаже, но на сайте числится отсутствующим. Между этими двумя ответами и лежит нужная частота — а мгновенным делаем только то, что от этого действительно выигрывает.
Где всё ломается
Список, который я вижу очень часто, почти постоянно. Ни один пункт не про «плохого программиста» — все про решения, которые не приняли вовремя:
Нет единого ключа соответствия. Товар в 1С и товар на сайте должны опознаваться друг в друге по чему-то неизменному — обычно по внутреннему идентификатору или артикулу. Если связывать по названию, то первое же переименование породит дубль. Выглядит это буднично: в каталоге появляется вторая «Футболка белая XL» — у одной есть остаток, у другой цена, а какая из них будет продана — неизвестно. Через год каталог превращается в кашу и разбирать её приходится руками.
Обмен гоняет всё целиком. На старте, когда товаров триста, полная выгрузка проходит за секунды. На тридцати тысячах она идёт час-два и валит сайт в момент выгрузки. Примета такой связки — в компании все знают «час, когда сайт тормозит» и просто не заходят в это время. Правильно обмениваться изменениями: только тем, что поменялось с прошлого раза.
Не доставили — выбросим. Сайт отправил заказ, 1С была недоступна — и заказ пропал. Или наоборот: 1С отправила остатки, сайт не ответил, остатки не легли в базу на сайте. Обиднее всего, что потерянный заказ не выглядит как потерянный: в 1С его просто нет, а на сайте он есть и клиент его ждёт. В нормальной связке между сторонами стоит очередь: не доставили — повторим, а не выбросим.
Никто не замечает поломку. Обмен встал в пятницу, обнаружили в среду. Всё это время сайт торговал остатками недельной давности. А узнают об этом обычно не из журнала и не из уведомлений системы, а по звонку покупателя, которому продали то, чего на складе нет. Журнал обменов и уведомление о сбое — самые скучные части работы и самые окупаемые. Почему тишина обходится дороже самой поломки — разбирал в статье почему интеграция «на коленке» ломается через полгода.
1С стоит там, где её выключают. Не поверите, но до сих пор нередкая история: база на компьютере бухгалтера, который уходит в 18:00. Ночной обмен при этом бывает по настроению, а верный признак — обмен «почему-то не идёт по выходным». Если обмен важен, база должна работать постоянно и это отдельная строка расходов.
Обновили конфигурацию — обмен сломался. Особенно если в 1С есть доработки. Типовое обновление вполне может задеть механизм обмена и узнают об этом по факту. Классика жанра — обновились в конце квартала, потому что отчётность, а про обмен вспомнили в понедельник, когда заказы за выходные никуда не приехали.
Правки руками с двух сторон одновременно. Менеджер поправил заказ в 1С, оператор — на сайте. Кто победит, зависит от того, чей обмен прошёл последним. И спор в итоге выходит не про данные, а про людей: «я же поменял» — «и я поменял». Это опять к правилу про единственного хозяина данных.
Что закладывать сразу
Чтобы связка пережила годы, достаточно нескольких вещей — и все они дешевле в начале, чем потом:
- сначала штатные механизмы. Для многих пар «1С и сайт» существует типовой обмен и если он закрывает задачу, брать надо его: он переживает обновления лучше самописного;
- единый ключ соответствия для товаров и контрагентов, зафиксированный на старте;
- обмен изменениями, а не всем массивом данных;
- очередь и повторные попытки с обеих сторон;
- журнал: что, когда, в какую сторону, с каким результатом — с возможностью посмотреть своими глазами;
- уведомление о сбое живому человеку;
- тестовая база 1С, на которой проверяются обновления до того, как их накатят на рабочую;
- написанные правила: кто единственный хозяин каждого поля, что и с какой частотой обменивается. Одна страница текста, которая через год стоит дороже всего остального.
Что спросить у подрядчика
Четыре вопроса, которые сразу показывают уровень:
- По какому полю сопоставляются товары и что произойдёт при переименовании?
- Что случится с заказом, если 1С в этот момент недоступна?
- Где я увижу журнал обменов и как узнаю о сбое?
- Как связка переживёт обновление конфигурации 1С?
Если на каждый вопрос есть конкретный ответ — перед вами человек, который собирал такое не раз. Если звучат общие фразы или «да там всё просто, потом расскажу» — про сложности вы услышите позже и за отдельные деньги… Что стоит подготовить со своей стороны до этого разговора — в чек-листе подготовки к автоматизации.
Если у вас уже есть обмен и он периодически чудит или падает — чаще всего его не нужно переписывать заново, достаточно найти, какое из правил выше нарушено. Напишите, посмотрим. Обращайтесь, решим вашу задачу!