Інтеграція KeyCRM з BAS і 1С: як налаштувати обмін замовленнями, залишками й ТТН

Коротко

• Найчастіше KeyCRM і BAS або 1С живуть поруч: продажі, доставка й переписка з клієнтами в KeyCRM, бухгалтерія й склад в обліку. Між ними хтось переносить замовлення руками.
• Інтеграція прибирає це перенесення: замовлення йдуть з KeyCRM в облік, а товари, ціни й залишки з обліку в KeyCRM. Оплати й ТТН ходять в обидва боки.
• Головне рішення до будь-якого коду: яка система за що відповідає. Без цього дані почнуть перезаписувати одне одного.
• Найчастіше такі обміни ламаються на зіставленні товарів, дублях клієнтів, оплатах і тихих збоях.
• Бухгалтерію не чіпаємо: ПДВ, податкові накладні, M.E.Doc і зарплата лишаються в BAS. Це і швидше, і спокійніше для бухгалтера.

Навіщо з’єднувати KeyCRM з BAS або 1С

KeyCRM зручна для продажів: замовлення з сайту, Prom, Rozetka й Instagram в одному списку, ТТН із картки, чеки, переписка з клієнтом. BAS або 1С тримає регламентований облік: ПДВ, податкові накладні, звітність, зарплату. Обидві системи потрібні, і проблема не в них, а в тому, що між ними працює людина.

Як це виглядає без інтеграції:

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

Інтеграція не замінює жодну з систем. Вона робить так, щоб кожна дія робилась один раз, а друга система дізнавалась про неї сама.

Яка система за що відповідає

Це перше, що ми погоджуємо з клієнтом, ще до технічних деталей. Кожен тип даних має одну головну систему, а друга лише отримує копію. Типова схема для інтернет-магазину чи дистриб’ютора:

• Товари й ціни: головний BAS або 1С. Номенклатуру веде облік, у KeyCRM вона оновлюється сама.
• Залишки: головний облік. Після руху товару або за розкладом залишок іде в KeyCRM, а звідти на сайт і маркетплейси.
• Замовлення: народжуються в KeyCRM, бо туди приходять клієнти. В обліку з’являються як замовлення покупця або видаткова накладна, залежно від того, як працює склад.
• Клієнти: в обидва боки, але з пошуком перед створенням: за телефоном, email або ЄДРПОУ.
• Оплати: накладений платіж і оплати карткою фіксуються в KeyCRM, банківські надходження в обліку. Між ними звірка.
• ТТН і доставка: створюються в KeyCRM, номер і статус потрапляють у документ обліку, повернення теж.

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

Як технічно передаються дані

У KeyCRM є відкритий API і вебхуки: система сама повідомляє, коли створено замовлення або змінився статус. З боку BAS і 1С варіантів кілька, і вибір залежить від конфігурації та версії:

• HTTP-сервіси в конфігурації: найгнучкіший варіант, коли є доступ до розробки в базі;
• OData: стандартний інтерфейс платформи, зручний для читання довідників і документів;
• обмін файлами: коли в базу не можна втручатися, а вивантаження вже налаштоване.

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

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

Де такі інтеграції ламаються

1. Зіставлення товарів. В обліку артикул один, на сайті інший, а в KeyCRM третій. Ще гірше з наборами, варіантами розмірів і одиницями виміру: «уп.» в обліку і «шт.» на сайті. Перш ніж передати перше замовлення, ми будуємо таблицю відповідностей і перевіряємо її на реальних замовленнях.
2. Дублі клієнтів. «ТОВ Ромашка», «Ромашка ТОВ» і «Ромашка» стають трьома контрагентами. Тому новий клієнт створюється лише після пошуку за телефоном, email або ЄДРПОУ.
3. Оплати. Автоматика, яка сама розносить платежі по замовленнях, виглядає логічно. У нашому проєкті для дистриб’ютора косметики перевірка на реальних даних показала: платіж, «більший за борг», майже завжди означав, що оплату вже внесли вручну. Автоматичне рознесення тихо задвоювало б оплати. Тому гроші проводить бухгалтер, а система лише підказує.
4. Статуси. У KeyCRM може бути десяток статусів замовлення, а в BAS документ або проведений, або ні. Відповідність статусів треба погодити окремо, інакше «скасовано» в KeyCRM залишиться проведеною накладною в обліку.
5. Тихі збої. Найнебезпечніший збій той, що не кидає помилку. У європейського дистриб’ютора медтехніки система створює близько 10 замовлень на день з пошти, і частина листів зникала без жодної помилки. Відтоді кожен документ у наших обмінах обробляється окремо, а будь-яка зупинка приходить у Telegram з причиною.

Як ми запускаємо обмін

1. Схема обміну. Що й куди передається, яка система головна, що робити при розбіжності. Одна сторінка, яку розуміють і власник, і бухгалтер.
2. Копія бази. Перші тести тільки на копії BAS або 1С. Робочу базу не чіпаємо, доки все не перевірено.
3. Паралельний запуск. Обмін працює поруч із ручним процесом, і ми порівнюємо результат по кожному замовленню. Так ми робимо й зі звітами: коли дистриб’ютор косметики переходив із таблиць на панель поверх KeyCRM, нові цифри збіглися з таблицею по кожному з 184 замовлень у боргах, і лише тоді панель стала основною.
4. Щоденна звірка. Після запуску в Telegram щодня приходить лише те, що не зійшлося: замовлення без документа в обліку, різні суми, залишки, що розійшлися.
5. Сповіщення про збої. Якщо обмін зупинився, людина дізнається одразу, а не тоді, коли клієнт спитає, де його замовлення.

Якщо ви хочете перейти з 1С

Частина бізнесів поступово відходить від 1С. Найспокійніший шлях не стрибок, а гібрид: бухгалтерія лишається в BAS або іншій обліковій програмі, яку знає ваш бухгалтер, а продажі, склад і клієнти переходять у KeyCRM. Обмін між ними налаштовується так само, як описано вище, і перехід не зупиняє продажі ні на день.

Питання, які ставлять найчастіше

Інтеграція з 1С і з BAS відрізняється? Майже ні: BAS і 1С працюють на одній платформі, тож обмін будується однаково. Відрізняються конфігурації та версії, тому ми завжди дивимося на конкретну базу.

Чи треба щось міняти в бухгалтерії? Ні. ПДВ, податкові накладні, M.E.Doc і зарплата лишаються як є. Змінюється лише те, що замовлення, залишки й оплати більше не переносять руками.

У нас обмін уже є, але він ламається. Це часта історія. Розбираємо, що й коли передається, де губляться дані й чому дублюються клієнти, лагодимо і додаємо сповіщення та щоденну звірку.

Детально про те, як ми це робимо: інтеграція з BAS і 1С, впровадження KeyCRM, кейс звітів з KeyCRM для дистриб’ютора косметики. Перший дзвінок і демо безкоштовні.