Ситуація, знайома майже кожному магазину, що виріс із «кількох замовлень на тиждень»: на сайті товар є, а на складі його немає. Клієнт оформив, оплатив, чекає — і отримує дзвінок «вибачте, позиція закінчилась». Одночасно менеджер вручну перебиває замовлення з пошти в облікову систему й час від часу помиляється в цифрі чи адресі.
Обидві проблеми мають спільну причину: сайт і облік живуть окремими життями. Інтеграція розвʼязує це не «покращенням процесу», а тим, що прибирає ручну ланку між ними. Розберемо, як це влаштовано.
Що таке облікова система в цьому контексті
Це та програма, у якій у вас лежить правда про товар і гроші: BAS (колишня 1С в українській реалізації), Dilovod, «Універсал», галузеві рішення, іноді — просто складський модуль CRM. Спільне в них одне: саме там ведуться прихід, залишки, ціни й документи.
Сайт при цьому — вітрина. Він показує те, що йому сказали показувати. Питання лише в тому, хто і як часто йому це говорить: людина раз на тиждень чи система кожні 15 хвилин.
Що синхронізувати і в який бік
Ключове рішення, яке треба ухвалити до початку робіт: для кожного типу даних визначити джерело істини — систему, чиє значення завжди головне. Без цього ви отримаєте два довідники, які суперечать один одному, і безкінечні суперечки «а чому на сайті інша ціна».
Типовий робочий розподіл:
З обліку на сайт:
- Товари й характеристики — назви, артикули, категорії, властивості.
- Ціни — включно з акційними й, за потреби, персональними для оптових клієнтів.
- Залишки — головне, заради чого все й затівається.
- Статуси замовлення — «прийнято», «комплектується», «відправлено», номер накладної.
Із сайту в облік:
- Замовлення — з позиціями, кількостями, сумою, способом доставки й оплати.
- Клієнти — контакти, історія покупок.
- Заявки (якщо це не магазин, а послуги) — але їх частіше ведуть у CRM, звʼязаній із сайтом.
Чому «вивантаження раз на добу» — погана ідея
Найпоширеніший компромісний варіант: раз на ніч файл із залишками вивантажується на сайт. Виглядає розумно й коштує дешево. На практиці це означає, що цілий робочий день сайт торгує вчорашніми залишками.
Для магазину з тисячею однакових позицій це терпимо. Для магазину, де товар унікальний або в наявності по одній-дві штуки, — це щоденні дзвінки з вибаченнями. Кожен такий дзвінок — це і втрачене замовлення, і мінус до довіри: людина, якій уже пообіцяли й скасували, назад зазвичай не повертається.
Розумний мінімум для більшості:
- Регулярна синхронізація (кожні 15–60 хвилин) для товарів, цін і залишків.
- Перевірка залишку в момент оформлення для критичних позицій — щоб система не дала оформити те, чого вже фізично немає.
- Миттєва передача замовлення в облік — у момент оформлення, а не пакетом уночі.
Як це працює технічно
Варіантів звʼязку, по суті, три.
1. Через API облікової системи. Найкращий сценарій: система має документований інтерфейс, сайт звертається до нього напряму — питає залишки, віддає замовлення. Швидко, надійно, у реальному часі. Так працює більшість сучасних хмарних систем (Dilovod, KeyCRM, частина конфігурацій BAS).
2. Через проміжний шар (обмінник). Класика для локальних 1С/BAS, які «дивляться всередину» й не мають публічного API. Між сайтом і обліком ставиться невеликий сервіс: облік вивантажує в нього дані за розкладом, сайт бере їх звідти, а замовлення накопичуються в черзі, поки облік по них не прийде. Головна перевага — сайт не «падає» разом із локальним сервером бухгалтерії й не чекає, поки той увімкнуть.
3. Через файловий обмін (XML/CSV). Найстаріший спосіб: облік кладе файл, сайт його розбирає. Працює, але це і є та сама синхронізація «раз на добу» з усіма її наслідками. Прийнятно як тимчасове рішення або для рідко змінюваного каталогу.
Для типового українського магазину на власному сайті найчастіше виходить схема облік → обмінник → сайт, плюс окремим каналом — замовлення з сайту в чергу, і звідти в облік. Це стійка конструкція: якщо одна зі сторін тимчасово недоступна, дані не губляться, а чекають у черзі.
Що зазвичай ламається (і забирає більшість часу)
Розробники зазвичай попереджають про це не одразу, тож скажемо прямо: найдорожча частина інтеграції — не код, а дані.
- Бардак у довідниках. Один і той самий товар заведений двічі з різними артикулами. Категорії названі «як склалось». Одиниці виміру — де «шт», де «штук», де порожньо.
- Немає стабільного ідентифікатора. Якщо звʼязувати товари за назвою, будь-яка правка назви в обліку створить на сайті дубль. Потрібен незмінний ключ — артикул або внутрішній код.
- Кілька складів. Що показувати на сайті: суму залишків, залишок конкретного складу, чи тільки той, з якого реально відвантажують?
- Комплекти й варіанти. Товар із розмірами й кольорами в обліку часто лежить як окремі позиції, а на сайті має бути однією карткою з вибором.
- Ціни з ПДВ і без. Класичне джерело розбіжностей між сайтом і рахунком.
Практичний висновок: перед інтеграцією варто навести лад в обліку. Це нудна робота, але вона все одно буде зроблена — питання лише в тому, зробите ви її свідомо чи виявите посеред запуску, коли на сайті зʼявиться три однакові позиції з різними цінами.
Що бізнес отримує на виході
- Реальні залишки на сайті — менше скасувань і вибачень.
- Ціни в одному місці. Змінили в обліку — змінилось скрізь, включно з товарним фідом для Google Shopping.
- Замовлення падають в облік автоматично — менеджер не перебиває їх руками й не помиляється в адресі.
- Клієнт бачить статус — а разом із ним і номер накладної Нової пошти, що знімає половину дзвінків у підтримку.
- Масштабованість. Сто замовлень на день не потребують у пʼять разів більше менеджерів.
- Документи формуються з тих самих даних — про це є окремий матеріал про автоматизацію рахунків і актів.
Скільки це коштує й скільки триває
Орієнтири для України:
- Базова інтеграція (товари, ціни, залишки на сайт; замовлення в облік): від 20 000–60 000 ₴, зазвичай 2–4 тижні.
- Складніші сценарії (кілька складів, персональні ціни, комплекти, двобічні статуси, повернення): рахуються окремо, ціна залежить від логіки, а не від кількості полів.
- Підтримка. Інтеграція — жива система: облік оновлюється, довідники змінюються. Закладіть невеликий регулярний бюджет на нагляд, як і на підтримку сайту.
Головний важіль економії — не знижка від підрядника, а чисті дані на старті й чітко описані правила обміну.
Головне
Інтеграція сайту з обліковою системою — це не «додатковий модуль», а перехід від двох паралельних реальностей до однієї. Поки залишки живуть окремо від вітрини, ви системно продаєте те, чого немає, і платите менеджерам за ручне перебивання цифр.
Ми в Obliko робимо такі звʼязки як частину системної роботи: розбираємось, що є джерелом істини, як часто мають оновлюватись дані, що робити, коли одна зі сторін недоступна, — і будуємо обмін, який переживає і оновлення обліку, і пікові дні. Напишіть, у якій системі ви ведете облік і скільки позицій у каталозі, — скажемо, що можна звʼязати напряму, а де потрібен проміжний шар.
Навіщо звʼязувати сайт з обліковою системою, якщо менеджер і так усе заводить руками?
Ручне введення працює рівно до того моменту, поки замовлень мало. Далі зʼявляються три постійні проблеми: клієнт замовляє товар, якого вже немає (бо залишки на сайті вчорашні), ціни на сайті не збігаються з прайсом, а менеджер витрачає години на перебивання замовлень із сайту в облік — і помиляється. Інтеграція не «прискорює менеджера», вона прибирає цілий клас помилок, які прямо коштують грошей і репутації.
Що саме синхронізують між сайтом і обліком?
Класичний мінімум: з обліку на сайт ідуть товари, ціни й залишки; із сайту в облік — замовлення й клієнти. Далі за потребою додають статуси замовлення (щоб клієнт бачив, що воно вже відвантажене), номери накладних Нової пошти, знижки й персональні ціни для оптовиків, повернення. Важливо одразу визначити, яка система є «джерелом істини» для кожного типу даних — інакше два довідники почнуть суперечити один одному.
Як часто мають оновлюватись залишки?
Залежить від того, як швидко у вас розходиться товар. Якщо позицій багато й вони не унікальні — вистачить синхронізації раз на 15–60 хвилин. Якщо товар штучний або дефіцитний (і продати його двічі критично) — потрібне оновлення в реальному часі: сайт перевіряє залишок у момент оформлення замовлення. Найгірший варіант — вивантаження раз на добу: воно майже гарантує продажі того, чого вже немає.
Скільки коштує інтеграція сайту з BAS чи 1С?
В Україні типова інтеграція «товари, ціни, залишки → сайт; замовлення → облік» коштує орієнтовно від 20 000–60 000 ₴ разово, залежно від того, чи є в системі готовий API, наскільки чисті довідники й скільки нестандартної логіки (кілька складів, персональні ціни, комплекти). Основний час зазвичай забирає не код, а узгодження даних: пошук дублів, приведення одиниць виміру й категорій до ладу.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.