Інтеграція 1С з сайтом: синхронізація товарів, цін і замовлень

Інтеграція 1С з сайтом потрібна тоді, коли менеджер щодня вручну переносить ціни й залишки з облікової системи в адмінку, а покупці все одно замовляють товар, якого вже немає на складі. На досвіді власних проєктів із каталогами від кількох сотень до десятків тисяч позицій розбираємо, які дані мають ходити між 1С та інтернет-магазином, як часто, де обмін найчастіше ламається і скільки коштує налаштування. Усе описане стосується і BAS: принцип обміну там такий самий, відрізняються окремі налаштування конфігурації.

Які дані синхронізувати між 1С і сайтом і як часто

Перше правило: для кожного типу даних має бути одна головна система. Якщо ціну можна змінити і в 1С, і в адмінці сайту, рано чи пізно вони розійдуться, і ніхто не скаже, яка з них правильна.

Типова помилка: синхронізувати все й одразу що п'ять хвилин. Повне вивантаження товарів з 1С на сайт для каталогу на 30 000 позицій з такою частотою перевантажить сервер на звичайному хостингу: новий обмін стартуватиме раніше, ніж закінчився попередній. Правильна схема розділяє потоки: легкі й часті оновлення цін та залишків окремо, важкий обмін каталогом уночі. Друга помилка стосується контенту. Описи, фото й мета-теги здебільшого наповнюють на сайті, бо в 1С для них немає зручного інструменту. Якщо обмін під час кожного запуску перезаписує ці поля даними з 1С, робота контент-менеджера і SEO-фахівця зникає за ніч. У технічному завданні треба прямо прописати, які поля 1С заповнює лише під час створення товару і більше не чіпає.

Як влаштований обмін 1С з інтернет-магазином: три робочі схеми

Стандартний обмін через CommerceML

CommerceML — це формат XML-файлів для обміну, який підтримують типові торговельні конфігурації 1С і BAS, наприклад «Управління торгівлею» та «Комплексна автоматизація». У них є вбудований механізм обміну з сайтом: 1С формує файл каталогу і файл пропозицій із цінами та залишками, передає їх на сайт і забирає звідти нові замовлення. Плюси: на боці 1С майже не потрібне програмування, тому це найдешевший варіант. Мінуси: великі файли, обмежена гнучкість, а нестандартні реквізити (наприклад, сумісність запчастин чи окремі ціни для дилерів) доводиться доопрацьовувати з обох боків.

Обмін через API

1С публікує HTTP-сервіс або звертається до API сайту і передає лише змінені дані невеликими порціями. Залишок змінився на складі, і за хвилину він уже оновився в магазині. Ця схема потрібна за швидкого обороту товару, для оптових кабінетів і персональних цін, але вимагає програміста 1С.

Проміжний сервіс між 1С і сайтом

Між обліковою системою та магазином ставлять окремий сервіс із чергою завдань. Він приймає дані з 1С, перевіряє їх, відсіює помилки й поступово записує на сайт, маркетплейси та в B2B-портал. Такий підхід виправданий, коли каналів продажу кілька, а каталог великий: збій в одному каналі не зупиняє решту.

Інтеграція 1С з WooCommerce, OpenCart і кастомними магазинами

WooCommerce

Для каталогів до кількох тисяч товарів готових модулів обміну зазвичай вистачає. Проблеми починаються з варіативними товарами: у WooCommerce кожна варіація зберігається як окремий запис із десятками полів метаданих. Стандартний імпорт через функції WordPress на 10 000+ позиціях з розмірами й кольорами може тривати годинами. Тому для великих каталогів ми пишемо власний імпортер. Він записує дані пакетами, вимикає перерахунок кешів і службових таблиць на час обміну і запускає його один раз наприкінці. Залежно від сервера й обсягу каталогу обмін, який тривав години, після такої переробки скорочується до хвилин або кількох десятків хвилин.

OpenCart

Структура бази в OpenCart простіша, тому імпорт зазвичай іде швидше. Але опції товару тут не мають власного артикула, а кількість ведеться окремо для кожного значення опції. Комбінацію «розмір + колір» стандартний OpenCart не обліковує, тоді як у 1С кожна така характеристика має свій залишок. Без доопрацювання сайт не покаже коректно, що синій M закінчився, а червоний M є. Детальніше про цю проблему ми писали в статті про помилки магазинів із великою кількістю модифікацій товарів.

Кастомні магазини на Laravel і Next.js

Тут структуру даних проєктують одразу під облік у 1С: окремі сутності для характеристик, складів, типів цін і груп клієнтів. Це найгнучкіший варіант для каталогів на десятки тисяч позицій і оптових продажів, але й найдорожчий на старті. Якщо ви ще обираєте платформу, подивіться наше чесне порівняння WooCommerce та OpenCart.

Типові поломки обміну і як їх уникнути

Дублікати товарів і SKU

Причин зазвичай три: товари зіставляють за назвою чи артикулом, які в 1С не унікальні або час від часу редагуються; частину товарів створили на сайті вручну ще до інтеграції; базу 1С переносили на нову конфігурацію з перестворенням довідників, і внутрішні ідентифікатори номенклатури змінилися. Надійний ключ для зіставлення один: внутрішній ідентифікатор номенклатури 1С (GUID), який зберігають на сайті в окремому полі. Якщо магазин уже працює, перед першим обміном робимо одноразове зіставлення наявних товарів за артикулом і формуємо звіт про конфлікти. Так товари не дублюються, а старі URL і позиції в Google зберігаються.

Залишки на сайті не збігаються зі складом

Класична ситуація: популярного товару на складі 3 штуки, обмін відбувається раз на годину, а за цю годину надходить 5 замовлень. Інша типова причина: сайт показує сумарний залишок по всіх складах разом із браком, транзитом і товаром, уже зарезервованим під інші замовлення. Синхронізація залишків з 1С працює коректно, коли виконано три умови:

• на сайт передається вільний залишок, тобто фактичний мінус резерв, і лише з обраних складів;
• під час оформлення замовлення сайт одразу зменшує залишок у себе, не чекаючи наступного обміну;
• залишки оновлюються окремим легким обміном частіше, ніж каталог.

Для магазинів з кількома складами або точками самовивозу це окреме завдання, яке ми розбираємо на сторінці про синхронізацію складу інтернет-магазину.

Зависання на великих каталогах

Симптоми знайомі: обмін обривається з помилкою сервера, половина товарів оновилася, решта зі старими цінами, а під час наступного запуску все повторюється. Причини: один величезний XML-файл, ліміти часу й пам'яті на хостингу, повторне завантаження всіх фото під час кожного обміну. Що допомагає: передавати дані пакетами в архівах, обробляти їх у фоновій черзі, а не в межах одного запиту, вивантажувати лише змінені позиції, а фото оновлювати тільки тоді, коли змінився сам файл. З такими навантаженнями ми працювали в проєкті інтернет-магазину «Копійка»: каталог на десятки тисяч товарів і постійний обмін з 1С.

Замовлення, що не доходять до 1С

Найчастіше замовлення застрягає, коли в 1С не налаштовані відповідності способів доставки й оплати, коли товар із замовлення вже видалили з номенклатури або коли для кожного покупця створюється новий контрагент. Рішення: зіставляти клієнтів за номером телефону, вести журнал обміну і надсилати сповіщення в Telegram, якщо замовлення не потрапило в 1С, наприклад, протягом 15 хвилин.

Обмін ламається після оновлення 1С

Оновлення конфігурації може скинути налаштування вузла обміну або змінити структуру файлів. Перед оновленням робочої бази проганяйте тестовий обмін на копії. Якщо цим ніхто не займається, перший сигнал про проблему дадуть покупці.

Що підготувати в 1С до старту інтеграції

З нашого досвіду, наведення ладу в базі іноді займає більше часу, ніж сама інтеграція. Перевірте до початку робіт:

• артикули унікальні, дублі номенклатури об'єднані або позначені на вилучення;
• групи номенклатури відповідають майбутнім категоріям сайту або є таблиця відповідності;
• розміри й кольори оформлені як характеристики номенклатури, а не дописані в назву;
• визначені типи цін, які йдуть на сайт, і склади, з яких рахується залишок;
• відомі версії конфігурації та платформи 1С, є копія бази для тестів;
• є відповідальна людина з боку 1С: ваш програміст, адміністратор або компанія, яка обслуговує вашу 1С.

Якщо каталог великий і структуру груп у 1С будували під бухгалтерію, а не під покупця, її краще не переносити на сайт один до одного. Категорії на сайті проєктують окремо, а обмін лише розкладає товари за таблицею відповідності.

Як правильно поставити завдання підряднику

Фраза «потрібна інтеграція з 1С» у брифі для різних підрядників означає що завгодно: від налаштування модуля за день до тримісячного проєкту. Щоб оцінки були порівнянними, зафіксуйте в ТЗ:

1. Перелік даних і напрям обміну для кожного типу.
2. Частоту обміну окремо для каталогу, цін, залишків і замовлень.
3. Головну систему для кожного поля та список полів, які 1С не перезаписує.
4. Ключ ідентифікації товарів і правила першого зіставлення з наявним каталогом.
5. Таблицю відповідності статусів замовлень, способів оплати й доставки.
6. Що відбувається в разі помилки: журнал, сповіщення, хто реагує.
7. Хто виконує роботи на боці 1С.
8. Критерії приймання: наприклад, оновлення залишків по всьому каталогу триває не довше 10 хвилин, тестове замовлення з'являється в 1С з правильним контрагентом і доставкою.

Загальну логіку складання документа ми описали в статті як скласти технічне завдання на розробку інтернет-магазину. На етапі вибору підрядника запитайте, чи працював він з каталогом вашого розміру, як вирішує проблему дублікатів і чи є в команді програміст 1С.

Скільки коштує і скільки триває інтеграція 1С з сайтом

Діапазони нижче орієнтовні: точна сума залежить від платформи сайту, конфігурації 1С і стану даних.

Що найчастіше збільшує бюджет: з вашого боку немає програміста 1С, і роботи в конфігурації виконує підрядник; брудні дані з дублями й порожніми артикулами; сильно змінена нестандартна конфігурація; потреба підключити обмін до магазину, який уже працює, без втрати SEO-позицій. Закладайте й супровід. Після оновлень 1С, появи нового складу чи типу ціни обмін треба доналаштовувати. У Kliox бюджет і терміни фіксуються в договорі, а після запуску кожен проєкт отримує 10 годин безкоштовної підтримки: їх можна використати на доналаштування обміну в перші тижні роботи.

Часті запитання

Чи відрізняється інтеграція з BAS від інтеграції з 1С?

Принципово ні. Торговельні конфігурації BAS підтримують той самий формат обміну, а різниця зводиться до версії конфігурації та окремих налаштувань вузла обміну. Оцінка робіт приблизно однакова.

Чи підійде готовий модуль обміну?

Так, якщо каталог невеликий, без складних характеристик, а конфігурація 1С типова. На великих каталогах і з нестандартними даними модуль або не впорається з навантаженням, або його доопрацювання коштуватиме як окрема розробка.

Хто має робити доопрацювання на боці 1С?

Краще ваш програміст або компанія, яка обслуговує 1С: вони знають конфігурацію і зміни, внесені в неї раніше. Якщо такої людини немає, цю частину бере на себе підрядник, але йому знадобиться доступ до копії бази, а бюджет зросте. Головне, щоб за кожен бік обміну відповідала конкретна людина.

Чи можна підключити 1С до магазину, який уже працює?

Можна, без зупинки продажів. Спочатку налаштовуємо обмін на копії сайту й тестовій базі 1С, зіставляємо наявні товари з номенклатурою, а потім перемикаємо робочий магазин, зазвичай у години найменшого трафіку. Якщо ви плануєте інтеграцію або наявний обмін регулярно дає збої, надішліть нам опис конфігурації 1С і платформи сайту. Підкажемо, яка схема підійде, і назвемо реальні терміни. Як ми працюємо з такими проєктами, описано на сторінці про інтеграцію 1С з інтернет-магазином.