Є завжди. Майже. Це модуль вашої ERP платформи, що вміє працювати з вашої CMS.
Універсальна, і тому, швидше за все, не зможе врахувати всі тонкощі вашого бізнесу.
1. Новий проект, де бізнес-процеси тільки опрацьовуються, і в них можна врахувати вимоги штатної інтеграції.
2. Проект на будь-якому етапі, якщо не порушені вимоги штатної інтеграції.
Текстовий файлик (або CSV)
Проста структура даних.
У більшості випадків ERP може вивантажити дані таким чином.
Легко сприймається людиною (інше питання - навіщо людині це потрібно).
Проста структура даних.
Щоб передати інформацію складніше «Назва - Опис - Характеристика - Ціна», доведеться сильно напружитися. Проста структура даних в одному файлі виллється в набір файлів, і це все треба буде кодувати - час, гроші, вітер.
Навіть складну структуру можна вкласти в даний формат - але буде важко.
Передаються плоскі дані, структура максимально проста.
Є підтримка даного формату в ERP. (Якщо немає, то потрібен фахівець по системі для створення такого функціоналу).
Якщо вам захочеться використовувати довідники або будь-які інші ускладнення структури даних (наприклад, колір в товарах з іконкою кольору, бренд з логотипом і т.п.) - це збільшить час і вартість розробки.
Відкритий формат, розроблений для російського ринку. Легко розширюємо. Теоретично.
Є штатною інтеграцією 1С з сайтом. Фактично - це добре документований варіант передачі комерційних даних в XML.
Доопрацювання функціоналу можлива, але краще її уникати. Інакше можна втратити можливість оновлювати платформи і модулі інтеграції.
Дрібні доопрацювання не ламають можливість апдейта систем. Хоча це все індивідуально.
Потрібно ретельно стежити за версіями формату в ERP і CMS. Наприклад, в ERP будуть необхідні дані, але CMS не зможе ці дані «зрозуміти» через різницю форматів.
Так як. формат відкритий, деякі рішення будують на ньому з власними доробками. І, хоча стверджується, наприклад, підтримка формату cml2, потрібно «вчитуватися в дрібний шрифт». Доопрацьований формат накладає свої вимоги на дані, що передаються.
Формат наворочено, з нуля писати його підтримку - серйозно упороться за часом. Незважаючи на міць - «тонкощі» можуть не враховуватися і все одно буде потрібно доопрацювання.
Формат для більшості рішень надмірний.
Є модулі для платформ беруть участь в обміні.
Якщо потрібні доопрацювання, то знадобиться програміст ERP системи.
Позаштатний обмін XML / JSON
Власна структура даних, тому в ній містяться тільки необхідні дані.
Ніколи не треба писати з нуля, тому що через XML завжди є сторонні мінімальні рішення.
Потрібно опрацювати формат даних.
Якщо формат виходить складним, варто подумати про використання СML.
СML не задовольняє вимогам і надмірний.
Складна структура даних.
Є програміст на стороні ERP системи.
Якщо вашу базу колупали і перекроювали, то ситуація нештатна. Така база буде активно чинити опір інтеграції з коробки. Щоб змусити її працювати з сайтом, доведеться потанцювати з бубном. І чим активніше, тим інтеграція буде довше і дорожче.
Межі деталізації по інтеграції не існує - в кожному новому проекті свої нюанси. То там бомбане, то там. Доводиться міняти процес розробки з урахуванням шишок і опіків. Ось як це відбувається у нас зараз.
Як будується процес
Якщо замовнику потрібна інтеграція c 1C, то про масштаб завдання нам потрібно знати якомога раніше. Тому вже на етапі продажу виникають незручні запитання на кшталт «Яка у вас версія 1С?» І «Чи займається базою який-небудь фахівець? А що він з нею робить? »
Не всякий топ-менеджер або маркетолог в курсі, що твориться з його системою. Але без цих даних дати інформацію по вартості і термінів інтеграції неможливо - вилка виходить така, що ніякої конкретики: від 8 до 80 годин на опис протоколу і від 40 до 200 годин на реалізацію інтеграції. Тому знати, з чим ми маємо справу, потрібно вже на етапі прототипу.
Ми просимо замовника разом з його фахівцем заповнити чек-лист. Це допомагає зрозуміти, чим повинні обмінюватися сайт і 1C клієнта, і в якому стані остання. Так розуміємо, наскільки все запущено, звужує терміни і вилковим вартість.
Ось так масштабно виходить. Руки бояться, так? Заспокойте їх - не потрібно робити все і відразу. Те, без чого сайт не буде сайтом, допілівать в першу чергу. А приємні, але не критичні фішки типу тих же знижок за лояльність, можна відкласти на другий етап робіт над інтеграцією.
Швидкість виконання завдань по протоколу на інтеграцію залежить від того, як швидко ворушиться фахівець замовника і допілівать систему під наші вимоги. Тому ми можемо іноді і паличкою ткнути в неповороткий бік. Заради загального блага, так би мовити.
З коробки в моїх проектах вийшло тільки один раз - на «Еко». Мегасложного технічного завдання не треба було: на стороні сайту ми допив дві функції. Плюс трохи понервувати, коли числові характеристики прийшли рядками - все-таки по ним фільтр, всі справи.
Але це швидше виняток - 1С ніхто не міняв, товари виводились як є, замовлення на сайт не поверталися. Технічне завдання на інтеграцію - часом єдиний спосіб навести порядок в складному проекті з безліччю задіяних осіб.
По-перше, це можливість чітко сказати фахівця 1С, що ми від нього чекаємо. І замовнику - чого ми чекаємо від 1Сніка. По пунктах, без можливості злитися. З контролем кожного пункту (червоний прапорець / зелений прапорець).
По-друге, це популярність і прозорість. Чи не якісь абстрактні «ну на тижні зроблю», а чіткі терміни і зафіксовані домовленості. Зідзвонюємося часто, контрольних точок багато, мовчунів на мороз :)
По-третє, це описаний протокол, до якого можна звертатися в разі спірних питань. Нюанси по ходу збірки так чи інакше все одно спливуть. Але а) це контрольовано, б) це не пекла катастрофа, ставить під загрозу весь проект ( «ми не можемо надати вам вивантаження в такому форматі, переробляйте каталог»).
Протокол на інтеграцію може розходитися в деяких моментах із загальним технічним завданням. Коли є вивантаження і розуміння, як з нею працювати, можуть відпасти якісь колишні забаганки замовника або додатися нові фішки.
Це привід менеджеру проекту знову перечитати загальне ТЗ і світлофором пофарбувати, що все-таки буде на сайті, а що реалізувати не вийде. Те ж саме зробити з прототипом, і краще - разом із замовником. Це хороший спосіб відловити всі взаємодії. Правда, возиться з прототипом - процес довгий і трохи занудний, тому користуємося їм тільки на самих хардкорних проектах.
Коли інтеграційний протокол, ТЗ і прототип готові і пофарбовані прапорцями / Текстовиделітелі, можна нарешті відповісти на найважливіше питання замовника - скільки це коштує. Складається точний кошторис, затверджується протокол робіт.
Ціна залежить від того, наскільки інтеграція була далека від штатної. Чим далі - тим дорожче.
Бітрікс і правда може в інтеграцію, і ми його любимо за це. Але часто йому потрібна допомога. Іноді - реанімація. І без фахівців вже не обійтися.